Access Restrictions for Change

Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.4.5.Source

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

1. [a]

   physical access restrictions associated with changes to the system are defined;

   1 example covers this

2. [b]

   physical access restrictions associated with changes to the system are documented;

   1 example covers this

3. [c]

   physical access restrictions associated with changes to the system are approved;

   No example covers this objective yet. Submit your own example.

4. [d]

   physical access restrictions associated with changes to the system are enforced;

   No example covers this objective yet. Submit your own example.

5. [e]

   logical access restrictions associated with changes to the system are defined;

   1 example covers this

6. [f]

   logical access restrictions associated with changes to the system are documented;

   1 example covers this

7. [g]

   logical access restrictions associated with changes to the system are approved; and

   1 example covers this

8. [h]

   logical access restrictions associated with changes to the system are enforced.

   1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

• addresses[a][b][e][f][g][h]

  CM.L2-3.4.5 · Access Restrictions for Change

  Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.

  • [a]

    physical access restrictions associated with changes to the system are defined;

  • [b]

    physical access restrictions associated with changes to the system are documented;

  • [e]

    logical access restrictions associated with changes to the system are defined;

  • [f]

    logical access restrictions associated with changes to the system are documented;

  • [g]

    logical access restrictions associated with changes to the system are approved; and

  • [h]

    logical access restrictions associated with changes to the system are enforced.

  Only the deployment pipeline can write to production; humans hold review rights

  CCControlVerdict Corpus@cv-corpusOSCJul 31, 2026

  Community is just starting — add yours. No verdicts yet.

  Implementation

  AO coverage. Claims the logical access restriction objectives [e] defined, [f] documented, [g] approved, and [h] enforced, plus [a] and [b] — physical restrictions are defined and documented for the facilities we control. Objectives [c] and [d] (physical restrictions approved and enforced) are not claimed in this example. We own no hosting hardware; approval and enforcement of physical access to the facilities holding enclave workloads is performed by the cloud provider and evidenced by their audit reports, which we track as an inherited control rather than assert as our own implementation.

  Logical restrictions defined and documented [e][f]. A written matrix states who may change what: the deployment identity may write to enclave infrastructure; platform engineers may propose changes and read production state; nobody has standing write access to production resources. Emergency access exists as a named break-glass role. The matrix is version-controlled with the infrastructure code it governs.

  Approval [g]. The matrix and each subsequent revision are approved by the enclave owner with security review. Individual grants require a ticket approved by someone other than the requester, and grants that would create standing production write access are refused by policy rather than negotiated case by case.

  Enforcement [h]. A deny policy at the account level blocks manual writes to enclave resources by human principals, so the pipeline is the only write path and drift by console clicking is not merely discouraged but impossible. The pipeline runs under a workload identity federated from the repository, with no long-lived keys. Break-glass activation is time-bound, requires a ticket reference, alerts security immediately, and is reconciled within 24 hours.

  Physical, in what we do control [a][b]. Office network closets holding enclave-reaching switches are badge-restricted with the access list defined and documented; that list is maintained under the physical protection domain, and the change process here simply points to it rather than duplicating it.

  Maintenance. Monthly report of break-glass activations against tickets. Quarterly review that no human principal has acquired standing write permissions, run as a policy simulation rather than a visual check. Annual re-approval of the matrix and re-read of the provider's current audit report.

  Accepted gap. One managed database's maintenance window settings can only be changed in the provider console, outside the pipeline. That specific permission is granted to two named engineers, is excluded from the deny policy by an explicit documented exception, and its use alerts.

  What the evidence looks like

  • Access restriction matrix with version history and enclave owner approval
  • Account-level deny policy blocking manual writes by human principals
  • Pipeline workload identity federation configuration (no long-lived keys)
  • Break-glass activation records with tickets and reconciliation notes
  • Cloud provider audit report reference covering the unclaimed physical objectives, plus the badge access list for office closets

  Environment

  Cloud-only OSC that retired its colocation cage last year. Enclave workloads run in one cloud subscription; the office has network closets but no servers.

  Tools

  • CI/CD
  • Cloud IAM
  • Cloud IdP

  Edit history

  · No edits yet