Cyber Resilience

← ISO 27001 Annex A

A.5.30 Organizational

ICT readiness for business continuity

AttributesCorrective A Respond Continuity Resilience

Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?

The implementation guidance for this control is published in ISO/IEC 27002:2022 and is not reproduced here. The structured attributes and the cross-walk rationales below are derived facts and our own AI-authored analysis.

Mapped NIST 800-53 r5 controls (25)

Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

CP-10←M →M CP-2←F →M CP-3←P CP-4←M →P CP-6←M CP-7←M →M CP-8←M CP-9←P →P PE-11←P SC-5←P RA-2gov

Why these map — AI rationale (under review)

CP-10mostlyaligns with — Both controls focus on restoring systems and information to required states within defined timeframes after an interruption.
CP-10mostlycovers — A.5.30's broad ICT readiness requirement for availability during disruption accounts for the bulk of CP-10's recovery/reconstitution to a known state, but leaves a residual of specific technical reconstitution procedures, parameters, and post-disruption triggers not fully detailed in the ISO control.
CP-2mostlyaligns with — Both controls require development and maintenance of contingency plans that define recovery objectives and procedures to sustain critical operations during disruption.
CP-2mostlycovers — A.5.30's ICT readiness directly implements the core of CP-2's contingency planning and continuity requirements for information assets, but leaves some residual (e.g., explicit mission/business function identification, metrics, and full role/contact details) that sit outside its narrower ICT focus.
CP-7mostlycovers — A.5.30's broad requirement to ensure ICT availability during disruption accounts for the bulk of CP-7's alternate-site mandate (as one primary way to achieve continuity), but leaves a residual of CP-7's specifics (agreements, exact RTO parameters, on-site equipment/supplies) uncovered by the higher-level ISO statement.
CP-4partialaligns with — Both controls mandate periodic testing and exercises of continuity plans to validate their effectiveness.
CP-4partialcovers — A.5.30's broad requirement to ensure ICT availability during disruption is addressed in part by CP-4's testing/review/corrective-action steps that validate and improve contingency readiness, but most of A.5.30 (planning, resource provisioning, and actual continuity measures) sits outside this testing control.
CP-7partialaligns with — Both controls consider alternate processing capabilities as part of strategies to maintain ICT service availability after disruption.
CP-9partialaligns with — Both controls address the need to back up and restore information to meet recovery point objectives during business continuity events.
CP-9partialcovers — A.5.30's broad ICT-readiness-for-BC requirement touches backup as one enabling slice for availability during disruption, but the bulk of cp-9's specific backup-frequency, scope, and protection details sit outside what A.5.30 itself mandates.
RA-2partialaligns with — Both controls use business impact analysis to determine the criticality of processes and the resources required to support them.
RA-2implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.

Aligned NIST CSF 2.0 outcomes (20)

NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

ID.AM-05←P RC.RP-04←M GV.OC-04gov ID.IM-04gov ID.RA-04gov ID.RA-05gov ID.RA-06gov PR.IR-03gov RC.RP-05gov

Why these map — AI rationale (under review)

ID.IM-04mostlyaligns with — The ISO control requires ICT continuity plans to be developed, approved, exercised, and maintained so they can be executed when disruption occurs, which directly supports the CSF outcome of establishing and maintaining incident response and other operational plans.
PR.IR-03mostlyaligns with — By defining RTOs, RPOs, and performance requirements for ICT services and then implementing tested strategies to meet them, the control ensures mechanisms exist to achieve resilience requirements during adverse situations.
GV.OC-04partialaligns with — The control identifies critical ICT services and their required availability levels so the organization can continue delivering products and services that external stakeholders depend on.
ID.RA-04partialaligns with — The control uses business impact analysis to quantify the magnitude and duration of impacts from disrupted activities, which aligns with the CSF outcome of identifying potential impacts and likelihoods of threats exploiting vulnerabilities.
ID.RA-05partialaligns with — Outputs from the BIA and risk assessment are used to select and prioritize ICT continuity strategies, matching the CSF outcome of using threats, vulnerabilities, likelihoods, and impacts to inform risk response prioritization.
ID.RA-06partialaligns with — The control requires choosing and implementing ICT continuity strategies based on BIA and risk assessment results, which aligns with the CSF outcome of selecting, prioritizing, planning, and tracking risk responses.
GV.OC-04implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.IM-04implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.RA-04implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.RA-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.RA-06implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
PR.IR-03implements — A.5.30 directly operationalizes ICT continuity mechanisms that achieve the exact resilience requirements named in PR.IR-03 for normal and adverse situations

Related OWASP ASVS 5.0 requirements (4)

Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

V15.2.2←P V16.5.2←P V16.5.3←P V2.4.1←P

Related weaknesses / CWE (4)

Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

CWE-1384←P →P CWE-400→P

Why these map — AI rationale (under review)

CWE-770nonemitigates — Specifying performance and capacity limits for prioritized ICT services in continuity plans constrains how many resources can be allocated without explicit approval, limiting an attacker’s ability to exhaust memory, file handles, or other finite assets.
CWE-1384mitigates — ICT readiness for business continuity includes resilience to environmental conditions.
CWE-400mitigates — Defining RTOs and capacity requirements for ICT services during business-impact analysis forces organizations to provision sufficient resources and throttling mechanisms, reducing the likelihood that an attacker can induce denial-of-service through uncontrolled resource consumption.

Mitigated MITRE ATT&CK techniques (364)

Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

T1001←M T1001.001←M T1001.002←M T1001.003←M T1003.003→M T1005→M T1006←M →M T1014←M T1027.001←M T1027.002←M T1027.006←M T1027.007←M T1027.008←M T1027.009←M T1027.010←M T1027.011←M T1027.014←M T1036←M T1036.003←M T1036.005←M T1036.008←M T1036.009←M T1036.012←M T1055←M T1055.001←M T1055.002←M T1055.003←M T1055.004←M T1055.005←M T1055.008←M T1055.009←M T1055.011←M T1055.012←M T1055.013←M T1055.014←M T1055.015←M T1070←M T1070.003←M T1070.004←M T1070.005→M T1070.006←M T1070.008←M T1070.010←M T1071←M T1071.001←M T1071.004←M T1071.005←P T1072←P T1074→M T1074.002→M T1078←P T1078.004←M T1090←M T1090.001←M T1090.002←M T1090.003←M T1095←M T1098.005←M T1102←M T1102.001←M T1104←M T1110.001→M T1111←M T1112←P T1114.001→M T1127←M T1127.001←M T1133←M T1134←M T1134.003←P T1134.004←P T1134.005←P T1137.001→P T1204.004←P T1205←P T1207←M →M T1211←M T1218←M T1218.005←M →P T1218.007←M T1218.008←M T1218.010←M T1218.011←M T1218.012←M T1218.013←M T1218.014→M T1219→P T1219.003←M T1221←P T1222←M T1222.001←M T1222.002←M T1480.001←M T1484←M T1484.002←M T1485←M →M T1485.001←P →M T1486←M →M T1489←M →M T1490←M →M T1491→M T1491.001→P T1491.002→M T1495←M →P T1496←M →P T1496.001←M →P T1496.002←P →P T1496.003←P →P T1496.004←P →M T1497←M T1498←M →M T1498.001←M →M T1498.002←M →P T1499←M →M T1499.001←M →P T1499.002←M →P T1499.003←M →P T1499.004←M →P T1518.002←P T1528→M T1529←M →M T1530→M T1531←M →M T1535←M T1537←M →P T1539←F T1542←M →M T1542.002←M →M T1542.003←M →P T1542.004→M T1542.005→P T1543.002←M T1543.003←P T1546.003→P T1546.012←P T1547.012→P T1548.006←M T1550←M T1550.001←F T1550.002←F T1550.003←F T1550.004←F T1553.001←M T1553.002←P T1553.003←M T1553.004←P T1553.005←M T1553.006←M T1554←P T1556←M T1556.001←M T1556.005←P T1556.006←M T1556.007←M T1556.009←M T1558.001→M T1561←F →M T1561.001←M →M T1561.002←M →M T1564←M T1564.004←M T1565.001→M T1565.002←P T1566.003←M T1568←M T1568.002←M T1568.003←M T1571←M T1572←M T1574←M T1574.001←M T1574.004←M T1574.012←P T1574.013←P T1578←P T1578.001←M T1578.002←M T1578.003←M →P T1578.004←M →P T1578.005←M T1583.007←M T1599←M T1599.001←M T1600←P T1600.001←P T1601.001←M →P T1601.002←M T1606←M T1606.001←M T1606.002←M T1610←P T1611←P T1612←P T1620←M T1621←M T1647←P T1653←P T1657→M T1665←M T1666←M T1667←P →P T1677←P T1678←M T1685←M →M T1685.001←M T1685.002←M T1685.003←M T1685.004←M T1685.005←M →M T1685.006←M →P T1686←M T1686.001←M T1686.002←M T1686.003←M T1687←M T1688←M T1689←P T1690←M

Why these map — AI rationale (under review)

T1003.003recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus procedures and tested mechanisms to restore prioritized ICT resources (including information in backups) after a disruption, which directly recovers from the post-exfiltration state where NTDS.dit or its backup copies have been accessed or duplicated by the adversary.
T1005recovers — ICT readiness for business continuity (with its BIA-derived RTO/RPO, restoration procedures, tested plans and backup-like recovery of information) restores the state destroyed or degraded by the T1005 collection event once it has run; the named remainder is the window of exfiltrated data that cannot be recovered.
T1006recovers — A.5.30 ensures ICT continuity plans, RTO/RPO, and tested recovery procedures exist to restore prioritized ICT services and information after a disruption, which directly recovers state altered by T1006's volume reads/writes or shadow-copy exfiltration.
T1070.005recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers state destroyed by an adversary's cleanup of network shares that were used in the attack.
T1074recovers — A.5.30 ensures ICT continuity plans, RTOs, RPOs and tested recovery procedures exist to restore prioritized information and services after a disruption; this directly recovers the state destroyed or made unavailable by an adversary staging (and then exfiltrating) data.
T1074.002recovers — A.5.30's ICT continuity plans, RTO/RPO-driven restoration procedures, tested recovery, and explicit focus on restoring prioritized information after disruption directly enable recovery of data that an adversary has staged (and potentially impacted) during an incident.
T1110.001prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, and tested procedures (including RTOs for prioritized services) that prepare for, mitigate, and respond to disruptions; this directly prevents successful password guessing on critical ICT services by enabling rapid failover or recovery before the technique can achieve persistent access or impact availability.
T1114.001recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus procedures for restoring prioritized ICT resources (including information such as local email data files) after disruption, which directly enacts recovery of the collected or lost asset.
T1137.001prevents — A.5.30's BIA-driven ICT continuity strategies, plans, testing and RTO/RPO requirements for prioritized services can constrain macro-enabled template abuse as a persistence vector in critical Office-dependent workflows, but this is only a minority slice of the technique's surface (file/registry hijacks, macro policy bypass, non-prioritized systems).
T1207recovers — A.5.30 ensures ICT continuity plans, RTO/RPO-driven restoration procedures, tested recovery of prioritized services and information assets after disruption, which directly recovers from the AD manipulation and metadata tampering performed by a rogue DC.
T1218.005detects — A.5.30 requires monitoring and testing of ICT continuity plans and response procedures for disruptions, which can surface anomalous use of mshta.exe as part of an ICT service disruption but does not mandate or focus on detection of this specific technique.
T1218.014recovers — A.5.30 ensures ICT continuity plans exist with defined RTO/RPO and tested recovery procedures for prioritized services and information, directly enabling state restoration after an adversary uses MMC to delete backup catalogs (T1490) or otherwise disrupt availability.
T1219responds — A.5.30 requires organizational structure, plans, and tested procedures to respond to and manage ICT service disruptions (including those that could arise from or enable C2 via remote tools), but does not directly address containment or eradication of the T1219 technique itself.
T1485detects — A.5.30 requires ICT continuity plans (developed from BIA) to be regularly evaluated through exercises and tests that surface whether the organization can still meet availability/RTO/RPO objectives when data destruction occurs, providing detection of gaps in readiness.
T1485prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets and tested recovery procedures that enable restoration of destroyed data/assets to meet availability objectives, thereby stopping the T1485 impact from persisting; it does not stop the adversary from executing the destruction itself.
T1485recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after a disruption, which directly recovers availability destroyed by T1485's targeted file/infrastructure deletion.
T1485responds — A.5.30 requires plans, structure, and tested procedures that activate once disruption (including data-destruction events) is underway to contain impact, restore prioritized ICT services within RTO/RPO, and recover availability.
T1485.001recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus procedures and tested mechanisms to restore prioritized information and ICT services after a disruption, which directly recovers from the data destruction performed by T1485.001; mostly because the control is scoped to BIA-prioritized resources rather than every possible bucket or object.
T1486detects — A.5.30 requires ICT continuity plans (including response procedures) that are exercised/tested and cover RTO/RPO-driven restoration of prioritized services and information; this surfaces ransomware encryption events once underway as part of the detection/response path, but only for the scoped/prioritized subset of assets rather than broadly across all T1486 targets.
T1486prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets, tested recovery procedures and organizational readiness that directly enable restoration of encrypted data and services after a T1486 event, thereby preventing the final unavailability impact from persisting.
T1486recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus procedures and tested mechanisms to restore prioritized ICT services and information after a disruption, which directly recovers data rendered unavailable by T1486 encryption (the event-lane recovers anchor for A.8.13 vs T1486).
T1486responds — A.5.30 requires plans, structure, procedures and tested exercises that activate once disruption (including ransomware encryption) is underway to contain, restore ICT services within RTO/RPO, and meet availability objectives, which is the core of `responds`.
T1489detects — A.5.30 requires ICT continuity plans (including response procedures) to be regularly evaluated through exercises and tests and supported by an organizational structure to respond to disruption; this surfaces service-stop events that impair availability/RTO but only as part of tested continuity/response processes, not general detection instrumentation.
T1489prevents — A.5.30's BIA-driven ICT continuity strategies, plans, RTO/RPO specs, testing and organizational structure for preparing/mitigating ICT disruptions directly prevent many T1489 instances that target critical services (e.g. Exchange, SQL, cloud APIs) by ensuring rapid restoration and availability during/after stoppage, but do not stop the adversary technique itself from executing on any platform.
T1489recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after a disruption, which directly recovers state destroyed by T1489's service-stop (or follow-on data-impact) techniques.
T1489responds — A.5.30 explicitly requires ICT continuity plans with response procedures, organizational structure to respond to disruption, and tested plans that restore prioritized ICT services within RTOs once a stop/disable event is underway.
T1490recovers — A.5.30 requires ICT continuity plans with defined RTO/RPO, restoration procedures, tested recovery capabilities, and adequate structure to restore prioritized ICT services and information after disruption, directly addressing recovery from T1490's deletion or disablement of recovery features and backups.
T1491recovers — A.5.30 requires ICT continuity plans with explicit RTO/RPO-driven restore procedures for prioritized services and information; restoring defaced visual content (the integrity impact) is a direct instance of recovering the affected ICT resources after the T1491 event.
T1491.001recovers — A.5.30 plans, tests, and enacts restoration of ICT services and data to BIA-defined RTO/RPO after a disruption (including post-defacement integrity or availability loss), but the control's scope is limited to prioritized ICT resources rather than every internal system or desktop that could be defaced.
T1491.002recovers — A.5.30 ensures ICT continuity plans, RTOs, and tested recovery procedures exist to restore defaced external systems/services to operational state post-disruption, directly addressing recovery after the defacement event.
T1495prevents — A.5.30's BIA-driven ICT continuity strategies, plans, RTO/RPO targets, tested recovery procedures and organizational readiness for disruption directly enable restoration of corrupted firmware/BIOS to restore availability, which stops the full technique from denying ongoing use even though it does not stop the initial overwrite/corruption from occurring.
T1495recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers availability lost to firmware corruption on affected devices.
T1495responds — A.5.30 requires plans, structure, procedures and tested response/recovery actions that activate once an ICT disruption (including firmware corruption rendering devices inoperable) is underway, enabling containment, restoration of prioritized ICT services within RTO/RPO, and return to availability; this matches the `responds` verb but is partial because the clause is scoped to organization-owned ICT continuity rather than all possible firmware targets (e.g. third-party network devices or non-prioritized hardware) and does not itself perform the response.
T1496detects — A.5.30 requires ICT continuity plans that are exercised/tested and include performance/capacity specs plus RTO/RPO monitoring elements, which can surface anomalous resource consumption or availability impacts from hijacking after the fact, but only as part of broader continuity testing rather than dedicated real-time detection of the technique itself.
T1496prevents — A.5.30's BIA-driven ICT continuity strategies, RTO/RPO requirements, plans, testing and organizational structure for preparing/mitigating ICT disruptions directly prevent many hijacking forms (e.g. cryptomining, bandwidth abuse) from causing availability impact by ensuring continued service operation, but this is only a slice of the class since it does not stop initial co-option or non-availability forms like spam generation.
T1496recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, directly recovering availability impacted by resource hijacking such as cryptomining or bandwidth abuse.
T1496responds — A.5.30 requires plans, structure, procedures and tested response/recovery actions that activate once an ICT disruption (including resource-exhaustion hijacking) is underway, containing impact and restoring prioritized services to meet RTO/RPO; the named remainder is non-ICT hijacking vectors outside its explicit scope.
T1496.001detects — A.5.30 requires ICT continuity plans that are regularly evaluated through exercises and tests (plus BIA-derived RTO/RPO/performance specs), which can surface anomalous resource consumption as a disruption indicator, but this is indirect governance-level planning rather than active runtime detection of the hijacking technique itself.
T1496.001prevents — A.5.30's BIA-driven ICT continuity strategies, plans, RTO/RPO specs, testing and organizational readiness for disruption directly prevent the availability impact (unresponsiveness, service degradation) from compute hijacking once the technique runs, but do not stop initial co-option or resource consumption itself.
T1496.001recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers availability degraded by compute hijacking (resource exhaustion or unresponsiveness).
T1496.001responds — A.5.30 explicitly requires organizational structure, plans, response procedures, exercises/tests and RTO-driven restoration to manage and recover from ICT disruptions, which directly addresses containment/eradication once compute-hijacking impact (resource exhaustion, unresponsiveness) is underway.
T1496.002detects — A.5.30 requires ICT continuity plans that are regularly evaluated through exercises and tests (plus BIA-derived RTO/RPO monitoring of prioritized services), which can surface anomalous bandwidth consumption as an availability-impacting disruption once it occurs, but the control is scoped only to continuity of prioritized ICT services rather than broadly detecting the bandwidth-hijacking technique itself across all systems.
T1496.003recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers availability and data state after an SMS-pumping-induced overload or cost event.
T1496.003responds — A.5.30 requires plans, structure, exercises and procedures that respond to and manage an ICT service disruption once it is underway (including during and after phases), which directly matches the availability impact and channel-overwhelm effects of SMS pumping; partial because the clause is scoped to prioritized ICT services identified via BIA/RTO/RPO rather than all messaging channels or non-ICT fraud vectors.
T1496.004recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers availability and data state after a T1496.004-induced outage or quota exhaustion.
T1498detects — A.5.30 requires testing/evaluation of ICT continuity plans and monitoring of performance/capacity against BIA-derived RTO/RPO during disruption, which can surface a Network DoS as an availability-impacting event once underway, but this is scoped only to prioritized ICT services within the continuity program rather than broadly detecting all instances or precursors of the technique.
T1498prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets, tested recovery procedures and organizational readiness that enable continued availability of prioritized ICT services during disruption, which directly counters the availability degradation/blockage that defines T1498; it is only partial because the control is scoped to the organization's own prioritized ICT assets and does not stop an external adversary from directing volumetric traffic at them or at upstream providers.
T1498recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, directly recovering availability lost to a network DoS that has already exhausted bandwidth.
T1498responds — A.5.30 explicitly requires ICT continuity plans with response procedures, organizational structure to respond to disruption, and tested plans that restore prioritized ICT services within RTO/RPO once a disruption (such as Network DoS bandwidth exhaustion) is underway.
T1498.001detects — A.5.30 requires testing/evaluation of ICT continuity plans and procedures that respond to disruptions (including availability-impacting network floods), which surfaces whether the plans function against the technique but does not mandate ongoing detection or monitoring of the flood itself.
T1498.001prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets, tested recovery procedures and organizational readiness that enable continued availability of prioritized ICT services during (and after) a disruption such as a direct network flood; this stops the technique from fully denying the organization's objectives even though the flood itself is not blocked at the network edge.
T1498.001recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, directly recovering availability lost to a network flood DoS.
T1498.001responds — A.5.30 requires developed, tested ICT continuity plans with explicit response procedures, organizational structure to respond to disruption, and RTO-driven restoration of prioritized ICT services, which directly enacts containment/eradication once a direct network flood (DoS) is underway; the named remainder is that the control does not itself perform real-time containment actions such as traffic scrubbing or immediate rerouting.
T1498.002detects — A.5.30 requires ICT continuity plans (including monitoring of availability during disruption) to be tested and exercised, which can surface anomalous traffic patterns from a reflection amplification DoS once it is underway, but the control's focus is on BIA-driven readiness and recovery rather than real-time detection mechanisms.
T1498.002prevents — A.5.30's BIA-driven ICT continuity strategies, plans, RTO/RPO specs, testing and organizational readiness for disruption directly enable withstanding or rapidly restoring availability after a reflection-amplification flood, thereby preventing the technique from achieving its full DoS objective in scoped ICT services; it does not stop the packets from being generated or reflected.
T1498.002recovers — A.5.30 explicitly plans, tests and enacts ICT recovery (RTO/RPO, prioritized restoration of services and information) after a disruption that includes DoS-induced loss of availability; the control therefore restores the state the reflection-amplification technique destroyed.
T1498.002responds — A.5.30 requires plans, structure, and tested procedures to respond to and recover from ICT disruptions (including availability-impacting DoS events), but stops at preparedness and high-level response planning rather than mandating real-time containment or eradication actions once a reflection amplification flood is underway.
T1499detects — A.5.30 requires ICT continuity plans (including response procedures) that are regularly evaluated through exercises and tests, which surfaces whether the organization can detect and respond to availability disruptions from endpoint DoS, but the control itself does not mandate or perform detection mechanisms.
T1499prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets, tested recovery procedures and organizational readiness that enable prioritized ICT services (including those targeted by endpoint DoS) to resume within defined windows, thereby stopping the sustained availability loss the technique seeks to cause; it does not stop the initial resource-exhaustion or crash vector itself.
T1499recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after a disruption, directly recovering availability degraded by an Endpoint DoS technique.
T1499responds — A.5.30 requires plans, structure, procedures and tested response/recovery capabilities that activate once an ICT disruption (including endpoint DoS) is underway, performing containment, restoration to RTO/RPO targets and management of the event.
T1499.001detects — A.5.30 requires ICT continuity plans (developed from BIA) that are tested/exercised and include response procedures for disruptions, which can encompass detection of availability-impacting events like OS resource exhaustion; however, it is silent on any specific monitoring, anomaly detection, or logging mechanisms and focuses primarily on preparedness, RTO/RPO planning, and recovery rather than real-time detection of the technique itself.
T1499.001prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets and tested recovery procedures that can prevent full loss of availability from an OS-exhaustion DoS by enabling rapid restoration of prioritized ICT services, but does not stop the attack technique itself from running or exhausting OS resources.
T1499.001recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers availability lost to an OS-exhaustion DoS (the impact already realized).
T1499.001responds — A.5.30 requires plans, structure, exercises and procedures to respond to and recover from ICT disruptions (including those from resource-exhaustion DoS that impair availability), but its BIA-driven focus on pre-planned RTO/RPO restoration of prioritized services does not address containment or eradication of the live flood itself, leaving a large slice of the incident-response act named by the verb unaddressed.
T1499.002detects — A.5.30 requires testing/evaluation of ICT continuity plans and procedures that respond to disruptions (including availability-impacting ones), which can surface DoS-like exhaustion events during exercises, but does not mandate ongoing detection or monitoring of the live technique itself.
T1499.002prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets, tested recovery procedures and organizational readiness that enable continued availability of prioritized ICT services during disruption, which directly counters the availability loss from service-exhaustion floods (a named subset of the technique's impacts); it does not stop the flood itself from being launched or from consuming resources.
T1499.002recovers — A.5.30 explicitly requires ICT continuity plans with RTO/RPO, restoration procedures, and tested recovery to restore availability of ICT services and information after a disruption such as a service-exhaustion flood has occurred.
T1499.002responds — A.5.30 requires ICT continuity plans with response procedures, organizational structure to respond to disruption, and tested plans that restore prioritized ICT services within RTO/RPO once a service-exhaustion flood is underway; this matches the `responds` verb for containment/eradication of realized impact, but only partially because the clause is scoped to planned/prioritized ICT services from BIA (not all possible network services or non-ICT elements in the technique) and recovery does not always bound an ongoing flood.
T1499.003detects — A.5.30 requires testing/evaluation of ICT continuity plans and procedures that address disruption (including availability-impacting events), which can surface DoS-like exhaustion in tested scenarios, but the control's core focus is on preparedness, BIA-derived RTO/RPO planning and recovery rather than ongoing detection of the live technique.
T1499.003prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, and tested recovery procedures (with RTO/RPO) that prepare for, mitigate, and respond to disruptions including resource-exhaustion DoS, thereby stopping many instances of T1499.003 from causing sustained unavailability; it is only partial because the control is planning-oriented and does not itself implement the specific runtime protections (e.g., rate limiting or resource caps) that would block the technique in all cases.
T1499.003recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after a disruption, which directly recovers availability following an application-exhaustion DoS that has already denied service.
T1499.003responds — A.5.30 requires plans, structure, exercises and procedures that respond to and recover from ICT disruptions (including resource-exhaustion DoS once underway), but its BIA-driven focus on pre-planned continuity for prioritized services leaves many application-exhaustion vectors (non-prioritized apps, untested edge cases, novel flood patterns) outside the scoped response
T1499.004prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets, testing and organizational readiness that enable recovery of prioritized services after a crash-induced DoS, thereby stopping the persistent denial-of-availability outcome the technique seeks; it does not stop the vulnerability exploitation or initial crash itself.
T1499.004recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after a disruption, which directly recovers state destroyed by a successful T1499.004 DoS exploit (with the bounded remainder being any unrecoverable window since the last RPO and non-ICT assets outside the BIA scope).
T1499.004responds — A.5.30 requires plans, structure, exercises and procedures that respond to and recover from ICT disruptions (including those from exploitation-induced crashes), but its focus is on pre-planned continuity for named business services rather than on-the-fly containment/eradication of an in-progress T1499.004 exploit.
T1528recovers — A.5.30 ensures ICT continuity plans, RTOs, RPOs, and tested recovery procedures exist to restore prioritized ICT services and information after a disruption (including one caused by stolen tokens), directly matching the recovers verb; the named remainder is that it does not address non-ICT or non-prioritized assets impacted by the technique.
T1529detects — A.5.30 requires ICT continuity plans (including response procedures) to be regularly evaluated through exercises and tests, which surfaces whether shutdown/reboot techniques would impede recovery, but does not mandate ongoing detection of the technique in flight.
T1529recovers — A.5.30 explicitly requires ICT continuity plans with RTO/RPO, restoration procedures, tested recovery to maintain availability of ICT services and information after a disruption, which directly addresses recovery from a shutdown/reboot that interrupts access or impedes response.
T1529responds — A.5.30 requires plans, structure, procedures and tested exercises that respond to a disruption (including one initiated by T1529) by restoring prioritized ICT services within RTO/RPO, which directly matches the `responds` verb of containment/eradication once the technique is underway.
T1530recovers — ICT continuity plans, RTO/RPO definitions, restoration procedures, and tested recovery mechanisms directly restore availability of information assets (including cloud-stored data) after a disruption or loss event has occurred.
T1531detects — A.5.30 requires ICT continuity plans (including response procedures) to be regularly evaluated through exercises and tests, which surfaces gaps in readiness to handle account-access-removal disruptions but does not mandate ongoing detection of the technique itself
T1531prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, and tested recovery procedures (incl. RTO/RPO for prioritized services and information) that can restore account access post-disruption, thereby preventing the adversary's availability-interruption goal from succeeding permanently; it does not stop the initial account manipulation technique itself.
T1531recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers from account-access-removal effects (including those paired with shutdown/reboot or ransomware) once the disruption has occurred.
T1531responds — A.5.30 requires plans, structure, procedures and tested exercises that respond to ICT disruptions (including account-access loss as one form of availability impact), containing the event and restoring prioritized services within RTO/RPO; the ransomware context where T1531 deliberately precedes encryption to impede recovery is explicitly inside the BIA-driven continuity response that this control owns.
T1537responds — A.5.30 requires plans, structure, and tested procedures to respond to and recover from ICT disruptions (including those from exfiltration via cloud transfers/backups), but only after impact is realized and only for the availability slice of the technique, not the data loss or exfiltration itself.
T1542recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after a disruption, which directly recovers state following a Pre-OS Boot persistence implant that has already altered firmware or boot components.
T1542.002recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which recovers state after the firmware modification technique has already run and persisted.
T1542.003recovers — A.5.30's BIA-driven RTO/RPO, ICT continuity plans, and tested restoration procedures for prioritized services and information directly enable recovery of state after a bootkit has executed and persisted below the OS, though the control's focus on general availability leaves a named remainder for cases where boot-sector remediation requires offline tools or full reimaging outside standard ICT continuity playbooks.
T1542.003responds — A.5.30 requires organizational structure, plans, procedures and tested response/recovery actions for ICT disruptions (including those from low-level persistence like bootkits), but only after the disruption is already recognized and the BIA/RTO/RPO process has scoped it; the control does not itself perform containment or eradication.
T1542.004recovers — A.5.30 ensures ICT continuity plans, RTO/RPO-driven recovery procedures, tested restoration of prioritized services and information after disruption, which recovers state post-ROMMONkit persistence on network devices (a form of ICT disruption) though the firmware manipulation itself may require additional remediation steps.
T1542.005recovers — A.5.30 plans, tests, and restores prioritized ICT services/information to meet BIA-derived RTO/RPO after disruption, which can recover from a device running a malicious image once detected, but only for a bounded subset of affected assets and does not address the boot-time technique itself.
T1546.003detects — A.5.30 requires testing/evaluation of ICT continuity plans and procedures that can surface anomalous WMI subscriptions as part of preparedness for disruption, but the control's BIA-driven focus on availability and recovery does not mandate or guarantee detection of this specific persistence technique.
T1547.012detects — A.5.30 requires monitoring and testing of ICT continuity plans and response procedures for disruptions, which can surface anomalous boot-time DLL loading or service restarts as part of incident detection, but does not mandate or focus on specific detection of this persistence technique.
T1558.001recovers — A.5.30 ensures ICT continuity plans, RTO/RPO-driven restoration procedures, tested recovery of prioritized services and information assets after a disruption that can include credential-compromise events such as golden-ticket use.
T1561detects — A.5.30 requires ICT continuity plans (including response procedures) to be regularly evaluated through exercises and tests, which surfaces whether detection/response mechanisms for disruptions like disk-wipe events function as intended within the BIA-derived RTO/RPO scope; this is a genuine but bounded slice of the full technique (e.g., it does not mandate ongoing monitoring or anomaly detection itself).
T1561prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets, tested recovery procedures and organizational readiness that enable restoration of wiped ICT services and data after a T1561 event, thereby preventing the final unavailability outcome even though the wipe technique itself is not stopped.
T1561recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers state destroyed by disk-wipe (T1561) once the attack has run; the named remainder is that not every wiped asset may be in the BIA-prioritized set.
T1561responds — A.5.30 requires plans, structure, procedures and tested exercises that respond to a disruption (including one caused by disk wipe) by restoring prioritized ICT services within RTO/RPO, which directly matches the `responds` verb of containment/eradication once the availability-interruption technique is underway.
T1561.001detects — A.5.30 requires ICT continuity plans (including response procedures) to be regularly evaluated through exercises and tests, which surfaces whether detection/response mechanisms for disruptions like disk-wipe exist and work, but the control itself does not mandate or perform detection of the T1561.001 technique.
T1561.001prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, RTO/RPO targets, tested recovery procedures and organizational readiness that directly enable restoration of wiped systems and data within defined timeframes, thereby preventing the adversary's intended availability interruption from becoming permanent or business-ending (cf. A.8.13 recovers mostly on T1486; A.5.1 recovers none on T1486).
T1561.001recovers — A.5.30 explicitly requires RPO definitions, restoration procedures for prioritized ICT resources/information, and tested plans to restore availability after disruption, directly addressing recovery from disk-wipe impact on storage and ICT services.
T1561.001responds — A.5.30 requires plans, structure, procedures and tested response/recovery capabilities that activate once disruption (including disk-wipe events) is underway, directly matching the `responds` verb of containment/eradication during an active technique.
T1561.002detects — A.5.30 requires ICT continuity plans (including response procedures) to be regularly evaluated through exercises and tests that surface whether the organization can still meet RTO/RPO when disk structures are wiped, thereby detecting gaps in readiness; this is only a slice of the full technique because the control is silent on real-time detection of the wipe itself while it is underway.
T1561.002prevents — A.5.30 requires BIA-driven ICT continuity strategies, plans, and tested recovery procedures (with explicit RTO/RPO) that prepare for, mitigate, and respond to disruptions including those from disk-structure wipes, thereby stopping the full availability-loss impact of the technique in scoped critical systems; it does not stop the adversary from executing the wipe itself.
T1561.002recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, directly recovering availability destroyed by disk-structure wipe (the technique's core impact).
T1561.002responds — A.5.30 requires plans, structure, procedures and tested exercises that respond to and recover from a disruption (including one caused by disk-structure wipe), bounding its impact once underway.
T1565.001recovers — A.5.30 ensures ICT continuity plans include RTO/RPO specs and restoration procedures for prioritized information assets (explicitly from BIA outputs), directly enabling recovery of manipulated stored data to a prior consistent state after the T1565.001 impact is realized.
T1578.003detects — A.5.30 requires ICT continuity plans (including response procedures) that are exercised/tested and cover RTO/RPO-driven restoration of services and information; this surfaces deletion events that would otherwise destroy evidence during a disruption, but only for prioritized ICT assets inside the BIA scope, not arbitrary adversary-driven instance terminations.
T1578.003recovers — A.5.30 explicitly requires ICT continuity plans with defined RTO/RPO plus tested procedures to restore prioritized ICT services and information after disruption, which directly recovers from the post-deletion state (lost instance and artifacts) for assets covered by the BIA.
T1578.003responds — A.5.30 requires plans, structure, and tested procedures to respond to and recover from ICT disruptions (including after an incident), which can encompass containment/eradication steps once a cloud instance deletion tactic is underway as part of a broader disruption event, but the control is scoped to business continuity objectives rather than specifically addressing adversarial evasion tactics.
T1578.004recovers — A.5.30 plans, tests and enacts ICT continuity (including RTO/RPO-driven restore of services and information after disruption) which directly recovers state destroyed by the revert technique once it has run; the named remainder is that the control's BIA-driven scope may not encompass every transient/ephemeral artifact the adversary can wipe.
T1578.004responds — A.5.30's response procedures, organizational structure for responding to disruption, and tested plans for restoring ICT services within RTO/RPO bounds can contain/eradicate a reversion that disrupts availability (e.g. by failing over or restoring from clean backups), but the control's focus is on unplanned business disruptions rather than deliberate adversarial evasion, leaving most of the technique's post-reversion cleanup and detection aspects untouched.
T1601.001recovers — A.5.30 plans, tests, and restores prioritized ICT services/information to meet BIA-derived RTO/RPO after disruption, which can recover state altered by a patched network-device image once the compromised component is replaced or rolled back, but only for the bounded subset of network devices treated as ICT resources in the BIA (most T1601.001 targets lie outside that scope).
T1657prevents — A.5.30's BIA-driven ICT continuity planning, RTO/RPO setting, strategy selection, tested recovery plans and organizational readiness directly prevent the business-disruption and availability-loss slice of T1657 (e.g. ransomware extortion that withholds funds or data until paid, or NotPetya-style disruption masked as financial theft), but leave the pure social-engineering, account-compromise and technical-theft paths to monetary loss untouched.
T1657recovers — A.5.30 ensures ICT continuity plans, RTOs, RPOs, and tested recovery procedures exist to restore prioritized ICT services, information assets, and availability after a disruption that financial theft (via ransomware extortion, BEC, or other means) can cause.
T1657responds — A.5.30 requires plans, structure, and tested procedures to respond to and manage ICT service disruptions (including those from ransomware extortion that realizes financial theft via T1486), bounding impact once underway; the named remainder is non-ICT slices of pure social-engineering BEC/fraud.
T1667recovers — A.5.30 ensures ICT continuity plans exist with defined RTO/RPO and tested recovery procedures that restore prioritized ICT services and information after a disruption, which directly recovers from the inbox overload and buried legitimate messages caused by email bombing.
T1667responds — A.5.30 requires plans, structure, and tested procedures to respond to and recover from ICT disruptions (including overloads that impair availability of email services), but the control is scoped to business continuity events rather than adversary-driven harassment or social-engineering precursors, leaving a large remainder of T1667 instances unaddressed.
T1685recovers — A.5.30 ensures ICT continuity plans, RTOs, RPOs, and tested recovery procedures exist to restore prioritized ICT services, information, and defensive capabilities (including logging/telemetry tools) after a disruption caused by the technique.
T1685.005recovers — A.5.30 plans, tests, and restores ICT services/information to BIA-defined RTO/RPO levels after a disruption; clearing event logs is an ICT-disruption technique whose post-impact state (lost audit trail) is recovered via the prioritized backup-and-restore procedures the control mandates.
T1685.006recovers — A.5.30 plans, tests, and restores prioritized ICT services/information to meet BIA-derived RTO/RPO after disruption, which can recover cleared logs when they are in scope as a prioritized ICT resource, but the control is silent on forensic log restoration and most log-clearing events fall outside declared business continuity disruptions

Prevented OWASP Web Top 10 (2025) risks (2)

OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

A09←M A10←P

Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.