Overview
Use this checklist whenever identity, access, or endpoint policy is proposed as a versioned diff. Work through it before opening the change, during review, before merge, and after rollout. Scale the depth of review and monitoring to the change's risk, but do not bypass ownership, independent approval, validation, or evidence.
Before you open the change
- Keep the change scoped to one clear purpose. Split unrelated fixes into separate diffs so reviewers can evaluate each change independently.
- Keep the diff small enough for a reviewer to examine closely, including generated policy output and affected dependencies.
- Explain why the change is needed, what outcome is expected, and which users, devices, workloads, resources, environments, and policy owners are in scope.
- Assign an owner, risk classification, and linked change record or issue. Record any deadline, dependency, or operational constraint.
- Compare the proposed change with the current declared and effective policy, not with memory or an outdated export.
- For temporary access or exceptions, encode a machine-enforced expiration with an exact date, time, and time zone. Assign an owner to any required follow-up review.
During review
- Effective change. Verify the resulting permission or posture delta, not only the edited lines. Confirm what becomes allowed, denied, required, exempted, or inherited.
- Scope and least privilege. Confirm the change is neither broader nor narrower than intended and does not create unnecessary privilege, toxic combinations, or a separation-of-duties conflict.
- Blast radius. Quantify the affected identities, groups, devices, applications, workloads, resources, and environments. Investigate any difference from the expected population.
- Dependencies and conflicts. Check group nesting, inherited roles, precedence, overlapping endpoint profiles, recent changes, and pending changes that could amplify or silently undo the proposal.
- Duration. Confirm whether the change should be permanent. Verify that temporary grants and exceptions expire automatically rather than relying only on a reminder.
- Recovery. Define a tested recovery path appropriate to the risk: revert, roll forward, pause enforcement, isolate the target, or use an approved emergency procedure. State the signals and authority required to invoke it.
- Break-glass access. If emergency access is affected, confirm the change is intentional, verify that an independent recovery path remains available, and test it through the organization's approved procedure.
- Compliance mapping. If the change implements or affects a tracked control, link the relevant requirement and identify the evidence this change must retain.
- Independent ownership review. Require approval from someone other than the author and from the responsible policy or system owner when the change affects their control boundary.
Automated validation
- Validate policy syntax, schema, references, types, and required fields. Treat warnings that can change enforcement as failures.
- Run tests for intended allows and expected denials, including boundary conditions, precedence, inheritance, expiration, and fail-closed behavior.
- Fail the check if no policy tests are discovered or if the generated policy output differs from the artifact reviewed.
- Generate the effective policy or permission delta in a form the reviewer can inspect. Flag unexpected additions, removals, exemptions, and target-count changes.
- Run required checks against the exact revision awaiting approval and repeat them when the diff, dependency set, or target baseline changes.
Before merge and rollout
- Validate the change in a representative staging environment, simulation, test account, or canary group where feasible. Include both expected success and expected denial scenarios.
- Define rollout rings, success criteria, abort criteria, monitoring signals, and the person authorized to pause or recover the deployment.
- Use repository rules that require pull-request review, passing status checks, and policy-owner approval where appropriate. Prevent direct pushes and unreviewed bypasses to the protected branch.
- Bind approval to the exact diff. Dismiss or repeat approval when a later commit, dependency change, or conflict resolution changes what will merge.
- Confirm that the deployable artifact is derived from the reviewed revision and that the production deployment record can identify that revision.
- Notify the help desk, affected teams, security, and service owners at the point defined in the rollout plan. If merge deploys automatically, complete required communication before merge.
After rollout
- Record the deployed revision, artifact, environment, actor or automation identity, start and completion times, target population, and deployment result.
- Verify effective state on representative targets. Test that intended access works, intended denials remain enforced, and unrelated controls have not changed.
- Monitor the defined success, failure, and recovery signals for a period appropriate to the change's risk and usage frequency. Do not rely on a fixed monitoring window for every policy.
- For staged rollout, compare canary results with the acceptance and abort criteria before expanding to the next ring.
- Confirm continuous reconciliation is active where supported. Otherwise, schedule a named owner and verification cadence to detect drift from the approved state.
- Attach validation, approval, deployment, observed-state, exception, and recovery evidence to the change record before closing it.
Worked example
Proposed change: add contractor-jane to finance-readonly until 2026-10-31T23:59:59-04:00.
Before opening, the author limits the change to one identity and one group, records the business reason and owner, links the contractor engagement, and encodes the expiration in policy. During review, the reviewer inspects the effective permissions inherited through finance-readonly, confirms that the role cannot write or export restricted data, verifies the target count, and checks for overlapping changes.
Automated checks validate the policy and test both permitted report access and denied write operations. Before merge, a representative test identity confirms the expected behavior, required checks and policy-owner approval are attached to the latest revision, and the help desk receives the rollout notice.
After rollout, the deployment record identifies the approved revision and target. The owner verifies Jane's effective access and denied operations, monitors the defined signals, and confirms that reconciliation will remove or flag the grant if it remains active after the encoded expiration.
Common failure modes
- Unscoped change. A broad role or group is changed when a specific identity, resource, action, or device class would meet the requirement.
- Missing expiration. Temporary access becomes permanent because removal depends on a reminder or follow-up ticket.
- Misleading diff. The edited lines look safe, but inheritance, precedence, or generated output produces a broader effective change.
- Untested denial. The happy path works, but nobody verifies that prohibited actions remain blocked.
- Stale approval. A later commit or conflict resolution changes the diff after the reviewer approved it.
- Unsafe recovery. A blind revert restores excessive access or removes a newer protective change.
- Incomplete evidence. The repository shows approval but cannot prove which revision reached production or whether the effective state converged.
How to use this resource
Turn the applicable checks into a pull-request template and enforce objective gates through repository rules and continuous integration. Define risk tiers so routine changes remain efficient while high-impact identity, endpoint, privileged-access, and break-glass changes receive stronger review, testing, rollout, and evidence requirements.
Related resources
- See the GitOps for Endpoint Compliance pillar guide for the full review, enforcement, and reconciliation model.
- See Reviewing Access Policy Changes Like Code for a closer look at effective permission review.