Cyber Resilience Engineering: Designing Systems That Keep Working When an Attack Succeeds
Cyber resilience engineering designs systems that keep critical services running when an attack succeeds, using NIST SP 800-160 Volume 2. The four goals, fourteen techniques, seven design moves, how to test it, and what regulators expect.
Cyber Resilience
Most security programmes are built to keep attackers out. Cyber resilience engineering starts from a less comfortable assumption: some attacks will succeed, and what matters then is how much of the business keeps working, how quickly the rest comes back, and whether it comes back stronger. NIST's guidance on building cyber-resilient systems, SP 800-160 Volume 2, turns that assumption into a design discipline. Here is what it says and how to apply it to an ordinary enterprise estate.
In short. Cyber resilience is the ability to anticipate, withstand, recover from and adapt to attacks and failures. In practice it means designing so that a successful attack is contained, critical services keep running in a degraded form, recovery does not depend on anything the attacker can reach, and every incident leaves the architecture stronger. Start from the services the business cannot lose, protect the way back first, and prove it with tests rather than documents.
Cybersecurity and cyber resilience are not the same thing
NIST defines cyber resiliency as "the ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by cyber resources." The difference from conventional security is the starting assumption, and it changes what you build.
| Conventional security | Cyber resilience | |
|---|---|---|
| Assumes | Attackers can be kept out | Some attackers will get in and stay for a while |
| Measures | Controls in place, vulnerabilities closed | How much still works during an attack, and how fast the rest returns |
| Focus | Systems and their weaknesses | Business services and their dependencies |
| Success looks like | No incident | An incident that stayed small, a recovery that worked, and a design that changed afterwards |
The framework in NIST SP 800-160 Volume 2
NIST Special Publication 800-160 Volume 2 Revision 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach, was published in December 2021 and remains the current version. It organises resilience into four goals, eight objectives and fourteen techniques, with a set of design principles and implementation approaches underneath. Its starting point is explicit: the guidance is "predicated on the assumption that the adversary will breach defenses and establish a long-term presence in organizational systems."
Anticipate
Stay informed and prepared: know what you depend on, what threatens it, and what you will do.
Withstand
Keep essential functions running while under attack, even in a degraded form.
Recover
Restore functions during and after the attack, to a state you can trust.
Adapt
Change functions, processes and architecture to reduce the impact of the next attack.
The eight objectives sit under those goals: Prevent or Avoid, Prepare, Continue, Constrain, Reconstitute, Understand, Transform and Re-Architect. The fourteen techniques are the building blocks. The table translates each into what it usually means in an enterprise.
| Technique | In an enterprise estate |
|---|---|
| Adaptive Response | Pre-agreed actions to isolate segments, disable accounts or switch to fallback modes when an attack is detected |
| Analytic Monitoring | Detection that sees attacker behaviour early, with logs stored where the attacker cannot delete them |
| Contextual Awareness | Knowing which business services depend on which systems, so impact can be judged in minutes |
| Coordinated Protection | Layers that are designed to work together, so one failure does not open the whole path |
| Deception | Decoy accounts, credentials and files that no legitimate user touches, so any use is an alert |
| Diversity | Not letting one credential, platform or vendor be a single point of failure, for example separate credentials for backups |
| Dynamic Positioning | The ability to move a critical function to another site, region or platform when its home is compromised |
| Non-Persistence | Rebuilding from known-good images and code instead of cleaning compromised systems; short-lived credentials |
| Privilege Restriction | Tiered administration, just-in-time rights, and no standing domain admin accounts in daily use |
| Realignment | Removing functions, connections and data you do not need, so there is less to attack |
| Redundancy | Spare capacity and copies, including backups, that an attacker cannot take out in the same step |
| Segmentation | Boundaries that contain an attack to one part of the estate |
| Substantiated Integrity | Checking that what you restore or run has not been tampered with: signed images, verified backups |
| Unpredictability | Varying things an attacker relies on, such as rotating credentials and changing decoys |
Under the techniques, the publication lists several dozen representative implementation approaches, such as protected backup and restore and predefined segmentation, and it adds five strategic and fourteen structural design principles, among them "assume compromised resources". Its Appendix F analyses the potential effects of each technique against attacker behaviour described in MITRE ATT&CK for Enterprise, which is useful when you need to show what a design change actually defends against. MITRE's CREF Navigator lets you explore the framework interactively.
Resilience techniques against a ransomware attack
Ransomware is the attack most resilience programmes are designed around. The table shows which techniques act at each stage, which is a quick way to check a design for gaps. A ransomware readiness assessment tests the same chain in practice.
| Attack stage | Techniques that act here | What it looks like |
|---|---|---|
| Initial access | Realignment, Privilege Restriction | Fewer internet-facing services; MFA on remote access and email |
| Credential theft and escalation | Privilege Restriction, Deception | Tiered administration; decoy admin accounts that alert on any use |
| Lateral movement | Segmentation, Analytic Monitoring | Boundaries between zones; detections for remote execution and unusual credential use |
| Finding and deleting backups | Redundancy, Diversity, Substantiated Integrity | Immutable or offline copies under separate credentials, with integrity checks |
| Encryption | Adaptive Response, Coordinated Protection | Pre-agreed isolation of segments; layered controls on hypervisors and file servers |
| Recovery | Non-Persistence, Substantiated Integrity, Dynamic Positioning | Rebuild from images and code, verify before restoring, recover to another site or region |
| After the incident | Realignment, Adaptive Response | Change the architecture that allowed it, not only the system that was exploited |
Start from the services, not the systems
Resilience is measured at the level of business services: payments, order processing, patient admissions, trading. The first step is to name the few services the organisation cannot lose, decide how long each can be down or degraded, and trace what each depends on, including identity, network, third parties and the people who run it.
Regulators use the same idea. The Basel Committee defines operational resilience as "the ability of a bank to deliver critical operations through disruption", and RBI's guidance on operational resilience asks regulated entities to set a tolerance for disruption, also called impact tolerance, for each critical operation: the level of disruption they are willing to accept across a range of "severe but plausible scenarios". A business impact analysis is the practical tool for this, run with the business owners of each service rather than by IT alone. Its output tells you where resilience engineering is worth the money and where ordinary backup and recovery is enough.
A worked example: a payments service
To make this concrete, take a hypothetical payments service at a mid-sized financial company. The numbers are illustrative; the method is what matters.
| Step | For the payments service |
|---|---|
| Tolerance | Leadership agrees payments may run in a degraded mode for up to four hours and must be fully restored within 24 hours. |
| Dependencies | Application servers, the payments database, hardware security modules, the directory and single sign-on, links to the payment networks, the operations team and two critical suppliers. |
| Degraded mode | Accept and queue payment instructions, process priority payments manually, and keep customer channels read-only. |
| Protecting the way back | Database backups with an immutable copy, under credentials that do not exist in the production directory; server configuration held as code. |
| Identity | Payments administrators on privileged access workstations, no standing domain admin rights, and an emergency access route that does not depend on the directory. |
| Containment | The payments environment in its own segment, reachable only from named jump hosts. |
| Test | A timed restore of the database and a rebuild of the application tier from code in an isolated environment, compared with the four-hour and 24-hour tolerances. |
The first test often shows a gap, and that gap, measured in hours, is what justifies the investment. A business impact analysis produces the tolerances; the restore test shows how far you are from them.
Seven design moves that make an estate resilient
These moves most often close the gap between how long a service can be down and how long it would really take to recover. Cyber resilience engineering usually works through them in this order.
1. Protect the way back first
Backups with an immutable or offline copy, their own credentials outside the production directory, and integrity checks before restore. Redundancy, diversity and substantiated integrity, applied to the one system every other recovery depends on.
2. Make identity hard to take over
Tiered administration, privileged access workstations, phishing-resistant MFA for admins, and no domain admin rights in daily use. Most large outages start with one over-privileged account.
3. Segment for containment
Boundaries between user networks, servers, management interfaces and critical services, with rules you have tested from the inside.
4. Decide in advance how to degrade
For each critical service, the minimum version that must keep running, the manual fallback, and who can trigger it. Adaptive response is a decision made before the incident, not during it.
5. Make rebuilding routine
Servers and cloud resources built from images and code, so a compromised system is replaced rather than cleaned. Non-persistence turns recovery from forensics into redeployment.
6. See the attack while it is small
Detections for the techniques that precede mass impact, such as credential theft and backup deletion, plus decoy credentials that alert on first use.
7. Remove what you do not need
Old systems, open connections and stale data are attack surface with no business value. Realignment is often the cheapest resilience improvement available.
Rebuilding identity: the recovery most plans miss
Almost every recovery depends on identity: servers, applications and administrators all need the directory to work. If the directory has been compromised or wiped, it has to come back first, and from a state you can trust. Microsoft publishes an Active Directory forest recovery guide for exactly this situation, and it is worth reading before you need it.
- Back up domain controllers to a copy the attacker cannot reach, and know which backup predates the compromise.
- Document the recovery order and rehearse it in an isolated environment, not on the production network.
- Keep recovery credentials and emergency access accounts that do not depend on the directory being up. For cloud identity, Microsoft recommends emergency access accounts in Microsoft Entra ID for the same reason.
- Plan to reset privileged credentials after recovery, including the KRBTGT account, because an attacker may still hold them.
Prove it by testing
A resilience design is a hypothesis until it has been tested. The tests that matter are the ones that measure the things the design promises: a timed restore of a critical service from the immutable copy, a crisis simulation where leadership chooses between degraded operation and shutdown, and a red team or purple team exercise that checks whether containment actually holds.
The cost of relying on luck is well documented. When NotPetya hit Maersk in 2017, its roughly 150 domain controllers were set up to replicate with each other, a design that, as Wired later reported, "hadn't accounted for one scenario: where every domain controller is wiped simultaneously." Recovery depended on a single domain controller in Ghana that happened to be offline during the attack because of a power outage. Replication is not backup, and a lucky outage is not a recovery plan.
Measuring resilience
Resilience is measured by testing against the tolerances the business agreed, not by counting controls. These measures work well in a board report:
| Measure | What it tells you |
|---|---|
| Timed restore of each critical service, against its tolerance | Whether recovery is actually fast enough |
| Critical services with a tested degraded mode | How much of the business keeps working during an attack |
| Time to isolate a network segment in an exercise | Whether containment works at the speed it needs to |
| Critical data with an immutable or offline copy under separate credentials | Whether the way back survives stolen admin credentials |
| Administrator accounts with phishing-resistant MFA | How hard identity is to take over |
| Time to rebuild a standard server from code | Whether rebuilding instead of cleaning is real or theoretical |
Our guide to security metrics for the board covers how to present them.
Regulators are asking for resilience
Resilience has moved from good practice into regulation in several of the markets we work in.
- India, banking. RBI's guidance note on operational risk management and operational resilience, first issued in April 2024 and reissued in November 2025, asks regulated entities to identify critical operations and set a tolerance for disruption for each. The original note drew on the Basel Committee's 2021 Principles for Operational Resilience.
- India, securities. SEBI's Cybersecurity and Cyber Resilience Framework puts resilience in its name and its requirements; see our SEBI CSCRF compliance guide.
- European Union. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied to financial entities since 17 January 2025. It covers ICT risk management, incident reporting and resilience testing, including threat-led penetration testing at least every three years for the entities selected for it, and it requires backups to be restored using systems "physically and logically segregated from the source ICT system".
- United Kingdom. The NCSC Cyber Assessment Framework, version 4.0 from August 2025, has a principle on resilient networks and systems (B5), covering resilience preparation, design for resilience and backups, and an objective on minimising the impact of incidents.
Common mistakes
- Treating replication as backup. Replication copies encryption and deletion as faithfully as it copies data.
- A recovery site that shares identity with production. If the same accounts administer both, one compromise takes both.
- Tolerances set by IT alone. The business has to own how long it can be without a service, or the numbers will not hold under pressure.
- Runbooks that assume the network and directory are up. In a destructive attack, they often are not.
- Restore tests that recover a file, not a service. Bringing back a whole service, with its dependencies, within the time allowed is the real test.
- Treating resilience as a one-off project. The estate, the threats and the business all change, so the design and the tests have to keep up.
Most of these surface in an existing business continuity and disaster recovery plan as soon as it is tested against a cyber scenario instead of a site outage.
Resilience is a programme, not a project
Applying these techniques touches architecture, operations, identity, suppliers and the way decisions get made during an incident. That makes it a change programme as much as an engineering one: owners for each critical service, a budget tied to the tolerances the board agreed, and a regular cycle of testing and adapting. In organisations where security is still run as a collection of tools, a security transformation is often the step that makes resilience possible.
A 90-day starting plan
Days 1–30 — Services and tolerances
Name the critical services, agree how long each can be down or degraded, and map their dependencies, including identity and suppliers.
Days 31–60 — Protect the way back
Separate backup credentials, add an immutable copy, and run a timed restore of the most critical service. Record the real recovery time.
Days 61–90 — Test and decide
A leadership tabletop on a destructive attack, then a prioritised design roadmap: the identity, segmentation and rebuild changes that close the largest gaps between tolerance and reality.
Frequently Asked Questions
Click any question to expand the answer.
QWhat is cyber resilience engineering?
Designing systems and operations so that critical services keep working through an attack, recover to a state you can trust, and improve afterwards. It assumes some attacks will succeed and plans for how much of the business still works when they do. NIST SP 800-160 Volume 2 is the main engineering framework for it.
QWhat is the difference between cybersecurity and cyber resilience?
Conventional cybersecurity aims to keep attackers out and measures controls and vulnerabilities. Cyber resilience assumes some attackers get in and measures how much still works during an attack and how quickly the rest comes back. Both are needed; resilience covers what happens when prevention fails.
QWhat is NIST SP 800-160 Volume 2?
A NIST publication, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. Revision 1, published in December 2021, is the current version. It defines four goals, eight objectives and fourteen techniques for building systems that can anticipate, withstand, recover from and adapt to attacks.
QWhat are the four cyber resiliency goals?
Anticipate, withstand, recover and adapt: be prepared for attacks, keep essential functions running during one, restore functions afterwards, and change processes and architecture to reduce the impact of the next.
QWhat are the 14 cyber resiliency techniques?
Adaptive Response, Analytic Monitoring, Contextual Awareness, Coordinated Protection, Deception, Diversity, Dynamic Positioning, Non-Persistence, Privilege Restriction, Realignment, Redundancy, Segmentation, Substantiated Integrity and Unpredictability.
QIs cyber resilience the same as business continuity?
They overlap, but business continuity plans were usually written for site failures, power loss or natural events. Cyber resilience assumes an adversary who targets your backups, credentials and recovery tools on purpose, so it designs recovery that does not depend on anything the attacker can reach.
QDo immutable backups make us resilient?
They are necessary but not sufficient. You also need backup credentials outside the production directory, integrity checks before restore, a way to rebuild identity, and timed restore tests. CISA's #StopRansomware Guide recommends offline, encrypted backups with regular testing of their availability and integrity, and cautions that immutable storage needs careful configuration.
QHow do you measure cyber resilience?
By testing against the tolerances the business agreed: how long a timed restore of each critical service takes from the protected copy, how far a simulated attack spreads before containment, and how many critical services have a tested degraded mode. Self-assessment questionnaires alone do not measure it.
QWhat is impact tolerance?
The maximum disruption an organisation is willing to accept to a critical service, set for severe but plausible scenarios. RBI calls it tolerance for disruption, or impact tolerance. It turns resilience into a measurable target that restore tests and exercises can be compared against.
QHow is cyber resilience tested?
With timed restores of critical services from protected copies, crisis simulations where leadership makes real decisions, and red or purple team exercises that check whether containment holds. Each result is compared with the tolerances the business agreed.
QWhat does RBI expect on operational resilience?
RBI's guidance note on operational risk management and operational resilience, first issued in April 2024 and reissued in November 2025, asks regulated entities to identify critical operations and set a tolerance for disruption for each, based on severe but plausible scenarios.
QWhere should we start?
Name the few services the business cannot lose and agree how long each can be down. Then protect the way back: separate backup credentials, add an immutable or offline copy and run a timed restore of the most critical service. Use what that restore teaches you to prioritise identity, segmentation and rebuild work.
Related reading
For setting recovery targets you can actually meet, see business impact analysis: RTO and RPO after ransomware. For the attack most resilience programmes are designed around, the ransomware defence playbook for India. For the infrastructure underneath it all, data centre security: hypervisors, management controllers and backups. For reporting resilience to the board, security metrics for the board.
Sources
- NIST, SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems: A Systems Security Engineering Approach.
- MITRE, CREF Navigator.
- Basel Committee on Banking Supervision, Principles for Operational Resilience (March 2021).
- Reserve Bank of India, Operational risk management and operational resilience (current text).
- European Union, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA).
- NCSC, Cyber Assessment Framework.
- CISA, #StopRansomware Guide.
- Wired, The Untold Story of NotPetya, the Most Devastating Cyberattack in History.
- Microsoft, Active Directory forest recovery guide.
- Microsoft, Manage emergency access accounts in Microsoft Entra ID.
Adayptus Consulting
Cyber Resilience, Adayptus
Adayptus Consulting Private Limited is a cybersecurity consultancy based in Noida, India, designing resilience around the services a business cannot lose and proving it with timed restores and exercises.
On This Page
- Cybersecurity and cyber resilience are not the same thing
- The framework in NIST SP 800-160 Volume 2
- Resilience techniques against a ransomware attack
- Start from the services, not the systems
- A worked example: a payments service
- Seven design moves that make an estate resilient
- Rebuilding identity: the recovery most plans miss
- Prove it by testing
- Measuring resilience
- Regulators are asking for resilience
- Common mistakes
- Resilience is a programme, not a project
- A 90-day starting plan
- Frequently Asked Questions
- Related reading
- Sources
