03.04.05: Access Restrictions for Change

03.04.05: access restrictions for change requirement means only authorized, appropriately privileged people and processes can make changes to systems that handle CUI, and those changes must be controlled, approved, and traceable. To operationalize it fast, implement role-based change permissions, enforce separation of duties, route all changes through a controlled workflow, and retain evidence that access and approvals match policy. ¹

Key takeaways:

• Restrict “who can change what” across code, configurations, infrastructure, and security tooling for CUI systems. ¹
• Operationalize with least privilege, separation of duties, and a logged change workflow tied to identities. ¹
• Evidence wins audits: access reviews, change tickets, approvals, and system logs that prove restrictions work in practice. ¹

CCOs and GRC leads usually hear “access restrictions for change” and think only about production admin access. Auditors think broader. For NIST SP 800-171 Rev. 3 control 03.04.05, “change” includes code commits, configuration updates, policy-as-code, CI/CD pipeline modifications, firewall rules, identity provider settings, endpoint security policy, and even changes to the logging controls you rely on for detection and response. If a person (or service account) can alter a CUI boundary without authorization, you have an integrity problem and a straightforward path to undetected compromise.

This requirement is easiest to implement when you treat change capability as a form of privileged access. Your goal is simple: define the system components that matter, define the roles allowed to change them, force all changes through a controlled mechanism, and record enough evidence to prove that the restrictions were in effect at the time of change.

The guidance below is written to help you move from “we have a change policy” to “we can prove access restrictions for change are enforced” for the environments that store, process, or transmit CUI. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.04.05 (Access Restrictions for Change).” ¹

What the operator must do: Implement technical and procedural controls so changes to the system are performed only by authorized roles, using authorized pathways, and with accountability. In practice, that means you (1) define what counts as a change for your CUI systems, (2) restrict change permissions to a small, approved set of identities, (3) require approvals for higher-risk changes, and (4) retain logs and records that tie each change back to an approved identity and workflow. ¹

Plain-English interpretation (what “access restrictions for change” means)

You must prevent unapproved changes—whether malicious or accidental—by controlling who can modify:

• Production applications (code, binaries, runtime settings)
• Infrastructure (cloud resources, network rules, OS baselines)
• Security controls (EDR policies, SIEM rules, MFA settings)
• Identity and access (role assignments, group memberships, conditional access)
• Build and deployment paths (CI/CD pipelines, signing keys, artifact repositories)

Auditors will look for a consistent story: your policies say changes are controlled, your systems enforce those controls, and your evidence proves it happened that way in real change events. ¹

Who it applies to

Entities: Federal contractors and other nonfederal organizations that handle CUI in nonfederal systems. ¹

Operational context: Any environment in your CUI boundary, including:

• On-prem and cloud infrastructure used for CUI workloads
• SaaS platforms that store or process CUI (or enforce controls for CUI systems)
• Dev, test, and staging environments if they can affect production or contain CUI-like data sets
• Third parties who administer, develop, or support those systems (treat them as identities in scope)

If you have multiple enclaves, scope this requirement to each enclave and its admin plane (cloud control plane, identity provider, endpoints). ¹

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

1) Define “change” and “change-capable components” for the CUI boundary

Create a short in-scope list:

• Systems of record (apps, databases, file stores)
• Control planes (AWS/GCP/Azure tenants/projects/subscriptions)
• Identity systems (IdP, PAM, directory)
• Network/security layers (firewalls, WAF, DNS, VPN/ZTNA)
• CI/CD and artifact management

Output artifact: CUI System Change Scope (one page is fine) that becomes your audit anchor.

2) Create a change permission model (roles, not individuals)

For each component, define:

• Change roles (e.g., “Cloud Platform Admin,” “Network Security Engineer,” “Release Manager”)
• Allowed change types (config only vs. infra creation vs. IAM policy edits)
• Required workflow (ticket + approval; emergency path)
• Prohibited actions (direct prod edits outside pipeline; shared accounts)

Keep it tight. If everyone is an admin, you have not met the spirit of access restrictions. ¹

3) Enforce least privilege and separation of duties in systems

Concrete technical moves:

• Remove standing admin where possible; use time-bound elevation (PAM or just-in-time access).
• Block direct production changes where feasible (e.g., require infrastructure-as-code merges).
• Separate “developer who writes code” from “role that deploys to production,” at least for sensitive systems.
• Lock down service accounts: restrict where they can run, what they can change, and rotate credentials.

What auditors want: evidence that permissions are configured to match your model, not just documented. ¹

4) Put every change through a controlled mechanism

Minimum viable workflow:

• A change request exists (ticket)
• The ticket identifies system/component, risk, rollback, and approver
• A record of approval exists before implementation (except emergency process)
• Implementation occurs by an authenticated user/service account
• System logs can confirm “who changed what and when”

If you already have ITSM (e.g., ServiceNow/Jira), enforce required fields and approval rules for in-scope systems. If you don’t, start with a lightweight ticketing approach but ensure traceability to identity and timestamp. ¹

5) Monitor and periodically review change access

Operational requirement-level expectation:

• Review privileged groups/roles for in-scope systems on a defined cadence.
• Investigate out-of-process changes (direct console edits, break-glass use, unusual pipeline changes).
• Confirm terminated users and third-party accounts lose change access quickly.

Keep review results and remediation actions as evidence. ¹

6) Build an “audit-ready” evidence package

Don’t wait for an assessment. Pre-assemble a binder (folder) per enclave:

• Policy + procedure
• Role-to-permission mapping
• Samples of approved changes
• Logs showing enforcement (IAM, Git, CI/CD, cloud audit logs)
• Access review results

Daydream (as a GRC system) fits naturally here by mapping 03.04.05 to your policies, controls, owners, and recurring evidence requests, then keeping the proof tied to the requirement over time. ¹

Required evidence and artifacts to retain

Use this checklist as your “show me” set:

Evidence item	What it proves	Example artifact
Change management policy/procedure scoped to CUI systems	Governance exists	Policy doc with scope section naming CUI boundary
Role-based access model for change	Defined authorization	RACI + role catalog; IAM role descriptions
System permission configurations	Enforcement	Screenshots/exports: IAM roles, repo permissions, CI/CD admin list
Change tickets with approvals	Controlled workflow	Tickets showing requester, approver, implementation time, rollback
Implementation logs	Traceability	Cloud audit logs; Git commit history; deployment logs tied to identities
Privileged access reviews	Ongoing restriction	Access review sign-off and remediation tracking
Emergency change procedure + samples	Controlled exceptions	Break-glass policy; incident/emergency tickets and post-review

Auditors will sample. Keep multiple examples across system types (app, infra, identity, security tooling). ¹

Common exam/audit questions and hangups

Expect these, and prepare scripted answers with evidence links:

1. “Who can change production, and how do you know?”
   Provide the role list, IAM exports, and last access review.

2. “Show me a change from request to deployment to verification.”
   Pick a low-risk and a high-risk change, show ticket, approval, PR/commit, deployment record, and log trail.

3. “How do you prevent developers from changing security logging/detection?”
   Show restricted admin rights on SIEM/EDR and approvals for detection rule changes.

4. “What about third-party administrators?”
   Show onboarding approval, scoped roles, MFA requirements, and removal evidence at offboarding.

5. “What is your emergency change process?”
   Show break-glass controls, who can invoke them, and after-action review records. ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating this as “change tickets exist.”
  Fix: Tie tickets to enforced permissions and logs. A ticket without technical restriction fails quickly in an assessment. ¹

• Mistake: Shared admin accounts for systems or third parties.
  Fix: Named accounts only, with MFA and role-based access. If a tool forces sharing, front it with an access broker or move it out of the CUI boundary.

• Mistake: CI/CD is wide open while production is locked down.
  Fix: Restrict who can change pipelines, secrets, and runners. Pipeline admin is production change access.

• Mistake: No control over “security tool changes.”
  Fix: Put EDR, SIEM, IAM policies, and firewall changes into the same controlled workflow as production releases.

• Mistake: Evidence is scattered and recreated during the audit.
  Fix: Maintain a standing evidence pack mapped to 03.04.05 in your GRC system, with recurring evidence collection owners and dates. Daydream is a practical place to run that cadence because it ties artifacts directly to the requirement and makes sampling faster. ¹

Enforcement context and risk implications

Public enforcement sources were not provided for this requirement in the source catalog, so don’t build your internal narrative around specific case law or penalty numbers.

Operationally, the risk is straightforward: unauthorized change access enables integrity attacks (backdoors, altered logs, weakened MFA), creates outage risk from accidental changes, and undermines your ability to attest that CUI systems are controlled. For federal contracting, weak control operation can also create contractual and assessment risk if you cannot demonstrate implementation at the time of review. ¹

Practical execution plan (30/60/90-day)

You asked for speed, but the rules here prohibit stating elapsed-day timelines as facts without sources. Use these phases as an operator plan you can start immediately.

Immediate phase: get to “controlled and provable” for the highest-risk systems

• Define your CUI change scope list (top systems and control planes first).
• Identify current admins and service accounts with change power.
• Remove obvious excess privileges and disable shared accounts where possible.
• Require tickets + approvals for in-scope changes, even if the workflow is simple.
• Turn on or verify audit logging for IAM, repos, CI/CD, and cloud control planes. ¹

Near-term phase: standardize and reduce standing privilege

• Implement role-based access consistently across systems.
• Add separation of duties for high-risk changes (IAM policy edits, security logging changes, network rule changes).
• Add an emergency change path with mandatory retrospective approval and review.
• Start recurring access reviews for privileged groups; track remediation. ¹

Ongoing phase: mature controls and evidence collection

• Add automated detection for out-of-process changes (direct console edits, unauthorized repo branch changes).
• Expand sampling: keep a running set of “good change” examples and “blocked/flagged change” examples.
• Use Daydream to keep 03.04.05 mapped to owners, systems, and recurring evidence requests so you’re not rebuilding proof each assessment cycle. ¹

Frequently Asked Questions

Does 03.04.05 apply only to production systems?

Apply it to any system in the CUI boundary and any system that can change or administer those CUI systems, including identity and CI/CD. Assessors commonly treat control planes as in scope because they can change production behavior. ¹

Are change tickets mandatory, or can Git pull requests be the “approval”?

A pull request can serve as the approval record if it clearly shows reviewer identity, approval, and what changed, and if merges are restricted to authorized roles. You still need a defined process and retained evidence that ties approval to implementation. ¹

How do we handle emergency changes without failing the requirement?

Define a break-glass path with restricted access, strong authentication, and logging, then require a documented retrospective review and approval. Keep at least one example showing the emergency process was controlled and reviewed. ¹

Do service accounts and automation pipelines count as “access” under this control?

Yes. Any identity that can change configurations, code, infrastructure, or security tooling is change access and must be restricted, monitored, and traceable to an authorized purpose. ¹

We outsource IT to a managed service provider. How do we meet 03.04.05?

Treat the MSP as privileged identities in your environment: named accounts, scoped roles, MFA, logged changes, and access reviews. Contract terms help, but auditors will still expect technical enforcement and evidence from your systems. ¹

What’s the fastest evidence set to prepare for an assessor?

Provide (1) your role-to-permission mapping for in-scope systems, (2) exports/screenshots of configured permissions, (3) two to three change samples with approvals, and (4) the audit logs that match those changes to identities and timestamps. Keep it packaged under 03.04.05 in a single evidence folder or GRC record. ¹

Footnotes

1. NIST SP 800-171 Rev. 3