SA-24: Design For Cyber Resiliency

Quick-reference card

What this control requires

SA-24 requires your organization to engineer cyber resiliency directly into the design of systems, components, and services. This control goes beyond conventional security hardening by demanding that you define goals, objectives, techniques, implementation approaches, and design principles specifically aimed at sustaining operations during and after adversarial events.

In practice, this means you can’t treat resiliency as an afterthought bolted onto finished architectures. You need to build it into the system and services acquisition lifecycle from the start. SA-24 calls for defining what resiliency looks like for your environment, then selecting the specific techniques and design principles that will achieve it.

Once those elements are defined, you must integrate them into your organization’s risk management process or systems security engineering process. The intent is to ensure that resiliency decisions flow from deliberate planning rather than ad hoc responses to incidents as they arise.

Why it matters

Most organizations invest heavily in preventing attacks but allocate far fewer resources to sustaining operations when those defenses inevitably fail. SA-24 exists to close that gap by requiring structured forethought about how systems will absorb, adapt to, and recover from adversity.

Failure to maintain this control introduces audit risk during NIST SP 800-53 assessments and Federal Information Security Modernization Act (FISMA) reviews. Auditors will look for documented evidence that cyber resiliency was a design input, not an undocumented assumption.

Beyond compliance, the absence of deliberate resiliency design leaves your organization without a structured path back to full operations after disruption. Recovery becomes improvisational rather than procedural, which extends downtime and increases damage.

In regulated industries, this gap compounds quickly. Organizations subject to multiple overlapping frameworks may face repeated findings if resiliency design can’t be demonstrated across system boundaries.

The distinction between cybersecurity and cyber resiliency matters here. Cybersecurity focuses on preventing unauthorized access and protecting data. Cyber resiliency focuses on limiting damage and maintaining essential functions when prevention fails, then restoring and adapting those functions afterward.

What attackers exploit

Attackers target the absence of resiliency planning through several vectors:

• Ransomware campaigns that encrypt critical systems, betting that organizations without recovery design principles will pay to restore operations
• Supply chain compromises that propagate through interconnected services where no resilient design boundaries exist
• Persistent access campaigns where adversaries maintain long-term footholds in environments that lack adaptive response capabilities
• Distributed denial-of-service (DDoS) attacks against organizations without alternate communications protocols or degraded-mode operating procedures

How to implement

For your organization

The core challenge with SA-24 is translating abstract resiliency concepts into concrete, documented design decisions that auditors can verify. Many organizations struggle because they conflate general disaster recovery planning with the structured resiliency engineering that this control demands.

Define your cyber resiliency goals. Start by identifying the outcomes your organization needs when facing adversity. NIST special publication (SP) 800-160, Volume 2, outlines four foundational goals: anticipate (maintain informed preparedness), withstand (continue essential functions), recover (restore functions during and after disruption), and adapt (modify functions in response to predicted changes). Map each goal to the specific mission and business functions it protects.

Establish resiliency objectives for each goal. Objectives translate goals into measurable targets. You should specify which systems must remain operational during an attack, what degraded modes of operation are acceptable, and how quickly functions must be restored. Document the rationale behind each objective so future reviewers understand the tradeoffs your organization accepted.

Select techniques, implementation approaches, and design principles. NIST SP 800-160, Volume 2, provides the Cyber Resiliency Engineering Framework with a catalog of techniques such as adaptive response, analytic monitoring, coordinated protection, diversity, and redundancy. For each technique, identify the implementation approach that fits your architecture and the design principles that guide its application.

Integrate resiliency into your risk management or systems security engineering process. Don’t create a standalone resiliency document that sits apart from your existing processes. Instead, embed resiliency decisions into your system design documentation, security requirements specifications, and system security plans. This integration ensures that resiliency artifacts are reviewed, updated, and tested alongside your other security controls.

Common tooling categories include business impact analysis platforms, cyber risk analysis tools, architecture modeling software, and configuration management databases that track which resiliency techniques apply to which system components.

Common mistakes include treating resiliency as identical to disaster recovery, failing to document the relationship between resiliency goals and specific system components, and selecting techniques without validating that implementation approaches are compatible with existing architectures. Another frequent gap is defining resiliency elements but never incorporating them into the risk management process, which means the definitions exist on paper but don’t influence actual design decisions. Organizations also sometimes overlook the need to revisit resiliency design as threat landscapes and system architectures evolve over time.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for SA-24.

Related controls

• CA-07 — Continuous Monitoring: provides the ongoing visibility needed to detect when cyber resiliency measures are degraded or compromised
• CP-02 — Contingency Plan: documents the specific actions your organization takes when disruptions occur, directly supporting the “recover” resiliency goal
• CP-04 — Contingency Plan Testing: validates that your contingency procedures work as designed, testing whether resiliency techniques perform under adversarial conditions
• CP-09 — System Backup: ensures that critical data and system state can be restored, a foundational requirement for any resiliency recovery objective
• CP-10 — System Recovery and Reconstitution: defines how systems return to a known secure state after disruption, implementing the recovery dimension of resiliency design
• CP-11 — Alternate Communications Protocols: supports the “withstand” goal by ensuring communication continuity when primary channels are compromised
• CP-12 — Safe Mode: enables systems to continue operating in a restricted capacity during adversity, directly implementing the “withstand” resiliency goal
• CP-13 — Alternative Security Mechanisms: provides backup security capabilities when primary mechanisms fail, supporting adaptive response techniques
• IA-10 — Adaptive Authentication: adjusts authentication requirements based on threat conditions, applying the adaptive response resiliency technique to identity verification
• IR-04 — Incident Handling: coordinates organizational response to security events, connecting detection and response activities to resiliency recovery and adaptation goals

Frequently asked questions

What is NIST SP 800-53 SA-24

SA-24 requires organizations to define cyber resiliency goals, objectives, techniques, implementation approaches, and design principles, then implement them as part of a risk management or systems security engineering process. The control ensures that systems are designed to anticipate, withstand, recover from, and adapt to adverse conditions. It was introduced in Revision 5 and draws on the Cyber Resiliency Engineering Framework from NIST SP 800-160, Volume 2.

What happens if SA-24 is not implemented

Without SA-24, your organization lacks documented evidence that cyber resiliency was a deliberate design input, which creates findings during FISMA and NIST SP 800-53 audits. Auditors will flag the absence of defined resiliency goals and design principles as a gap in your system design documentation. The operational consequence is that recovery from disruptions becomes ad hoc, extending downtime and increasing the scope of damage to mission-critical functions.

How do you audit SA-24

Auditors verify that your organization has documented cyber resiliency goals, objectives, techniques, implementation approaches, and design principles for each in-scope system. They review system design documentation and system security plans to confirm that selected resiliency elements are integrated into the risk management or systems security engineering process. Assessors also examine assessment and authorization records to validate that implemented techniques achieve the stated resiliency objectives.

What is the difference between cybersecurity and cyber resiliency

Cybersecurity focuses on preventing unauthorized access, protecting confidentiality, and maintaining data integrity. Cyber resiliency assumes that some attacks will succeed and focuses on limiting the resulting damage, continuing essential functions during adversity, restoring capabilities afterward, and adapting to predicted future threats. The EU Cyber Resilience Act reflects this growing regulatory emphasis on resiliency as a complement to traditional security controls.