defensiva
cyber resilience
cyber resilience assessment
cyber resilience metrics

Cyber Resilience Assessment: How to Measure It

What a cyber resilience assessment is, how it differs from a risk assessment and DORA, and the metrics and maturity model to measure resilience.

SecraJuly 6, 202610 min read

A cyber resilience assessment measures something that traditional vulnerability analysis overlooks: not how many gaps you have, but how much your organisation withstands when an attack exploits them. The question it answers isn't "am I protected?" but "can I keep operating and recover when protection fails?". That shift in focus matters, because it assumes the incident will happen and concentrates on the ability to anticipate, withstand, recover and adapt. This article explains what such an assessment actually is, how it differs from a one-off risk assessment and from DORA compliance, and which concrete cyber resilience metrics let you answer, with numbers, the question of how to measure cyber resilience.

Key takeaways on cyber resilience assessment

  • It measures the ability to keep operating and recover from an incident, not only to prevent it.
  • It builds on the four goals of NIST SP 800-160 Vol. 2: anticipate, withstand, recover and adapt.
  • The core metrics are MTTD, MTTR, RTO, RPO, control coverage and blast-radius containment.
  • A five-level maturity model lets you benchmark and set a realistic target.
  • It is not the same as a risk assessment (predictive and point in time) or as DORA compliance (a regulatory obligation).

What a cyber resilience assessment is

A cyber resilience assessment evaluates, with evidence, the extent to which an organisation can keep its critical business functions running during and after an adverse event. The most cited reference framework is NIST SP 800-160 Vol. 2 (Cyber Resiliency Engineering Framework), which structures resilience into four goals: anticipate the threat, withstand its impact, recover the service and adapt for next time. Alongside it sit NIST CSF 2.0, which added the Govern function, ISO 22301 for business continuity, ISO/IEC 27031 for ICT readiness and the C2M2 model from the US Department of Energy.

The difference from a purely preventive approach is one of mindset. Prevention tries to reduce the probability that an incident occurs. Resilience assumes it will and measures what happens then: how long it takes to notice, how far it spreads, how long you are down and how much data you lose. An organisation can have a strong catalogue of controls and still show low resilience if it has never tested whether those controls contain and recover from a real incident.

Resilience, risk and DORA: three different things

These three concepts are often blurred in commercial conversations, and it is worth separating them because they answer different questions.

ExerciseQuestion it answersNatureScope
Risk assessmentWhat could go wrong and how bad?Predictive and point in timeEvery threat prioritised by likelihood and impact
Resilience assessmentHow much do I withstand and recover when it happens?Outcome-based and continuousCritical services and their ability to operate under stress
DORA complianceDo I meet the regulation's articles?Regulatory obligationDesignated financial entities and their ICT providers

A risk assessment (following ISO 27005 or NIST SP 800-30) estimates the likelihood and impact of threats at a given moment in order to prioritise controls. It is a snapshot: useful for deciding where to invest, but silent about what happens when the risk materialises. A resilience assessment starts exactly there, at the moment of impact, and is continuous by nature because environments change daily.

DORA compliance (EU Regulation 2022/2554) is a different matter: a legal obligation for financial entities and their critical providers that mandates ICT risk management, incident reporting, digital operational resilience testing (including intelligence-led TLPT) and third-party oversight. It is binary: you meet the articles or you do not. You can be compliant on paper and still show low measured resilience, and the reverse. A resilience assessment is the technical and management discipline that feeds that compliance with real evidence. If your context is financial, it is worth cross-reading our DORA compliance guide and the differences between DORA and NIS2.

Cyber resilience metrics (how to measure cyber resilience)

Without metrics, resilience is an opinion. These are the cyber resilience metrics that turn that opinion into a figure you can defend before the board.

Detection and response: MTTD and MTTR

MTTD (mean time to detect) measures how long passes from the moment compromise occurs until someone notices. MTTR can mean mean time to respond or to recover, so it is worth breaking it down: MTTA (acknowledge the alert), time to contain and total time to recover. The lower the MTTD, the less room the attacker has to move. These figures come from the SIEM, the EDR and the work of the Blue Team, and they are only reliable when measured against real or simulated incidents rather than estimates.

Recovery: RTO and RPO

The RTO (recovery time objective) is the maximum tolerable time a critical service can be down before causing unacceptable damage. The RPO (recovery point objective) is the maximum amount of data, measured in time, that you can afford to lose, and it drives the frequency of your backups. The usual trap is to set objectives on paper and never measure the real value: the achieved RTO in a restore drill tends to be far worse than the target RTO. That gap, not the target, is what measures real resilience. This requires testing full restores from immutable backups, something we develop in our guide on what a backup is.

Control coverage

Control coverage expresses what percentage of the relevant MITRE ATT&CK techniques are actually prevented or detected in your environment. It is the bridge between resilience and adversarial validation: having an EDR is not enough, you have to confirm which techniques it stops. This figure comes from running a continuous security validation programme, which also catches configuration drift: 80 percent coverage that drops to 60 in three months warns of degraded controls before an attacker does.

Blast-radius containment

Blast-radius containment measures how far an intrusion can spread before segmentation, least privilege or isolation stop it. It is quantified with assumed-breach exercises: the number of lateral hops possible from a compromised endpoint, the time to reach a critical system and the percentage of crown-jewel assets reachable. A small blast radius turns a severe incident into a mere nuisance.

A maturity model to benchmark against

A maturity model lets you position yourself and set a realistic target instead of aiming for perfection all at once. We adapt here the logic of C2M2 and the NIST CSF tiers into five rungs.

  • Level 1, Initial. No resilience objectives are defined. Recovery is improvised and nothing is measured. Backups exist but have never been restored.
  • Level 2, Reactive. There are backups and some response runbooks. RTO and RPO are defined for a few systems, but metrics are not tracked over time.
  • Level 3, Managed. Resilience objectives are documented, with RTO and RPO for every critical service. The response plan is tested at least once a year and MTTD and MTTR are recorded.
  • Level 4, Measured. Validation is continuous, blast-radius exercises are run, metrics are shown as trends and control-coverage drift is watched.
  • Level 5, Adaptive. Resilience is engineered by design: segmentation, immutable backups, controlled failure testing. Metrics govern board decisions and every incident feeds a measurable improvement.

Most mid-sized organisations sit between level 2 and level 3. The value of a formal assessment is precisely to place you with evidence and chart the path to the next rung.

A step-by-step self-assessment checklist

This checklist works as an on-ramp to a full resilience assessment. Answer honestly: every "no" is a gap that a formal exercise would quantify.

  1. Have you identified and prioritised your critical business services and their dependencies through a business impact analysis (BIA)?
  2. Do documented RTO and RPO exist per critical service, and have you tested them in the last twelve months?
  3. Do you measure MTTD and MTTR against real or simulated incidents rather than estimates?
  4. Do you have immutable or offline backups, and have you run a full end-to-end restore?
  5. Is your network segmented to limit the blast radius, and have you run an assumed-breach exercise?
  6. Is your incident response plan tested with tabletop exercises and with technical tests?
  7. Do you track control coverage against MITRE ATT&CK and watch its drift?
  8. Is there a crisis and communications plan with defined roles for inside and outside the organisation?
  9. Does every incident generate lessons learned that feed back into controls and processes?

If you answered "no" to three or more points, your resilience depends more on luck than on design. A formal assessment translates those gaps into a prioritised plan with objectives and cost.

Frequently asked questions

How does a resilience assessment differ from a risk assessment?

A risk assessment is predictive and point in time: it estimates which threats are most likely and with what impact in order to prioritise controls. A resilience assessment is continuous and outcome-based: it measures what happens when the risk materialises, that is, how long you take to detect, how far it spreads, how long you are down and how much data you lose. One decides where to invest; the other checks whether that investment withstands the blow.

Does DORA compliance mean I am resilient?

Not necessarily. DORA is a regulatory obligation for the financial sector that mandates processes, reporting and testing. You can meet the articles on paper and still show low measured resilience if you have never tested your real RTOs or your blast-radius containment. Compliance sets a floor; a resilience assessment measures actual capability and generates the very evidence DORA requires.

What are the minimum metrics to start measuring resilience?

Four figures are a solid starting point: MTTD and MTTR for detection and response, and real RTO and RPO (the ones achieved in a drill, not the paper targets) for recovery. With those four you can already plot a trend and benchmark against your sector's target. Control coverage and blast-radius containment are the natural next step.

How often should a resilience assessment be done?

The full formal snapshot is usually annual, but the metrics that support it should be measured continuously. Backup restores and assumed-breach exercises are recommended at least quarterly, and control coverage is watched permanently to catch drift. An annual assessment with no continuous measurement in between ages very quickly.

Next step

A cyber resilience assessment only delivers value if someone turns it into defensible metrics and a clear improvement plan. At Secra we measure your real MTTD, MTTR, RTO and RPO, run blast-radius containment exercises and place you on the maturity model with evidence rather than impressions. If you want to know how much your organisation withstands today, tell us the context and we'll tell you where to start.

About the author

Secra Solutions team

Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.

Share article