Policy Lifecycle and Governance¶
Industrial access policy must remain manageable after initial creation. L2Proxy keeps individual policies, complete Policy Profiles, and running service profiles as distinct, traceable objects.
Managed lifecycle¶
Operational requirement
↓
Policy composition
↓
Engineering review
↓
Policy Profile assembly and save
↓
Service assignment
↓
Commissioning and active enforcement
↓
Controlled revision or retirement

Figure — Lifecycle and governance continue through monitor, review, and refine stages.
Management capabilities¶
| Managed object | Available management purpose |
|---|---|
| Access Policy | Create, inspect, search, edit, enable or disable, reorder, revise, and delete |
| Policy membership | Select which policies belong to a profile and control their evaluation order |
| Policy Profile | Create, preview, save, inspect, update, regenerate, customize, and remove |
| Final rules file | Produce and maintain the complete service-ready policy file in the required L2Proxy location |
Service assignment, activation, and instance operation have their own controlled lifecycle under Standalone Deployment and Operations.
Separation of change¶
Editing an Access Policy does not silently rewrite every saved Policy Profile. Editing a Policy Profile does not silently change which running service uses it. These boundaries allow each change to be reviewed at the correct level:
- policy intent and industrial logic;
- membership and order of the complete policy set;
- assignment to a specific protected user path;
- activation of the independent enforcement service.
Recommended customer controls¶
| Control record | Recommended content |
|---|---|
| Access request | User, purpose, equipment, required operations, and duration |
| Engineering approval | Point map, commands, ranges, prerequisites, and exception handling |
| Policy review | Policy revision, outcome, logging, and evaluation order |
| Profile review | Complete member list, order, and final profile revision |
| Service assignment | User access path, selected Policy Profile, and responsible owner |
| Commissioning evidence | Representative permitted, denied, and abnormal cases |
| Change record | Reason, approver, effective time, and rollback decision |
Suggested responsibilities¶
| Role | Primary responsibility |
|---|---|
| Operations | Confirm that the access matches the intended task and operating procedure |
| Protection and control engineering | Confirm equipment states, sequences, ranges, and prerequisites |
| OT security | Confirm least privilege, event evidence, and enforcement outcome |
| Service owner | Confirm the user, purpose, and ongoing business need |
| Change authority | Approve profile assignment, activation, revision, or retirement |
Review triggers¶
A policy should be reviewed when:
- a vendor contract or maintenance task ends;
- a user's role changes;
- equipment or point mapping changes;
- operating limits or switching procedures are revised;
- a new command or protocol operation is introduced;
- an incident reveals unexpected access or behavior;
- the associated Policy Profile or service is reassigned.
Industrial boundary¶
Policy enforcement supplements—rather than replaces—plant procedures, relay protection, process interlocks, safety instrumented functions, and operator authority. Its purpose is to ensure that observed network activity remains aligned with the access and industrial operations the customer explicitly approved.
Return to Industrial Policy Management.