PR.IR-03 says mechanisms are implemented to achieve resilience requirements in normal and adverse situations. The important word is requirements. You first decide how much downtime and data loss each system can tolerate, then build only as much redundancy as that justifies.
CSF is voluntary guidance. There is no CSF certification.
What good looks like
Each important system has a stated availability target. The design backs that target up: no single server, database, region, or person whose failure takes it down. Failover is tested, not assumed. NIST's examples include avoiding single points of failure, using load balancing, and using redundant storage and power.
How to implement it
- Rank your systems by business impact. Three tiers is plenty.
- For each tier, write a recovery time and a recovery point you will aim for.
- Draw the request path for the top tier and mark every single point of failure: one database instance, one DNS provider, one engineer holding a credential.
- Fix the cheapest and most likely ones first. Run two or more instances behind a load balancer. Use managed databases with replicas across zones. Keep a second admin with access to critical accounts.
- Test failover twice a year. Write down what broke.
- Record the results and feed fixes back into the backlog.
A worked example
A company runs its customer portal on a single virtual machine with a local database. It has nightly backups and a documented restore, but the last restore test was two years ago. The owner writes a requirement: the portal may be down for four hours and may lose at most one hour of data.
The design does not meet that. The team moves the database to a managed service with a replica in a second zone, runs the application on two instances behind a load balancer, and sets backups to continuous. They then run a failover test on a quiet weekend, record that it took twenty minutes, and file the result. The requirement is now met and the evidence exists.
Single points of failure beyond servers
Resilience gaps are often organizational. One engineer knows how to deploy. One person holds the only admin credential for the domain registrar. One DNS provider serves everything. Add these to your single point of failure list. Fix them with documented procedures, a second trained person, and break glass accounts stored safely.
Test it, then write it down
An untested failover is a hope. Schedule two exercises a year: one restore from backup into a clean environment, and one failover of the most important service. Record the date, the steps, the time taken, and what went wrong. Turn each problem into a ticket. After a few cycles, the records form strong evidence for customers who ask about availability.
What auditors and customers look for
They rarely ask for perfection. They want to see that you set targets, designed to meet them, and tested the design. A one page summary of your tiers, your targets, your last failover test, and the fixes that followed answers most questions about availability and business continuity at once.
Evidence to collect
- The tiered system list with targets.
- Architecture diagrams showing redundancy.
- Failover or restore test records with dates and outcomes.
- Tickets that closed single point of failure findings.
Common gaps
Redundancy that exists on paper but has never been exercised. Replicas in the same zone. A single DNS or identity provider with no fallback. Targets that nobody wrote down, so no one can say whether the design is adequate.
Quick check
Do we need multi region for every system?
No. Match the design to the written requirement. Many internal systems are fine with a good backup and a tested restore.
Sources
- NIST Cybersecurity Framework 2.0 (NIST CSWP 29), PR.IR-03 and its implementation examples.
