CM-5: Access Restrictions for Change

CM-5 requires you to define, document, approve, and enforce who can make system changes, and under what conditions, across both logical access (accounts, roles, pipelines) and physical access (facilities, consoles). Operationalize it by restricting change privileges to authorized roles, routing changes through an approved workflow, and retaining evidence that restrictions were enforced for real changes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• CM-5 is about controlling change power: only explicitly authorized people and paths can modify production systems. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• You must cover both logical and physical access paths that could result in a system change, not only your ticketing workflow. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Evidence matters: auditors expect to see role definitions, approvals, enforcement points, and sample change records that prove restrictions worked.

The cm-5: access restrictions for change requirement is a change control gate focused on access, not paperwork. Your objective is simple: prevent unauthorized, unapproved, or untraceable changes to systems by restricting who can change what, how changes are approved, and how restrictions are enforced. The control language is explicit that you must define and document the restrictions, get them approved, and enforce them across physical and logical access paths. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a CCO, Compliance Officer, or GRC lead, the fastest path to execution is to treat CM-5 as an access design problem with a change-management wrapper: map “change authority” to roles, implement technical enforcement (RBAC, branch protections, separation of duties in pipelines, privileged access controls, facility controls), then make approvals and evidence collection routine. CM-5 also creates clean audit boundaries for third parties: if a managed service provider can change configurations, you must be able to show that their access is restricted, approved, and monitored the same way you do internally.

This page gives requirement-level implementation guidance you can hand to IT, Security, and Engineering leads, then test as a control owner.

Regulatory text

Requirement (excerpt): “Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator meaning: you must (1) specify the access rules for making changes, (2) write them down in a controllable form (policy/standard + procedure), (3) have an authorized approver sign off on those rules, and (4) prove the rules are actually enforced in the environments and tooling where changes happen. “Access restrictions” includes both:

• Logical: admin roles, production write access, cloud console privileges, CI/CD permissions, database schema change permissions, break-glass access.
• Physical: data center access, console/KVM access, network closets, secure lab environments where firmware or device configs can be altered.

Plain-English interpretation (what CM-5 is really asking)

CM-5 expects you to control “who can change the system” with the same rigor you control “who can access the system.” If a person (or third party) can deploy code, alter infrastructure-as-code, change firewall rules, modify cloud IAM, or patch servers, they have change capability. CM-5 requires you to tightly constrain that capability, require approval paths, and prevent bypass routes.

A useful test: if an engineer can make a production-impacting change without (a) being in a defined role, (b) going through an approved mechanism, or (c) leaving traceable logs, CM-5 is not met.

Who it applies to (entity and operational context)

CM-5 is relevant wherever you align to NIST SP 800-53 Rev. 5, especially for:

• Federal information systems and programs assessed against NIST 800-53 controls. (NIST SP 800-53 Rev. 5)
• Contractor systems handling federal data, including environments run by third parties on your behalf, where change authority can alter confidentiality, integrity, or availability. (NIST SP 800-53 Rev. 5)

Operationally, it applies to:

• Production and pre-production environments (and any environment that can later be promoted to production).
• CI/CD pipelines, source control, and artifact repositories.
• Cloud management planes (AWS/Azure/GCP), SaaS admin consoles, network/security tooling.
• Data platforms where schema, permissions, or retention configurations can change.
• Facilities and hardware access paths where physical access enables system changes.

What you actually need to do (step-by-step)

1) Define “change surfaces” for your system

Create a list of where changes can occur, aligned to your architecture:

• Source code repos and protected branches
• CI/CD pipelines and deployment tooling
• Infrastructure-as-code repos and state backends
• Cloud IAM and org-level policy tooling
• OS/hypervisor management and patch tools
• Network devices, firewalls, WAF, DNS
• Databases and data warehouse admin paths
• Physical access points (if applicable)

Deliverable: Change Surface Inventory (owned by Security/IT with Engineering input).

2) Define roles and allowed change actions (RBAC matrix)

Write a matrix that answers:

• Which roles can propose a change?
• Which roles can approve a change?
• Which roles can implement a change?
• What are the constraints (time-bound, scope-bound, environment-bound)?
• What is prohibited (for example, direct production edits from a workstation)?

Keep it practical. Typical roles:

• Developer (no direct production write)
• Release manager / SRE (controlled deploy authority)
• Cloud/IAM admin (restricted, logged, often via PAM)
• Security engineer (policy changes with peer review)
• Third party operator (scoped to contract, time-bound)

Deliverable: Access Restrictions for Change Standard mapped to system components. (NIST SP 800-53 Rev. 5 OSCAL JSON)

3) Document the workflow that enforces approvals

CM-5 expects approvals, but approvals must connect to enforcement. Define:

• What qualifies as a “change” (code, config, infra, security policy, data schema)
• Required approval types (peer review, CAB, security review for sensitive systems)
• Emergency change path (break-glass) and required after-action review
• Evidence sources (tickets, pull requests, pipeline logs)

Deliverable: Change Approval Procedure that maps each change type to its required approvals. (NIST SP 800-53 Rev. 5 OSCAL JSON)

4) Implement technical enforcement (the control cannot be only a policy)

Focus on controls that prevent bypass:

• Source control protections: protected branches, mandatory reviews, signed commits where appropriate, restricted merge rights.
• CI/CD permissions: only the pipeline service account deploys; humans do not deploy from laptops; restrict who can edit pipeline definitions.
• PAM for privileged changes: require privileged sessions for admin consoles; time-bound elevation; record sessions where feasible.
• Cloud policy guardrails: deny policies for risky actions, approval gates for high-impact changes, separation of duties between IAM and deployment.
• Configuration management: standard tooling for patching and config drift detection, plus restricted admin permissions.
• Physical controls: badge access lists, visitor logs, escorted access, locked racks/rooms for change-capable equipment.

Deliverable: Enforcement Points Map that shows where restrictions are technically implemented.

5) Get the restrictions approved by an accountable authority

Approval should be explicit and durable:

• System owner, ISSO/ISO, or security leadership signs the standard/procedure.
• If your governance model uses a CAB, record CAB approval for the standard, not just individual changes.

Deliverable: Approval record (document version + approver + date) for the CM-5 standard/procedure. (NIST SP 800-53 Rev. 5 OSCAL JSON)

6) Operate, test, and collect recurring evidence

Build a lightweight operating rhythm:

• Periodic access review for change-capable roles (who has deploy, admin, merge rights).
• Sample-based verification: pick recent production changes and confirm approvals + authorized implementer + logs.
• Monitor exceptions: emergency access, failed approvals, direct console edits.

Deliverable: CM-5 evidence packet refreshed on a recurring schedule.

7) Extend to third parties (don’t let the contract be the control)

If a third party can make changes (managed hosting, MSP, SaaS configuration admin):

• Contractually require your approval workflow and logging.
• Require named accounts (no shared accounts), scoped privileges, and timely removal.
• Collect evidence from them: change tickets, access logs, approval records.

Daydream can help here by turning CM-5 into a repeatable requirement page tied to control owners, procedures, and a recurring evidence checklist, so internal teams and third parties produce consistent artifacts without re-litigating expectations each audit cycle.

Required evidence and artifacts to retain

Use this as your audit-ready checklist:

• CM-5 standard/policy defining physical and logical change access restrictions. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Change approval procedure mapping change types to approvals. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Role-to-permission matrix for change-capable systems (RBAC table).
• Tool configurations/screenshots or exports showing enforcement:
  • Repo branch protection settings
  • CI/CD permission model and deploy-only service accounts
  • PAM configuration for privileged roles
  • Cloud IAM role assignments for admin/change actions
• Sample change records (tickets/PRs/pipeline runs) that demonstrate:
  • Requestor and implementer were authorized
  • Required approvals occurred
  • Logs exist showing what changed and by whom
• Access reviews for privileged/change roles, plus remediation records.
• Exception handling records for emergency changes (approval after the fact, documented justification).
• Third party evidence where applicable: access lists, approvals, and logs for their change activity.

Common exam/audit questions and hangups

Auditors and assessors commonly probe:

• “Show me how you prevent a developer from changing production directly.”
• “Which roles can approve changes, and where is that documented?”
• “How do you enforce restrictions in the cloud console and not just in Git?”
• “What happens during an emergency? Who can bypass controls and how is it reviewed?”
• “How do you control third party change access and remove it when work ends?”
• “Provide a sample of changes and walk through request, approval, implementation, and evidence.”

Hangups to anticipate:

• Inconsistent definitions of “change” across teams.
• Multiple tooling paths that can modify production (GitOps plus console edits).
• Shared admin accounts, especially for third parties or legacy platforms.

Frequent implementation mistakes (and how to avoid them)

1. Policy-only CM-5

• Fix: document the rule, then implement enforcement in the tools where changes happen (repo protections, PAM, IAM guardrails).

2. Forgetting non-code changes

• Fix: include IAM, network, security tooling, data schema, and SaaS admin settings in your change surface inventory.

3. Emergency access becomes the normal path

• Fix: tightly control break-glass, require documented justification, and review each event with corrective actions.

4. Third party access is out of band

• Fix: require named accounts, scoped roles, your approval model, and evidence delivery as part of the operational process.

5. No evidence packet

• Fix: define recurring artifacts up front (exports, screenshots, sample changes) and assign an owner for monthly/quarterly collection.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CM-5. Practically, CM-5 failures translate into integrity and availability incidents: unauthorized changes, misconfigurations, and unapproved access paths that bypass peer review and security checks. CM-5 also affects incident response credibility; if you cannot prove who changed what and under what authority, containment and root cause analysis slow down, and audit findings tend to expand beyond change management into access control and monitoring.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign a CM-5 control owner and backups.
• Build the change surface inventory for the system.
• Draft the “Access Restrictions for Change” standard and RBAC matrix.
• Identify the highest-risk bypass paths (direct console edits, shared admin accounts, unrestricted deploy keys).

By 60 days (implement and enforce)

• Turn on or tighten branch protections and peer review requirements.
• Restrict production deploy to controlled identities (pipeline/service accounts) and limit who can modify pipelines.
• Implement privileged access controls for admin change paths (cloud console, OS admin, network devices).
• Publish and train the change approval procedure for common change types.
• Put third party change access under the same RBAC and approval expectations.

By 90 days (evidence and audit readiness)

• Run an access review for all change-capable roles and remediate exceptions.
• Collect a sample set of recent changes and assemble an evidence packet.
• Test the emergency change process end-to-end and document the after-action review pattern.
• Add CM-5 checks to your internal audit or continuous control monitoring plan.

Frequently Asked Questions

Does CM-5 require a Change Advisory Board (CAB)?

CM-5 requires defined, documented, approved, and enforced restrictions and approvals for changes, but it does not mandate a CAB by name. If you use a CAB, make it part of the documented approval workflow and ensure the approvals connect to enforcement points. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Are pull request reviews enough to satisfy CM-5?

PR reviews help, but CM-5 also expects you to restrict who can actually deploy and who can change infrastructure, IAM, and security configurations. Cover console access, pipeline permissions, and privileged roles, not only code review.

How do we handle emergency (break-glass) changes without failing CM-5?

Document a specific emergency path with tight eligibility, logging, and required after-action approval and review. Then keep evidence of each emergency event and the follow-up remediation.

What evidence is most persuasive in an assessment?

Assessors respond well to a tight chain: documented role restrictions, tool configurations that enforce them, and a walk-through of recent changes showing the authorized actor and recorded approvals. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Do physical access restrictions matter if we are fully cloud-hosted?

If your system has no physical change surface under your control, document that rationale and focus on logical access controls. If you do have offices, labs, or hardware that can affect the system, treat those areas as in-scope for CM-5. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How should we apply CM-5 to third parties that operate parts of our environment?

Require scoped, named access; align them to your change approval workflow; and collect logs and change records as deliverables. Treat their admin paths as part of your change surface inventory.