SA-24, Design For Cyber Resiliency, asks the organization to design systems, components and services to achieve cyber resiliency. It does that by defining five things: cyber resiliency goals, objectives, techniques, implementation approaches and design principles. Then it asks you to implement the selection as part of a risk management or systems security engineering process.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, and the closest thing in this family to a design level availability question.
What it means in practice
The guidance defines the stakes. Cyber resiliency is about limiting damage from adversity, and the damage can fall on the organization, on missions or business functions, on security itself, on systems, or on specific elements such as physical destruction or corruption of information.
It also describes what the goals are for: staying prepared for adversity, continuing essential functions despite it, and restoring them afterward. NIST points to SP 800-160 Volume 1 for the detail on achieving resiliency as an emergent property of an engineered system.
The values you pick are organization defined. That is both freedom and risk. An auditor will not tell you the right goals. They will check that you chose, wrote them down and built to them.
A workable small company version: goal, keep checkout available during a regional cloud outage. Objective, recover within a stated time. Technique, redundancy across zones. Design principle, no single dependency for payments.
Evidence to collect
- A document listing your chosen goals, objectives, techniques, approaches and principles.
- Architecture diagrams showing where each technique is applied.
- Test results, such as a failover exercise or a restore drill, with dates.
- The risk assessment or engineering review that drove the selection.
Common gaps
A goals document with no link to the architecture.
Resiliency claims never tested. A backup that has not been restored is a hope.
Considering only outages and ignoring corruption or malicious change.
How to implement it
- Choose a short list of goals tied to business functions.
- Turn each into a measurable objective, such as recovery time.
- Select techniques and record where they apply.
- Test each at least yearly and keep the report.
- Feed lessons back into the design and update the document.
What an auditor may ask
- Where are your resiliency goals written?
- Which test shows the objective is met?
- What changed after the last exercise?
A dated failover or restore report with follow up actions answers all three.
Quick check
Who defines the goals and techniques in SA-24?
The organization. The control text leaves those values for you to set.
