ID.RA-07: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked

ID.RA-07 is a day-to-day operations requirement disguised as a risk assessment statement: your organization must keep control of what changes, what deviates from standard, and what that means for risk. In practice, auditors and regulators look for two things: (1) a consistent mechanism that forces changes and exceptions into the light, and (2) proof that you assessed impact before you accepted new risk or weakened controls.

“Change” here includes technology changes (deployments, configuration updates, cloud service modifications), process changes (new onboarding flows, altered approval steps), and third-party changes (new critical suppliers, scope expansions, or material contract updates). “Exception” includes any approved deviation from policy, standard, baseline configuration, or required control, such as delayed patching, unsupported encryption settings, or skipped security testing.

Operationalizing ID.RA-07 means you define what must be logged, what must be risk-assessed, who can approve, how long exceptions can live, and what evidence you retain. If you do this well, you reduce surprise outages, control failures, and “we didn’t know that changed” incident narratives. Source framework text: (NIST CSWP 29) and transition reference (NIST CSF 1.1 to 2.0 Core Transition Changes).

Regulatory text

Excerpt: “Changes and exceptions are managed, assessed for risk impact, recorded, and tracked.” (NIST CSWP 29)

Operator translation:
You must run a governance process where:

1. changes and exceptions enter a formal system of record,
2. each item gets a risk impact assessment appropriate to its significance,
3. approvals are documented and tied to accountable owners, and
4. implementation (for changes) or remediation/expiration (for exceptions) is tracked to completion.

This is a control-expectation statement: if you cannot show the workflow and evidence trail, you will struggle to demonstrate that risk is being managed rather than discovered after the fact. (NIST CSWP 29)

Plain-English interpretation (what “good” looks like)

A working ID.RA-07 program has five characteristics:

1. One intake path: people know where to file changes and exceptions, and the tooling enforces required fields.
2. Risk impact is explicit: each request states affected assets/services, control impacts, and exposure change, not just “low/medium/high.”
3. Approval matches risk: higher-impact items route to security, risk, and business owners; emergency paths exist but require after-the-fact review.
4. Time-bounded exceptions: every exception has an owner, compensating controls, review date, and expiry/closure criteria.
5. Reporting exists: you can produce a register of open exceptions, overdue reviews, and high-risk pending changes on demand.

Who it applies to

Entity scope: Any organization running a cybersecurity program and using NIST CSF 2.0 as a framework reference, including regulated entities that map their security program to NIST CSF outcomes. (NIST CSWP 29)

Operational scope (where this bites):

• IT operations and infrastructure: patching deferrals, firewall rule changes, identity configuration changes.
• Application and product engineering: deployments, feature flags, changes to authentication flows, new integrations.
• Cloud and SaaS administration: changes to tenant settings, logging retention, privileged roles.
• Third-party management: onboarding a new third party, expanding data sharing, or accepting a third party’s control gap as an exception.
• Security operations: emergency changes during incidents, containment changes, temporary monitoring compensations.

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

Step 1: Define “change” and “exception” with clear triggers

Write definitions that are testable:

• Change trigger examples: modifies production configuration, alters access controls, introduces/changes data flows, affects logging/monitoring, changes third-party scope.
• Exception trigger examples: any deviation from policy/standard/baseline, missed control frequency, unremediated high severity vulnerability beyond your standard timeline, unperformed required review.

Add a short decision tree so requesters can self-classify. Keep it strict; ambiguity becomes unlogged activity.

Step 2: Establish a system of record (register) and required fields

You need one authoritative register for:

• Change requests (CRs)
• Exception requests (policy exceptions, risk acceptances)

Minimum fields to require:

• Request type (change vs exception)
• Service/asset affected (link to CMDB or inventory if you have it)
• Data classification impacted
• Control(s) impacted (policy/standard control reference)
• Risk impact assessment summary (before/after exposure statement)
• Approvers (business owner + security/risk as applicable)
• Implementation plan (for changes) or compensating controls (for exceptions)
• Testing/validation steps
• Planned date and completion date
• Exception expiry/review date and closure criteria (exceptions only)

Step 3: Build a risk impact assessment that operators can complete

Don’t ask for a mini risk thesis. Ask for a structured, defensible analysis:

• What changes in exposure? Example: “Admin role expanded to vendor support team” increases likelihood of unauthorized changes; reduces time-to-restore.
• What controls weaken or strengthen? Example: “Disabling MFA for service account” weakens authentication control.
• What’s the blast radius? Affected services, users, regions, and data types.
• What could go wrong? Tie to credible threat scenarios (credential theft, misconfiguration, data exfiltration, outage).
• What mitigations exist? Compensating controls, monitoring, rollback plan, segmentation, approvals.

Route “high-impact” items to a deeper review. Your policy should define what constitutes high impact (for example: production authentication changes, externally facing network changes, or exceptions affecting encryption/logging).

Step 4: Implement approval and segregation-of-duties rules

Operationalize who must sign:

• Business/system owner: accepts operational impact and service risk.
• Security/Risk: validates that risk analysis is credible and compensations are adequate.
• Change manager / IT operations: validates feasibility, scheduling, and rollback.

Prevent self-approval for meaningful items. If your organization is small, require at least one independent reviewer for non-trivial changes and all exceptions.

Step 5: Track to closure (changes) and to expiry/remediation (exceptions)

This is where programs fail.

For changes:

• Require implementation evidence (deployment record, ticket closure notes, monitoring checks).
• Require post-change validation (tests passed, logs verified, access reviews updated if roles changed).
• For emergency changes, require an after-action review and retroactive risk documentation.

For exceptions:

• Require expiry and re-review dates at creation.
• Require clear closure conditions: “patch applied,” “control implemented,” “service retired,” or “contract amended.”
• Run a recurring exception review meeting with Risk + control owners. The goal is to close items, not curate a museum of permanent exceptions.

Step 6: Report and govern

Build a monthly dashboard that answers:

• Open exceptions by severity/owner
• Exceptions nearing expiry or overdue for review
• Changes implemented without risk review (should be zero; if not, show emergency pathway compliance)
• Repeat exceptions (same control, same team) indicating systemic issues

If you need a practical way to keep this audit-ready, map ID.RA-07 directly to: policy statement, procedure, control owner, tooling workflow, and a recurring evidence pull. That mapping is a recommended control approach. (NIST CSWP 29) (NIST CSF 1.1 to 2.0 Core Transition Changes)

Required evidence and artifacts to retain

Keep evidence that proves both design (rules exist) and operation (rules are followed):

Program design artifacts

• Change management policy and procedure (including emergency change procedure)
• Exception/risk acceptance policy (approval authority, expiry requirements, compensating controls expectations)
• Risk assessment procedure for change/exception impact (template or form fields)
• RACI matrix for approvers and reviewers

Operational records (system-generated where possible)

• Change tickets with risk impact fields completed, approver timestamps, implementation logs, validation steps, closure notes
• Exception register export showing owner, rationale, risk impact, compensating controls, approvals, and expiry/review dates
• Evidence of recurring exception review (agenda, notes, action items)
• Samples of emergency changes with after-action documentation
• Metrics reports used by management (dashboards, monthly reports)

Common exam/audit questions and hangups

Auditors tend to test ID.RA-07 by sampling. Expect questions like:

• “Show me your exception register and how you ensure exceptions expire or are re-approved.”
• “Pick a recent production change. Where is the risk impact assessment, and who approved it?”
• “How do you determine which changes need security review?”
• “How do you handle emergency changes, and how do you prevent that path from becoming the default?”
• “How do third-party changes and third-party exceptions enter the same governance process?”

Hangup to plan for: teams may have “change tickets” but no explicit risk impact analysis. Another common issue is exceptions approved in email or chat with no system-of-record entry.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Exceptions with no expiry.
   Fix: enforce an expiry field in the intake form; no expiry, no approval.

2. Mistake: Risk impact is a single word (“low”).
   Fix: require before/after exposure and affected controls fields; reviewers reject vague entries.

3. Mistake: Emergency change path becomes a loophole.
   Fix: require retroactive documentation and management review of emergency volume; repeated emergency use triggers a root-cause action.

4. Mistake: Engineering changes bypass central change management.
   Fix: integrate CI/CD approvals with risk triggers (authn/authz changes, network boundary changes, logging changes) so “software change” equals “governed change.”

5. Mistake: Third-party exceptions handled only in procurement files.
   Fix: mirror third-party control gaps into the same exception register with an internal owner and compensating controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat this page as framework implementation guidance rather than enforcement prediction. Practically, weak change and exception governance increases the likelihood of control failures, unauthorized changes, misconfigurations, delayed remediation, and audit findings that cite “lack of evidence” rather than a single technical defect. The framework expectation is explicit that items must be “recorded, and tracked,” which makes evidence discipline a first-order risk. (NIST CSWP 29)

Practical 30/60/90-day execution plan

First 30 days (stabilize the workflow)

• Name a single owner for change governance and a single owner for exception governance (can be the same person in smaller orgs).
• Publish crisp definitions and triggers for changes and exceptions.
• Stand up the register in your existing ticketing/GRC tool; enforce required fields (especially risk impact and expiry).
• Start logging all new exceptions immediately; don’t wait for perfect taxonomy.

Days 31–60 (make risk impact review real)

• Implement risk impact templates that force “affected asset,” “control impact,” and “compensating controls.”
• Calibrate approval tiers: define which categories require Security/Risk approval vs standard change approval.
• Create the emergency change after-action checklist and require it for every emergency ticket.
• Begin monthly exception review with action owners and due dates.

Days 61–90 (prove operating effectiveness)

• Run an internal audit-style sample: pick recent changes and exceptions, verify end-to-end evidence completeness.
• Add reporting: open exceptions, upcoming expiries, overdue closures, repeat exceptions by control area.
• Tighten gates: reject incomplete risk narratives; prevent closure without validation evidence.
• Map the requirement to policy, procedure, control owner, and recurring evidence collection so audits stop being scavenger hunts. (NIST CSF 1.1 to 2.0 Core Transition Changes) (NIST CSWP 29)

Where Daydream fits naturally: If your bottleneck is “we can’t pull consistent evidence across tools,” Daydream helps by mapping ID.RA-07 to the exact artifacts you need and setting up recurring evidence collection and reminders, so exceptions don’t quietly age past expiry and change tickets don’t close without the risk fields you need.

Frequently Asked Questions

What counts as an “exception” for ID.RA-07?

Any approved deviation from your security policy, standard, baseline, or required control activity counts. If you can’t meet a control as written, record it as an exception with an owner, compensating controls, and an expiry.

Do we need a separate process for changes and exceptions?

You need clear handling for both, but you don’t need separate tooling. Many teams run a single intake system with two request types and different required fields (implementation plan for changes, expiry and compensations for exceptions).

How do we handle emergency changes without failing the requirement?

Allow an emergency path, but require rapid retroactive risk documentation, approvals, and post-change validation evidence. Emergency should be measurable and reviewed so it doesn’t become routine.

How deep should the “risk impact assessment” be?

Deep enough that a reviewer can understand what exposure changed, what controls were affected, and why the proposed mitigations are adequate. If an assessment can’t explain blast radius and compensating controls, it’s not reviewable.

Where do third-party control gaps belong?

If you accept a third party’s control deficiency (or your own inability to enforce a contractual requirement), log it as an exception in your register. Assign an internal owner, document compensations, and set a re-review tied to contract renewal or a remediation milestone.

What evidence do auditors usually ask for first?

A current exception register with expiry dates and approvals, plus a sample of recent production changes showing risk impact assessment and closure validation. If those are clean, the rest of the program is easier to defend.