Cyber Resilience

← ISO 27001 Annex A

A.8.32 Technological

Change management

AttributesPreventive C·I·A Protect Application security System and network security Protection

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 (21)

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).

CM-2←P CM-3←M →F CM-4←M →M CM-5←M CM-9←M →P SA-10←M →M CM-1gov SA-3gov

Why these map — AI rationale (under review)

CM-3fullcovers — ISO A.8.32 establishes the overarching change-management program that directly satisfies the full intent of CM-3 by requiring documented procedures, impact assessment, authorization, testing, implementation, and record-keeping for all system changes.
CM-1mostlyaligns with — By requiring documented and enforced change-control procedures, A.8.32 fulfills the policy-and-procedures foundation that CM-1 expects for configuration-change management.
CM-4mostlyaligns with — The ISO control mandates impact assessment of changes and consideration of dependencies, which aligns with CM-4’s requirement to analyze potential security and operational impacts before changes are approved.
CM-4mostlycovers — A.8.32's change-management process (including assessment of security-relevant effects) accounts for the bulk of CM-4's pre-change impact-analysis requirement; residual exists because A.8.32 does not explicitly mandate privacy-impact analysis or the same depth of formal documentation that CM-4 requires.
SA-10mostlycovers — A.8.32's change-management process and security-preserving requirements account for the bulk of SA-10's developer configuration management and approved-change controls, but a real residual remains on the developer-specific assignment, configuration-item identification, and integrity-documentation details that sit outside a generic organizational change-management control.
CM-9partialaligns with — The ISO control’s emphasis on integrated change procedures and record maintenance supports the configuration-management-plan elements addressed by CM-9.
SA-10partialaligns with — A.8.32’s lifecycle-wide change-control requirements extend to developer and maintenance activities, thereby partially satisfying SA-10’s developer configuration-management obligations.
CM-9covers — A.8.32's narrow focus on preserving security during change execution addresses only a slice of CM-9's broader requirements for a full configuration management plan spanning roles, lifecycle identification, item definition, and implementation.

Aligned NIST CSF 2.0 outcomes (16)

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).

PR.PS-01←M →M GV.PO-02gov ID.AM-08gov ID.RA-07gov PR.IR-03gov PR.PS-02gov

Why these map — AI rationale (under review)

ID.AM-08mostlyaligns with — Mandating controlled change processes across the entire system development life cycle supports the outcome of managing hardware, software, services, and data throughout their life cycles.
ID.RA-07mostlyaligns with — Requiring impact assessment and documentation of every change ensures that modifications and exceptions are evaluated for risk and tracked throughout the system life cycle.
PR.PS-01mostlycovers — The ISO control's formal change-control procedures, impact assessment, authorization, testing, and documentation directly implement the configuration-management practices required by PR.PS-01.
GV.PO-02partialaligns with — Documenting, enforcing, and updating change-control procedures ensures policies remain current and are communicated to reflect evolving requirements.
PR.IR-03partialaligns with — Including fall-back procedures and contingency planning within change control helps maintain resilience requirements during both normal and adverse situations.
GV.PO-02implements — 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.AM-08implements — A.8.32 operationalizes change management as the mechanism that keeps security properties intact across the full asset life cycle that ID.AM-08 requires; the link is within the shared domain of life-cycle security but is not an explicit citation of change management by the CSF outcome.
ID.RA-07implements — A.8.32 directly operationalizes the change-management process that ID.RA-07 requires for risk-impact assessment and tracking; the link is within the shared risk-management domain but the CSF outcome does not name the specific change-control mechanism.
PR.IR-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.

Related OWASP ASVS 5.0 requirements (9)

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).

V13.1.1→P V13.2.6→P V15.1.1→M V15.1.2←P V15.2.1←P →M V15.2.4←P V2.1.1→P V2.1.3→P

Why these map — AI rationale (under review)

V15.1.1mostlyaligns with — The ISO requirement for documented change control procedures that include impact assessment, authorization, testing, and acceptance directly supports the ASVS mandate to define risk-based remediation time frames for vulnerable third-party components.
V15.2.1mostlyaligns with — Formal change management that enforces testing, acceptance, and documentation ensures that only components meeting documented update and remediation time frames are present in production.
V13.1.1partialaligns with — Requiring documented change procedures that cover the full system development life cycle aligns with the need to document all external communication dependencies and service connections.
V13.2.6partialaligns with — The ISO emphasis on maintaining operating documentation and continuity plans after changes supports the ASVS requirement that connections to external services follow documented configuration limits.
V2.1.1partialaligns with — Change control that mandates specification, testing, and acceptance of changes aligns with documenting input validation rules to ensure they remain consistent with expected data schemas.
V2.1.3partialaligns with — Requiring impact assessment and authorization of changes before implementation aligns with documenting business logic limits and validations that must stay consistent across the application.

Related weaknesses / CWE (88)

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-1250nonemitigates — Change management can coordinate updates across replicas but does not inherently enforce real-time consistency.
CWE-1328nonemitigates — Change-management processes can require cryptographic verification of firmware versions before deployment.
CWE-250nonemitigates — Requiring impact assessment and authorization for every change discourages the introduction of processes or services that run with privileges beyond what the function actually needs.
CWE-269nonemitigates — Formal change procedures that include privilege-impact analysis and approval prevent the accidental or unauthorized assignment of elevated rights during system updates or new deployments.
CWE-279nonedetects — Change-management procedures can catch permission-setting mistakes before they reach production.
CWE-364nonemitigates — Change management may catch unsafe signal code during reviews but does not address the weakness itself.
CWE-471nonemitigates — Change-management procedures ensure that any modification to data presumed immutable is reviewed and authorized.
CWE-556nonemitigates — Change management processes can review configuration changes that introduce impersonation settings.
CWE-664nonemitigates — Change management governs resource modifications but does not cover creation or release.
CWE-772nonedetects — Change-management processes may catch missing de-allocation during reviews, but the control itself does not target resource lifetime.
CWE-841nonemitigates — Change management can require workflow adherence for changes but is not the primary mitigation.
CWE-96nonemitigates — Change management can catch unsafe code changes but does not enforce input neutralization.
CWE-1038finds — Change-management processes should evaluate the security impact of enabling or altering automated optimization features.
CWE-1059prevents — Change-management procedures rely on up-to-date technical documentation to assess impact.
CWE-1068prevents — Change management can catch drift after the fact, but does not guarantee initial implementation matches design.
CWE-1076prevents — Change management can require convention checks but does not inherently enforce them.
CWE-1078prevents — Change management can enforce code review and formatting checks, yet the control's primary focus is broader change governance.
CWE-1112prevents — Change management requires documenting changes to execution mechanisms, but does not ensure initial completeness.
CWE-114prevents — Change management can gate risky deployments but does not inherently block untrusted process control.
CWE-1164prevents — Change-management processes can catch irrelevant code during reviews but are not focused on it.
CWE-1174finds — Change management processes can enforce validation checks during code reviews and releases.
CWE-1188prevents — Requiring documented specification, testing, and acceptance of changes ensures that new or modified components are not initialized with insecure default settings that would otherwise be left in production.
CWE-123prevents — Change management processes help ensure security fixes for such weaknesses are properly deployed.
CWE-1242prevents — Change management processes require documented approvals, reducing the chance of hidden features being introduced.
CWE-1251prevents — Change-management processes can catch configuration drift that leads to unsynchronized mirrors, but the control is broader.
CWE-1269prevents — Change-management procedures ensure only approved, release-ready configurations are deployed.
CWE-1282mitigates — Change management can restrict field updates to immutable data but does not enforce the underlying storage design.
CWE-1304prevents — Change management processes can detect and prevent unauthorized or corrupted configuration changes during power save/restore.
CWE-1321prevents — Change-management processes ensure security fixes for prototype-pollution issues are tracked and deployed.
CWE-1329mitigates — Change-management processes can plan for component replacement, yet cannot eliminate the inherent non-updateability of an already-deployed component.
CWE-1394prevents — Change-management processes should detect and remediate default cryptographic keys.
CWE-15prevents — Change management enforces controlled, authorized modifications to settings.
CWE-284prevents — Requiring formal authorization, impact assessment, and documented approval for every change stops developers or operators from unilaterally introducing code or configuration that bypasses intended access-control boundaries.
CWE-285prevents — Mandatory review and acceptance testing of changes before deployment reduces the chance that an authorization decision will be implemented incorrectly or will grant unintended rights.
CWE-324mitigates — Change-management processes can trigger key rotation, but do not inherently enforce cryptographic expiry rules.
CWE-372prevents — Change-management procedures may indirectly catch state-related defects during release reviews.
CWE-416prevents — Change-management processes help ensure memory-safety fixes are deployed consistently.
CWE-430prevents — Change management verifies that handler mappings remain correct after updates.
CWE-435prevents — Change management can require impact analysis of component interactions before deployment.
CWE-440finds — Change management can catch specification deviations introduced by modifications.
CWE-449prevents — Change management can catch UI defects before release but does not itself define correct action semantics.
CWE-455prevents — Change management may catch initialization configuration issues during deployment reviews.
CWE-459finds — Change-management processes may require cleanup verification, but the control itself does not address the weakness.
CWE-477prevents — Change management can trigger reviews that remove obsolete functions but does not directly address them.
CWE-480prevents — Change management processes may include code review gates that incidentally catch operator mistakes.
CWE-489prevents — Change management can enforce removal of debug code as part of release gates.
CWE-507prevents — Change management reduces the risk of unauthorized Trojan Horse code being introduced during updates.
CWE-508prevents — Change-management processes can prevent unauthorized introduction of malicious code.
CWE-509prevents — Change management reduces risk of malicious code being introduced during updates.
CWE-511prevents — Change management reviews reduce the chance of unauthorized malicious code insertion.
CWE-553prevents — Change management can catch the addition of such files if reviewed, but is not a direct mitigation.
CWE-561finds — Change-management processes may catch dead code during reviews but are not designed to address it.
CWE-573prevents — Change management can catch specification drift during updates but is not a primary mitigation.
CWE-648prevents — Change management can catch misuse of privileged APIs during reviews but does not inherently prevent the weakness.
CWE-667prevents — Change management may catch locking issues introduced by modifications but does not prevent the weakness itself.
CWE-670prevents — Change-management gates may prevent deployment of flawed logic but do not address the coding defect itself.
CWE-672prevents — Change-management processes can introduce or remove resource-lifetime controls.
CWE-684prevents — Change management processes reduce the chance of unintended functional deviations during updates, though they do not directly address initial specification conformance.
CWE-689prevents — Ensures changes to access controls are managed, preventing interim exposure during copy.
CWE-691prevents — Change management reduces introduction of control-flow defects through controlled updates but does not address the weakness directly.
CWE-710prevents — Change management can enforce review against standards.
CWE-732prevents — Change-control procedures that explicitly update operating documentation and user procedures ensure that newly introduced files, services, or resources receive correct permission assignments rather than inheriting insecure defaults.
CWE-787prevents — Change management can enforce review gates that catch unsafe memory operations before deployment.
CWE-825prevents — Change-management processes can require re-validation of memory safety after modifications, indirectly reducing the weakness.
CWE-911prevents — Change-management processes may catch reference-count issues introduced by modifications, but do not address the root coding flaw.
CWE-912prevents — Change management processes can catch unauthorized additions but do not inherently prevent hidden functionality from being introduced.

Mitigated MITRE ATT&CK techniques (670)

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.003←M T1006←M T1014←M T1021.006→P T1027.001←M T1027.002←M T1027.003←M T1027.004←M T1027.005←M T1027.006←M T1027.007←M T1027.008←M T1027.009←M T1027.010←M T1027.011←M T1027.013←M T1027.014←M T1027.016←M T1027.017←M T1027.018←M T1036←M T1036.003←M T1036.005←M T1036.006←M T1036.007←M T1036.008←M T1036.009←M T1036.011←M T1036.012←M T1037←P →P T1037.001→P T1037.002→P T1037.003→P T1037.004←P →P T1047→P T1053←P →P T1053.002←M T1053.005←M →P T1053.006←P →P T1053.007←M →P 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 T1056.003→P T1059→P T1059.008←P →P T1068←M T1070←M T1070.003←M T1070.004←M T1070.006←M T1070.007←M T1070.008←P T1070.010←M T1071←M T1071.001←M T1071.004←M T1072←M →P T1074.001→P T1078.001←M →P T1078.004←M T1080←P →P T1090.001←M T1090.002←M T1090.003←M T1095←M T1098←M →P T1098.001→P T1098.002←P →P T1098.003→P T1098.004←M →P T1098.005←M →P T1098.006→P T1098.007←M T1102←M T1102.001←M T1102.002←M T1104←M T1110.001→M T1111←M T1112←M T1114.003←P T1127←M →P T1127.001←M T1127.002←M T1127.003←M T1132.002←M T1133←M T1134←M T1134.001←M T1134.002←M T1134.003←M T1134.004←M T1134.005←M T1136←P →P T1136.001←P →P T1136.002→P T1136.003←P T1137→P T1137.001←P →P T1137.002→P T1137.003→P T1137.004←P →P T1137.006←P →P T1176←M →P T1176.001←M T1176.002←M →P T1185←M T1189←M T1190←M →P T1195←M →P T1195.001←P →P T1195.002←M →P T1197→P T1202←M T1203→P T1204.003←M T1204.004←M T1204.005←M T1205←M T1210→P T1211←M →P T1212→P T1216←M T1216.001←M T1216.002←M →P T1218←M T1218.001←P T1218.002←M T1218.003←M →P T1218.004←M T1218.005←M →P T1218.007←M →P T1218.008←M →P T1218.009←M →P T1218.010←M T1218.011←M T1218.012←M T1218.013←M T1219.001→P T1219.002←M T1219.003←M T1220←M T1221←M T1222←M T1222.001←M T1222.002←M T1480.001←M T1484→P T1484.001←M →P T1484.002→P T1485→P T1486→M T1489←M T1490→M T1491→P T1491.001→P T1495←P →P T1496.001←P →P T1496.002→P T1496.004←P T1497←P T1498←P →P T1498.001←P T1499←M →P T1499.004←P →P T1505←M →P T1505.001←P →P T1505.002←P →P T1505.003→P T1505.004←M →P T1505.005←P T1505.006←M →P T1525←M →P T1529←P →P T1531←P T1535←M T1537←M T1539←F T1542←M T1542.001←M T1542.002←M →P T1542.003←M →P T1542.004←M →P T1542.005←M →P T1543←M →P T1543.001←M →P T1543.002←M →P T1543.003→M T1543.004←M →P T1543.005←M →P T1546←P →P T1546.001←P →P T1546.003→P T1546.004←M →P T1546.007→P T1546.008←P →P T1546.011←P →P T1546.012←M T1546.013→P T1546.015→P T1546.016←P →P T1546.017←M →P T1546.018→P T1547←P →P T1547.001←M →P T1547.002←P T1547.003→P T1547.004←P →P T1547.005←M →P T1547.006←M →P T1547.007→P T1547.008←M T1547.009←P →P T1547.010←P T1547.012←P →P T1547.013←P →P T1547.014→P T1548←M →P T1548.001←P T1548.002←M T1548.003←M →P T1548.004←M T1548.005←M →P T1548.006←M T1550←M T1550.001←F T1550.002←M T1550.003←F T1550.004←F T1552.001→P T1553←M T1553.001←M T1553.002←P T1553.003←M T1553.004←M T1553.005←M T1553.006←M T1554→P T1556←M →P T1556.001←M →P T1556.003→P T1556.005←P →P T1556.006←M T1556.007→P T1556.008←M T1556.009←M T1559.003→P T1561←M →M T1561.001←P →M T1561.002→P T1565→P T1565.001→P T1565.002→P T1565.003→P T1566.002←M T1566.003←M T1568←M T1568.002←M T1568.003←M T1569→P T1569.002→P T1569.003→P T1571←M →P T1572←M T1574←M →P T1574.001←M →P T1574.004←M T1574.005←M →P T1574.006←M T1574.007←P →P T1574.008←M →P T1574.009←M →P T1574.010←P →P T1574.011←M →P T1574.012←P T1574.013←M T1574.014←P T1578→P T1578.001←M T1578.003→P T1578.004←M →P T1578.005→P T1584←P T1584.001←P T1599←M T1599.001←M T1600←M T1600.002←P T1601→P T1601.001←M →P T1601.002→P T1606←M T1606.001←M T1606.002←M T1608.003←P T1609→P T1610←P →P T1611←M →P T1612←M →P T1620←M T1621←M T1622←F T1647←M T1649→P T1651←P T1653←P T1665←P T1666→P T1668←P T1671←P T1677→P T1678←M T1684.002←M T1685←M T1685.001←M →P T1685.002←M →P T1685.003←M T1685.004←M T1685.005←M →P T1685.006←M T1686←M →P T1686.001←M →P T1686.002←M T1686.003←M T1687←M T1688←M T1689←M →P T1690←M

Why these map — AI rationale (under review)

T1021.006detects — A.8.32's documented change procedures, impact assessment, testing, records, and integration with continuity/response plans can surface anomalous or unauthorized WinRM-related changes (e.g. new service configs, remote access rules, or script deployments) during the managed process, but this is limited to change events and does not broadly instrument runtime WinRM usage.
T1037prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch and block many malicious or insecure modifications to boot/logon initialization scripts, but does not reach all cases (e.g., already-compromised admin accounts, emergency changes, or un-reviewed local/remote script alterations on diverse platforms).
T1037.001detects — A.8.32's formal change-management process (including impact assessment, authorization, testing, documentation and records of all changes) would surface an anomalous addition or modification of a UserInitMprLogonScript registry value or script when performed through approved channels, but the technique can be realized by direct registry writes outside any managed change process, leaving a genuine slice undetected.
T1037.001prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized addition of a malicious logon-script Registry value during approved changes; this is a genuine but minority slice of the technique, which can also be introduced outside any managed change (e.g., direct admin/registry abuse post-compromise).
T1037.002prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) over modifications to system files like the loginwindow.plist; this stops many unauthorized or untested malicious insertions but leaves a remainder for changes performed through approved processes, emergency paths, or on deprecated/out-of-scope legacy systems.
T1037.003detects — A.8.32 mandates documented change control that includes planning/assessing impact, authorization, testing, records, and updates to operating/continuity documentation; this surfaces unauthorized or anomalous logon-script modifications (the persistence vector) when they occur through the managed process, but only for changes that route through formal change management rather than direct registry/Group Policy edits outside it.
T1037.003prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) across the SDLC would catch and block many malicious or unauthorized modifications to network logon scripts/GPOs, but leaves open slices such as initial legitimate deployment of a malicious script, emergency changes, or post-deployment abuse that do not route through the change process.
T1037.004detects — A.8.32's documented change control (planning/assessing impact, authorization, testing, records, and maintaining continuity/response docs) surfaces unauthorized or anomalous modifications to RC scripts as part of the formal process, but only for changes that go through the managed procedure on covered systems; it does not instrument runtime detection of stealthy or out-of-band abuse on deprecated/legacy paths or unmonitored lightweight distributions.
T1037.004prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that would catch or block unauthorized modification of RC scripts when followed; it does not reach ad-hoc, emergency, or out-of-process changes on lightweight/deprecated systems where the technique is noted to be especially effective.
T1047detects — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and maintaining records) can surface anomalous or unauthorized use of WMI during approved changes, but does not mandate runtime monitoring of WMI abuse outside the change window and leaves most adversary-in-the-wild executions undetected.
T1053prevents — A.8.32 mandates formal change-control procedures (planning/assessment of impact, authorization, testing, documentation, emergency fall-backs) that reach the introduction or modification of scheduled-task mechanisms, thereby stopping many legitimate-but-abusable changes that would enable T1053; it does not stop an already-privileged adversary from directly invoking the OS scheduler outside any approved change process.
T1053.005prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that can block unauthorized or insecure creation/modification of scheduled tasks when those tasks are introduced as part of a managed change; this reaches only a minority slice of T1053.005 because the technique is most often used post-compromise by an already-authenticated adversary outside any formal change window.
T1053.006prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) over the SDLC including maintenance; this constrains how systemd timer unit files and services can be introduced or altered as changes, but does not stop an adversary who already has write privileges from creating them outside approved processes.
T1053.007prevents — A.8.32 mandates formal change-control procedures (planning/assessing impact, authorization, testing, documentation, emergency fallbacks) across the SDLC that would catch and block unauthorized or malicious CronJob/container-orchestration changes before they reach production, but the control is silent on runtime enforcement inside an already-live cluster and does not reach every possible abuse vector an adversary could introduce post-approval.
T1056.003prevents — A.8.32's formal change process (planning, authorization, testing, documentation) can block unauthorized or untested modifications that would install the capture code on the portal, but does not stop all vectors such as initial exploitation or post-compromise use of already-legitimate admin access.
T1059prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that can constrain which interpreters are present or how they may be invoked, directly preventing some abuse vectors; this is only a slice because built-in interpreters required by the platform cannot be removed and many post-compromise execution paths remain reachable.
T1059.008prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that can block unauthorized or unvetted CLI commands/config changes on network devices before they are applied, but this is only a slice of the technique (adversary abuse of legitimate CLI access post-compromise or via stolen creds) rather than the bulk, with a nameable remainder in runtime execution and non-change vectors.
T1072prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that can block unauthorized or unvetted modifications to deployment tools, thereby stopping many abuse paths; it does not reach credential theft, direct exploitation, or already-compromised admin access to those tools.
T1074.001detects — A.8.32's mandated records, tests, impact assessments and change-authorization process can surface anomalous staging activity when it occurs inside a managed change window, but the control is silent on runtime monitoring of ad-hoc file/registry copies outside formal changes.
T1078.001prevents — A.8.32's formal change-management process (planning impact, authorization, testing, documentation, and updating related procedures across the SDLC) catches many post-installation or integration-created default accounts and forces their handling (e.g., renaming, disabling, or credential rotation), but leaves the initial factory-built defaults, pre-change-management appliances, and unchanged legacy systems outside its reach.
T1080prevents — A.8.32's formal change-control process (planning impact, authorization, testing, documentation, and integration across the SDLC) can catch and block malicious tainting of shared content or binaries during authorized updates to repositories or network shares, but leaves the dominant unauthorized/adversary-driven infection vectors (e.g., direct writes, directory-share pivots) untouched.
T1098detects — A.8.32 mandates documented change control that includes planning/assessing impact, authorization, testing, records, and communicating changes; this surfaces anomalous or unauthorized account modifications as part of the formal process, but only for changes that route through the managed SDLC/change pipeline (many T1098 actions such as direct credential or permission tweaks on live systems, iterative password updates, or in IaaS/identity-provider environments bypass it).
T1098prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) constrains unauthorized or un-reviewed account manipulations that subvert policy or alter permissions/credentials, but only for changes that route through the controlled process; stealthy post-compromise manipulations by an already-privileged adversary fall outside that boundary.
T1098.001prevents — A.8.32 mandates formal change processes (planning/assessment of impact, authorization, testing, documentation) that can block unauthorized credential-addition changes when they are routed through approved channels; however, the technique is most often performed via direct privileged API/CLI use after initial compromise rather than through managed change workflows, leaving a large slice of executions untouched.
T1098.002prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized permission grants if performed as a managed change, but the technique is most often executed post-compromise via direct admin/PowerShell actions outside any formal change window, leaving the bulk of real-world abuse untouched.
T1098.003detects — A.8.32 mandates documented change control procedures that include planning/assessing impact, authorization, communication, testing, implementation, records, and updates to documentation/plans; this surfaces unauthorized or anomalous role/permission changes (especially via enforced authorization, records, and impact assessment) but only for changes that fall inside the formal process and does not guarantee detection of stealthy or external-tenant modifications.
T1098.003prevents — A.8.32 mandates formal change-management processes (planning/assessment of impact, authorization, testing, documentation) that can catch and block unauthorized role/permission additions when performed through managed channels; however, the technique can still succeed via direct API abuse by already-privileged compromised accounts, emergency paths, or external tenant roles outside the change-control boundary.
T1098.004prevents — A.8.32 mandates formal change-control procedures (planning/assessment, authorization, testing, documentation) that reach the modification of SSH authorized_keys and sshd_config files; this constrains the technique on systems under the process but leaves a bounded remainder (emergency changes, unmanaged cloud API/metadata paths, network devices, and post-deployment maintenance outside the SDLC) unreached.
T1098.005prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) would catch and block many unauthorized device-registration actions when performed as a managed change to MFA or Intune configuration, but the technique is most often executed post-compromise via self-service enrollment paths that bypass the formal ICT change process entirely.
T1098.006detects — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and records of all changes) surfaces unauthorized role/permission additions in container clusters when they occur through the managed process, but does not instrument or guarantee detection of out-of-band or stealthy modifications that bypass the change-control workflow.
T1098.006prevents — A.8.32 mandates formal change-control procedures (planning/assessing impact, authorization, testing, documentation) across the SDLC that would catch or block unauthorized role-binding or ABAC-policy changes if the process is followed; however, the control is a governance process rather than an enforcement mechanism, so it only constrains the slice of T1098.006 performed through managed changes and leaves adversary-in-the-middle or out-of-band modifications as a large remainder.
T1110.001prevents — A.8.32 mandates formal change-control procedures (including impact assessment, testing, authorization, and updates to operating docs, continuity plans, and authentication-related configurations) that, when followed, block the introduction or persistence of weak/default credentials, overly permissive services, or missing lockout policies that enable password guessing; the bounded remainder is guessing against already-deployed strong per-account credentials or external brute-force that survives those controls.
T1127prevents — A.8.32's formal change-management process (planning, assessment, authorization, testing, documentation) across the SDLC would catch and block many developer-utility-based bypasses if applied to the introduction or modification of those signed utilities, but leaves a genuine remainder: legitimate pre-existing utilities, emergency changes, and post-deployment abuse that the control does not reach.
T1136prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized account creation when performed as a system change, but the technique can be executed directly at runtime by an already-privileged adversary outside any managed change window.
T1136.001prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized local account creation when performed as a managed change; this stops the technique for changes that route through the process but leaves the dominant case (adversary executing net user/useradd/esxcli/kubectl outside any change window) untouched.
T1136.002prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) constrains how domain accounts are created as part of managed ICT changes, but does not stop an already-privileged adversary from creating one outside that process.
T1137prevents — A.8.32 mandates formal change-control processes (planning, assessment, authorization, testing, documentation) across the SDLC that would catch and block many Office-application persistence mechanisms (e.g., unsafe add-ins, template macros, or Outlook rules) before they reach production, but the clause is silent on the specific technical enforcement of safe defaults or macro/add-in restrictions, leaving a genuine minority slice of T1137 techniques (especially post-deployment Office 365 abuse) unreached.
T1137.001prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized modification of Office templates or registry keys used for persistence when those changes are performed through managed processes; it does not stop an already-privileged adversary from directly writing to the template files or registry outside the change-management workflow.
T1137.002prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) across the SDLC including maintenance; this would catch and block addition of the malicious Office Test registry key/DLL in managed environments, but the technique can still be introduced outside formal change processes (e.g. direct post-compromise registry edits by an adversary).
T1137.003prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch and block malicious Outlook form additions if applied to mailbox/custom-form configuration; this is a genuine but minority slice of the technique, which also succeeds via initial compromise, registry abuse, or unmanaged clients outside the change-managed perimeter.
T1137.004prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) would catch and block malicious addition of an Outlook Home Page URL during legitimate system or mailbox configuration changes, but the technique can still be introduced post-compromise outside any managed change window, leaving a genuine minority slice prevented.
T1137.006prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized add-in installation for persistence when the change is reviewed; this is a genuine but minority slice of the technique because most add-in abuse occurs via already-compromised user context or Office auto-load paths outside managed change windows.
T1176prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation, and integration across the SDLC) can stop malicious or abused extensions from being introduced or persisting when they qualify as changes to software or ICT infrastructure, but the technique also succeeds via social engineering, marketplace compromise, or manual user install outside any organizational change process.
T1176.002prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that can block unauthorized or unvetted IDE extensions from reaching production systems, but leaves the dominant installation vectors (marketplace trust, side-loading, benign-extension abuse) largely untouched when those processes are not applied to developer workstations or extension ecosystems.
T1190prevents — A.8.32 mandates formal change processes (planning, assessment, testing, authorization, documentation) across the SDLC that can stop misconfigurations or unpatched bugs from reaching production Internet-facing systems, but leaves software bugs, zero-days, and pre-existing weaknesses in deployed code or edge devices untouched.
T1195prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and integration across the SDLC) directly constrains manipulation of development tools/environments, source repositories, open-source dependencies, and update mechanisms, but leaves shipment interdiction, factory-infected images, and second-order compromises largely untouched.
T1195.001prevents — A.8.32 mandates formal change-control processes (planning/assessment of impact, authorization, testing, documentation, and integration across the SDLC) that directly constrain manipulation of dependencies, dev tools, and CI/CD components before they reach consumers, but leaves open slices such as upstream open-source supply-chain attacks, typosquatting, and abandoned-package hijacks that occur outside the organization's own change-management boundary.
T1195.002prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, records, integration across SDLC) catches and blocks many supply-chain manipulations of source, builds, or updates before release, but leaves residual paths such as upstream third-party components or non-integrated distribution mechanisms that the control does not reach.
T1197detects — A.8.32's change control procedures (planning/assessing impact, authorization, testing, documentation, and maintaining records of changes) can surface anomalous or unauthorized BITS job creation/management as part of ICT/software change processes, but this is limited to changes that are routed through formal change management rather than stealthy adversary abuse of the BITS interface.
T1203prevents — A.8.32's formal change-management process (impact assessment, testing, authorization, documentation) across the SDLC can catch and block many insecure-coding changes that would introduce exploitable client-application vulnerabilities, but leaves a bounded remainder: zero-day or externally supplied third-party/client software whose vulnerabilities are unknown at change time.
T1210prevents — A.8.32's formal change process (impact assessment, testing, authorization, patching via documented lifecycle) stops many exploitable vulnerabilities from reaching production or persisting, but leaves residual unpatched legacy services, emergency changes, and zero-days that still enable T1210
T1211prevents — A.8.32 mandates formal change processes (planning, assessment, testing, authorization, documentation) across the SDLC that reduce the chance of introducing exploitable flaws used for stealth/evasion; this prevents a slice of the technique but leaves residual unpatched or undiscovered vulnerabilities and does not reach all stealth vectors (e.g., post-deployment SaaS/cloud flaws discovered via reconnaissance).
T1212prevents — A.8.32 mandates formal change processes (planning, assessment, testing, authorization) across the SDLC that can catch and block vulnerable code/config before deployment, preventing some exploitation paths for credential access; it does not reach all vulnerabilities (e.g., 0-days, unpatched third-party, or runtime replay flaws) so the coverage is a genuine but minority slice.
T1216.002detects — A.8.32's documented change control, testing, impact assessment, and record-keeping can surface anomalous or unauthorized use of SyncAppvPublishingServer.vbs during managed changes, but the control is scoped only to approved change processes and does not mandate runtime monitoring of living-off-the-land abuse outside that scope
T1218.003detects — A.8.32's documented change control, testing, impact assessment, and record-keeping can surface anomalous or unauthorized use of CMSTP during managed changes, but the control is scoped to approved change processes and does not broadly instrument or monitor for abuse of this signed binary outside those processes.
T1218.003prevents — A.8.32 mandates formal change-control procedures (planning/assessment of impact, authorization, testing, documentation, emergency fall-backs) that, when applied to ICT/software changes, can stop malicious or bypass-prone CMSTP usage from being introduced or persisting through the SDLC; this is only a slice of the technique because the control does not reach runtime abuse of an already-present legitimate signed binary by an adversary.
T1218.005detects — A.8.32's documented change procedures, impact assessment, testing, records and integration with continuity/response plans can surface anomalous or unauthorized use of mshta.exe during managed changes or maintenance, but this is limited to changes that fall inside the formal process rather than arbitrary adversary execution of the technique.
T1218.005prevents — A.8.32's formal change-control process (planning, assessment, authorization, testing, documentation) can prevent unsafe introduction or enablement of mshta.exe abuse vectors during system/software changes, but does not block runtime abuse of an already-present trusted binary on production Windows systems.
T1218.007prevents — A.8.32's formal change-control process (planning, assessment, authorization, testing, documentation) can block unsafe introduction or enablement of msiexec abuse vectors during the SDLC and maintenance, but does not stop runtime abuse of a legitimately present, signed binary on already-deployed Windows systems.
T1218.008detects — A.8.32's documented change control (planning, testing, authorization, records, and integration across the SDLC) surfaces unauthorized or anomalous use of signed binaries like odbcconf.exe during managed implementation and maintenance, but only for changes that fall inside the formal process; ad-hoc or post-deployment abuse to proxy execution is outside its scope.
T1218.008prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) for introducing or modifying systems/software can block unvetted signed binaries or REGSVR abuse paths from entering production environments, but does not stop post-deployment adversary abuse of an already-present legitimate odbcconf.exe
T1218.009detects — A.8.32's documented change control procedures (planning/assessing impact, authorization, testing, records, emergency fall-backs) surface anomalous or unauthorized use of signed binaries like Regsvcs/Regasm when they are treated as changes to ICT infrastructure or software, but this is limited to managed/authorized change windows rather than arbitrary adversary execution of the technique.
T1219.001detects — A.8.32's documented change procedures, impact assessment, testing, authorization, and record-keeping can surface anomalous or unauthorized IDE tunneling setups during managed changes or maintenance, but this is limited to changes that trigger the formal process rather than ongoing detection of stealthy or persistence-based tunneling.
T1484prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) across the SDLC that would block unauthorized or untested policy modifications like those in T1484; it is only partial because the control is a process requirement whose effectiveness depends on implementation rigor, permission enforcement lives in other clauses, and the technique's temporary-modify-revert pattern can still evade detection even when the process is followed.
T1484.001detects — A.8.32 mandates tests, impact assessment, authorization, records, and documentation of all changes (including to AD/GPO settings in the SDLC and ICT infrastructure), which surfaces unauthorized or anomalous GPO modifications when the formal process is followed; it is not a monitoring or anomaly-detection mechanism and leaves substantial coverage gaps for stealthy or out-of-process modifications.
T1484.001prevents — A.8.32 mandates formal change-management processes (planning, authorization, testing, documentation) that, when applied to GPO modifications, block unauthorized or untested changes that realize T1484.001; it reaches only the managed-change slice, not the many other vectors (e.g., direct SYSVOL writes, delegated write abuse, or malicious scripts) that do not route through the formal process.
T1484.002detects — A.8.32 mandates tests, impact assessment, authorization, records, and emergency procedures for all changes (including to identity/trust configuration in the SDLC and ICT infrastructure), which can surface malicious or anomalous trust modifications if they route through the formal change process; this is only a slice because the technique is designed for direct, stealthy manipulation that bypasses change management entirely.
T1484.002prevents — A.8.32 mandates formal change-management processes (planning, authorization, testing, documentation) that can block unauthorized or unassessed trust modifications when applied to identity infrastructure, but the control is a procedural requirement whose coverage depends on implementation scope and does not inherently stop all adversarial trust changes (e.g., via compromised credentials or out-of-band federation additions).
T1485recovers — A.8.32 explicitly requires that ICT continuity plans, response/recovery procedures, operating documentation and user procedures be updated as part of every change so they remain appropriate; this directly supports (and is often a prerequisite for) successful recovery from a realized T1485 event that has destroyed data or infrastructure.
T1486recovers — A.8.32 explicitly requires that ICT continuity plans, response/recovery procedures, operating documentation and user procedures be updated as necessary when changes are made, directly supporting post-impact restoration of availability after T1486 encryption (as in the explicit event-lane anchor for A.8.13 vs T1486).
T1490recovers — A.8.32 explicitly requires that ICT continuity plans, response and recovery procedures, operating documentation and user procedures be updated as necessary when changes occur, directly supporting restoration of recovery capability after an adversary has inhibited it via T1490.
T1491prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation, and contingency) across the SDLC and maintenance prevents unauthorized or untested modifications that could enable or realize defacement, but only for changes that follow the controlled process; it does not stop an already-compromised adversary from directly altering visual content outside that process.
T1491.001prevents — A.8.32's formal change process (planning, authorization, testing, documentation) across the SDLC would catch and block many unauthorized modifications that realize internal defacement, but it does not stop post-compromise adversary actions that bypass change controls or occur outside managed processes.
T1495prevents — A.8.32's formal change-management process (planning impact, authorization, testing, fallback, documentation) across the SDLC and ICT infrastructure directly stops many unauthorized or untested firmware modifications that would otherwise enable T1495, but leaves a bounded remainder for supply-chain, out-of-band, or emergency changes that can still introduce corruptible firmware.
T1496.001detects — A.8.32's documented change procedures, impact assessment, testing, records, and continuity-plan updates can surface anomalous compute usage or unauthorized resource-consuming changes during the managed change lifecycle, but this is limited to changes that go through the formal process rather than stealthy post-compromise mining that evades change control entirely.
T1496.002detects — A.8.32's required records, tests, impact assessments, and integration with continuity/response procedures can surface anomalous bandwidth-consuming changes or malware-driven hijacking during managed change windows, but the clause is scoped only to authorised changes and does not mandate ongoing network monitoring outside the change process.
T1498recovers — A.8.32 requires that ICT continuity plans and response/recovery procedures be updated as necessary when changes occur, which directly supports post-DoS restoration of availability via tested fall-backs and updated recovery procedures.
T1499prevents — A.8.32's formal change process (impact assessment, testing, authorization, fallback, documentation) can prevent changes that would introduce or worsen resource bottlenecks, crash conditions, or unpatched DoS vectors in the application stack, but it does not stop already-present endpoint DoS techniques, external botnets, spoofing, or traffic manipulation that require no target change.
T1499recovers — A.8.32 requires updating ICT continuity plans, response/recovery procedures, and fall-back mechanisms as part of change control, which directly supports restoring availability after an Endpoint DoS but does not itself perform the restoration.
T1499.004prevents — A.8.32's formal change process (impact assessment, testing, authorization, documentation) across the SDLC catches many exploitable vulnerabilities before they reach production, but does not guarantee discovery of all crash-triggering flaws (especially zero-days) nor mandate specific secure-coding or vulnerability-remediation steps.
T1499.004recovers — A.8.32 explicitly requires that ICT continuity plans, response/recovery procedures, operating documentation and user procedures be updated as necessary after changes, which directly supports recovery from the availability loss and side-effects (data destruction, service stop, etc.) caused by this exploitation technique.
T1505prevents — A.8.32 mandates formal change processes (planning/assessment, authorization, testing, documentation) across the SDLC that would catch and block many malicious server-component installs, but leaves open slices such as emergency changes, unmonitored platforms, or insider abuse where the process itself can be subverted.
T1505.001prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) across the SDLC would catch many malicious or unauthorized stored-procedure/CLR changes before they reach production, but the technique can still be introduced via direct DB admin access, runtime events, or emergency paths that bypass the full process.
T1505.002prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that would catch and block registration of a malicious transport agent if the process is followed; the remainder is changes performed outside that process or by privileged insiders who bypass it.
T1505.003detects — Enforced change-management processes and acceptance testing make unauthorized insertion or modification of web shells far more difficult to achieve undetected.
T1505.003prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized insertion of a web shell during maintenance or updates, but leaves open the initial compromise vectors (e.g. exploiting a web vuln to drop the shell without any change record) and emergency changes that can bypass full process.
T1505.004prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation, and emergency fallbacks) across the SDLC would catch and block many malicious IIS component installations if the adversary's changes route through it, but the technique can still be executed via direct file placement, privilege escalation, or out-of-band compromise without triggering the process.
T1505.006prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) over all system changes including those to ICT infrastructure and software; this directly constrains the abuse of VIB installation as a change, but leaves residual paths via emergency changes, privileged esxcli --force use, and acceptance-level tampering that the control's own guidance does not fully close.
T1525detects — A.8.32's documented change control procedures (planning/assessing impact, authorization, testing, records, and maintaining related docs/plans) can surface anomalous or unauthorized image modifications during managed changes, but do not require or guarantee detection of stealthy post-compromise implants outside formal change processes.
T1525prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and emergency fallbacks) would catch and block malicious image implants when the image is introduced or updated through controlled channels, but the technique can still succeed via direct registry writes or compromised instances outside that process.
T1529recovers — A.8.32 explicitly requires that ICT continuity plans, response/recovery procedures, operating documentation and user procedures be updated as part of every change so they remain appropriate after the change; this directly supports post-shutdown/reboot recovery when the change itself was a reboot or when the reboot was performed under controlled change procedures.
T1542.002prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and emergency fallbacks) reaches the slice of T1542.002 where firmware changes are introduced through managed ICT/software lifecycles, but leaves the sophisticated out-of-band compromise of components with weaker integrity checking untouched.
T1542.003prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) over the SDLC including maintenance; this constrains the authorized modification path that a bootkit would abuse to reach MBR/VBR/ESP, but does not stop raw unauthorized writes once an adversary already has the necessary privileges.
T1542.004prevents — A.8.32 mandates formal change-management processes (planning/assessment of impact, authorization, testing, documentation, emergency fallbacks) that reach the firmware-upgrade path described in T1542.004 when performed under organizational control; the same process is absent or bypassed in the adversary's local/remote unauthorized overwrite, so the control prevents the technique only where the change is routed through it rather than the bulk of the attack surface.
T1542.005prevents — A.8.32 mandates formal change-management processes (planning/assessing impact, authorization, testing, documentation, and contingency) across the SDLC and ICT infrastructure that would catch and block an unauthorized configuration change to point a device at a malicious TFTP server; this directly stops the technique from succeeding on managed devices, but the remainder is unmanaged/legacy devices or changes performed outside the formal process.
T1543detects — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and records of all changes) surfaces unauthorized or anomalous creation/modification of system processes when those actions are routed through the required change workflow, but does not instrument or discover stealthy out-of-band adversary techniques that bypass the process entirely.
T1543prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) across the SDLC would catch many malicious or unauthorized creations/modifications of services/daemons during deployment or maintenance, but leaves open the remainder of post-deployment runtime abuse, in-band admin tools, or emergency changes that adversaries routinely exploit.
T1543.001prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) across the SDLC would catch or block many malicious launch-agent .plist additions or modifications if applied to system configuration changes, but the technique can still be executed by an already-privileged adversary outside formal change windows or on unmanaged user-level paths.
T1543.002prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) over the entire SDLC including maintenance; this directly constrains the creation or modification of systemd .service files, generators, and related artifacts that adversaries rely on for T1543.002, but only where those changes are routed through the enforced process — unmanaged or out-of-band modifications remain possible.
T1543.003prevents — Mandatory change-control procedures and testing for new or modified Windows services limit an adversary’s ability to install persistent malicious services.
T1543.004detects — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and record-keeping) surfaces unauthorized or suspicious Launch Daemon plist modifications during the required review steps, but only for changes that go through the controlled process — it does not instrument or detect stealthy, out-of-band modifications by an already-privileged adversary.
T1543.004prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation, impact assessment) across the SDLC that would stop many unauthorized or poorly-vetted modifications to LaunchDaemon plists and referenced executables; it does not reach every vector (e.g., already-elevated malicious code that follows the process, or changes outside managed ICT infrastructure).
T1543.005prevents — A.8.32 mandates formal change-management processes (planning, authorization, testing, documentation) across the SDLC that would catch or block many unauthorized modifications to container services, daemons, or DaemonSets, but the control is silent on enforcement strength, emergency paths, and runtime configuration changes that adversaries can still perform outside the managed process.
T1546prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) across the SDLC would catch many malicious modifications to event triggers, but leaves a genuine minority slice (emergency changes, post-deployment runtime abuse, or changes outside the governed ICT baseline) unreached.
T1546.001prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) over the entire SDLC that would catch and block unauthorized Registry modifications to file associations if the change is routed through the approved process; however, the technique can still be performed directly at runtime by any process with Registry write access, outside any managed change window, leaving a genuine minority slice prevented.
T1546.003detects — A.8.32's formal change-management process (planning, authorization, testing, documentation, and records of all changes) surfaces anomalous or unauthorized WMI event subscriptions when they are introduced as changes, but does not require or perform runtime detection of already-installed malicious subscriptions or their triggered executions.
T1546.003prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized or malicious WMI event subscriptions when they are introduced as changes to production systems; this is a genuine but minority slice of the technique because many instances are created directly at runtime by already-privileged code without traversing a managed change process.
T1546.004prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) over the entire SDLC including maintenance; this directly constrains the adversary action of inserting malicious commands into shell config files, but only for changes that fall under the enforced process — user-level ~/. files, ad-hoc emergency edits, and unmanaged scripts remain outside that boundary.
T1546.007detects — A.8.32's documented change control procedures (planning/assessing impact, authorization, testing, records, and maintaining updated continuity/response procedures) can surface anomalous or unauthorized Netsh Helper DLL registrations during the formal change process, but this is limited to changes that go through the managed process rather than stealthy direct registry writes or runtime abuse.
T1546.007prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) across the SDLC would catch and block malicious or unauthorized Netsh helper-DLL registration as a change, but the technique can also be introduced outside managed change windows (e.g., via other persistence, VPN software, or direct registry edits), leaving a genuine minority slice prevented.
T1546.008prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation, and controlled implementation across the SDLC) would catch and block most unauthorized binary replacements or registry pointer changes to accessibility features, but the clause is silent on enforcement strength, emergency changes, and post-deployment monitoring so a determined adversary can still succeed within the residual.
T1546.011prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) over the SDLC including maintenance; this reaches the introduction and modification of shims (a form of OS-level change) in managed environments but leaves the built-in Windows shimming mechanism itself untouched and does not constrain abuse by already-privileged administrators.
T1546.013prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) over modifications to systems and software throughout the SDLC, which would catch or block unauthorized profile.ps1 edits in managed environments; it reaches only a minority slice because the technique also succeeds via unmanaged user-level profiles, non-ICT scripts, or changes outside formal processes.
T1546.015prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch or block many unauthorized Registry modifications used for COM hijacking, but the control is silent on enforcement strength, detection of stealthy/emergency changes, and does not guarantee prevention of all such hijacks (e.g., those using approved-but-malicious updates).
T1546.016prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that can catch and block malicious or unauthorized modifications to installer packages and their scripts before deployment, but this is only a slice of the technique: it does not stop adversaries from abusing unmodified legitimate installers, supplying tampered packages outside the managed change process, or exploiting post-install scripts during user-driven installation.
T1546.017prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) over modifications to ICT infrastructure and software including rule files in /etc/udev/rules.d and similar; this stops many unauthorized udev rule additions that realize T1546.017, but the control is silent on enforcement strength, emergency paths, and non-change vectors such as initial deployment or supply-chain insertion of malicious rules, leaving a genuine minority slice prevented.
T1546.018prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) across the SDLC including maintenance; this would catch and block many malicious insertions of .pth or sitecustomize.py files during approved changes, but the technique can still be introduced outside any managed change process (e.g. direct filesystem writes by an already-privileged adversary or during untracked emergency maintenance), so only a slice is prevented.
T1547prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that would catch and block many unauthorized autostart modifications (registry keys, boot directories, kernel extensions) before they reach production, but the control is silent on runtime detection or on changes performed outside a managed development/maintenance process, leaving a genuine minority slice of T1547 untouched.
T1547.001prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized Registry-run-key or startup-folder modifications if those locations are in scope; however, the control is silent on enforcement strength, monitoring of the actual keys/folders, and changes performed outside approved processes, leaving a large residual slice of the technique reachable.
T1547.003prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) across the SDLC that would catch or block unauthorized registry changes and malicious DLL registration when performed through managed processes; however, the technique can still be executed via direct out-of-band registry edits or unmonitored emergency paths, leaving a genuine minority slice prevented.
T1547.004prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch and block malicious or unauthorized Registry modifications to Winlogon keys before they reach production, but this is only a slice of the technique's attack surface (e.g., does not address already-compromised systems, runtime abuse, or changes outside managed ICT processes).
T1547.005detects — A.8.32's formal change-management process (planning, authorization, testing, documentation, and records of all changes including to registry, boot, and LSA components) surfaces unauthorized SSP modifications when they occur through the required review and audit trail, but only for changes that follow or deviate from the enforced process — not for stealthy direct registry edits that bypass change control entirely.
T1547.006prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that can block unauthorized or unvetted kernel-module changes on systems built and maintained under it; this is a genuine but minority slice of the technique because the control is procedural/governance, does not reach already-deployed systems or malicious runtime loading, and leaves the dominant in-the-wild LKM/kext rootkit vector untouched.
T1547.007prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would catch and block unauthorized plist modifications for persistence if applied to macOS login configs; this is only a slice of the technique's attack surface (e.g., initial compromise vectors, non-managed systems, or post-change tampering remain unaddressed).
T1547.009prevents — A.8.32 mandates formal change-control processes (planning, authorization, testing, documentation) across the SDLC that would catch or block unauthorized shortcut creation/modification for persistence when those changes fall under managed configuration or deployment; it does not reach ad-hoc or post-compromise abuse outside that process.
T1547.012detects — A.8.32's formal change-management process (planning, authorization, testing, documentation, and records of all changes to systems and ICT infrastructure) surfaces unauthorized or anomalous additions of print processors via the registry, API, or spooler restarts when those changes are routed through the mandated process; it does not instrument runtime detection of the technique itself or changes performed outside the process.
T1547.012prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) over system/software modifications including registry and service changes; this blocks many but not all abuse paths (e.g., direct privileged API use or emergency changes outside the process).
T1547.013prevents — A.8.32 mandates formal change-control procedures (planning/assessment of impact, authorization, testing, documentation, and enforcement) across the SDLC that would catch and block unauthorized addition or modification of XDG .desktop files in /etc/xdg/autostart or ~/.config/autostart; this is genuine but only a slice because the technique can be performed outside managed change windows, by non-developer accounts, or via mechanisms that bypass the formal process.
T1547.014detects — A.8.32's documented change control, impact assessment, testing, authorization, and record-keeping can surface anomalous or unauthorized Registry modifications (including to Active Setup keys) during the managed change process, but this is limited to changes that go through formal procedures rather than stealthy direct abuse by an adversary.
T1547.014prevents — A.8.32 mandates formal change-control procedures (planning/assessment of impact, authorization, testing, documentation, and integration across the SDLC) that would catch and block unauthorized Registry modifications to Active Setup/StubPath during managed changes, but leaves open the remainder of direct adversary writes outside any approved change window or on unmanaged systems.
T1548prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) across the SDLC can stop many unsafe elevation-control changes from reaching production, but leaves residual paths (e.g., runtime abuse of already-deployed mechanisms, unpatched 0-days, or changes outside the managed process) untouched.
T1548.003prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) over modifications to the sudoers file and related sudo configs; this directly stops many adversarial edits that create the weak configurations the technique relies on, but leaves a remainder where changes occur outside the formal process, via social engineering, or in unmanaged emergency paths.
T1548.005prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) catches misconfigurations that create temporary-elevation paths during system or infrastructure changes, but does not reach the bulk of the technique: runtime abuse of already-granted JIT/impersonation/PassRole permissions or approval misconfigurations outside a managed change window.
T1552.001prevents — A.8.32's formal change process (planning impact, testing, authorization, documentation) can catch and block insecure credential storage introduced during system changes or SDLC, but leaves pre-existing files, user-created credential stores, backups, and unchanged legacy systems untouched.
T1554prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and controlled implementation across the SDLC) directly constrains unauthorized binary modifications and patching that T1554 relies on; it is only partial because the control is a procedural requirement whose enforcement and coverage depend on organizational implementation rigor rather than a universal technical barrier.
T1556prevents — A.8.32 mandates formal change-control processes (planning, assessment, authorization, testing, documentation) that can catch or block malicious modifications to auth mechanisms like PAM/LSASS/SAM during the SDLC or maintenance, but does not stop an already-privileged adversary from making the change outside that process.
T1556.001detects — A.8.32's mandated change records, impact assessments, authorization, testing, and emergency/fallback procedures surface unauthorized patches to LSASS or domain-controller authentication processes when they deviate from the formal, documented change workflow.
T1556.003prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) across the SDLC would catch or block many malicious or unauthorized PAM modifications if followed, but does not guarantee prevention of all stealthy or insider-driven changes to authentication components.
T1556.005detects — A.8.32's documented change control procedures (planning/assessing impact, authorization, testing, records, communicating changes) can surface unauthorized or anomalous modifications that enable reversible encryption (e.g. via FGPP or Set-ADUser), but this is limited to changes that are captured in the formal process rather than all possible stealthy or out-of-band ways the property can be set.
T1556.005prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) would catch and block many unauthorized or ill-considered toggles of AllowReversiblePasswordEncryption, but the technique can still be performed by an already-privileged adversary who follows the process or exploits an emergency path, and the control does not reach the underlying credential-storage decision itself.
T1556.007detects — A.8.32's documented change control, testing, impact assessment, authorization, and record-keeping (especially of emergency/contingency changes) can surface unauthorized or anomalous modifications to on-premises/cloud hybrid auth components (PTA agents, AD FS configs, DLL loads), but this is limited to changes that route through the formal process and does not broadly instrument runtime authentication behavior or cloud-side agent registration.
T1556.007prevents — A.8.32 mandates formal change control (planning, authorization, testing, documentation) across the SDLC and infrastructure/software changes, which would block many unauthorized patches/backdoors to hybrid auth processes if followed; however, the technique can still be introduced via compromised privileged accounts, emergency changes, or cloud-side modifications outside the on-prem change process.
T1559.003prevents — A.8.32 mandates formal change processes (planning, assessment, authorization, testing, documentation) across the SDLC that can catch and block insecure XPC implementations (poor validation/sanitization) before they ship, but does not guarantee complete coverage of all XPC code or eliminate the technique in already-deployed systems.
T1561recovers — A.8.32 explicitly requires that ICT continuity plans, response/recovery procedures, operating documentation and user procedures be updated as part of every change so they remain appropriate; this directly enables recovery from a disk-wipe availability event once it has occurred.
T1561.001recovers — A.8.32 explicitly requires that ICT continuity plans, response/recovery procedures, operating documentation and fall-back mechanisms be updated as part of every change so that, after a disk-wipe event, restored availability and irrecoverable-data work-arounds remain current and effective.
T1561.002recovers — A.8.32 explicitly requires that ICT continuity plans, response/recovery procedures, operating documentation and user procedures be updated as necessary when changes are made, directly supporting post-wipe recovery of boot structures via tested fall-back and continuity mechanisms.
T1565prevents — A.8.32's formal change process (planning/assessing impact, authorization, testing, documentation, and emergency fallbacks) constrains unauthorized or unvetted data manipulations during system changes across the SDLC, but leaves many runtime/operational manipulation vectors (e.g., direct DB writes or process injection) untouched.
T1565.001prevents — A.8.32's formal change process (planning, assessment, authorization, testing, documentation) catches and blocks many unauthorized or integrity-breaking modifications to stored data during the SDLC and maintenance, but does not stop post-deployment runtime manipulation by an already-privileged adversary.
T1565.002prevents — A.8.32's formal change-control process (planning/assessing impact, authorization, testing, documentation, and integration across the SDLC) catches and blocks many unsafe modifications that would otherwise allow transmitted-data manipulation to be introduced or persist, but leaves a bounded remainder: in-transit interception techniques that do not involve a 'change' to the system itself.
T1565.003prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation, and integration across the SDLC) would catch and block many unauthorized or untested modifications to binaries, file associations, or runtime components that enable T1565.003, but it does not stop an adversary who already has the privileges or access needed to bypass the process, nor does it address the prerequisite information-gathering phase.
T1569prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) constrains how services are created or modified, blocking many abuse paths that rely on unauthorized or untested service changes; it is only partial because the technique can still succeed via legitimate but abused services, runtime interaction without a 'change', or changes outside the formal process.
T1569.002prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would block unauthorized or untested malicious service creation/execution in managed environments, but leaves unmanaged ad-hoc abuse (e.g. via sc.exe/PsExec on unmanaged systems or emergency paths) untouched.
T1569.003prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation, and integration across the SDLC) can block unauthorized or unvetted use of systemctl to create/start malicious systemd services, but leaves many post-deployment, legitimate, or emergency/abuse vectors untouched.
T1571prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) would catch and block many adversary-driven configuration changes that alter protocol/port pairings on victim systems, but does not address adversary use of non-standard ports in their own C2 traffic without touching the victim.
T1574prevents — formal change-management process with impact assessment, authorization, testing, and documentation before implementation directly blocks many hijack vectors that rely on unauthorized or untested modifications to execution paths, libraries, directories, or registry entries, but leaves residual risk from insider abuse of the approved process itself and from changes outside the formally managed SDLC
T1574.001prevents — A.8.32's formal change-management process (impact assessment, authorization, testing, documentation, and controlled deployment) can block many DLL-planting or substitution vectors that arise during software updates or system changes, but leaves untouched the dominant runtime abuse vectors (search-order hijacking, phantom DLLs, sideloading of already-deployed binaries) that require no change event.
T1574.005prevents — A.8.32 mandates formal change-control procedures (including impact assessment, testing, authorization, and documentation) across the SDLC that would catch and block insecure installer permissions or temp-directory creation during development or maintenance of the affected software; this stops the weakness from reaching production in covered cases, but the control is silent on runtime enforcement, third-party installers outside the organization's SDLC, and emergency changes, leaving a genuine minority slice prevented.
T1574.007prevents — A.8.32's formal change-management process (impact assessment, authorization, testing, documentation, and integration of procedures across the SDLC) can catch and block unsafe PATH modifications or hijackable directory insertions when they are introduced via planned changes or software updates, but leaves the dominant runtime vectors (adversary direct modification of $PATH/$HOME, shell config changes, or /etc/paths.d manipulation outside any change window) untouched.
T1574.008prevents — A.8.32's formal change-management process (impact assessment, authorization, testing, documentation) can catch and block unsafe code changes that would introduce a vulnerable non-full-path call or weak search-order logic during development or maintenance, but does not reach already-deployed vulnerable binaries or runtime hijacking vectors.
T1574.009prevents — A.8.32 mandates formal change processes including impact assessment, testing, authorization, and documentation across the SDLC; this can catch and block unquoted-path introductions during design/maintenance of services, shortcuts, or software, but does not guarantee discovery of every existing unquoted path (especially in unmanaged or legacy components) nor enforce the specific fix of adding quotes.
T1574.010prevents — A.8.32's formal change process (planning impact, authorization, testing, documentation, and integration across SDLC/maintenance) catches and blocks many unsafe permission-altering changes to service binaries/directories before they reach production, but leaves a genuine remainder: ad-hoc or emergency changes, misconfigurations outside the managed change window, and permission flaws introduced by non-change actions such as initial deployment or third-party installers.
T1574.011prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation) would catch and block many Registry-permission-altering changes during the SDLC and maintenance, but leaves residual cases such as post-deployment emergency changes, misconfigurations outside the managed process, or direct Registry manipulation that bypasses the change-control gate.
T1578prevents — A.8.32 mandates formal change processes (planning, assessment, authorization, testing, documentation) that can block unauthorized or ill-considered modifications to cloud compute infrastructure, but only where those changes route through the enforced process; an adversary with sufficient privileges can still perform T1578 outside that process or via emergency paths.
T1578.003detects — A.8.32's required records of changes (including planning, authorization, testing, implementation and emergency fall-back) plus impact assessment and communication to interested parties can surface anomalous or unauthorized instance deletions after the fact, but the clause is scoped to managed/approved changes rather than adversarial evasion and does not mandate the monitoring or logging depth that would catch stealthy deletions in IaaS.
T1578.003recovers — A.8.32 explicitly requires that change control procedures include emergency/contingency considerations and fall-back procedures plus updates to ICT continuity plans and response/recovery procedures, which can enable recovery of deleted cloud instances or their artifacts when the change process is followed.
T1578.004prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation, and contingency/fallback procedures) constrains unauthorized or untracked reversion of cloud instances, but does not stop an adversary with valid cloud-console or API access from performing the revert as a deliberate post-activity cleanup step.
T1578.005prevents — A.8.32 mandates formal change-control procedures (planning/assessment of impact, authorization, testing, documentation) that reach the configuration changes named in T1578.005; this stops many unauthorized modifications at the process gate, but the control is silent on enforcement strength, technical enforcement (e.g., IAM on the management plane), and emergency paths that adversaries routinely abuse, leaving a genuine minority slice prevented.
T1601detects — A.8.32's documented change procedures, impact assessment, authorization, testing, records, and emergency fall-back requirements surface unauthorized or anomalous modifications to system images when followed, but only for changes inside the managed process and not for stealthy in-memory or storage alterations outside it on embedded network devices.
T1601prevents — A.8.32 mandates formal change processes (planning, authorization, testing, documentation) across the SDLC that would block unauthorized or unvetted modifications to a system image when followed; it reaches only a slice because the technique can be performed live in memory or on already-compromised devices outside the controlled change window, and the control is governance rather than an enforcement mechanism.
T1601.001detects — A.8.32's documented change control (planning/assessment, authorization, testing, records, and emergency procedures) surfaces unauthorized or anomalous patches to the system image when they deviate from the formal process, but only for changes that route through operator procedures or documented maintenance; in-memory runtime patching via debug commands, boot loader implants (ROMMONkit), or direct memory manipulation often bypasses these controls entirely.
T1601.001prevents — A.8.32 mandates formal change-control procedures (planning/assessment, authorization, testing, documentation, emergency fallbacks) that, when enforced on network-device firmware/OS images, stop adversaries from using the documented operator procedures the technique relies on; the remainder is in-memory/bootloader patches that bypass those procedures.
T1601.002detects — A.8.32 requires documented change control procedures that include planning/assessing impact, authorization, testing, records, and emergency fall-back; these surface unauthorized or anomalous downgrades (especially via records, tests, and post-change verification) but only where the downgrade is treated as a managed change rather than a stealthy boot-file replacement on embedded devices outside formal processes.
T1601.002prevents — A.8.32 mandates formal change-control procedures (planning/assessing impact, authorization, testing, documentation, emergency fallbacks) across the SDLC that would catch and block unauthorized or untested downgrades of a network-device OS image; this directly stops the technique in managed environments, but the clause is silent on enforcement strength, physical access to embedded storage, and unmanaged/legacy devices, leaving a genuine minority slice unaddressed.
T1609prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) across the SDLC can block unauthorized or insecure container deployments/entrypoints that enable T1609, but leaves the bulk of runtime abuse vectors (docker exec, kubectl exec, API/kubectl abuse under existing permissions) untouched.
T1610prevents — A.8.32 mandates formal change-management processes (planning, assessment, authorization, testing, documentation) across the SDLC that would catch and block many unauthorized or malicious container deployments when they are treated as changes; this is a genuine but minority slice because the technique can also be performed via direct API calls, compromised credentials, or unmonitored workloads that never route through the controlled change process.
T1611detects — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, documentation, and maintaining records) can surface misconfigurations or risky alterations that enable container/VM escapes (e.g., privileged containers, bind mounts, exposed sockets) before or after they are introduced, but does not mandate runtime monitoring or anomaly detection for the technique itself.
T1611prevents — A.8.32 mandates formal change processes (planning, assessment of impact/dependencies, authorization, testing, documentation) that can catch and block many misconfigurations enabling T1611 (e.g., privileged containers, bind mounts of host FS, exposed docker.sock) before deployment or during maintenance, but leaves residual paths such as post-deployment exploits, unpatched hypervisor vulns, or runtime abuse of system calls.
T1612prevents — A.8.32 mandates formal change-control procedures (planning/assessing impact, authorization, testing, documentation) across the SDLC that would catch and block many malicious image builds on a managed host; however, the technique can still succeed via ad-hoc Docker API calls, emergency paths, or unmanaged build activity outside the enforced process.
T1649prevents — A.8.32's formal change-management process (planning, authorization, testing, impact assessment, documentation) across the SDLC and ICT infrastructure can prevent misconfigurations and weak enrollment/renewal settings that enable certificate forgery or theft, but does not stop direct theft of existing valid certificates or root-CA key compromise.
T1666prevents — A.8.32 mandates formal change-management processes (planning/assessing impact, authorization, testing, documentation) that reach IaaS hierarchy modifications when performed as managed changes, thereby stopping many unauthorized or unvetted ones that realize T1666; it leaves the stealthy/unauthorized-permission-abuse slice (e.g. compromised Global Admin calling CreateAccount/LeaveOrganization) untouched.
T1677detects — A.8.32 mandates tests/acceptance, impact assessment, documentation and records of changes across the SDLC; this surfaces some poisoned-pipeline scenarios (especially direct/indirect changes caught in review or test) but leaves public/fork-based and many indirect injection vectors outside its defined change-management scope.
T1677prevents — A.8.32 mandates formal change-control procedures (planning/assessment of impact, authorization, testing, documentation, emergency fallbacks) across the SDLC that, when applied to CI/CD configuration and build files, directly stop unauthorized injection of malicious code in Direct, Indirect, and Public Pipeline scenarios; it is only partial because the clause is a process requirement whose coverage depends on implementation rigor and does not itself enforce technical controls such as branch protection, signed commits, or runner isolation that the technique can still bypass.
T1685.001prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) across the SDLC that would catch or block many unauthorized registry/service/auditpol modifications if applied to production systems; however, the technique can still be executed by an already-privileged adversary outside any managed change window or on unmanaged endpoints, so only a minority slice is prevented.
T1685.002prevents — A.8.32 mandates formal change-control procedures (planning, authorization, testing, documentation) across the SDLC that would catch or block many unauthorized modifications to logging configurations before they take effect; however, it does not address privilege escalation, runtime tampering by already-privileged actors, or emergency changes that bypass the process.
T1685.005detects — A.8.32's change control procedures (planning/assessing impact, authorization, testing, documentation, and maintaining records) can surface anomalous or unauthorized log-clearing actions when they are performed through managed change processes, but most instances of T1685.005 (ad-hoc admin commands, direct file deletion, or post-reboot disablement) occur outside any formal change workflow and are therefore unseen by it.
T1686prevents — A.8.32's formal change-management process (planning, authorization, testing, documentation) applied to firewall configurations would stop many unauthorized modifications, but the technique can still be executed via direct privileged runtime tampering, emergency changes, or unmonitored paths that the control does not reach.
T1686.001detects — A.8.32's required records, tests, authorization, impact assessment and documentation of changes can surface unauthorized or anomalous firewall/security-group modifications after they occur, but this is governance around managed change rather than dedicated monitoring or anomaly detection, leaving most in-flight or stealthy abuse undetected.
T1686.001prevents — A.8.32 mandates formal change processes (planning/assessing impact, authorization, testing, documentation) that can catch or block unauthorized firewall rule modifications in the SDLC or maintenance, but does not stop an already-privileged adversary from making ad-hoc changes outside those processes.
T1689prevents — A.8.32's formal change-management process (planning/assessing impact, authorization, testing, records, and updating continuity docs) prevents many downgrade opportunities by blocking unvetted outdated/vulnerable versions or configurations from being introduced or retained, but leaves residual cases (e.g., adversary-forced runtime downgrades, legacy compatibility that cannot be removed, or changes outside the managed SDLC) untouched.

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

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).

A01←P →P A02←P →P A03←P →P A05→P A06←P →P A07←P A08←P →P A10→P

Why these map — AI rationale (under review)

A01mitigates — Change management procedures (planning impact, testing, authorization, fallback, documentation updates) can catch and limit some Broken Access Control defects during implementation or maintenance, but do not bound or reduce the realized impact of those that ship.
A01prevents — A.8.32's formal change-management process (impact assessment, authorization, testing, documentation) catches many classes of access-control defects before they reach production, but leaves real residual (e.g. CSRF, path-traversal naming issues, and logic errors that survive review) exactly as graded for the identical A01 category in the AC-3 anchor.
A02mitigates — Change-management procedures that include impact assessment, testing, acceptance, documentation updates and contingency planning reduce the chance that a new misconfiguration is introduced or that an existing one survives a change, but they do not themselves harden defaults, close exposed settings or remove an already-present misconfiguration.
A02prevents — A.8.32's formal change-management process (impact assessment, authorization, testing, documentation) catches and blocks many insecure configuration states from reaching production, but does not itself harden defaults, enforce secure baselines, or eliminate all misconfiguration vectors (e.g., runtime cloud settings or incomplete hardening outside the managed change window).
A03mitigates — Change management procedures (planning impact, testing, authorization, deployment, fallbacks, documentation) can limit the blast radius or consequences of a realized supply-chain failure (e.g., by catching bad updates before full rollout or enabling quick rollback), but do not reduce the presence or exploitation of the underlying vulnerable/outdated/compromised dependency, pipeline or signing issue itself.
A05mitigates — Change management procedures that include impact assessment, testing (8.29), authorization and fall-back can catch and limit the blast radius or realization of injection flaws introduced during changes, but do not address the core neutralization failure itself.
A06prevents — A.8.32 mandates formal change-management processes (impact assessment, authorization, testing, documentation) across the SDLC that catch and block many insecure-design defects before they reach production; it does not guarantee that the initial architecture or threat model itself is sound, so the coverage is a genuine but bounded slice of the class.
A08mitigates — Change management procedures (planning, testing, authorization, deployment, records, and contingency) limit the blast radius and downstream consequences of an integrity failure during updates or CI/CD processes, but do not bound or reduce the realized weakness itself when it occurs (e.g. unsigned code or deserialization).
A08prevents — A.8.32's formal change process (planning, authorization, testing, documentation, emergency fallbacks) directly blocks many integrity failures at the source by catching unsigned updates, unvetted CI/CD pipeline changes, and insecure deserialization paths before they reach production; it does not cover all supply-chain or runtime trust failures outside managed change windows.
A10mitigates — Change management procedures that include impact assessment, testing, acceptance, emergency fall-backs and updated continuity plans limit the blast radius and consequence of mishandled exceptions reaching production, but do not address the root cause of the exception paths themselves.
A10prevents — A.8.32's formal change-management process (impact assessment, testing, authorization, documentation, and contingency/fallback planning across the SDLC) directly reduces the chance that error-handling paths will be introduced with leaks, fail-open behavior, or inconsistent states, but does not guarantee that every exceptional-condition defect is caught or eliminated.

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.