Split the roles so no single person can request, approve, deploy and verify a production change alone. For routine patches, a peer or system owner approves and an automated pipeline deploys. For small teams, an independent reviewer on any high-risk change is the practical minimum.
What separation of duties means here
NIST SP 800-53 describes separation of duties as identifying and documenting the duties of individuals that must be separated, and defining access authorizations to support it. Its configuration control family also asks that access restrictions for making changes to the system be defined, documented, approved and enforced, and that proposed changes be reviewed and approved with explicit consideration of security impact.
In patching terms: the person who wants the change is not the sole approver, and the approver is not the sole person with access to apply it.
A role map that works for most teams
| Step | Typical owner | Independent from |
|---|---|---|
| Identify and rank the finding | Security or platform team | Implementer |
| Prepare the fix | Developer or engineer | Approver |
| Approve the change | System owner or peer reviewer | Preparer |
| Deploy | Pipeline with scoped credentials | Preparer, where possible |
| Verify | Scanner job or second person | Deployer |
A pipeline that deploys only changes that passed review is a clean way to separate approval from deployment, because the credentials sit with the automation, not with an individual who might also approve.
Small teams
A team of three cannot staff five independent roles. Alternatives:
- Require a second person to review every change that touches production credentials or exposed services.
- Make the pipeline enforce the review, with branch protection and required approvals, so it cannot be skipped quietly.
- Log every manual production action, and review the log weekly.
- For emergencies, allow one person to act and require a second person to review within a set time.
Document the compromise in policy. Auditors accept a reasoned small-team design more readily than a pretend large-team one.
Least privilege completes the picture
Separation fails if everyone has admin rights anyway. NIST's least privilege control allows only the accesses necessary for assigned tasks. New York's financial services rule likewise asks covered entities to limit privileged accounts and their use, and to review user access privileges at least annually. Apply the same to patch tooling: deployment credentials, scanner credentials and exception approvals each deserve scoped roles.
Evidence to keep
- The role matrix and who holds each role.
- Approval records showing different people for preparation and approval.
- Branch protection or pipeline settings exports.
- A sample of changes with full trails.
- The emergency override log and its after-the-fact reviews.
Where tooling helps
Gates that block a merge or release when a finding breaks policy turn rules into controls that do not depend on memory. Safeguard policies, gates and guardrails can enforce those checks in the pipeline, and fix pull requests from autonomous remediation are off by default, with every category on Manual, so a reviewer stays in the loop.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a pull request is held until a check passes, a simple example of approval enforced by the pipeline.
Quick check
Can an engineer approve their own emergency patch?
Policy can allow it for emergencies if a second person reviews it afterward within a set time. Routine changes should not allow self approval.
Does automation count as separation?
It can, when the pipeline enforces review and holds the deployment credentials, and when changes to the pipeline itself also need review.
Sources
- NIST SP 800-53 Rev. 5 catalog, AC-5, AC-6, CM-3, CM-5
- 23 NYCRR 500.7, Access privileges and user management
Last reviewed: 19 October 2026.
