ID.RA-07 Changes and exceptions managed: evidence and audit guide

What ID.RA-07 changes and exceptions managed requires in practice

ID.RA-07 asks that changes and exceptions are managed: each change and each exception to a standing rule is assessed for its risk impact, recorded, and tracked until it is closed or revisited. In CSWP 29 this is a Subcategory of the Risk Assessment Category in the IDENTIFY Function, and the outcome is paraphrased here, not quoted. If you must show ID.RA-07 is met, you are showing that your organization can answer three questions for any change or exception: what was the risk of doing it or not doing it, who approved it, and when is it next reviewed.

The risk this addresses is quiet drift. A configuration change goes into production without a risk assessment, a firewall rule is opened for a vendor and never closed, or a risk accepted last year on the basis of a planned fix still stands after the fix was dropped. Exceptions are the harder problem because they rarely expire on their own. Change evidence is usually scattered across a ticketing system, a version control history, a CAB spreadsheet and email approvals, so an assessor who samples one change may find no link to its test results or rollback plan. NIST publishes four Implementation Examples for this Subcategory rather than a pass or fail test, so the question an assessor asks is whether your procedure covers documenting, reviewing, testing and approving changes, recording the risks and rollback guidance, and periodically reviewing accepted risks. Confirm with your assessor which of these they expect you to evidence for your scope.

A practical starting point is to decide one system of record for changes and one for exceptions, then make every exception carry an owner, a risk statement, a compensating control, a rollback or fallback note and a review date. Sample a few recent changes end to end and check that each links to an approval and a test result. Sample expired or overdue exceptions and confirm someone reviewed them. Open-source service management tools such as GLPI, which supports change tickets following ITIL practices, can hold this record if they are configured to require the fields you need. The organization owns the decisions and the approval authority. An implementation partner can configure the workflow and collect evidence, but only the organization's own governance can accept a risk.

Which changes and exceptions fall inside ID.RA-07 scope

ID.RA-07 applies wherever a change could alter risk and wherever an accepted deviation from policy or control persists. The boundary is set by a handful of decisions about which environments, release types and exception categories the organization brings under one managed process, and each decision assigns ownership to a different team.

Production infrastructure changes

Changes to production servers, network devices, cloud accounts, identity providers and backup systems usually sit at the core of ID.RA-07. Decide whether non-production environments are in scope, and if so, whether a change that is later promoted is tracked once or twice. Platform engineering typically owns the request, while the change advisory group or an equivalent reviewer approves it. Check that every production change has a recorded risk assessment and a rollback path.

Application release changes

Application releases carry code, dependency and database changes that can affect confidentiality and availability at once. Scope them by asking whether a hotfix, a minor version and a schema migration follow the same review and testing path. Development leads usually own the release record, and security engineering reviews releases that touch authentication, data handling or external interfaces. Confirm that test evidence is linked to each release ticket.

Configuration and security control changes

Changes to firewall rules, access policies, logging settings and endpoint protection alter the control environment itself, so they belong inside ID.RA-07 even when they look operational. Define which configuration items are security relevant, since a missed logging change can disable detection without anyone noticing. Security operations or the control owner typically proposes these changes, and the risk record should state which control objective each change could weaken.

Emergency changes

Emergency changes made to contain an active incident or restore service are the riskiest group because review often happens after implementation. Scope them with explicit criteria for what qualifies, a named approver who can act out of hours, and a deadline for retrospective review. Incident response and the on-call engineer usually execute the change, and the change owner completes the record afterward. Ask how many emergency changes were later found unnecessary or unauthorized.

Third-party changes affecting the organization

Vendor updates, SaaS feature changes, cloud provider maintenance and managed service modifications can change your risk without any action on your side. Decide how these enter the process, typically through vendor notices, contract change clauses or monitoring of provider status pages. Vendor management or the service owner usually tracks them, and the risk record should note whether your own controls still hold after the change. Confirm which vendors must notify you and within what window.

Policy and control exceptions

An exception is a documented decision to operate outside a policy requirement or a control for a stated period. Scope exceptions by requiring a written justification, a compensating control, a named risk owner and an expiry date. Control owners request them, and the risk owner approves them. Review open exceptions on a fixed schedule, because ID.RA-07 expects accepted risks to be revisited rather than left in place indefinitely.

How an assessor tests changes and exceptions

This table shows each step an assessor takes when testing ID.RA-07, from sampling recent changes and exceptions to checking closure and scheduled review of accepted risks. Read each row as a question the assessor will ask and the record the organization should be able to produce. The main takeaway is that a change is only credible when its trail runs unbroken from request to closure.

Assessor step	What the assessor checks	Evidence to have ready	Common finding
Sample selection	Pulls a sample of recent standard, normal and emergency changes plus active exceptions across in-scope systems	Complete change and exception register with dates, owners and systems, exported for the review period	Register omits emergency changes or exceptions held outside the main tool
Request and risk assessment	Confirms each sampled change has a recorded reason and a risk assessment of making or not making it	Change request, impact analysis and risk entry linked to the change record	Risk assessment written after implementation or missing for low-visibility changes
Approval timing	Compares the approval timestamp with the implementation timestamp to confirm authorization came first	Approval workflow history showing approver identity and time before deployment	Retroactive approvals recorded days or weeks after the change went live
Testing and rollback plan	Checks that testing results exist and that a documented rollback plan was prepared for each sampled change	Test records, test environment evidence and a rollback procedure tied to the change ID	Rollback plan is generic text or cannot be executed on the system as it stood
Emergency changes	Verifies that urgent changes were logged, reviewed after the fact and given the same closure checks	Emergency change records with a post-implementation review and follow-up tickets	Emergency changes never reviewed or closed, so the exception path becomes the normal path
Exception expiry and review	Checks that each accepted risk or exception has an owner, an expiry date and a review on the schedule the organization set	Exception register with acceptance decision, approving authority, expiry and dated review notes	Exceptions with no expiry date or whose review dates have passed without action
Closure and reconciliation	Confirms the change closed only after verification and that the configuration baseline reflects the change	Closure record, verification result and configuration or asset inventory update	Changes marked complete while the live configuration differs from the record
Informative references (illustrative)	Assessor may map the tests to SP 800-53 Rev. 5.2.0 CM-3, CM-4 and CA-7 from the NIST Reference Tool	Evidence that supports configuration change control, impact analysis and continuous monitoring	Organization cannot show which control set its change process was designed against

How to implement ID.RA-07 step by step

This sequence turns ID.RA-07 from a policy statement into a working change and exception process, with each step producing a document, template or register that an assessor can inspect. It is designed so the organization owns the decisions while an implementation partner can prepare the tooling and evidence.

Define change and exception categories
Start by listing the kinds of change your environment makes, such as standard, normal, emergency and configuration changes, and the kinds of exception you may grant, such as temporary deviations from a security baseline or accepted risks on unpatched systems. Assign each category an owner and state which categories need approval from risk or security. The output is a short classification procedure that the change and risk teams both sign off. You know it is done when every incoming request can be placed in exactly one category.
Set the risk criteria for each category
Define how the organization assesses the risk of making a change and the risk of not making it, using the likelihood and impact scales already in your risk method. Specify which systems, data or exposures raise a change to a higher review level. Record the criteria in the change policy or risk procedure so that reviewers apply them the same way. The output is a written risk rating table with examples of each level. It is done when two reviewers rating the same sample request reach the same level.
Document the change and exception workflow
Write the procedure for documenting, reviewing, testing and approving each change or exception, naming the roles that act at each stage and the minimum fields a request must contain. Include the testing expectation for each category and the point at which a change may be scheduled. Configure your ticketing or change tool to follow this flow, for example with a change ticket template and an exception form. The output is an approved workflow document and a working ticket template. It is done when a sample request can move through every stage without leaving the tool.
Require rollback plans and impact records
Make a rollback plan a mandatory field for every change above the lowest category. The plan should state the trigger for rollback, the steps to restore the prior state, the data or configuration that must be preserved, and who authorizes the rollback. Record the risks of implementing the change and the risks of delaying it in the same ticket. The output is a rollback requirement in the procedure and a completed rollback section in each sampled ticket. It is done when a reviewer can answer how the change would be reversed without asking the requester.
Open the exception register and set review intervals
Create a register for every accepted exception that records the affected asset, the justification, the compensating controls, the approver, the expiry or review date and the link to the related risk entry. Set a review interval for each exception based on its risk rating, and state in the procedure who triggers a review when conditions change. The output is an exception register that is reachable by auditors and the risk owner. It is done when each open exception has an owner, an approver and a next review date.
Run the first review cycle and record results
Hold a first review of completed changes and open exceptions against the procedure, sampling both approved and rejected requests. Check that testing evidence, approvals and rollback plans are present, that exceptions have not passed their review dates, and that accepted risks still match current conditions. Record findings, assign corrective actions and update the procedure where practice diverged from the design. The output is review minutes, a findings list and an updated register. It is done when every finding has an owner and every expired exception has been renewed, closed or escalated.

Choosing a system of record for changes and exceptions

Change tickets are the core evidence for ID.RA-07. They show what was proposed, who reviewed it, what testing happened, who approved it and how rollback would work. A self-hosted ITSM module is the natural fit when the platform or infrastructure team already runs change workflows. The GLPI documentation for the Assistance module describes tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. Whether it covers your approval chain, testing fields and rollback template is a question to confirm against your own process.

Approval steps: Check whether approvals can be routed by change type and whether the approver's decision is timestamped and kept.
Testing and rollback fields: Confirm the change record can hold test results and a rollback plan, not just a free-text comment.
Planning views: Calendar or planning views help avoid conflicting changes in the same window.
Recurring changes: Standard changes that repeat can be templated, which keeps routine work from cluttering the register.
Link to assets: Confirm that changes can be tied to the configuration or asset records they affect.

Ask the vendor or implementer to demonstrate a full change record from request to closure using your own approval matrix.

Evidence that satisfies ID.RA-07

ID.RA-07 is tested by sampling records, not by reading policy alone. The cards below cover the artifacts that show a change or exception was assessed, approved, tested and revisited, and the routines that keep those records current between audits.

Change requests with risk ratings

Each change request should describe what will change, which systems and data it touches, who requested it and why, and a risk rating that reflects the likely impact of the change failing. Assessors look for ratings that were set before approval and that match the scope described in the request. Check that standard changes, emergency changes and normal changes each follow a documented path with different approval depth. A request with no risk field, or with ratings that never vary, usually signals a form nobody reads.

Approval records and segregation

Keep a timestamped approval trail that names the approver, their authority for the affected system, and the decision. The person who builds a change should not be the only person who approves it, and emergency approvals should be reviewed after the fact. Confirm that the approval workflow in your tooling cannot be bypassed by editing a ticket status directly. Export the trail for a sample of changes so you can show the sequence to an assessor without reconstructing it from email.

Test results before release

Attach evidence that each change was tested in a non-production environment or against defined acceptance criteria before deployment. Test results can be a pipeline log, a signed test sheet or a reviewer's note, but each should link to the specific change identifier. Where testing was not possible, the record should state the compensating checks and who accepted that gap. Assessors often pick a recent production change and ask for the test evidence first.

Rollback plans per change

Every change record should contain a rollback plan that states the trigger for reverting, the steps, the data that must be preserved, and the owner who decides. ID.RA-07 expects the risk of not making a change to be recorded alongside the risk of making it, and the rollback plan is the main evidence for the second half. Verify that backups or configuration snapshots referenced in the plan were actually restorable, and keep a note of any rollback that was executed.

Exception register with expiry dates

An exception is a documented decision to operate outside a standard or configuration. Each register entry should name the control affected, the business reason, the compensating measures, the risk owner and an expiry date. Exceptions without an expiry date tend to become permanent without anyone deciding that they should. Confirm with your risk owners how exceptions are renewed, and whether any exception has been open longer than its approved term.

Periodic review of accepted risks

ID.RA-07 includes revisiting risks that were accepted on the basis of future actions, so keep dated review records for each accepted risk. A review record should show who reviewed the risk, whether the planned actions happened, whether the rating still holds, and what was decided. Hold a monthly exception review that closes, renews or escalates each open entry, and sample closed changes each quarter to confirm their records are complete. Record the date and attendees of every review, because the absence of review records is a common finding.

What meeting ID.RA-07 costs in money and effort

This table breaks down the cost components of running formal change and exception management for ID.RA-07, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. No figures are given because none were supplied, so use the drivers and the quote checklist to compare proposals on the same written scope.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Tooling or licenses	Software vendor or subscription provider for a ticketing or change platform	Recurring when licensed per user or per module; none when self-hosted open source is used	Number of approvers and requesters, and whether change and exception records need separate workflows
Engineering time for workflow setup	Implementation partner or internal platform engineers configuring change templates, approval steps and exception forms	One-time, with later adjustments	Number of change types, integration with configuration and deployment pipelines, and the depth of rollback fields
Change board time	Internal staff such as the change manager, system owners and security reviewers	Recurring	Change volume, number of systems in scope and how often emergency changes bypass normal review
Exception review and risk acceptance	Risk owners and the security function reviewing accepted risks	Recurring, usually on a set review cycle	Exception count, expiry rules and whether each exception needs a documented compensating control
Evidence upkeep	Internal staff or the partner keeping approvals, test results and rollback records retrievable	Recurring	Retention period, number of audit samples requested and the degree of manual record keeping
External review and independent assessment	Independent auditor or assessor who tests the process; the organization owns the controls	Recurring, tied to each assessment cycle	Assessment scope, sample sizes chosen by the assessor and whether the process is documented before the assessment starts
Self-hosted hosting and operations	Internal platform team or partner running the servers in the client's own infrastructure	Recurring	Hosting footprint, backup and upgrade frequency and the support hours agreed in the retainer

Which open-source tools support change and exception evidence

GLPI is licensed under GPL-3.0-or-later. Its Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, which gives an organization a single place where a change request can move from submission to approval and closure. For ID.RA-07, the change record is the core artifact: it shows what was proposed, who reviewed it, whether it was tested and who approved it.

Change tickets: Each change can be recorded as its own item with a description, requester and assigned technician, creating a dated trail for sampling.
Planning views: Plannings help teams schedule changes so reviews and approvals happen before implementation rather than after.
Statistics: Reports on change volume and status support the periodic review of accepted risks that ID.RA-07 expects.
Recurring items: Recurrent tickets can model standard, pre-approved changes such as routine patching, which keeps their evidence consistent.
Kanban view: A visual board shows which changes are waiting for testing, approval or rollback planning.

Confirm with your team whether GLPI's change workflow matches your approval chain, including emergency changes and rollback fields, before you adopt it.

Where change and exception programs usually fall short

Most organizations already have a change process and an exception process on paper. The gaps appear where those processes meet real work: emergency fixes, accepted risks that nobody revisits, and rollback plans that exist only in a document. Each card below names one gap, why it weakens ID.RA-07 evidence, and what to check before an assessor asks.

Exceptions with no review date

An exception approves a deviation from a standard, such as an unpatched service or a skipped configuration baseline, and then nothing schedules a second look. ID.RA-07 expects accepted risks to be revisited, so an exception without an expiry or review date is a gap. Check that every open exception has a named owner, a recorded risk statement, a compensating control and a next review date stored in the ticket or risk register. Ask which exceptions have passed their review date without closure.

Emergency changes never reviewed

Urgent fixes often go straight to production with a promise to document them later, and the paperwork never arrives. The change record then shows no approver, no test result and no link to the incident that triggered the change. Require a retrospective review within a window your organization sets, and confirm that the review checks whether the change was tested, whether it was recorded and whether a permanent fix replaced a workaround. Make the retrospective a closed step in the change workflow.

Rollback plans never tested

A rollback plan listed in a change request is only evidence if someone has shown it works. Many teams write a sentence such as restore the previous image and never run the steps against a realistic copy of the environment. Ask for the rollback steps, the data needed to reverse the change and the person who executes them. Where a change cannot be rolled back, the record should say so and show the compensating step, such as a verified backup taken before the change.

Approvals given in chat

Quick approvals in a chat channel or a hallway conversation leave no durable record of who agreed, what they agreed to and what evidence they saw. When the change causes an outage, the team reconstructs the decision from memory. Route approvals through the ticketing system, even when the request comes from chat, and link the chat thread to the ticket. The approval record should name the approver, the scope, the risk assessment and the test evidence.

Changes outside the tracked inventory

A change program only covers what it knows about. Configuration edits made directly on a hypervisor, a firewall rule added by a vendor engineer or a script run on a shared server can bypass the ticket queue entirely. Compare configuration drift reports and asset records against the change log each quarter, and treat any unrecorded change as an exception that needs a record. This check links ID.RA-07 to the asset inventory in ID.AM.

Exceptions approved by one person

When a single manager can approve both a change and the exception that waives its controls, the separation that makes the decision credible disappears. Assign risk acceptance to a role with authority over the risk, such as the system owner with security review, and record that role in the exception. Confirm that the approver is not the requester and that the risk owner has seen the residual risk statement before approval.

Questions buyers ask about ID.RA-07

Is ID.RA-07 certified by NIST?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. ID.RA-07 is a Subcategory of the CSF 2.0 Core, so the question is never whether a control is certified but whether your change and exception process produces evidence that an assessor or customer can test. Organizations show alignment through their own documentation, records and, where a contract requires it, a report from an independent assessor. DeployOpen prepares systems and evidence for that review but does not issue reports or certificates.

How much effort does ID.RA-07 take, and what drives it?

Effort depends mostly on how many systems change, how many teams touch production, and whether change records already exist in a ticketing tool. The work breaks into four parts: defining what counts as a change and an exception, setting approval and testing gates, recording risk and rollback plans for each change, and running periodic reviews of accepted risks. Each part can be one-time setup or recurring work. Ask any provider for a quote built from a written scope that lists the systems, change volume, tooling and approval paths in scope.

Can an in-house team implement ID.RA-07 without outside help?

Often yes, if the team already runs a change process and has an owner for risk acceptance. The harder parts are usually cultural: getting engineering to record changes before they happen, and getting risk owners to revisit exceptions on a schedule. An internal team can build the procedure, configure a ticketing tool and collect evidence. Outside help is most useful when the team lacks time, has no tooling experience, or needs a second opinion on whether the evidence will hold up in an assessment.

How long does preparation for ID.RA-07 typically take?

No reliable general duration applies, because preparation depends on the current state of change management. An organization with a documented change board and a working ticket history has less to build than one that makes changes through chat messages and email. Ask any provider to state its duration in the written scope and to name the dependencies, such as access to change systems, staff availability and the number of environments. Treat any single timeline quoted without that context with caution.

What does ID.RA-07 need from engineering and risk owners?

It needs engineering to describe each change in a form that can be reviewed, including the purpose, affected systems, test results and rollback steps. Risk owners need to approve exceptions in writing, state the risk they accept and set a review date. Specifically, the work requires:

Engineers who attach test evidence and a tested rollback plan to every change record
Risk owners who sign off exceptions and see the risks of not making a change
A named person who runs the periodic review of accepted risks

Without these roles, the process produces tickets but not the evidence the Subcategory describes.

How does ID.RA-07 relate to ISO 27001 change controls?

The two overlap in practice. NIST's CSF 2.0 Reference Tool lists ISO/IEC 27001:2022 clause 6.1.3 and Annex A control 8.32 as informative references for ID.RA-07, so an organization that runs an ISO 27001 change control process can often reuse much of its evidence. The overlap is not identical, though: ID.RA-07 places emphasis on recording the risk of making or not making a change and on revisiting accepted risks. Confirm the mapping against the current reference tool and against your auditor's expectations before relying on it.

Which open-source tools can record ID.RA-07 evidence?

A ticketing system is the most direct option. GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. Zammad is a web-based helpdesk that consolidates requests into one ticket system, which suits teams that receive change requests from many channels. Both are self-hosted options that can hold change records within your own infrastructure. Confirm that the chosen tool supports the approval, rollback and review fields your procedure requires before committing to it.

How ID.RA-07 relates to other CSF and standards requirements

ID.RA-07 carries forward a requirement that many organizations already met under CSF 1.1. NIST's transition spreadsheet maps it to the former PR.IP-3 subcategory, which sat in the Protect function under the old structure. The outcome is the same in substance: changes and exceptions are managed, their risk impact is assessed, and they are recorded and tracked. What changed is placement. CSF 2.0 moved the requirement into the Identify function, Risk Assessment category, so a change record is now read as evidence of risk identification and risk decisions rather than only as a configuration control. If your CSF 1.1 assessment cited PR.IP-3, update the mapping before you reuse that evidence, and confirm the new identifier against the transition spreadsheet linked from the Topic Sources.

The Reference Tool lists informative references for ID.RA-07 in several standards. For ISO/IEC 27001:2022, it points to clause 6.1.3, which concerns the risk treatment process, and Annex A control 8.32, which covers change management. For SP 800-171 Rev. 3, it points to requirements 03.04.03 and 03.04.04 in the configuration management family. Read these as pointers to where a related requirement lives, not as proof that one change record satisfies each of them. An assessor will still test each control on its own terms, so a single ticketing workflow may need different evidence for an ISO 27001 surveyor, a CMMC or SP 800-171 assessor and a CSF self-assessment. Ask your assessor which pieces of evidence they will accept for each framework before you design the workflow.

The reference points also tell you where to focus. Before you rely on any cross-reference, check the current version of the standard you are assessed against, because the mappings change when standards or NIST's informative references are updated. Confirm the exact clause and requirement wording with the publisher or your assessor rather than inferring it from a shorthand label. NIST does not certify or endorse mappings, and it does not validate that a particular tool or process meets any of these requirements. Treat the Reference Tool as a starting index for your gap analysis, then document your own decisions about scope, risk acceptance and evidence for each framework.

How DeployOpen prepares change and exception evidence for ID.RA-07

DeployOpen helps organizations set up the change and exception records that ID.RA-07 asks for, using self-hosted open-source service management tools inside the client's own infrastructure. The organization owns its change and exception decisions, and an independent assessor decides whether the evidence meets the outcome.

How we scope

Agree in writing which change types, exception types and approval paths the engagement covers.
Define which systems, platforms and environments feed change records and which are out of scope.
Set out which deliverables, such as workflows, templates and evidence exports, the fixed scope includes.

How we build

Configure a self-hosted ticketing and change workflow that records requests, reviews, testing and approvals.
Build templates that capture the risk of making or not making a change and the rollback plan.
Set up a register of accepted exceptions with owners, review dates and a documented process for revisiting them.

How we hand over

Document the workflow, roles and approval rules so the client's own staff can operate them.
Provide a sample evidence pack that maps change and exception records to the ID.RA-07 outcome for your assessor.
Confirm with your auditor or assessor which record formats and retention periods they expect before go-live.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover periodic review of the exception register and changes to workflows as processes evolve.
Ask any provider to confirm which tool features are native and which need custom configuration in your environment.