CP-12 Safe mode: requirements and evidence

What CP-12 safe mode asks a system to do

If you operate a system that supports critical functions, CP-12 asks one question you must be able to answer in advance: what does the system do when defined conditions are detected, and what is it still allowed to do while in that state? The control requires the system to enter a safe mode of operation with defined restrictions when those conditions occur. The organization decides what the conditions are and what the restrictions look like, so the requirement is only as good as those definitions. The catalog ties the control to critical operations, and its guidance cites examples such as air traffic control and nuclear power plant operations, where a degraded but predictable state is safer than either full operation under abnormal conditions or an abrupt shutdown.

The risk CP-12 addresses is a system behaving unpredictably at the moment it matters most. Without a defined safe mode, operators improvise under pressure, automated functions may keep acting on bad inputs, and recovery depends on people who may not know what the system is doing. A safe mode gives operators a known state to fall back to and a known set of functions that remain available. Ask your system owners to write down the trigger conditions, the restrictions applied in each mode, the roles that can enter and leave the mode, and the functions that must keep running. Confirm these against the system's own design, since the control does not supply them.

CP-12 is difficult to test because nothing about it is fixed in advance. SP 800-53A assesses it with one determination statement and the examine, interview and test methods, and the test object is the mechanism that implements the safe mode. An assessor will want the contingency plan, operation and installation manuals, contingency test records and incident handling records, plus interviews with personnel who run the system and its network. Expect to demonstrate, not just describe, that the conditions are detected and the restrictions take effect. Note that SP 800-53B Release 5.2.0 does not select CP-12 in the low, moderate or high baselines or the privacy baseline. It applies only when your organization, a contract or an overlay adds it, so confirm with the requirement owner whether it is in scope before you invest in the test.

Which systems need a CP-12 safe mode

CP-12 is not in any SP 800-53B baseline, so a safe mode requirement exists only when an organization selects it through tailoring or an overlay. The cards below cover the system types where a safe mode is a credible design choice and the scoping decisions that change how much work it creates.

Real-time operational systems

Systems that must keep acting on live inputs, such as process control, dispatch or monitoring platforms, are the clearest candidates. CP-12 asks the system to enter a safe mode with defined restrictions when defined conditions are detected, and NIST's guidance cites critical operations such as air traffic control as the kind of setting it has in mind. Check which conditions trigger the mode, which functions are restricted, and whether operators can still see the system state while it runs.

Safety-relevant functions

Where a failure could cause physical harm or environmental damage, a safe mode defines what the system may still do when normal operation is unsafe. Map each safety-relevant function to a documented restriction and confirm with the system owner and safety engineers which restrictions are acceptable. Decide early whether the safe mode is an automated response, an operator-initiated action, or both, because that choice changes the test plan.

Authorization boundary membership

CP-12 only creates assessment work for components inside the authorization boundary. Confirm whether the systems that run the safe mode, such as controllers, gateways and monitoring servers, are included in the boundary documented in the system security plan. A component left outside the boundary may still affect the safe mode behavior, so document the interfaces and how the boundary owner accepts that dependency.

Baseline or overlay selection

Because SP 800-53B Release 5.2.0 does not select CP-12 for the low, moderate or high baselines or the privacy baseline, the organization must add it by tailoring a baseline or applying an overlay. Record the decision, the rationale and the owner of the decision in the security plan. Ask the authorizing official or the program office whether an applicable overlay already requires CP-12 before tailoring the baseline yourself.

Operating teams and their procedures

The safe mode only works if the people who run the system know it exists. Identify the operations staff and system administrators who must recognize the mode, follow the restricted procedures and restore normal operation. Their role-based training and the contingency plan steps for leaving safe mode should be written together, so the assessor can trace the interview answers back to the documents.

Third parties that operate or depend on the system

Vendors who maintain controllers, hosted monitoring services or upstream data feeds can change how the safe mode triggers or recovers. Before scoping, list each external provider, what it supplies, and whether its service agreement covers changes to safe mode logic. Confirm with procurement and legal how these dependencies are documented, since the assessor will ask who can alter the restrictions and how those changes are controlled.

Defining the conditions and restrictions CP-12 depends on

CP-12 has two organization-defined parameters (CP-12_ODP[01] and CP-12_ODP[02] in the SP 800-53A labels), and the control cannot be met until your organization sets them. One parameter defines the conditions that trigger the system's move into safe mode, and the other defines the restrictions that apply while it runs there. Assessors look for both values to be specific, measurable, documented and approved by the people accountable for the system's critical functions. A parameter that reads as a general intent, such as "when the system is under threat," gives an assessor nothing to test against, because they cannot tell whether a given event should have triggered the mode or whether the restrictions actually applied.

The assessment procedure for CP-12 asks an assessor to examine the contingency plan, operation and installation manuals, contingency test records and incident handling records, interview system operation personnel and system and network administrators, and test the mechanisms that implement safe mode. Each of those steps depends on the parameter values being written down in a place the assessor can read. Confirm with your system owner which document holds the approved values, and check that the contingency plan, the operations manuals and the test records all reference the same conditions and restrictions. Mismatched wording across those documents is a common reason an otherwise sound control produces an open finding.

The restrictions should be derived from the functions the system must keep running, not from what is easiest to switch off. Start from the essential functions and recovery priorities documented in the contingency plan, then decide which operations must continue in a reduced form and which must stop to protect the process or the people it serves. Real-time operations are the typical case that SP 800-53 has in mind, where a restriction that removes a non-essential feature may be preferable to a full shutdown. Record the rationale for each restriction, and have the same people who own the critical function sign off on it. Confirm the final values with your own engineering and operations leads, since the control does not prescribe them.

How an assessor tests CP-12 safe mode

This table breaks down the single SP 800-53A determination statement for CP-12 by assessment method, showing the objects an assessor examines, interviews and tests, the evidence to prepare and the findings that appear most often. Read each row as a checklist for what the organization must be able to produce before the assessment starts.

Assessment method	Assessment objects and evidence to prepare	Common findings
Examine	Contingency plan, system operation and installation manuals, and the defined conditions and restrictions for safe mode. Evidence should show which conditions trigger safe mode and what the system does in that state.	Plan describes safe mode in general terms with no defined trigger conditions or restrictions, or the manuals never mention it.
Examine	Contingency plan test records and incident handling records showing that safe mode was exercised or invoked, with results and corrective actions.	No test records exist for safe mode, or the records only cover backup and failover testing.
Interview	Personnel with system operation responsibilities and system and network administrators, asked how they recognize a trigger condition and how they place the system in safe mode.	Operators cannot describe the trigger conditions or the restrictions, and administrators give different answers.
Test	Mechanisms implementing safe mode, such as configuration settings, automated controls or documented manual steps, exercised against the defined conditions to confirm the restrictions take effect.	Mechanism is not present in the production configuration, restrictions are incomplete, or the test was run only in a non-representative environment.
Test	Recovery from safe mode back to normal operation, confirming the system returns to its expected state once conditions clear.	Return to normal operation is undocumented, leaving restrictions in place or requiring unplanned rebuilds.
Scope check	Documented scope of the safe mode requirement for each critical function, with the organization-defined parameters set for CP-12 and recorded in the system security plan.	Organization-defined parameters are blank or inconsistent with the plan, so the assessor cannot tell what was tested.

Implementing CP-12 safe mode step by step

This sequence turns CP-12 from a sentence in a control catalog into a documented, tested safe mode that operators understand, that detection logic can trigger, and that an assessor can trace from defined conditions to recorded test results.

Set the two organization-defined parameters
Start by assigning values to the two organization-defined parameters in CP-12, which govern the conditions that trigger safe mode and the restrictions that apply once it is entered. The control owner, usually the system owner with input from the contingency planning lead, writes each value down in the system security plan entry for CP-12. The output is a signed parameter record that names each condition in operational terms, such as a specific telemetry signal or a loss of a named service, so that a tester can later check whether the condition was defined clearly enough to detect.
Design safe mode with the critical function's operators
Work with the people who run the critical function to decide what the system keeps doing, what it stops, and who may override the state. Engineers document the restrictions, such as disabled write paths, frozen configuration changes or reduced command sets, and confirm that each restriction preserves the essential operation. The output is a safe mode design record listing each restriction, its rationale, the operators who approved it and any manual actions required, which later becomes the basis for both the system design and the operator procedures an assessor will examine.
Build detection and transition mechanisms
Implement the logic that detects the defined conditions and moves the system into safe mode, then implement the mechanisms that enforce its restrictions. Teams should also decide how the system signals the transition to operators and records it in logs. Configuration, code and any automation should be placed under the change control already used for the system so each mechanism can be traced to a version. The output is a configuration baseline and a test-ready build that show the detection rules, the enforcement points and the logging of each transition.
Document the procedure in the contingency plan and manuals
Add the safe mode procedure to the system contingency plan and to the operation and installation manuals that the assessment procedure names as examine objects. The entries should state the defined conditions, the restrictions, who may enter and exit safe mode, how to restore normal operation and where incident handling records are kept when safe mode is entered during an event. The output is a revised contingency plan and manual set with version numbers and a change history, so an assessor can compare the written procedure with the configured system.
Test the transition and the restrictions
Run tests that trigger each defined condition in a controlled environment and confirm that the system enters safe mode, enforces every restriction and returns to normal operation when authorized. Include at least one exercise with the operators who would respond in production, and record deviations as findings to be corrected before the procedure is accepted. The output is a test plan, test records and a list of issues with their resolution, which together match the test objects and contingency plan test records that the assessment procedure lists.
Record the approval and schedule review
Have the authorizing official or the designated approver review the parameters, design, procedure and test results, then record the decision. The approval should name the date, the version of the system and contingency plan it covers, and any residual risk accepted. Confirm with the assessor, or with the internal assessment team, how often the approval must be revisited under the organization's own policy, since the frequency is set by the organization. The output is a signed approval record and a review entry that the assessor can match to the test records and the interview statements of personnel with system operation responsibilities.

Evidence that proves the CP-12 safe mode works

An assessor testing CP-12 looks for a chain of evidence: the conditions that trigger safe mode, the restrictions that apply, proof that the mechanisms work, and records showing that safe mode was used in practice. Each card below names one artifact and the check that keeps it current between assessments and after system changes.

Defined conditions and restriction approvals

The assessment starts with the organization-defined parameters: the conditions that trigger safe mode and the restrictions that apply while it runs. Keep a written record of each condition and restriction, with the owner of the operational decision and the approval date. Confirm that the conditions match what the system can actually detect, since a condition nobody monitors will never trigger. Review the list whenever the operating envelope or the critical function changes.

Contingency plan safe mode section

The contingency plan should describe how the system moves into safe mode, who decides, what functions keep running, and how normal operation resumes. Assessors compare this section against the system's actual behavior, so every step must name a role or a mechanism. Update the section whenever restrictions, interfaces or operators change, and record the revision in the plan's change history.

Operation and installation manuals

Operators need instructions for entering safe mode, verifying that restrictions are in force and leaving the state safely. Installation manuals should show how the safe mode mechanisms are deployed and configured. Check that both manuals reflect the current software version and that the steps were tested against it, not copied from an earlier release.

Safe mode test records

Test records are the strongest proof that the transition works. Each record should show the triggering condition, the time the system entered safe mode, which restrictions were confirmed, the functions that continued, and the return to normal operation. Retain results from every test, including failed ones and the corrective actions that followed. Repeat the test after significant changes to the system.

Incident handling records

When safe mode was entered in a real event, the incident record should show the detection, the decision to enter safe mode, the restrictions applied and the recovery steps. These records connect CP-12 to incident response and show that the condition and restriction definitions were used as written. Where safe mode has never been triggered, say so in the plan and rely on test records instead.

Configuration and code evidence

Assessors ask for the configuration and code behind the mechanisms. Keep version-controlled configuration for the trigger logic and the restriction settings, and record the change approval for each modification. Use a baseline of the configuration so drift can be detected. Confirm the evidence covers the same version that was tested and deployed.

What meeting CP-12 safe mode costs

This table breaks the effort behind CP-12 safe mode into components, showing who is paid for each, whether it is one-time or recurring, and what changes its size. NIST does not estimate compliance costs, so use the table to scope and quote work, not to predict a number. The main takeaway is that most of the recurring cost comes from keeping safe mode drills and evidence current after system changes.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Detection and transition design	Engineering staff or implementation partner	One-time, revisited after major changes	Number of defined conditions and how many subsystems must change state together
Defining safe mode restrictions	Operations leads with system owners	One-time, then recurring on review	How many functions must be restricted and how many operator decisions each one needs
Safe mode drills and test effort	Operations staff, test engineers, system owners	Recurring at the frequency the organization defines	Number of conditions tested, system complexity and whether drills affect live operations
Evidence upkeep	Compliance or security staff	Recurring	Frequency of system changes, number of drill records and how well records are kept
External testing or review	Independent testing firm or consultant	Often one-time per scope, repeated after major change	Whether the mechanism is tested by a third party and how much of the system is in scope
Auditor sampling and assessment	Independent assessor or auditor	Recurring at each assessment cycle	Number of safe mode events the assessor samples and how cleanly records map to CP-12
Platform and monitoring changes	Engineering staff and tool vendors, where licensed	Recurring	Whether detection depends on tools that need licenses, updates or hosting in the client environment

Who owns CP-12 safe mode: your team, a partner and the auditor

Your organization owns CP-12. Safe mode is a operational decision about a system that supports critical functions, so the defined conditions, the restrictions that apply in safe mode and the authority to trigger it must come from the people accountable for that function. NIST leaves the organization-defined parameters to the organization, and the two parameters in CP-12 are yours to set and justify. Your team also decides when the mode is entered, who can override it and how operations resume.

Defined conditions: Write the detection conditions in terms your operators and monitoring tools can act on, and record why each one matters to the critical function.
Restrictions: Specify which functions stop, which continue and which require manual approval while the system is in safe mode.
Decision authority: Name the roles that may enter and exit safe mode, and the escalation path when they are unavailable.
Operating procedures: Maintain the runbooks that operators follow, and keep them aligned with the contingency plan.
Exercises: Run the safe mode procedures in your own exercises and keep the outcomes.

Before any outside party is engaged, confirm that someone on your side can state the defined conditions, the restrictions and the decision owner without consulting the vendor.

Where CP-12 safe mode efforts usually fall short

CP-12 is short, but it depends on decisions the organization must make and then keep current. The gaps below tend to appear where those decisions were never written down, tested or tied to the rest of the contingency program.

Undefined condition and restriction parameters

CP-12 leaves the triggering conditions and the restrictions of safe mode to the organization through its organization-defined parameters. Teams often state that safe mode exists without naming which detected conditions start it or which functions stop, slow down or stay available. Fix this by writing each trigger and each restriction as a testable statement, with an owner and a value, and checking that the two organization-defined parameters in the control are filled in before any assessor asks.

Safe mode that exists only on paper

A safe mode drawn in an architecture diagram or described in a policy does not protect a real system. The assessor's test objects include the mechanisms that implement safe mode, so the question is whether the running system can actually enter that state. Confirm with the system owner that a mechanism exists in the production configuration, that it can be reached without a developer, and that its restrictions appear in the system's documentation.

Restrictions that were never tested

Restrictions often look correct in design reviews and then fail when the system is actually constrained. A restriction that blocks a function may also block a dependency that operators need to recover. Schedule safe mode exercises alongside the contingency plan tests, record which restrictions held and which did not, and feed each failure into a corrective action with an owner and a due date.

No link to the contingency plan

Safe mode is useful only when operators know when to invoke it and what happens next. If the system contingency plan does not name safe mode, its entry conditions, the people authorized to start it and the path back to normal operation, responders will improvise during the event. Check that the contingency plan, the incident handling procedures and the safe mode procedures refer to one another and use the same condition names.

Missing records of past transitions

Each time a system enters or leaves safe mode, the organization should be able to show who authorized the change, what triggered it, which restrictions applied and when normal operation resumed. Many teams keep these details in chat threads or memory. Ask for a log or ticket for every transition, including test transitions, and confirm that the audit records for the system capture the entry and exit events so the evidence exists when an assessor samples it.

No change control for safe mode logic

The rules that decide when safe mode starts and what it restricts are configuration or code, and they change as the system changes. A new service or a revised threshold can quietly disable a trigger. Place safe mode logic, its parameters and its restriction lists under the same change process as other system configuration, and have the owner review the safe mode settings whenever the system's functions or interfaces change.

CP-12 safe mode questions buyers ask before hiring help

What drives the cost of implementing CP-12 safe mode?

The cost depends mainly on how many systems support critical functions, how many safe mode conditions and restrictions the organization defines, and how much engineering work is needed to make the platform actually enter and exit that state. Costs fall into two groups: the one-time work to define conditions, restrictions and procedures, build or configure the mechanisms, and test them, and the recurring work to re-test after changes and keep the contingency documentation current. No public figures are attached to CP-12 in the sources used for this page, so ask for a fixed-scope quote built from a written list of systems, conditions and restrictions. DeployOpen does not publish prices.

How long does a CP-12 safe mode engagement usually take?

Duration depends on the number of systems in scope, whether the platform already has a usable safe mode, and how many people must agree on the defined conditions and restrictions before work starts. Because CP-12 is tied to critical operations, the decision-making step often takes longer than the technical build. The timeline should appear in the written scope, with milestones for definition, build, testing and evidence collection. Ask for those milestones explicitly rather than a single end date.

What does CP-12 need from our operations and engineering staff?

CP-12 needs input that only your staff can give. Operations staff must describe which functions are critical and what a safe state looks like for them. Engineers must confirm which system conditions can be detected reliably and which restrictions will not break dependent processes. Typical inputs include:

Named owners for each critical function and their operating procedures
Agreed condition triggers and who may override them
Test windows on non-production or staged environments
Access to system administration and installation documentation

Plan for these people to be available during definition and testing, not only at the end.

Can our own team implement CP-12 without outside help?

Yes, if your team already runs the platform, has the engineering capacity and can document and test the work independently. Many organizations handle the definition step internally because only they know which operations are critical. Outside help is most useful where the team lacks time, has not built a safe mode before, or needs an independent check before an assessment. Whichever path you choose, the organization owns the control and its decisions.

What can an implementation partner sign off on for CP-12?

An implementation partner can prepare the system, configure the mechanisms, run tests and assemble the evidence. It cannot issue an audit report, attestation or certification. An independent assessor, or the authorizing official in a federal context, makes the determination. The organization accepts the residual risk and approves the defined conditions and restrictions. Confirm this split in the written scope so that roles are clear before work begins.

Is CP-12 required by default under SP 800-53?

No. SP 800-53B does not select CP-12 for the low, moderate or high baselines or for the privacy baseline. An organization adds it when its risk assessment, mission, contract or regulator calls for safe mode behavior, usually by tailoring a baseline or applying an overlay. Check the contract or authorization package for explicit requirements before scoping the work, because a missing requirement is a reason to confirm scope, not to assume it is absent.

What evidence should we expect the assessor to ask for?

SP 800-53A assesses CP-12 by examining documents, interviewing personnel and testing the mechanisms that implement safe mode. Expect requests for the contingency plan, system operation and administration manuals, contingency test records, incident handling records, and test results showing the safe mode actually activates and restricts operations as defined. Ask your partner to map each artifact to the assessment objects before testing begins, so gaps appear early.

How DeployOpen scopes and prepares CP-12 safe mode evidence

DeployOpen works on CP-12 Safe mode as an implementation partner: it helps the organization define the safe mode conditions and restrictions for systems that support critical functions, then prepares the configuration and evidence an assessor will examine. The organization owns the control, and only an independent assessor issues any assessment result.

How we scope

Agree in writing which systems support critical functions and therefore need a defined safe mode.
Document the organization-defined conditions and the restrictions that apply in safe mode for each in-scope system.
Confirm the two organization-defined parameters for CP-12 and record who approves those values.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts.

How we build

Configure the self-hosted platforms in the client's own environment so that the defined conditions trigger the safe mode restrictions.
Test the safe mode mechanisms against the defined conditions and record the results with timestamps.
Align safe mode with incident handling, change management and contingency plan procedures so responsibilities are clear.
Keep configuration changes under version control so the safe mode settings can be reviewed over time.

How we hand over

Deliver the safe mode procedures, operation manuals and configuration documentation the assessor will examine.
Provide contingency plan test records and incident handling records that show safe mode was exercised.
Walk operations and system administration staff through the restrictions and the recovery steps to leave the mode.
Confirm with the organization's assessor which evidence formats and locations they expect before handover.

How we support

Ongoing support, upgrades and continuous testing of safe mode mechanisms are available as a retainer.
Review safe mode conditions and restrictions when systems change, and update the documentation to match.
Repeat safe mode tests on a schedule the organization defines, and retain the results for later assessment.
Ask the organization's assessor whether they want additional evidence before a formal assessment begins.