Quick-reference card
| Field | Value |
|---|---|
| Control ID | SI-17 |
| Control Name | Fail-safe Procedures |
| Framework | NIST SP 800-53, Revision 5 |
| Control Family | System and Information Integrity |
| Baselines | — |
| Relevance | System (First Party and Third Party) |
| Risk Severity | Low |
What this control requires
SI-17 requires organizations to define and implement fail-safe procedures that activate automatically when specific system failure conditions occur. Rather than allowing systems to fail unpredictably, this control mandates that organizations predefine what happens when critical components stop working, communication links drop, or operational connections break down.
Without documented fail-safe procedures, system failures cascade in ways that are difficult to contain. Operators may not know what steps to take when communication between critical system components is lost, and ad hoc responses tend to introduce additional vulnerabilities. The NIST SP 800-53 framework addresses this gap by requiring organizations to pair every anticipated failure condition with a corresponding response procedure.
In practice, implementing SI-17 means identifying the specific failure conditions your environment faces and mapping each one to a documented response. Those responses might include alerting operator personnel, reestablishing system settings, shutting down affected processes, restarting the system, or escalating to designated organizational personnel. The goal is removing ambiguity from failure response so that operators follow a predetermined path instead of improvising under pressure.
Why it matters
Organizations that lack predefined fail-safe procedures face audit findings and compliance gaps that undermine their overall security posture. Auditors expect documented evidence that failure conditions have been anticipated and that corresponding response procedures exist. Missing this control introduces risk that extends beyond technical failure into regulatory and certification territory.
Failure to maintain SI-17 can result in certification withdrawal or unfavorable findings during federal authorization assessments. Assessors specifically look for documented lists of failure conditions paired with tested response procedures. Organizations that treat fail-safe planning as optional often discover the gap during an audit, when remediation timelines are compressed and stakes are highest.
Building cyber resilience requires treating failure as inevitable rather than exceptional. Systems will lose communication links, components will degrade, and operational connections will break. The difference between a controlled response and a chaotic one comes down to whether fail-safe procedures were defined, documented, and rehearsed before the failure occurred.
How to implement
The most common failure mode for SI-17 implementation is treating it as a documentation exercise rather than an operational capability. Organizations write generic fail-safe policies but never map them to specific system components or test whether operators can execute the procedures under realistic conditions.
For your organization
Start by inventorying the critical communication paths and dependencies in your environment. Identify every connection between system components and between those components and your operational facilities. Each connection represents a potential failure point that needs a corresponding fail-safe procedure.
Document a fail-safe procedure for each identified failure condition. Each procedure should specify the triggering condition, who gets alerted, what information the alert contains, and the specific steps operator personnel must follow. Avoid vague instructions like “contact IT support.” Instead, name the designated organizational personnel, provide contact information, and define the decision tree for subsequent steps.
Common subsequent steps to document include:
- Doing nothing (when the failure is non-critical and self-resolving)
- Reestablishing system settings to a known-good configuration
- Shutting down affected processes to prevent cascading failures
- Restarting the system or affected subsystem
- Contacting designated organizational personnel for escalation
Test your fail-safe procedures through tabletop exercises and, where feasible, controlled failover drills. Testing reveals gaps that documentation alone cannot surface, such as whether alerting mechanisms reach operator personnel or whether system settings can be reestablished within acceptable timeframes. Maintain records of each test, including outcomes and corrective actions.
Integrate your fail-safe procedures with your broader incident response plan. Fail-safe procedures often overlap with incident response workflows, and misalignment between the two creates confusion during actual failures. Review and update your fail-safe procedure documentation at least annually and after any significant system architecture changes.
A common mistake is defining fail-safe procedures at the policy level without mapping them to specific technical configurations. Your system design documentation should reference the fail-safe procedures and explain how system configuration settings enforce them. Use your NIST 800-53 compliance checklist to verify that all required artifacts are in place.
For your vendors
When assessing vendors against SI-17, request evidence that the vendor has identified failure conditions specific to the services they provide to your organization and has documented corresponding fail-safe procedures.
Key questionnaire questions to include:
- What failure conditions have you identified for the systems that process, store, or transmit our data?
- What fail-safe procedures activate when those failure conditions occur?
- How do you alert operator personnel when a failure condition triggers?
- What are the specific subsequent steps your personnel follow after a failure event?
- How frequently do you test your fail-safe procedures, and can you provide test results?
Evidence to request:
- The vendor’s documented list of failure conditions and associated fail-safe procedures
- System design documentation showing how fail-safe procedures are integrated
- Records of fail-safe procedure testing, including dates, scope, and outcomes
- Configuration documentation demonstrating automated fail-safe mechanisms
Red flags to watch for:
- Vendors who cannot produce a specific list of failure conditions for their environment
- Generic fail-safe documentation that doesn’t reference specific system components or communication paths
- No evidence of fail-safe procedure testing within the past 12 months
- Fail-safe procedures that lack designated personnel or contact information for escalation
Verify that the vendor’s fail-safe procedures account for failures that could affect your data or service availability. A vendor may have robust internal fail-safe procedures but no documented response for failures that impact customer-facing systems or data flows.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Policy documentation | System and information integrity policy defining fail-safe requirements, roles, and review cadence |
| Fail-safe procedure documentation | Documented list of failure conditions paired with specific response procedures, designated personnel, and subsequent steps |
| System design documentation | Architecture diagrams and design documents showing how fail-safe procedures integrate with system components and communication paths |
| Configuration evidence | System configuration settings and screenshots demonstrating automated fail-safe mechanisms, alerting thresholds, and failover triggers |
| Security safeguard documentation | List of security safeguards protecting system memory from unauthorized code execution during failure states |
| Test records | Fail-safe procedure test results including dates, scope, pass/fail outcomes, and corrective actions taken |
| System security plan | System security plan sections addressing SI-17 implementation status, planned milestones, and responsible personnel |
| Audit records | System audit logs capturing fail-safe procedure activations, alert deliveries, and operator response actions |
Cross-framework mapping
No applicable cross-framework mappings have been configured for this control.
Related controls
- CP-12 — Safe Mode: Defines the secure operating state that systems transition to during failures, complementing the procedural response that SI-17 requires.
- CP-13 — Alternative Security Mechanisms: Provides backup security functions when primary mechanisms fail, working alongside fail-safe procedures to maintain protection during degraded operations.
- SC-24 — Fail in Known State: Specifies the technical requirement for systems to enter a defined secure state upon failure, while SI-17 governs the procedural response that supports that transition.
- SI-13 — Predictable Failure Prevention: Focuses on anticipating and preventing component failures before they occur, reducing the frequency of scenarios where SI-17 fail-safe procedures activate.
Frequently asked questions
What is NIST SP 800-53 SI-17?
SI-17 is a NIST SP 800-53 control that requires organizations to implement predefined fail-safe procedures when specific system failure conditions occur. The control mandates identifying failure conditions, such as loss of communication among critical system components, and pairing each condition with documented response steps. Those response steps include alerting operator personnel, reestablishing system settings, shutting down processes, restarting systems, or contacting designated organizational personnel.
What happens if SI-17 is not implemented?
Without SI-17, system failures trigger ad hoc responses that increase downtime and create security gaps. Operator personnel lack specific instructions on subsequent steps, leading to inconsistent and delayed recovery actions. Organizations also face audit findings and potential certification issues, as assessors verify that documented fail-safe procedures exist and have been tested against identified failure conditions.
How do you audit SI-17?
Auditors verify SI-17 by examining the organization’s documented list of failure conditions and confirming that each condition has an associated fail-safe procedure. The assessment validates that fail-safe procedures have been implemented, that alerting mechanisms reach operator personnel, and that test records demonstrate the procedures work as designed. Auditors also review system configuration settings and system design documentation to confirm that automated fail-safe mechanisms align with the documented procedures.
What is the difference between fail-safe and fail-secure?
Fail-safe procedures prioritize system availability and operator safety by transitioning to a known, stable state when failures occur, while fail-secure mechanisms prioritize denying unauthorized access by defaulting to a restrictive state during failure. SI-17 focuses on the procedural response to failure conditions, including alerting personnel and defining subsequent steps. SC-24 (Fail in Known State) addresses the complementary technical requirement of ensuring systems enter a defined secure state, making the two controls natural partners in a comprehensive failure response strategy.