A.8.6 Technological
Capacity management
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 (12)
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).
Why these map — AI rationale (under review)
- CP-2mostlyaligns with — Both controls require identifying resource needs and planning actions to ensure systems can meet operational demands under varying conditions.
- SC-6mostlycovers — A.8.6's broad capacity planning for facilities, HR, offices, and processing resources accounts for the bulk of SC-6's resource-availability allocation requirement, but leaves a residual of technical, system-level, and denial-of-service-specific protections untouched.
- CM-6partialaligns with — Both emphasize ongoing monitoring and tuning of system resources to maintain performance and availability.
- PL-2partialaligns with — Both require documenting capacity-related planning decisions for critical systems to support consistent resource management.
- SC-6partialaligns with — Both address ensuring adequate resources are available to prevent degradation of security functions due to resource exhaustion.
- SI-4partialaligns with — Both require monitoring of system resources to detect capacity issues before they impact operations or security.
Aligned NIST CSF 2.0 outcomes (19)
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).
Why these map — AI rationale (under review)
- ID.AM-08mostlyaligns with — Capacity planning that accounts for business criticality, future requirements, and life-cycle considerations aligns with managing systems, hardware, software, services, and data throughout their life cycles.
- PR.IR-04mostlyaligns with — The ISO control's focus on monitoring utilization, stress-testing, and ensuring sufficient capacity to meet peak demands directly supports maintaining adequate resource capacity for availability.
- ID.IM-03partialaligns with — Using capacity monitoring data and stress-test results to identify and avoid resource constraints reflects identifying improvements from execution of operational processes and activities.
- ID.RA-04partialaligns with — Projecting future capacity needs and identifying resource limitations or single points of failure contributes to understanding potential impacts and likelihoods of threats exploiting vulnerabilities.
- PR.PS-01partialaligns with — Establishing a documented capacity management plan and applying tuning, monitoring, and optimization practices supports configuration management practices.
- ID.AM-08implements — Assessed as NOT holding by the authoring instrument at v1.19-2026-08-23. 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-03implements — 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.
- PR.IR-04implements — A.8.6 directly operationalizes the exact resource-capacity outcome that PR.IR-04 names for availability
- PR.PS-01implements — 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.
Related OWASP ASVS 5.0 requirements (10)
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).
Why these map — AI rationale (under review)
- V13.1.2partialaligns with — Defining and monitoring maximum concurrent connections and resource limits for services is a concrete implementation of the ISO control's call to identify capacity requirements and apply monitoring to maintain availability.
- V13.1.3partialaligns with — The ISO control's emphasis on documented projections of future capacity needs and resource-management strategies for external services aligns with the ASVS requirement to define resource-management strategies for every external system the application uses.
- V15.2.2partialaligns with — The ISO control's requirement to monitor utilization and perform stress-testing to ensure capacity meets peak demand directly supports the ASVS requirement to implement defenses against loss of availability caused by resource-intensive functionality.
Related weaknesses / CWE (28)
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).
Why these map — AI rationale (under review)
- CWE-405nonemitigates — Stress-testing and demand-reduction tactics (e.g., bandwidth throttling) blunt amplification vectors that would otherwise let an attacker multiply resource consumption through a single request.
- CWE-406nonemitigates — Capacity management directly limits excessive outbound traffic that an actor could otherwise trigger.
- CWE-920nonemitigates — Capacity management directly limits resource consumption, including power, thereby mitigating the weakness.
- CWE-1049finds — Capacity management identifies and mitigates resource exhaustion from inefficient large-table queries.
- CWE-1050mitigates — Capacity management directly limits resource exhaustion caused by unbounded loops.
- CWE-1072mitigates — Capacity management can indirectly reduce resource exhaustion from unpooled connections but does not mandate pooling.
- CWE-1176finds — Capacity management can drive optimization of CPU-intensive algorithms to prevent resource exhaustion.
- CWE-1325mitigates — Capacity management directly limits total memory consumption across objects, mitigating unbounded sequential allocations.
- CWE-400prevents — By continuously monitoring utilization, stress-testing peak loads, and maintaining documented plans to scale or throttle resources, the control directly limits an attacker’s ability to drive a system into uncontrolled resource exhaustion.
- CWE-401finds — Capacity management may detect memory exhaustion symptoms but does not prevent the coding flaw.
- CWE-407mitigates — Capacity management can detect and mitigate performance degradation caused by algorithmic complexity attacks.
- CWE-408mitigates — Capacity management may mitigate impact of amplification but does not prevent the weakness itself.
- CWE-409mitigates — Capacity management can detect and prevent resource exhaustion from decompression bombs.
- CWE-410prevents — Capacity management directly addresses sizing resource pools to handle peak demand and prevent exhaustion.
- CWE-674finds — Capacity management includes monitoring and limits that mitigate resource exhaustion from runaway recursion.
- CWE-770prevents — Capacity projections and elasticity measures ensure that allocation requests are bounded and can be throttled, reducing the window in which an attacker can force unbounded resource reservations.
- CWE-774prevents — Capacity management directly limits resource allocation including file descriptors.
Mitigated MITRE ATT&CK techniques (304)
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.002←MT1001.003←MT1003.003→PT1006←FT1014←MT1020→PT1027.001←MT1027.002←MT1027.006←MT1027.007←MT1027.008←MT1027.009←MT1027.011←MT1027.014←MT1027.016←MT1027.018←MT1030←MT1036←MT1036.003←MT1036.005←MT1036.008←MT1036.009←MT1036.011←MT1036.012←MT1041→PT1046→PT1053→PT1053.007→PT1055←M →PT1055.001←M →PT1055.002←M →PT1055.003←M →PT1055.004←MT1055.005←MT1055.008←M →PT1055.009←MT1055.011←MT1055.012←MT1055.013←MT1055.014←M →PT1055.015←MT1059.008→PT1070←MT1070.004←MT1070.010←MT1071←MT1071.004←M →PT1071.005←MT1072→PT1074→PT1074.001→PT1074.002←M →PT1078←PT1090.001←M →PT1090.002←M →PT1090.003←MT1095←MT1098.005←M →PT1102←MT1102.002←MT1104←MT1110.003←MT1114.002→PT1127←MT1127.001←MT1127.003←MT1133←MT1134←MT1134.004←MT1205.002→PT1207←MT1211←PT1218←MT1218.005←M →PT1218.007←MT1218.008←MT1218.010←MT1218.011←MT1218.012←M →PT1218.013←MT1219→PT1219.002→PT1219.003←MT1221←MT1222←MT1222.002←MT1480.001←MT1484←MT1484.002←MT1485←M →PT1485.001←M →PT1486→MT1489←M →PT1490←M →MT1491.001→PT1495←MT1496→PT1496.001→PT1496.002→PT1496.003→PT1496.004→PT1498→PT1498.001←M →PT1498.002←M →PT1499→PT1499.001←M →PT1499.002→PT1499.003→PT1499.004←M →PT1529←P →PT1531←P →PT1535←M →PT1537←M →PT1539←MT1542←MT1542.002←MT1542.005→PT1546→PT1546.003→PT1546.015→PT1547.012→PT1548.005→PT1550←MT1550.001←FT1550.002←FT1550.004←FT1552.007→PT1553.001←FT1553.002←PT1553.003←MT1553.004←PT1553.005←MT1553.006←MT1556←MT1556.009←MT1561←M →MT1561.001←M →MT1561.002←M →PT1563.002→PT1564.004←MT1565.001→PT1567→PT1567.002→PT1567.004→PT1568.003←MT1571←MT1572←MT1574←MT1574.001←MT1574.004←MT1574.013←MT1578←M →PT1578.001←MT1578.002←M →PT1578.003←M →PT1578.004←M →PT1578.005←M →PT1583.003←MT1583.007←MT1584.005←PT1599←MT1599.001←M →PT1600←PT1601.002←MT1602.001→PT1606.001←FT1610←PT1611←MT1612←MT1620←MT1622←FT1647←PT1648←P →PT1653←PT1666←M →PT1667←M →PT1678←MT1685←MT1685.001←MT1685.002←MT1685.003←MT1685.004←M →PT1685.005←MT1685.006←MT1686←F →PT1686.001←P →PT1686.002←PT1686.003←M →PT1687←PT1688←MT1689←PT1690←M
Why these map — AI rationale (under review)
- T1003.003detects — A.8.6 requires detective controls and monitoring of system resources/utilization (including for mission-critical systems), which can surface anomalous access or copy attempts against NTDS.dit or related backups as capacity or availability anomalies, but this is indirect, not specific to credential dumping, and leaves the bulk of the technique's stealthy execution (e.g. via VSS or ntdsutil) unreached.
- T1020detects — A.8.6 requires detective controls, system monitoring, and resource-utilization tracking that can surface anomalous bandwidth consumption or automated bulk transfers, but the clause's scope is capacity management rather than security-event detection and the named remainder (stealthy, low-and-slow, or non-bandwidth-intensive exfiltration) is not covered.
- T1041detects — A.8.6's detective controls, system tuning/monitoring, stress-tests and resource-utilization monitoring can surface anomalous bandwidth consumption or traffic patterns that would accompany large exfiltration over a C2 channel, but the clause's focus is capacity and availability rather than security-event detection, leaving most stealthy or low-volume T1041 instances outside its intended scope.
- T1046detects — A.8.6 requires detective controls and monitoring of system resources (including projections and stress-tests) that can surface anomalous service-discovery activity when it consumes detectable capacity, but the clause is scoped to capacity/availability rather than to network, port, or mDNS scanning behaviors themselves.
- T1053detects — A.8.6 requires detective controls and monitoring of system resources/utilization to indicate problems in due time, which can surface anomalous scheduled tasks/jobs as capacity or performance issues, but this is incidental and does not target the technique itself.
- T1053.007detects — A.8.6 requires detective controls, system tuning/monitoring, stress-tests and resource-utilization monitoring that can surface anomalous container-orchestration jobs or capacity spikes caused by T1053.007, but the clause is scoped to capacity and performance rather than security events, leaving most stealthy abuse undetected.
- T1055detects — A.8.6 requires detective controls and system monitoring/tuning to indicate problems (including potential resource abuse or anomalies from injection) in due time, but this is scoped only to capacity/utilization concerns rather than the technique itself or its security intent.
- T1055.001detects — A.8.6 requires detective controls and system monitoring/tuning to indicate problems in due time, which can surface anomalous resource consumption or process behavior tied to DLL injection, but the clause is scoped to capacity/availability rather than security events and does not mandate the telemetry depth needed to reliably catch stealthy variants like reflective injection or module stomping.
- T1055.002detects — A.8.6 requires detective controls and monitoring of system resources/utilization to indicate problems in due time, which can surface anomalous resource consumption or process behavior tied to PE injection, but the clause is scoped to capacity management rather than security event detection and does not address evasion of process-based defenses.
- T1055.003detects — A.8.6 requires detective controls and system monitoring/tuning to surface problems (including resource anomalies that thread hijacking would produce), but capacity management is not scoped to security events or process injection and would miss stealthy hijacks that do not measurably affect utilization.
- T1055.008detects — A.8.6 explicitly requires detective controls and system tuning/monitoring to indicate problems in due time, which surfaces anomalous resource consumption or ptrace-driven process modification on monitored Linux systems; partial because the clause sets capacity-focused scope rather than mandating host/process telemetry depth that would reliably catch all ptrace injection.
- T1055.014detects — A.8.6 requires detective controls and system monitoring/tuning to indicate problems in due time, which can surface anomalous resource consumption or process behavior tied to VDSO hijacking on Linux, but the control is scoped to capacity/availability rather than security event detection and does not address evasion of process-based defenses.
- T1059.008detects — A.8.6 requires detective controls and system monitoring/tuning to indicate problems in due time, which can surface anomalous CLI usage on network devices as a capacity or availability issue, but this is incidental and does not target the technique itself.
- T1071.004detects — A.8.6 explicitly requires detective controls and system monitoring/tuning to surface problems (including anomalous resource consumption that DNS tunneling often produces), but the clause is scoped to capacity and availability rather than security-specific detection of protocol abuse or infrequent beacons.
- T1072detects — A.8.6 requires detective controls and monitoring of key system resources/utilization (including projections and stress-tests) that can surface anomalous capacity consumption or admin-tool activity once underway, but this is a minority slice of the technique whose dominant vectors are credentialed abuse of deployment tools rather than observable capacity exhaustion.
- T1074detects — A.8.6's detective controls and system monitoring can surface anomalous resource consumption or unexpected staging activity (e.g. sudden disk growth, new cloud instances), but the clause's focus is capacity planning and availability rather than adversary behavior, leaving most stealthy staging undetected.
- T1074.001detects — A.8.6 requires detective controls and monitoring of system resources/utilization that can surface anomalous local staging activity (e.g. sudden disk growth or unusual file copies), but this is indirect, scope-dependent, and does not target the technique itself.
- T1074.002detects — A.8.6 requires detective controls and monitoring of system resources/utilization (including in cloud environments) that can surface anomalous staging activity as a capacity or performance anomaly, but this is indirect, not specific to the TTP, and leaves the bulk of stealthy staging undetected.
- T1090.001detects — A.8.6 requires detective controls, system monitoring, and utilization tracking that can surface anomalous internal traffic patterns or resource spikes consistent with proxying, but the clause is scoped to capacity/availability rather than mandating detection of stealthy C2 redirection that blends with trusted protocols.
- T1090.002detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests and utilization monitoring of key resources that can surface anomalous capacity consumption or traffic patterns produced by external-proxy C2, but the clause's scope is capacity management rather than security-event detection so only a minority slice of the technique is reached.
- T1098.005detects — A.8.6 requires detective controls and monitoring of key system resources/utilization (including projections and stress tests) that can surface anomalous device registrations or sudden spikes tied to service exhaustion, but this is a minority slice of the technique whose dominant vectors are credentialed self-enrollment and conditional-access bypass rather than capacity exhaustion.
- T1114.002detects — A.8.6 requires detective controls and monitoring of system/resource utilization (including stress-tests and projections) that can surface anomalous email collection activity on Exchange/Office 365 as a capacity or performance deviation; this is a genuine but minority slice of the technique, which is primarily credentialed access rather than a resource-consumption event.
- T1205.002detects — A.8.6 requires detective controls and system monitoring/tuning to indicate problems in due time, which can surface anomalous resource usage or network activity tied to socket filters, but the technique's low CPU overhead, lack of active connections, and limited visibility into raw sockets leave most of it undetected.
- T1218.005detects — A.8.6 requires detective controls and monitoring of system resources/utilization to indicate problems in due time, which can surface anomalous mshta.exe execution as a capacity or performance anomaly; this is a genuine but minority slice of the technique (most detections rely on process, script, or network telemetry unrelated to capacity management).
- T1218.012detects — A.8.6 requires detective controls and monitoring of system resources/utilization to indicate problems in due time; this can surface anomalous verclsid.exe executions as a resource or process anomaly, but the clause is scoped to capacity and availability rather than security events or COM abuse specifically.
- T1219detects — A.8.6 requires detective controls and monitoring of system resources/utilization to indicate problems in due time; this surfaces anomalous remote access tool usage or capacity spikes from C2 sessions as a detectable problem, but only as a minority slice of the technique (most RAT activity is not primarily a capacity issue).
- T1219.002detects — A.8.6's detective controls and system monitoring can surface anomalous capacity consumption or resource spikes caused by interactive remote desktop sessions, but this is incidental and does not target the technique itself (which is often low-footprint and legitimate-looking).
- T1485detects — A.8.6 explicitly requires detective controls and system tuning/monitoring to indicate capacity/availability problems in due time, which surfaces the availability interruption from data destruction (especially at scale or on mission-critical systems) but does not address the technique's core destructive act or non-capacity indicators.
- T1485recovers — A.8.6 explicitly lists deletion of obsolete data, decommissioning of systems/databases/environments, and capacity planning (including cloud elasticity) as ways to free resources and restore availability after demand spikes or losses, which directly addresses recovery from the availability interruption caused by T1485's targeted file/infrastructure destruction; however, it does not address restoring overwritten/irrecoverable data itself or forensic recovery, leaving a substantial remainder.
- T1485.001detects — A.8.6 requires detective controls, system monitoring, and resource-utilization oversight that can surface anomalous lifecycle-policy changes or sudden mass-deletion activity on cloud storage, but only for resources inside the monitored scope and only after the modification occurs.
- T1486detects — A.8.6 requires detective controls and monitoring of key system resources (including utilization trends and stress-testing) that can surface anomalous encryption activity affecting capacity/availability, but this is indirect, not specific to the T1486 technique itself, and limited to resources inside the monitored scope.
- T1486recovers — A.8.6 explicitly lists deletion of obsolete data, decommissioning of systems/databases, and optimizing resources to free capacity, plus a documented capacity management plan for mission-critical systems; these directly enable restoration of availability after ransomware encryption has rendered data or systems unavailable.
- T1489detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests and resource-utilization monitoring that can surface anomalous service-stop activity (especially when it affects capacity/availability of mission-critical systems), but the clause's scope is capacity planning rather than security-event detection and does not reach cloud API-level service disables or non-capacity-impacting stops.
- T1490recovers — A.8.6 explicitly requires backups, stress-testing of recovery capacity, monitoring for capacity problems in due time, and documented capacity plans for mission-critical systems, which directly enable restoration of state after T1490 has deleted or disabled recovery features (see event-lane anchor for A.8.13 vs T1490 and the explicit recovery-oriented language in A.8.6).
- T1491.001detects — A.8.6's detective controls and system monitoring can surface anomalous changes to internal resources (e.g. login messages, wallpapers, or website content) as indicators of integrity problems, but the clause's focus is on capacity/utilization trends rather than defacement or integrity monitoring, leaving most of the technique's surface outside its scope.
- T1496detects — A.8.6 explicitly requires system tuning/monitoring, stress-tests, detective controls to indicate problems in due time, and manager monitoring of key resource utilization, which surfaces anomalous consumption patterns characteristic of resource hijacking (e.g. cryptomining, bandwidth proxying) on owned systems; partial because the clause's scope is limited to organization-managed facilities and does not address hijacking of co-opted third-party or external resources (e.g. SaaS, victim proxies) named in the technique.
- T1496prevents — A.8.6's identification, monitoring, tuning, stress-testing and demand-reduction steps (e.g. decommissioning, optimizing, restricting non-critical bandwidth) directly close many hijacking vectors before they can consume resources at scale; the remainder is undetected or privileged hijacking that evades the capacity plan.
- T1496.001detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests, and manager monitoring of key resource utilization to surface capacity problems in due time; this surfaces compute-hijacking consumption on monitored resources but is scoped only to capacity/availability indicators rather than the full technique (including process-killing, container API abuse, or non-capacity signals).
- T1496.001prevents — A.8.6's monitoring, stress-testing, projections, resource-utilization oversight and demand-reduction steps (e.g. decommissioning, optimizing, restricting non-critical bandwidth) directly constrain the compute-resource consumption that T1496.001 relies on, but do not stop initial compromise or all forms of hijacking (especially in unmanaged cloud/containers).
- T1496.002detects — A.8.6 explicitly requires detective controls and monitoring of key system resources (including bandwidth utilization) to indicate problems in due time, which surfaces anomalous consumption from bandwidth hijacking; partial because the clause sets scope by business criticality and does not mandate universal network-level instrumentation for all hijacking vectors (e.g., proxyjacking or botnet seeding outside monitored mission-critical systems).
- T1496.002prevents — A.8.6 requires monitoring utilization, projections, stress-testing, detective controls, and explicit demand-reduction steps (including denying/restricting non-critical bandwidth), which can stop the technique from consuming bandwidth on managed systems; it is only a slice because the control is scoped to the organization's own facilities and does not constrain adversary-owned or co-opted external bandwidth used in botnets, proxyjacking, or scanning.
- T1496.003detects — A.8.6 requires detective controls and monitoring of system resources/utilization to indicate problems in due time, which can surface anomalous SMS traffic or capacity exhaustion from pumping, but only as a general resource issue rather than specifically identifying the fraud technique or its root cause.
- T1496.003prevents — A.8.6's capacity monitoring, projections, stress-testing, detective controls, and demand-reduction steps (e.g. rate-limiting non-critical traffic or optimizing queries) can stop SMS-pumping traffic from exhausting messaging quotas or overwhelming channels before availability is lost, but this is only a slice: the control is silent on the specific abuse vectors (public OTP forms, unthrottled SaaS messaging endpoints) that dominate the technique.
- T1496.004detects — A.8.6 requires detective controls and monitoring of key resource utilization (with projections and stress-tests) that can surface anomalous consumption from hijacked SaaS services, but the clause is scoped to planned capacity management for the organization's own facilities rather than adversary-driven abuse of external SaaS quotas or LLM resources.
- T1498detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests and resource-utilization monitoring that can surface impending or realized capacity exhaustion (including bandwidth), but this is scoped only to the organization's own facilities and does not address external flood traffic, spoofing or botnet-driven exhaustion of upstream/provider bandwidth.
- T1498prevents — A.8.6 requires identifying capacity needs, monitoring/tuning, stress-testing, projections, and explicit actions (cloud elasticity, optimizing code/queries, restricting non-critical bandwidth) that stop bandwidth exhaustion from succeeding on covered resources; this is a genuine but minority slice of T1498 because the control addresses only the defender's own provisioning and demand-reduction, not the external flood volume, spoofing, or botnet scale that defines most of the class.
- T1498recovers — A.8.6 explicitly lists reducing demand (deleting obsolete data, decommissioning systems, optimizing code/queries, restricting non-critical bandwidth) and increasing capacity (hiring, more powerful systems, cloud elasticity/scalability) as ways to restore service availability after exhaustion, directly addressing post-DoS recovery for bandwidth and resource limits, but leaves many DDoS vectors (spoofing, botnets, external flooding beyond internal tuning) unaddressed.
- T1498.001detects — A.8.6 explicitly requires detective controls and system monitoring/tuning to indicate capacity/availability problems in due time, which surfaces symptoms of a direct network flood (saturated resources, degraded performance) but does not specifically target or reliably identify the adversarial flooding technique itself.
- T1498.001prevents — A.8.6's capacity planning, monitoring, stress-testing, tuning, demand-reduction steps (e.g. optimizing code/queries, restricting non-critical bandwidth) and cloud elasticity directly prevent saturation from many classes of direct network flood, but cannot stop an arbitrarily large botnet flood that exceeds all provisioned capacity.
- T1498.002detects — A.8.6 requires detective controls and monitoring of system resources/utilization to indicate problems in due time, which can surface anomalous traffic or capacity exhaustion from a reflection amplification flood, but does not specifically target or guarantee detection of the spoofed-packet or reflector patterns that define the technique.
- T1498.002prevents — A.8.6's capacity planning, monitoring, stress-testing, tuning, demand-reduction steps (e.g. optimizing code/queries, restricting non-critical bandwidth) and cloud elasticity directly address the availability impact of a reflection-amplification flood, but do not stop the adversary from sending spoofed packets to reflectors or prevent the attack from being launched.
- T1498.002recovers — A.8.6 explicitly addresses restoring availability after overload via capacity increase (cloud elasticity, more resources) or demand reduction (decommissioning, optimization), which recovers from realized DoS impact on the target; partial because it is general resource planning rather than incident-specific restoration of the exact degraded state.
- T1499detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, resource utilization monitoring by managers, and stress-testing to surface capacity problems in due time, which would detect many but not all endpoint DoS techniques (e.g., those using botnets, spoofing, or non-resource-exhaustion crashes outside monitored facilities).
- T1499prevents — A.8.6's identification of capacity requirements, monitoring, tuning, stress-testing, projections, and explicit demand-reduction steps (e.g. optimizing code/queries, deleting obsolete data, restricting non-critical bandwidth) directly block many resource-exhaustion paths that T1499 relies on to degrade availability; it does not address crash-condition exploits, botnet-scale distributed attacks, or spoofing that can still overwhelm even well-planned capacity.
- T1499recovers — A.8.6 explicitly lists increasing capacity (hiring, more powerful systems, cloud elasticity/scalability) and reducing demand (deleting obsolete data, decommissioning, optimizing code/queries) as ways to restore service availability after resource exhaustion, but does not address persistent crash conditions, botnet-driven scale, or non-resource DoS vectors.
- T1499.001detects — A.8.6 explicitly requires detective controls and system monitoring/tuning to indicate capacity problems in due time, which surfaces OS-level resource exhaustion from floods, but only as a general capacity signal rather than technique-specific detection of SYN/ACK floods or OS-imposed limits.
- T1499.001prevents — A.8.6's capacity planning, monitoring, tuning, stress-testing, demand-reduction steps (e.g. restricting non-critical bandwidth) and cloud elasticity directly address OS-imposed resource limits and exhaustion from floods like SYN/ACK, but do not stop the adversary from launching the packets or exhaust the OS limits in all cases (especially non-bandwidth vectors or unmonitored systems).
- T1499.002detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests and resource utilization monitoring that can surface impending exhaustion from service floods, but only for resources inside the organization's defined capacity plan and monitoring scope.
- T1499.002prevents — A.8.6 requires identifying capacity needs, monitoring/tuning, stress-testing, projections, and actions (including scaling, optimization, or demand reduction) to ensure facilities can handle peaks and avoid resource exhaustion; this directly stops many volumetric service-flood DoS techniques from succeeding by design, but leaves a bounded remainder for protocol-exploiting or zero-day floods that bypass even well-provisioned capacity.
- T1499.003detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests and resource utilization monitoring that surface impending capacity problems (including exhaustion from application-level load), but does not mandate detection of the adversarial T1499.003 technique itself or of the specific resource-intensive features being targeted.
- T1499.003prevents — A.8.6's identification of capacity requirements, stress-testing, monitoring, tuning, projections, and demand-reduction steps (e.g. optimizing code/queries, restricting non-critical bandwidth) directly constrain the ability of repeated requests to exhaust resources and cause DoS, but only for a slice of the technique (managed systems under the plan) rather than a bounded remainder, as the control is governance-oriented and does not mandate universal mechanisms against all application features or unmanaged environments.
- T1499.004detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests and resource utilization monitoring that can surface impending or realized capacity exhaustion from repeated exploitation crashes, but does not address detection of the vulnerability exploitation or crash itself.
- T1529detects — A.8.6 requires detective controls and monitoring of system resources/utilization (including stress-tests and projections) that can surface anomalous shutdown/reboot activity as a capacity or availability anomaly, but this is scoped only to resource/capacity indicators rather than the full technique surface (e.g. API calls, privilege use, or post-wipe intent).
- T1529recovers — A.8.6's capacity planning, monitoring, stress-testing, demand-reduction steps and explicit cloud-elasticity guidance enable restoration of service availability after a shutdown/reboot has occurred; the control does not address non-reboot availability impacts such as permanent destruction or unbootable states.
- T1531detects — A.8.6 explicitly requires detective controls and monitoring of key system resources (including utilization trends and projections) that can surface anomalous account manipulations or capacity/availability drops, but this is a minority slice of the broad technique that also includes direct credential changes, SaaS permission revocation, and Group Policy disables outside routine capacity monitoring scope.
- T1535detects — A.8.6 requires detective controls, system monitoring, and resource-utilization oversight that can surface anomalous cloud-instance creation or unexpected consumption in unused regions, but the clause's focus is capacity/availability rather than security-event detection and does not mandate coverage of all regions or cloud-specific anomaly rules.
- T1537detects — A.8.6 requires detective controls and monitoring of key system resources (including utilization trends and projections) that can surface anomalous large internal transfers or backups to another cloud account as capacity or availability anomalies, but the clause is scoped to capacity management rather than security monitoring and does not address cloud-native sharing mechanisms or internal API blends.
- T1542.005detects — A.8.6 requires detective controls and monitoring of key system resources/utilization (including projections and stress-tests) that can surface anomalous boot behavior or unexpected TFTP activity on network devices, but this is a minority slice of the technique's core (config manipulation + unauthorized image load at boot) rather than broad coverage.
- T1546detects — A.8.6's detective controls, system tuning/monitoring, stress-tests and resource-utilization monitoring can surface anomalous capacity consumption or unexpected triggers that are side-effects of T1546 persistence, but the clause's purpose and mechanisms target availability and performance rather than specifically detecting event-triggered execution abuse.
- T1546.003detects — A.8.6 requires detective controls and monitoring of key system resources (including system tuning, stress tests, and utilization tracking) that can surface anomalous WMI activity or resource consumption tied to event subscriptions, but this is a minority slice of the technique rather than its dominant persistence or privilege-escalation aspects.
- T1546.015detects — A.8.6 requires detective controls and system monitoring/tuning to surface problems with capacity and resource utilization in a timely manner; this can surface anomalous registry changes, unexpected COM object behavior or resource-consumption spikes tied to hijacking, but only as a minority slice of the technique's stealthy persistence footprint.
- T1547.012detects — A.8.6's detective controls and system monitoring can surface anomalous resource consumption or spoolsv.exe behavior tied to the malicious print processor, but the clause is scoped to capacity/availability rather than security events and does not require detection of the specific persistence technique.
- T1548.005detects — A.8.6 requires detective controls and monitoring of key system resources/utilization to indicate problems in due time; this surfaces anomalous temporary elevation or related capacity spikes from abuse, but the control's focus is general capacity (not privilege-escalation specifics) and leaves many stealthy impersonation cases outside monitored resources.
- T1552.007detects — A.8.6 requires detective controls and monitoring of system resources (including tuning, stress tests, and utilization of key resources) that can surface anomalous API access or capacity spikes tied to credential-gathering in container environments, but this is indirect, not specific to the technique, and limited to monitored mission-critical systems.
- T1561detects — A.8.6 explicitly requires detective controls and system tuning/monitoring to indicate problems in due time, plus manager monitoring of key resource utilization; this surfaces disk-wipe anomalies that affect capacity/availability but does not target the wipe action itself and leaves many execution vectors (e.g. direct raw writes, non-monitored devices) unreached.
- T1561recovers — A.8.6 explicitly lists deletion of obsolete data, decommissioning of systems/databases, and optimizing to free resources as ways to reduce demand and restore capacity after loss, directly enabling recovery from disk-wipe availability interruption.
- T1561.001detects — A.8.6 requires detective controls and monitoring of key system resources (including utilization trends and stress-testing) that can surface anomalous disk-wipe activity as a capacity or availability anomaly; this is a genuine but minority slice of the technique because the clause's focus is normal capacity management rather than security-event detection of destructive overwrites.
- T1561.001recovers — A.8.6 explicitly lists deletion of obsolete data, decommissioning of systems, and especially backups via cloud elasticity/scalability or a documented capacity plan to restore availability after destructive loss of storage capacity.
- T1561.002detects — A.8.6 requires detective controls and monitoring of key system resources (including utilization trends and stress-testing) that can surface anomalous disk activity or sudden capacity drops indicative of a disk-structure wipe, but this is indirect, not specific to the technique, and leaves large residual scope (e.g., offline attacks, non-monitored systems, or rapid propagation).
- T1561.002recovers — A.8.6 explicitly lists deletion of obsolete data, decommissioning of systems/databases, and optimizing storage as ways to reduce demand and free capacity, which can restore availability after a disk-structure wipe has rendered systems unbootable; this is genuine but only a slice of the full technique (e.g., does not address worm-like propagation or network-device reformatting).
- T1563.002detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests and resource-utilization monitoring that can surface anomalous RDP-session activity or the underlying capacity/privilege anomalies it produces, but the clause's focus is capacity planning rather than security-event detection so only a minority slice of the technique is reached.
- T1565.001detects — A.8.6 explicitly requires detective controls and system monitoring/tuning to indicate problems in due time, which surfaces anomalies from stored data manipulation on monitored resources, but only for capacity/availability impacts rather than integrity violations or the full range of manipulation techniques.
- T1567detects — A.8.6 requires detective controls, system tuning/monitoring, stress-tests and resource utilization monitoring that can surface anomalous consumption or data movement patterns consistent with exfiltration, but the clause is scoped to capacity/availability rather than security events and does not address the web-service cover, encryption or legitimate traffic blend described in T1567.
- T1567.002detects — A.8.6 requires detective controls, system tuning/monitoring, stress-tests and resource-utilization monitoring that can surface anomalous capacity consumption or data movement to cloud storage, but the clause's focus is legitimate business capacity rather than specifically adversary exfiltration behavior.
- T1567.004detects — A.8.6's detective controls, system tuning/monitoring, stress-tests, and resource-utilization monitoring can surface anomalous capacity consumption or outbound webhook traffic that blends with normal SaaS flows, but this is a minority slice of the technique (which is designed to evade detection via HTTPS and common services) rather than the bulk with a bounded remainder.
- T1578detects — A.8.6 requires detective controls, system tuning/monitoring, stress-tests and resource utilization monitoring that can surface anomalous modifications to cloud compute capacity (e.g. unexpected instance creation/deletion), but the clause is scoped to capacity/availability rather than security events or evasion and does not address evidence removal.
- T1578.002detects — A.8.6 requires detective controls, system monitoring, and resource-utilization tracking that can surface anomalous cloud-instance creation as a capacity or utilization anomaly, but the control's focus is on planned business capacity rather than security-specific detection of evasion-driven instance creation.
- T1578.003detects — A.8.6 requires detective controls, system tuning/monitoring, stress-tests and resource utilization monitoring that can surface anomalous capacity drops or instance deletions in IaaS environments, but the clause is scoped to capacity planning rather than security event detection and does not mandate coverage of all deletion events.
- T1578.003recovers — A.8.6 explicitly lists decommissioning of systems/environments and deletion of obsolete data as demand-reduction measures that can restore usable capacity after an instance is gone, and its backup-like elasticity guidance (cloud scaling, stress-testing, projections) can recover service availability post-deletion; this is only a slice of the forensic-evidence loss named in the technique.
- T1578.004detects — A.8.6 requires detective controls and monitoring of key system resources (including cloud capacity/utilization trends) that can surface anomalous snapshot restores or ephemeral storage resets as deviations from expected patterns, but this is scoped only to capacity management rather than general threat detection.
- T1578.005detects — A.8.6 requires detective controls, system tuning/monitoring, stress-tests and resource-utilization monitoring that can surface anomalous capacity changes or quota/policy modifications in cloud environments, but the clause is scoped to business-driven capacity planning rather than security-specific detection of adversarial compute-configuration abuse.
- T1599.001detects — A.8.6 requires detective controls and monitoring of key system resources (including network devices) to indicate problems in due time and avoid potential limitations, which surfaces anomalous NAT modifications on monitored boundary devices; partial because the control's scope is set by business criticality and capacity projections rather than mandating detection of all adversarial NAT traversal.
- T1602.001detects — A.8.6 requires detective controls and monitoring of key system resources (including utilization trends and projections) that can surface anomalous SNMP queries or MIB access patterns on managed devices; this is a genuine but minority slice of the technique, as the control's focus is capacity rather than comprehensive network telemetry or SNMP-specific detection.
- T1648detects — A.8.6 explicitly requires detective controls, system tuning/monitoring, stress-tests, and resource utilization monitoring that can surface anomalous consumption or creation patterns typical of serverless abuse (e.g. crypto-mining or unexpected function invocation), but the clause is scoped to capacity and availability rather than security events and does not address creation of functions, privilege modifications, or event-triggered persistence.
- T1666detects — A.8.6 requires detective controls and monitoring of key system resources (including cloud capacity/utilization trends) that can surface anomalous hierarchy changes as unexpected capacity or resource events, but this is indirect, not scoped to hierarchy modifications or evasion, and leaves most of the technique unseen.
- T1667detects — A.8.6 requires detective controls and monitoring of system resources (including email-related capacity) to indicate problems like overload in due time, which surfaces email bombing's flooding effect on inboxes and services, but only as a capacity/utilization anomaly rather than the adversarial technique itself or its precursor intent.
- T1685.004detects — A.8.6 requires detective controls and monitoring of system resources/utilization (including stress-tests and projections) that can surface anomalies in auditd service state, configuration changes, or resource impacts from disabling it, but this is a minority slice of the technique's methods (e.g., in-memory hooking or rule edits) rather than a bounded remainder, and the control's focus is capacity not security-event detection.
- T1686detects — A.8.6's explicit requirement for system tuning, monitoring, detective controls to indicate problems in due time, and manager monitoring of key resource utilization will surface anomalous firewall changes or capacity-impacting modifications on covered systems, but only as a minority slice of the technique (no dedicated coverage of firewall policy events, and many platforms/behaviors remain outside capacity-focused monitoring).
- T1686.001detects — A.8.6's detective controls, system monitoring, and manager oversight of key resource utilization can surface anomalous capacity changes or firewall-rule modifications that affect availability/efficiency, but this is incidental to its capacity-planning purpose and does not systematically target the T1686.001 technique itself.
- T1686.003detects — A.8.6 explicitly requires detective controls and system monitoring/tuning to indicate problems in due time, which surfaces anomalous capacity or configuration changes (including firewall modifications that affect network availability or resource usage), but does not target or comprehensively cover the specific T1686.003 mechanisms or indicators.
Prevented OWASP Web Top 10 (2025) risks (1)
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).
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.