A.8.32 Technological
Change management
Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?
The implementation guidance for this control is published in
ISO/IEC 27002:2022
and is not reproduced here. The structured attributes and the cross-walk
rationales below are derived facts and our own AI-authored analysis.
Mapped NIST 800-53 r5 controls (11)
Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- 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-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.
Aligned NIST CSF 2.0 outcomes (9)
NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
Why these map — AI rationale (under review)
- ID.AM-08mostlyaligns with — 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.
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).
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 (135)
Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).
Direction: ← other covers this;
→ this covers other (F/M/P = full / mostly /
partial). gov = governs / implements (a mandate, not coverage).
CWE-1038←P →PCWE-1059←P →MCWE-1068→MCWE-1076←P →PCWE-1078→PCWE-1112←P →PCWE-114→PCWE-1164→PCWE-1174→PCWE-1188→PCWE-123→PCWE-1242←P →PCWE-1250←PCWE-1251→PCWE-1269←P →MCWE-1282→PCWE-1291←PCWE-1304←P →PCWE-1321→PCWE-1328←PCWE-1329←P →PCWE-1394→PCWE-15←P →MCWE-240←PCWE-284→PCWE-285→PCWE-324→PCWE-372→PCWE-416→PCWE-428←PCWE-430←P →PCWE-435←P →PCWE-440→PCWE-449→PCWE-455→PCWE-459→PCWE-471←PCWE-477→PCWE-480→PCWE-489→PCWE-507←P →PCWE-508→PCWE-509←P →PCWE-511→PCWE-553→PCWE-561→PCWE-573→PCWE-648→PCWE-667→PCWE-670→PCWE-672→PCWE-675←PCWE-684→PCWE-689←P →PCWE-691→PCWE-710→PCWE-732→PCWE-755←PCWE-787→PCWE-825→PCWE-911→PCWE-912→M
Why these map — AI rationale (under review)
- CWE-1059mostlyprevents — Change-management procedures rely on up-to-date technical documentation to assess impact.
- CWE-1068mostlyprevents — Change management can catch drift after the fact, but does not guarantee initial implementation matches design.
- CWE-1269mostlyprevents — Change-management procedures ensure only approved, release-ready configurations are deployed.
- CWE-15mostlyprevents — Change management enforces controlled, authorized modifications to settings.
- CWE-912mostlyprevents — Change management processes can catch unauthorized additions but do not inherently prevent hidden functionality from being introduced.
- CWE-1038partialfinds — Change-management processes should evaluate the security impact of enabling or altering automated optimization features.
- CWE-1076partialprevents — Change management can require convention checks but does not inherently enforce them.
- CWE-1078partialprevents — Change management can enforce code review and formatting checks, yet the control's primary focus is broader change governance.
- CWE-1112partialprevents — Change management requires documenting changes to execution mechanisms, but does not ensure initial completeness.
- CWE-114partialprevents — Change management can gate risky deployments but does not inherently block untrusted process control.
- CWE-1164partialprevents — Change-management processes can catch irrelevant code during reviews but are not focused on it.
- CWE-1174partialfinds — Change management processes can enforce validation checks during code reviews and releases.
- CWE-1188partialprevents — 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-123partialprevents — Change management processes help ensure security fixes for such weaknesses are properly deployed.
- CWE-1242partialprevents — Change management processes require documented approvals, reducing the chance of hidden features being introduced.
- CWE-1251partialprevents — Change-management processes can catch configuration drift that leads to unsynchronized mirrors, but the control is broader.
- CWE-1282partialmitigates — Change management can restrict field updates to immutable data but does not enforce the underlying storage design.
- CWE-1304partialprevents — Change management processes can detect and prevent unauthorized or corrupted configuration changes during power save/restore.
- CWE-1321partialprevents — Change-management processes ensure security fixes for prototype-pollution issues are tracked and deployed.
- CWE-1329partialmitigates — Change-management processes can plan for component replacement, yet cannot eliminate the inherent non-updateability of an already-deployed component.
- CWE-1394partialprevents — Change-management processes should detect and remediate default cryptographic keys.
- CWE-284partialprevents — 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-285partialprevents — 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-324partialmitigates — Change-management processes can trigger key rotation, but do not inherently enforce cryptographic expiry rules.
- CWE-372partialprevents — Change-management procedures may indirectly catch state-related defects during release reviews.
- CWE-416partialprevents — Change-management processes help ensure memory-safety fixes are deployed consistently.
- CWE-430partialprevents — Change management verifies that handler mappings remain correct after updates.
- CWE-435partialprevents — Change management can require impact analysis of component interactions before deployment.
- CWE-440partialfinds — Change management can catch specification deviations introduced by modifications.
- CWE-449partialprevents — Change management can catch UI defects before release but does not itself define correct action semantics.
- CWE-455partialprevents — Change management may catch initialization configuration issues during deployment reviews.
- CWE-459partialfinds — Change-management processes may require cleanup verification, but the control itself does not address the weakness.
- CWE-477partialprevents — Change management can trigger reviews that remove obsolete functions but does not directly address them.
- CWE-480partialprevents — Change management processes may include code review gates that incidentally catch operator mistakes.
- CWE-489partialprevents — Change management can enforce removal of debug code as part of release gates.
- CWE-507partialprevents — Change management reduces the risk of unauthorized Trojan Horse code being introduced during updates.
- CWE-508partialprevents — Change-management processes can prevent unauthorized introduction of malicious code.
- CWE-509partialprevents — Change management reduces risk of malicious code being introduced during updates.
- CWE-511partialprevents — Change management reviews reduce the chance of unauthorized malicious code insertion.
- CWE-553partialprevents — Change management can catch the addition of such files if reviewed, but is not a direct mitigation.
- CWE-561partialfinds — Change-management processes may catch dead code during reviews but are not designed to address it.
- CWE-573partialprevents — Change management can catch specification drift during updates but is not a primary mitigation.
- CWE-648partialprevents — Change management can catch misuse of privileged APIs during reviews but does not inherently prevent the weakness.
- CWE-667partialprevents — Change management may catch locking issues introduced by modifications but does not prevent the weakness itself.
- CWE-670partialprevents — Change-management gates may prevent deployment of flawed logic but do not address the coding defect itself.
- CWE-672partialprevents — Change-management processes can introduce or remove resource-lifetime controls.
- CWE-684partialprevents — Change management processes reduce the chance of unintended functional deviations during updates, though they do not directly address initial specification conformance.
- CWE-689partialprevents — Ensures changes to access controls are managed, preventing interim exposure during copy.
- CWE-691partialprevents — Change management reduces introduction of control-flow defects through controlled updates but does not address the weakness directly.
- CWE-710partialprevents — Change management can enforce review against standards.
- CWE-732partialprevents — 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-787partialprevents — Change management can enforce review gates that catch unsafe memory operations before deployment.
- CWE-825partialprevents — Change-management processes can require re-validation of memory safety after modifications, indirectly reducing the weakness.
- CWE-911partialprevents — Change-management processes may catch reference-count issues introduced by modifications, but do not address the root coding flaw.
- CWE-1051nonenone — Change management can catch hard-coded identifiers during reviews, but is not specific to this weakness.
- CWE-1107nonenone — Change management indirectly benefits from centralized constants but does not directly address their placement.
- CWE-1116nonenone — Change management processes require documentation updates, indirectly ensuring comment accuracy after modifications.
- CWE-121nonenone — Change-management gates can enforce security reviews that catch buffer issues.
- CWE-122nonenone — Change management ensures controlled deployment of fixes for discovered heap-overflow vulnerabilities.
- CWE-1222nonenone — Change-management processes can review lock configurations, yet the weakness is a hardware-design issue outside runtime change control.
- CWE-1223nonenone — Change management processes may review hardware design changes but do not directly prevent race conditions in write-once registers.
- CWE-1233nonenone — Change management processes can require verification that lock bits remain set after updates.
- CWE-1245nonenone — Change management ensures hardware logic modifications do not introduce new FSM weaknesses.
- CWE-1250nonemitigates — Change management can coordinate updates across replicas but does not inherently enforce real-time consistency.
- CWE-1279nonenone — Change management processes may indirectly reduce the risk of premature cryptographic operations.
- CWE-1281nonenone — Change management ensures controlled rollout of microcode or firmware fixes that address processor errata causing lock-ups.
- CWE-1283nonenone — Change management controls limit unauthorized modifications to boot configuration and measurement components.
- CWE-1291nonenone — Change-management procedures can enforce distinct key usage and approval gates for production signing keys.
- CWE-1310nonenone — Change management governs controlled updates but cannot compensate for hardware lacking ROM patching ability.
- CWE-1313nonenone — Change management processes can enforce configuration baselines that disable runtime debug features.
- CWE-1314nonenone — Change management can restrict unauthorized updates to calibration values but does not enforce the technical write-protection mechanism.
- CWE-1316nonenone — Change management can catch erroneous address-map updates but does not inherently prevent the weakness.
- CWE-1326nonenone — Change management can protect firmware updates but does not ensure an immutable hardware root of trust exists.
- CWE-1328nonemitigates — Change-management processes can require cryptographic verification of firmware versions before deployment.
- CWE-240nonenone — Change management ensures structural consistency is preserved when modifications are introduced.
- 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-28nonenone — Change management ensures reviewed fixes for traversal bugs but does not prevent the weakness itself.
- CWE-281nonenone — Change-management procedures can require verification that permissions remain intact after modifications or restores.
- CWE-344nonenone — Change management processes can catch invariant values during reviews, but this is incidental.
- CWE-362nonenone — Change management reduces introduction of concurrency bugs during updates, yet does not address the weakness itself.
- CWE-364nonemitigates — Change management may catch unsafe signal code during reviews but does not address the weakness itself.
- CWE-366nonenone — Change management can introduce or remove synchronization flaws during updates.
- CWE-368nonenone — Change management may indirectly reduce introduction of such flaws but does not address the weakness itself.
- CWE-386nonenone — Change management may catch configuration drift but does not directly address symbolic name resolution in code.
- CWE-426nonenone — Change-management processes can enforce review of path-handling changes, indirectly lowering risk.
- CWE-428nonenone — Change-management processes can enforce review of path-handling changes that might introduce unquoted elements.
- CWE-454nonenone — Change management can catch unsafe initialization changes but does not inherently prevent the weakness.
- CWE-471nonemitigates — Change-management procedures ensure that any modification to data presumed immutable is reviewed and authorized.
- CWE-547nonenone — Change management may detect constant changes but does not prevent their initial hard-coding.
- CWE-556nonemitigates — Change management processes can review configuration changes that introduce impersonation settings.
- CWE-637nonenone — Change management can prevent ad-hoc complexity introduced during maintenance but does not address initial design complexity.
- CWE-638nonenone — Change management can revoke rights but does not ensure runtime mediation on every access.
- CWE-664nonemitigates — Change management governs resource modifications but does not cover creation or release.
- CWE-675nonenone — Change management processes can prevent introduction of duplicate resource operations during updates.
- CWE-695nonenone — Change management can catch policy violations but does not inherently block low-level functionality.
- CWE-696nonenone — Change management may catch order-related issues during reviews but does not address root cause.
- CWE-73nonenone — Change-management processes can enforce review of path-handling code but do not address the weakness at runtime.
- CWE-74nonenone — Change management can enforce review of code changes that might introduce injection flaws.
- CWE-755nonenone — Change management can introduce or miss exception-handling defects if not reviewed.
- CWE-765nonenone — Change-management procedures may surface the defect during reviews but do not directly prevent multiple-unlock coding errors.
- CWE-772nonedetects — Change-management processes may catch missing de-allocation during reviews, but the control itself does not target resource lifetime.
- CWE-821nonenone — Change management processes can introduce or miss synchronization fixes during updates.
- CWE-826nonenone — Change-management processes may catch resource-handling regressions but do not directly prevent the weakness.
- CWE-833nonenone — Change management may catch deadlock-related defects during reviews but does not directly address concurrency design.
- CWE-835nonenone — Change management can require review of loop logic when code is modified.
- CWE-841nonemitigates — Change management can require workflow adherence for changes but is not the primary mitigation.
- CWE-88nonenone — Change management can catch unsafe command patterns during reviews but is not a direct mitigation.
- CWE-909nonenone — Change management can enforce review of initialization logic during modifications.
- CWE-913nonenone — Change management can limit unauthorized dynamic code changes but does not enforce proper control mechanisms.
- CWE-96nonemitigates — Change management can catch unsafe code changes but does not enforce input neutralization.
- CWE-99nonenone — Change-management processes can catch unsafe identifier handling during code review but are not a direct mitigation.
Mitigated MITRE ATT&CK techniques (7)
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).
Why these map — AI rationale (under review)
- T1543.003mostlyprevents — Mandatory change-control procedures and testing for new or modified Windows services limit an adversary’s ability to install persistent malicious services.
- T1484.001partialmitigates — Requiring documented impact assessment and approval for Group Policy changes reduces the chance an attacker can silently alter domain policies to weaken security controls.
- T1505.003partialdetects — Enforced change-management processes and acceptance testing make unauthorized insertion or modification of web shells far more difficult to achieve undetected.
- T1547.001partialmitigates — Documented approval and rollback procedures for registry or startup-folder modifications reduce the likelihood an attacker can silently add autostart persistence mechanisms.
- T1553.006partialmitigates — Formal change authorization and testing requirements make it harder for an adversary to modify code-signing policies or trust settings without detection.
- T1574.001partialmitigates — Requiring impact assessment, testing, and authorization for software or library changes limits an adversary’s ability to hijack execution flow via malicious DLLs.
- T1053.005nonemitigates — Requiring authorization, testing, and documentation for scheduled-task changes hinders attackers from establishing scheduled execution of malicious code.
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.