What SC-24 fail in known state requires of a high-baseline system
If you own a high-baseline system, SC-24 Fail in known state requires you to show that when a failure occurs, your components move to a defined, safe state instead of an undefined one, and that the state information you care about survives the failure. The control has three organization-defined parameters that you must fill in: the components that must fail to a known state, the types of failure that trigger that behavior, and the system state information that must be preserved. An assessor will not accept a generic statement that the system is resilient. They will look for the specific list you wrote and check that the design and configuration match it.
The risk behind the control is simple. A component that fails open, drops its access rules, or restarts with an empty configuration can expose data or processes that were protected a moment earlier. Undefined failure behavior is hard to test because nobody has decided what the correct result is. The difficulty is that the decisions are design decisions. Whether a firewall, a key service or an authorization component fails closed, and what it keeps in memory or on disk for recovery, is settled when the architecture is drawn, not when the audit starts. Retrofitting that behavior into a running high-baseline system is costly, so the parameter values belong in early design reviews.
SC-24 is assurance-related and is selected only in the high baseline, so expect a closer look at how the decisions were made and kept current. Start by confirming the parameter values against the SP 800-53A examine objects, which include the list of failures, the state information to be preserved, the system design documentation and the configuration settings with their documentation. Then ask your engineering team to show failure tests or recorded results for the listed components. Open-source tools such as Prometheus and Grafana can help by collecting metrics and alerting when a component leaves its known state, but the control's requirement is set by your own parameter decisions, and you should confirm with your assessor which records they accept as evidence.
Which components and failure modes SC-24 applies to
SC-24 is only as useful as the definitions behind it. The organization must decide which components fail to a known state, which failure types it designs for, and where the state worth preserving lives. Each card below is a decision the organization owns, with the related controls that overlap it.
Defining the in-scope components
SC-24 requires the organization to name the components that must fail to a known state. Start with components whose failure could expose data, break access enforcement or leave a boundary open, such as firewalls, load balancers, authentication proxies, key management services and the security logging pipeline. Document the list as an organization-defined parameter with a reason for each entry. An assessor will compare the list against system design documentation, so an entry that the design does not describe will be questioned.
Choosing the failure types that matter
Each component needs a defined set of failure types it is designed to survive. Typical types include power loss, process crash, network loss, storage fault and control plane failure. Power loss and process crash often leave different state behind than a network partition, so a single generic answer is hard to defend. Record which failure types apply to each component and what the known state is for each one, such as closed for a boundary device or read-only for a configuration store.
Locating state information to preserve
The control asks which system state must survive a failure. In practice this means session tables, connection state, pending transactions, audit buffers and configuration versions. Map where each item lives, whether in memory, on local disk, in a database or in a control plane, and decide what must be recovered and what can be rebuilt. Confirm the storage location with the system owner before writing the parameter, because state held only in memory is lost on a crash.
Overlap with SC-7 and SC-22
SC-7 governs boundary protection and SC-22 governs the architecture of name and address resolution. A firewall or DNS resolver that fails open would defeat both, so SC-24 is often where their failure behavior is tested. Decide whether a failed boundary device blocks all traffic or passes it, and whether resolvers keep serving a last known good answer. Record the answer once and reference it from each control so the three assessments agree.
Overlap with CP-2, CP-10 and SI-13
Contingency planning (CP-2 and CP-10) covers how the system recovers and reconstitutes after disruption, and SI-13 covers predictable failure prevention and mean time to failure. SC-24 sits at the design layer, so the known state it defines should match the recovery steps in the contingency plan. If the contingency plan restores from backup while SC-24 assumes the device stays closed, the two documents conflict. Check that the recovery procedure and the failure state use the same definitions.
Evidencing the Class D and KSI-CNA-EIS links
FedRAMP's Rev5 baselines require SC-24 at Class D, and FedRAMP 20x lists SC-24 among the related controls for KSI-CNA-EIS (Enforcing Intended State). Whether that applies depends on the authorization the organization is pursuing, so confirm the class and key security indicator with the authorizing body before scoping. The organization must make the component and failure definitions itself. An implementation partner can prepare test records and configuration evidence, but it cannot decide what the known state should be.
How an assessor tests SC-24
This table maps the single SP 800-53A Release 5.2.0 determination statement for SC-24 to the examine objects an assessor reviews, the evidence that usually satisfies each one, and the findings that appear most often. Read it as a checklist of what to prepare before an assessor arrives, since most SC-24 gaps come from documents that do not match the running configuration.
| Assessment element | What the assessor checks | Evidence that passes | Common finding |
|---|---|---|---|
| Determination statement | The organization defines the components that fail to a known state, the failure types, and the state to preserve, and the system does so | Parameter values recorded in the system security plan with the matching design and configuration evidence | Parameters left undefined or described only in general terms |
| Examine: list of failures | A documented list of failure types that require the system to fail in a known state | A failure list tied to named components, such as authentication services, boundary devices or key stores | The list covers only one component class or omits network and storage failures |
| Examine: state information to preserve | The defined system state information kept through a failure for recovery | A written inventory of preserved state, such as configuration, session or transaction records, with the storage location | No inventory exists, or preserved state is not named in the plan |
| Examine: system design documentation | Whether the design describes how each component reaches its known state and keeps the state information | Architecture and design documents that describe fail-closed or fail-open behavior per component | Design text is generic and does not name the components or failure modes in scope |
| Examine: configuration settings and documentation | Whether live settings implement the design, such as restart behavior, failover modes and state retention | Exported configuration files and settings records that match the design, with change history | Design documents do not match configuration, or settings were changed without updating the documents |
| Interview method | Whether administrators and engineers can explain the known states and how recovery begins | Staff who can describe the failure list and the recovery steps consistently with the documents | Staff describe behavior that differs from the written design |
| Test method | Whether a controlled failure drives the component into the defined known state and preserves the defined state information | Test records showing the induced failure, the resulting state and the preserved data, retained for the assessor | No evidence that the design claims were exercised, or preserved state was lost during the test |
Implementing SC-24 step by step
This sequence turns SC-24 from a single assessment determination into a documented, tested design in which each defined component has a known failure state, the state information it must keep is named, and the results are on file for an assessor. Each step produces an artifact that the next step depends on.
Define the parameter values in the system security plan
The system owner and security lead fill in the three organization-defined parameters for SC-24 in the system security plan: the components that must fail to a known state, the types of failure that trigger it, and the system state information that must be preserved. Because the release has no enhancements, these three values carry the whole control, so vague wording here will show up as a finding later. The step is complete when each parameter names specific components and failure types, and the plan states who approved them. The output is the SC-24 entry in the plan with approved parameter values.
Map each component to a known failure state
Engineering staff list every component named in the parameters, such as network devices, application tiers, databases, identity services and management consoles, and record the defined known state each one should enter on each failure type. A known state might be fail-closed for an access path or a documented read-only state for a data store, but the choice must be deliberate and per component. The step is complete when every parameter component has one written failure state per failure type. The output is a failure-state matrix that the assessor can compare against the design documentation.
Design preservation of system state information
Architects specify what state information must survive a failure, such as session records, transaction logs, configuration snapshots or in-flight queue contents, and where it is stored and how it is restored. The design should show that preserved state does not itself become a path for an attacker or a source of inconsistent recovery. The step is complete when each preserved item has a storage location, a protection method and a restore procedure reviewed by the platform owner. The output is a design note that links state items to the failure states from the previous step.
Configure and document the settings
Platform engineers apply the chosen failure behavior in the open-source components, such as watchdog timers, health checks, service restart policies, load balancer fail-closed rules, or database read-only modes, and keep each setting under version control. Configuration keys and file names are recorded with the values in use and the component owner. The step is complete when a reviewer can trace each matrix entry to a specific configuration in the repository. The output is a configuration baseline and a settings register that matches the design note.
Test failure behavior in a non-production environment
The test team reproduces each defined failure type in an isolated, non-production copy of the system and observes whether each component reaches its documented known state and whether the preserved state information is intact afterward. Tests should include failures that occur during active transactions or sessions, not only clean shutdowns. Open-source monitoring can record the state transitions, for example by alerting on health-check failures in Grafana or by querying component metrics in Prometheus. Any deviation becomes a tracked defect with an owner. The output is a test plan with each run's result, timestamps and screenshots or log extracts.
Record results and close gaps
The security lead compares the test results with the failure-state matrix and the design note, records each component as meeting, partially meeting or not meeting its defined state, and routes any gap into the plan of action and milestones with a named owner. Retesting confirms closure, and the parameter values are revisited if testing showed a defined state was not achievable. The step is complete when every parameter has a passing result or an accepted, documented gap. The output is the signed test report and an updated SC-24 entry in the system security plan. Organizations should confirm with their independent assessor which evidence format they expect.
What a fail-to-known-state design looks like in practice
The first decision an organization must make for SC-24 is what known state a component should move to when a defined failure occurs, and it must justify that choice in writing. A fail-closed design stops processing and denies access until the fault is cleared, which protects confidentiality and integrity at the cost of availability. A fail-open design keeps the service running and passes traffic or requests without the normal checks, which favors availability but can let an attacker or a fault bypass a security function. A fail-safe design moves the component to a state that is physically or logically harmless for its purpose, such as a control that holds its last safe output or a gateway that drops only the affected flows. None of these is correct in general. The control text leaves the failure types and the target state as organization-defined parameters, so the decision belongs to the system owner and the risk acceptance record, not to the vendor default.
The second decision concerns what state is preserved so the system can recover. Typical candidates include configuration versions, session or transaction records, cryptographic key material references, audit records written before the failure, and the position of in-flight work. Preservation has to be deliberate: state that is written to memory only is lost on a crash, while state written to storage that is not protected can leak or be tampered with on restart. Ask the team to list each preserved item, where it lives, who can read it, and how the component confirms it is intact before resuming. The SC-24 assessment expects this to appear in system design documentation and in configuration settings, so the answers should be written down where an assessor will look for them.
The design must then be tested rather than assumed. Plan fault injection for each failure type named in the parameters, such as loss of a dependent service, certificate expiry, a stalled log pipeline or a failed policy check, and record the state the component actually reaches and what it preserved. Compare the observed result with the documented target state, and treat any gap as a finding with an owner and a date. Monitoring is part of the test: an alert that fires when a component enters its known failure state, built in a tool such as Prometheus or Grafana Alerting, gives the team evidence that the failure was seen. Confirm with your own engineers and any independent assessor which test methods they accept, since the assessment procedure names examine, interview and test methods.
Evidence that passes an SC-24 assessment
SC-24 is assessed largely from documents and records that show a designed failure behavior exists, was tested and stays current. The cards below group the artifacts an assessor will ask for, each with the check that keeps it accurate between assessments.
Parameter definitions in the SSP
SC-24 has three organization-defined parameters: the components that must fail to a known state, the failure types that trigger it, and the state information that must be preserved. The system security and privacy plan should state each value explicitly, with the component names as they appear in the inventory. Between assessments, check that the parameters still match the current architecture after any new component, failover path or change in failure handling. An assessor will compare the SSP wording against the design documentation, so a mismatch is a common finding.
Design documentation of failure states
Design records should describe, for each defined component, what the known state is (for example, a locked, closed or safe mode), what triggers a transition into it, and how the component returns to normal operation. Diagrams of fail-closed and fail-open decisions for security functions are the artifacts assessors read first. Review the documentation whenever a dependency, such as a load balancer, authentication service or firewall rule set, changes its failure behavior, because stale diagrams are a frequent gap.
Configuration baselines for failover and restart
Configuration records should show the settings that enforce the known state, such as default deny rules applied on restart, health check thresholds, watchdog timers and restart policies, along with the file or configuration key that holds each one. Store these in version control so the baseline and its history are provable. Re-verify the settings against the running systems on a fixed schedule set by your ISCM strategy, and record any drift as a finding with an owner.
Failure injection test records
Test records are the strongest evidence that the design works. Each record should name the failure injected (for example, a killed process, a severed network path or an unavailable dependency), the expected known state, the observed state, and the time taken to reach it. Keep the test plan, raw output and the sign-off by the person who reviewed the result. Rerun tests after any change to the component under test, and keep failed runs with their remediation, since assessors value an honest record over a clean one.
State preservation logs
The control also requires that defined state information survives a failure. Logs should show that the preserved data, such as session records, transaction state or configuration snapshots, was written before the component entered the known state and was recovered correctly afterward. Confirm log retention covers at least the test window and the period assessors sample. Check that the logs themselves are protected, since a failure that erases its own evidence will not pass review.
Change records for failure behavior
Changes to failure handling should go through the configuration change process, with a ticket that names the affected SC-24 component, the reviewer, the test evidence and the approval date. Tie each change to an updated design document and baseline. Review the change log at each assessment cycle to confirm that no failure-behavior change bypassed review, since assessors sample change records against the baseline to detect untracked edits.
What meeting SC-24 costs and what drives it
The largest one-time cost is usually design work: deciding which components must fail to a known state, what that state is, and which state information must survive a failure. This work is done once for each component class, then revisited when architecture changes. NIST does not estimate what this costs, so the figure depends on how many distinct components your system contains and how much each one differs from the others.
- Component count: Each distinct component type, such as load balancers, identity services, databases and message brokers, needs its own defined failure behavior.
- Failure type breadth: Fail-safe behavior for a crash differs from behavior for a network partition or a corrupted configuration, so more failure types add design decisions.
- Reuse of platform defaults: Where a self-hosted platform already offers documented restart, fallback or state-persistence behavior, design time shrinks, but the default must still be checked against your parameters.
- Documentation of decisions: Design rationale written during this phase is the material an assessor reads, so writing it late costs more.
Ask the proposer to list the components in scope and the failure types they will design for, and to state which of those decisions are one-time and which are revisited per release.
SC-24 asks for failure behavior to be proven, so testing is a distinct cost. SP 800-53A Rev. 5 assesses SC-24 with examine, interview and test methods, which means someone has to induce failures and record what the system did. Testing effort grows with the number of defined failure scenarios and the number of components that must be exercised.
- Failure injection scenarios: Each defined failure type on each in-scope component is a test case that must be designed, run and repeated after changes.
- Environment cost: Realistic failure tests need a non-production environment that resembles production, which may be an added infrastructure line.
- Retesting after change: Every significant architecture or configuration change can invalidate earlier results, creating a recurring cost.
- Test evidence capture: Logs, screenshots and timestamped outputs from each run are part of the cost, not an afterthought.
Ask for the test plan, the number of scenarios it contains, and whether retesting after each change is included in the fixed fee or billed separately.
Evidence for SC-24 is recurring. Configuration settings, design documentation and monitoring outputs change as the system changes, and an assessor will expect current material rather than a snapshot from the last review. This upkeep is often the cost that organizations underestimate, because it runs for as long as the control is in scope.
- Configuration drift checks: Scheduled checks that confirm failure-related settings still match the documented design, using tools such as Wazuh Security Configuration Assessment for endpoint configuration.
- Policy status records: Fleet policies answer yes or no questions about devices and show which devices pass or fail, which can serve as a recurring record if the policies are maintained.
- Monitoring and alert history: Grafana Alerting rules built on Prometheus metrics can show when a component entered an unexpected state and whether it recovered.
- Documentation currency: Design documents and configuration baselines need owners and review dates.
Ask who maintains each evidence source after the initial engagement ends, and how often the proposer expects to refresh evidence.
Independent assessors examine evidence and may sample components and failure scenarios. The assessor's fee is paid to the assessor, not to the implementation partner, and it depends on the assessment scope and the sampling the assessor chooses. DeployOpen prepares systems and evidence but does not issue assessment reports, so the assessor's cost sits outside any implementation quote. FedRAMP's Rev5 baselines require SC-24 at Class D, which means it is part of the FedRAMP assessment scope where that applies. NIST notes that Inspectors General independently assess agency systems under FISMA, a reminder that assessment cost is set by the assessing body.
- Sample size: The more components and failure scenarios in scope, the more an assessor may need to examine.
- Assessor independence: Review by a party not involved in building the controls is required by the assessment model.
- Re-assessment cycles: Ongoing assessments recur, so their cost recurs with them.
- Evidence readiness: Well-organized evidence usually shortens the examination, but this is an observation about effort, not a guaranteed saving.
Ask the assessor to confirm sampling assumptions in writing before the engagement starts.
Commercial monitoring, configuration assessment and alerting products often carry recurring license fees that scale with endpoints, hosts or data volume. Self-hosted open-source tools can reduce that license line, but they move cost into installation, hardening, integration and operations. Wazuh is GPL-2.0-only, Fleet is MIT, Grafana is AGPL-3.0-only and Prometheus is Apache-2.0, so license terms differ and should be reviewed by your legal team before adoption. Licensing does not remove the engineering, testing or evidence work described in the other tabs.
- Reduced license lines: Self-hosted tools remove per-seat or per-host subscription fees for the tools themselves, though support contracts may still apply.
- Operations staffing: Someone must run, patch and upgrade each tool, which is a recurring labor cost.
- Integration effort: Connecting monitoring, alerting and configuration tools to each other and to evidence storage is one-time work that recurs when versions change.
- License review: Confirm the obligations of AGPL-3.0 and GPL-2.0 for your deployment model with counsel.
Ask the proposer to show the license fees removed, the labor added, and the support model for each open-source tool in the written quote.
Open-source tools that support SC-24 evidence
Can Wazuh show that systems are configured to fail to a known state?
Wazuh can show that a configuration setting you have chosen to check is in the state you expect, which is supporting evidence for SC-24 but not proof of failure behavior. Its Security Configuration Assessment scans monitored endpoints against YAML policies, most of which are based on CIS benchmarks and can be extended with custom policies. Each policy checks files, directories, registry keys and running processes, and it recommends remediation for failed checks. For SC-24, you would write or select checks for the settings that govern fail-closed or fail-safe behavior, such as service startup and recovery options, firewall default actions, and failure handling in security components, then keep the scan results with the system's configuration documentation. Confirm with your assessor which settings they expect to see for your components, because the control depends on the design you define.
How do Fleet policies help with yes or no checks on fail-safe settings?
Fleet policies answer yes or no questions about devices, written as osquery queries, and the policies page shows which devices in each fleet pass or fail each policy. This suits SC-24 when the question is binary, for example whether a host's firewall is enabled by default, whether a critical service is set to restart on failure, or whether a device's disk encryption is active, which matters when state must be preserved. A failing device appears in the results, so you can track remediation against the same policy over time. Export or screenshot the pass and fail history as dated evidence. Fleet does not test what happens when a component actually fails, so pair its results with failure testing performed under your documented procedures. Fleet is released under the MIT license.
How can Grafana Alerting document failure conditions across metrics and logs?
Grafana Alerting builds alert rules from queries and expressions across multiple data sources, so one rule can watch metrics and logs together, and it gives teams one view to create, manage and act on alerts. For SC-24, alert rules can fire when a component drops into an unexpected state, such as a health endpoint failing, error rates rising after a dependency fails, or a watchdog metric going silent. The alert history and notifications show that the condition was detected and routed to people who act on it. Alerts show detection, not the designed fail-safe behavior, so keep the rule definitions, their owners and sample notifications in the documentation set that describes the failure states you chose. Grafana is licensed under AGPL-3.0-only, which applies to modified versions you distribute or make available over a network, so confirm the license terms with your legal team before you change its source.
What does Prometheus contribute to SC-24 failure evidence?
Prometheus collects metrics from instrumented jobs through a pull model over HTTP, stores them as time series identified by metric name and labels on its local storage, and queries them with PromQL. For SC-24, these time series give you a timestamped record of component health, restart counts, error rates and state metrics before, during and after a failure test. The data can show whether a component reached the state you defined and whether state information was preserved in the way your design describes. Prometheus stores data on local storage, so set retention and back up the data according to your records requirements. Prometheus is licensed under Apache-2.0. Confirm which metrics your assessor expects to see for each failure type, since the choice depends on the components and the failures you have listed.
Do these open-source tools alone prove a system fails to a known state?
No. None of Wazuh, Fleet, Grafana or Prometheus proves design behavior on its own. Each one produces evidence of a state or condition at a point in time: configuration checks, device policy results, alert history or metric series. SC-24 asks for a defined failure list, a defined known state, defined state information to preserve, and design documentation that explains these choices. The assessment procedure looks at the failures requiring a known state, the state information to be preserved, the system design documentation and the configuration settings with their documentation, and it uses interviews and tests to confirm them. Your organization owns the design and the decision about what counts as a known state. An implementation partner can prepare the tooling and document the evidence, but only an independent assessor issues the assessment conclusions.
Which SC-24 evidence should I collect from each tool?
Collect evidence that ties each tool's output to a defined failure and a defined known state:
- Wazuh: policy definitions, scan results with dates, and remediation records for failed checks.
- Fleet: policy queries, pass and fail history by device, and records of how failing devices were fixed.
- Grafana: alert rule definitions, owners, notification history and the runbooks linked to each rule.
- Prometheus: retained time series for the failure tests, the queries used to read them, and the retention settings.
Keep the failure list and the design documentation alongside these exports, and map each item to the failure type it supports. Ask your assessor to confirm the format and period of evidence they expect.
Can we set up these tools ourselves, or do we need outside help?
Your team can run these tools without outside help if it has the skills to deploy and maintain them, write the checks and queries, and document the evidence. The work that often takes outside help is defining which failures matter and what state each component should reach, deploying the tools in your own environment with consistent configuration, and building evidence packages that an assessor can follow. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue audit reports or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Ongoing support is available as a retainer.
What should I confirm about licensing before deploying these tools?
Confirm the license obligations for each tool with your legal team before you deploy or modify it. Wazuh is licensed under GPL-2.0-only, Fleet under MIT, Grafana under AGPL-3.0-only and Prometheus under Apache-2.0. These licenses differ in their conditions for redistribution, modification and network use, so the obligations for internal use may differ from those for a product you distribute or host for others. Note that the license applies to the software, not to the evidence it produces. Check the current license texts in each project's repository, and record the version you run so your evidence matches the configuration an assessor reviews.
Who defines, implements and assesses SC-24
Your organization owns SC-24. Before anyone configures anything, your team has to decide which components must fail to a known state, which types of failure trigger that behavior, and which state information must survive the failure. Those choices fill the organization-defined parameters that SC-24 leaves open, and they must reflect your system's risk, mission and recovery needs. The design decisions and the accountability for them stay with your people, even when outside help writes the configuration.
- Parameter decisions: Define the components, failure types and preserved state information in writing, and approve them through your normal governance.
- Design ownership: Keep the system design documentation current so it explains the intended failure behavior.
- Risk acceptance: Record any failure state you decide not to implement, with the reason and the approver.
- Operational owners: Name the people who respond when a component fails to its known state.
- Review cycle: Revisit the parameters when the architecture, the baseline or the threat picture changes.
Check that your parameter decisions are documented and approved before the implementation partner starts, because an assessor will compare the running configuration against them.
An implementation partner such as DeployOpen can prepare the systems that make SC-24 work. Under a written, fixed scope, the partner can configure self-hosted open-source platforms in your own infrastructure so components fail to the states your team defined, test those behaviors, and assemble the configuration records and test results an assessor will ask for. The partner prepares the evidence. It does not decide the parameters, accept the residual risk or certify the result.
- Configuration work: Build failure handling into the platforms and document the settings that enforce it.
- Failure testing: Induce the defined failure types in a controlled environment and record the observed state and recovery.
- Evidence packaging: Collect configuration files, test output and monitoring records mapped to the SC-24 determination statement.
- Documentation support: Draft the design and configuration documents for your team to review and approve.
- Handover: Transfer ownership of runbooks and configuration so your staff can operate and maintain the controls after the engagement.
Ask the partner to state in the written scope which deliverables it will produce, and confirm that the scope excludes issuing any audit report, attestation or certification.
The independent assessor examines SC-24 and decides whether it is met. SP 800-53A Release 5.2.0 gives the assessor one determination statement for SC-24, tested with examine, interview and test methods. The assessor reviews the list of failures that require a known state, the state information to be preserved, the system design documentation and the configuration settings with their documentation, then interviews staff and may observe a test. Only the assessor issues findings, and only an independent assessor or certification body can issue a report or certificate.
- Examination: The assessor reviews the failure list, preserved state definitions, design documents and configuration settings.
- Interviews: Staff explain how failures are detected, how the system reaches the known state and who acts afterward.
- Testing: The assessor may ask for a demonstration of a defined failure and check the resulting state.
- Findings: Any gap is recorded as a finding that your team tracks in its plan of action and milestones.
- Independence: The assessor must not design or configure the controls it tests, which is why DeployOpen does not issue reports or certifications.
Confirm with your assessor which evidence formats it accepts and whether it wants the test performed by your staff, the partner or the assessor itself.
Where SC-24 evidence usually falls short
Most SC-24 findings do not come from missing technology. They come from parameters nobody filled in, failure behavior that was designed but never exercised, and documents that describe a system that has since changed. The cards below cover the gaps assessors most often find, each with the check that closes it.
Undefined parameter values
SC-24 has three organization-defined parameters: the components that must fail to a known state, the failure types that trigger it, and the state information to preserve. An assessor cannot test a requirement whose values are blank or generic. Confirm that each parameter names specific components, specific failure conditions and specific state data, and that the system security plan repeats the same values.
Failure behavior assumed, never tested
Teams often assume a firewall, load balancer or application service fails closed because the vendor documentation says so. The examine and test methods in SP 800-53A expect proof. Run controlled failures in a non-production copy of the environment, record what the component does, and keep the results with the test date and configuration version.
State information not identified
Preserving state requires knowing what state exists. Session tables, transaction queues, key material, audit buffers and policy caches are common examples, and each has a different recovery need. Build an inventory of stateful components for each in-scope system, mark which state must survive a failure, and document where it is stored and how it is restored.
Design documents out of date
Assessors compare the design documentation against the configuration settings. When a load balancer rule, a fail-safe mode or a recovery script changes but the architecture diagram does not, the two disagree and the control looks unmanaged. Tie each design document to the configuration repository, review both at each change, and record the reviewer and date.
Cloud provider behavior not confirmed
Failover, managed database and load balancer behavior often sits with a cloud provider or managed service. Organizations sometimes cite the provider's general resilience claims as SC-24 evidence without checking the specific component and region. Ask the provider for the documented failure behavior of each service in use, confirm it against your configuration, and test it in your own account.
Monitoring that cannot show failures
Failures to a known state are only useful if someone sees them. Without alerting on state changes, a component can fail open for hours with no record. Use an alerting tool to flag a failed component, and keep the alert rule, its threshold and sample notifications as evidence that failure events reach responders.
SC-24 questions buyers ask before hiring help
How much effort does SC-24 fail in known state take?
SC-24 is one of the narrower controls in the SC family because it has no enhancements and only three organization-defined parameters, but the effort sits in the design work it forces. Your team must list the components that need a defined failure state, define what the known state is for each, and decide which types of failure trigger it. Then it must document what state information is preserved for recovery. The effort scales with the number of components and failure modes in the boundary, not with the control text. No duration is given here, so ask any partner to size the work from your architecture inventory in writing.
Can we implement SC-24 in-house without outside help?
Yes, the organization owns its controls and can implement SC-24 with its own engineers, provided they understand failover design, configuration management and recovery. Most teams find the hard part is evidence: an assessor will examine the list of failures, the preserved state information, the design documentation and the configuration settings, and expects them to agree with each other. An outside partner is useful when the team lacks capacity or when platforms need hardening or instrumentation. Only an independent assessor can test the control and issue a report.
What does the work need from our engineering team?
The work needs people who can describe how each component behaves when it fails. Typically this means:
- Platform or infrastructure engineers who know how load balancers, databases, message queues and clusters restart or stop.
- Application owners who can define the state that must survive a failure, such as transactions or session data.
- Security or compliance staff who map the results to the SC-24 determination statement and assessment objects.
Engineers should also keep the design documentation current, because an assessor compares it against live configuration.
How long does SC-24 implementation take?
No researched duration exists for SC-24, so this page does not state one. The timeline depends on how many components need a defined known state, how much of the design is already documented, and whether the assessment window is fixed by a contract or authorization. Ask any partner for a timeline tied to a written scope, and confirm with your assessor which evidence they will expect before work starts.
Is SC-24 required outside the high baseline?
In SP 800-53B, SC-24 is selected only in the high security control baseline, so moderate and low systems do not need it under that baseline. Other frameworks or contracts may still ask for it. FedRAMP's Rev5 baselines require it at Class D, so confirm which baseline and class your authorization uses. Your contract, agency or customer may also add it by tailoring, so check those documents rather than relying on the baseline alone.
What should a partner's written scope for SC-24 include?
A written scope should name the systems and components covered, the failure types that trigger a known state, and the known state defined for each component. It should also list the state information preserved for recovery and the configuration settings and design documents delivered. Include who owns each deliverable, what the partner will not do, and how changes after handover are handled. Because DeployOpen works on fixed-scope engagements agreed in writing before work starts, the scope document is where those points are fixed. Quotes follow from that scope, not from a published price list.
How do open-source tools help show SC-24 evidence?
Monitoring and configuration tools can show that components behave as the design says, which supports the examine and test methods. Prometheus collects metrics over HTTP and stores them as time series, and Grafana Alerting can alert on metrics and logs together, which helps show when a component entered a failure state. Fleet policies and Wazuh configuration assessment can check that endpoints match defined settings. Confirm with each assessor which artifacts they accept, because tool output supports the design documentation but does not replace it.
Where to read the control and its procedures
Start with the primary text before you scope anything for SC-24. The Release 5.2.0 OSCAL catalog published by NIST in the usnistgov/oscal-content repository holds the exact wording of SC-24, Fail in Known State, including its three organization-defined parameters, which are the places where your organization must make its own decisions: which components must fail to a known state, which failure types trigger that behavior, and which system state information must survive the failure. Because the control has no enhancements in Release 5.2.0, those parameters carry most of the work. Read the catalog entry alongside the SC-24 related controls it lists (CP-2, CP-4, CP-10, CP-12, SA-8, SC-7, SC-22 and SI-13), since contingency planning and boundary protection are where most of the evidence for fail-safe behavior will actually live.
Next, open the SP 800-53A Release 5.2.0 assessment procedure for SC-24. It contains one determination statement and examine objects that tell you what an assessor will ask for: the list of failures that require a known-state response, the state information to be preserved, system design documentation, and system configuration settings with their documentation. Treat these objects as your evidence checklist. Confirm the current wording in the CPRT and the OSCAL files before you rely on it, because NIST issues changes as numbered releases.
If your system is pursuing FedRAMP authorization, check the FedRAMP Rev5 control reference for the SC-24 requirement at Class D, and confirm it against the FedRAMP Consolidated Rules for 2026 that FedRAMP publishes in machine-readable form, since the baseline requirement is what the assessor will test. Confirm the baseline wording and any FedRAMP-specific guidance with FedRAMP or your 3PAO before you commit to a design, and note that SP 800-53B places SC-24 only in the high baseline, so a moderate system may not inherit the same expectation. Record the sources you used and their release identifiers in your control implementation statement so that the next reviewer can see which version your design was built against.
How DeployOpen prepares SC-24 evidence
DeployOpen approaches SC-24 Fail in known state as an engineering and evidence task inside your own infrastructure. We define the failure cases and known states with your team, build and test them in self-hosted open-source platforms, and hand over documentation an independent assessor can examine. Your organization owns the control; DeployOpen prepares the systems and evidence.
How we scope
- We agree in writing which components must fail to a known state and which failure types are in scope.
- We record the known state and the state information to preserve for each component, with your owners named.
- Engagements are fixed-scope, so deliverables and timelines are settled before any build work begins.
How we build
- We configure fail-closed behavior and state preservation in your self-hosted platforms, inside your cloud accounts or data centers.
- We test induced failures against the defined known states and record the results for each component.
- We set up monitoring and alert rules so failures to a known state are visible to operators when they occur.
How we hand over
- We deliver design documentation and configuration settings that match the known states your assessor will examine.
- We provide test records and monitoring evidence showing failures produced the defined known state and preserved state information.
- We hand over the package to your team, so your organization can present it to its independent assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can repeat failure tests after platform upgrades or configuration changes that touch known states.
- Ask us to confirm scope, deliverables and retainer terms in writing before any work starts.
