Govern the access policy lifecycle

Operating objective

Every access policy has a protected resource, business owner, technical owner, policy author, reviewer, approver, deployment path, effective version, evidence, exception process, and retirement condition. A policy change is authorized as carefully as the access it controls.

Define decision rights. The resource owner states acceptable subjects and actions. The platform owner maintains the policy system. Security defines cross-cutting requirements. No role silently owns all three.

Signals and evidence

Retain the policy request, protection need, resource and action, author, source revision, review result, automated tests, approval, deployment identity, effective time, target environments, runtime version, decision metrics, exceptions, and rollback. Connect one production decision to the exact effective policy.

Measure unmatched requests, deny and allow rates, reason codes, stale identity or context, exception use, policy age, owner status, and drift between source and runtime. A rise in denies can be a safe control or a broken rollout. Investigate the cause.

Response and recovery

1. Open a change with the resource, subject, action, context, reason, lifetime, and risk.
2. Review for default deny, least privilege, object-boundary limits, indirect privilege, and interaction with inherited policy.
3. Run positive, negative, conflict, stale-context, and failure-mode tests.
4. Obtain approval from an authorized reviewer who did not create the high-risk change.
5. Deploy to a bounded population. Observe decision and application results.
6. Promote with the same immutable version or stop and roll back.
7. Expire temporary access automatically. Review durable policy on ownership, resource, threat, or dependency change.
8. Retire the policy with the route, credential, resource, tests, and exceptions it served.

Emergency policy gets a separate short expiry, limited resource, named approver, strong evidence, and mandatory review after use. Break-glass is not an unreviewed permanent role.

Design tradeoffs and residual risk

Central policy improves consistency and can separate resource context from application owners. Distributed policy retains local detail and can drift. Reusable policy reduces duplication and increases the impact of one shared change.

Fast deployment reduces response time and increases review pressure. Staged rollout lowers blast radius and can leave versions inconsistent. State which version wins during partial rollout.

Residual risk includes incorrect requirements, compromised approvers, stale context, hidden direct routes, interaction between policy layers, and application actions outside gateway knowledge.

Pomerium boundary

Pomerium can evaluate configured route and inherited policy and provide decision evidence. Operators own policy governance, source control, review, approval, rollout, exception expiry, and application-level permissions. A Pomerium allow does not approve an application's object action.

Exercise

Take one broad production policy and move it through the full lifecycle. Add negative tests for another tenant, route, method, group, stale device, unavailable context source, and expired exception. Stage deployment and connect a real decision to the source revision.

Run a break-glass exercise. Grant one narrow emergency action for 30 minutes, use it once, verify evidence, let it expire, and prove that the same request now fails.

Evaluation checklist

• Does each policy name resource, action, owner, approver, and retirement condition?
• Can the effective production version be tied to review, tests, and approval?
• Do negative and failure-mode tests run before deployment?
• Are exceptions narrow, expiring, visible, and reviewed after use?
• Can rollback restore a known-good version without restoring revoked authority?