Every system modification is a potential attack surface expansion. Uncontrolled changes remain one of the top causes of self-inflicted outages and security incidents, turning routine updates into organizational risk events. ISO 27001 control 8.32 exists to prevent exactly that by formalizing how changes move from request to production.
What 8.32 requires
ISO 27001 8.32 is a technological control that requires organizations to subject all changes to information processing facilities and systems to a formal Change Management (CM) process designed to prevent the introduction of security risks. The official objective states that organizations must ensure every modification goes through structured planning, assessment, authorization, and documentation before reaching a production environment.
The scope is broad. Control 8.32 covers system upgrades, security patches, configuration changes, new deployments, and decommissions. It applies equally to development and operational environments, meaning organizations can’t treat staging as exempt from formal oversight. This includes changes to operating systems, application software, network configurations, middleware, and cloud infrastructure components.
The control sits within ISO 27001’s Annex A Domain 8 (Technological Controls), reinforcing that change management isn’t purely a governance exercise. It demands technical implementation through tooling, automation, and enforced workflows that prevent unauthorized modifications from reaching production systems.
In practice, this means every change needs a defined workflow that includes risk assessment, impact analysis, testing in a controlled environment, explicit approval from a designated authority, and a documented rollback plan. The control also requires maintaining an audit trail that captures who requested the change, who approved it, what testing occurred, and when deployment happened.
What separates 8.32 from a generic “have a change process” requirement is its emphasis on security outcomes. The process isn’t just about operational stability. It’s about ensuring that each modification is evaluated for its potential to introduce vulnerabilities, weaken existing controls, or create gaps that attackers can exploit. Organizations that treat change management as a rubber-stamp exercise miss the point entirely. Change management is a continuous monitoring concern, not a policy checkbox that gets reviewed once a year.
Why 8.32 matters
A mid-sized financial services firm pushes an infrastructure update on a Friday afternoon. The change modifies firewall rules to accommodate a new application, but the engineer responsible doesn’t submit the update through the standard approval workflow. By Monday morning, the security team discovers that the rule change inadvertently opened an API endpoint to the public internet. Automated scanners have already indexed it, and unauthorized access attempts are logged overnight. The incident triggers a data exposure investigation, regulatory notification obligations, and weeks of remediation.
This isn’t hypothetical. According to Gartner, 80% of unplanned downtime is caused by poorly managed changes. The risk isn’t just operational disruption. Uncontrolled changes create security exposures that attackers actively seek out, turning an internal process failure into an external attack surface management concern.
From an attacker’s perspective, poorly managed changes are low-hanging fruit. Configuration drift between environments means known vulnerabilities persist in production long after patches are available. Emergency changes deployed under pressure often bypass security review entirely, and the “temporary” exceptions they introduce have a habit of becoming permanent fixtures in the environment.
The consequences compound quickly. A single unreviewed configuration change can cascade into unauthorized access, data exposure, regulatory penalties, and reputational damage. Without formal change management, organizations have no reliable way to trace what changed, when it changed, and whether that change introduced the vulnerability being exploited. During incident response, this lack of traceability extends investigation timelines and increases the blast radius of what might have been a contained issue.
What attackers exploit
Poorly managed change processes create specific, predictable failure modes:
- Unreviewed configuration changes that open network paths or expose services to unauthorized access
- Emergency changes deployed without rollback plans that persist as permanent vulnerabilities long after the urgency passes
- Missing segregation of duties that allows developers to push code directly to production without independent review
- Orphaned test environments running production data with weaker access controls and outdated patches
- Inconsistent patching across environments that creates version drift, leaving some systems vulnerable to exploits already remediated elsewhere
Each of these represents a concrete entry point. Attackers don’t need sophisticated zero-day exploits when misconfigured infrastructure and unpatched systems are readily available.
How to implement 8.32
For your organization (first-party)
Building a compliant change management process starts with a formal Change Management Policy that defines change types (standard, normal, emergency), approval workflows, and escalation procedures. This document becomes the foundation auditors evaluate first.
From there, implement a structured Change Request process, sometimes called a Request for Change (RFC). Each RFC should include:
- Risk assessment: What could go wrong if this change fails or introduces a vulnerability?
- Impact analysis: Which systems, users, and processes are affected?
- Rollback plan: How do you revert if the change causes issues?
- Testing requirements: What validation must occur before production deployment?
Require all changes to be tested in a separate environment before production deployment. This seems obvious, but organizations routinely skip this step under time pressure, testing in production or using production data in test environments without appropriate controls.
Enforce authorization gates at critical points. Changes should require documented approval from a designated authority, and that approval should be captured in the ticketing system, not communicated verbally or through informal channels. For high-risk changes, convene a Change Advisory Board (CAB) to review the RFC, assess cross-system impacts, and approve or reject the deployment.
Maintain a complete audit trail. Every change ticket should record the request, risk assessment, approval, testing results, deployment timestamp, and post-implementation status. This trail becomes critical evidence during both incident investigations and compliance audits.
After significant changes, update your Business Continuity (BC) and Disaster Recovery (DR) plans. Infrastructure modifications can invalidate existing recovery procedures, and organizations frequently overlook this step until a continuity event exposes the gap.
Finally, conduct post-implementation reviews to verify changes achieved their intended outcomes without unintended side effects. These reviews close the feedback loop and surface process improvements. A structured post-implementation review should compare actual outcomes against the RFC’s stated objectives, document any unexpected impacts, and capture lessons that improve future change assessments.
The tooling that supports this process typically includes IT Service Management (ITSM) platforms like ServiceNow or Jira Service Management for change ticketing, version control systems like Git for code and configuration tracking, CI/CD pipelines with built-in approval gates, and Configuration Management Databases (CMDBs) for maintaining the baseline state of infrastructure components.
Common mistakes to avoid:
- Treating emergency changes as exempt from documentation (they still require retrospective documentation within a defined timeframe)
- Allowing change approval bottlenecks that incentivize teams to bypass the process entirely
- Failing to update continuity plans after infrastructure changes
- No rollback plan for critical deployments
For your vendors (third-party assessment)
When assessing vendor change management practices as part of your third-party risk management program, ask specific questions that reveal process maturity:
- “Describe your change management process for production systems.”
- “How are emergency changes handled and documented?”
- “Who approves production changes, and is there segregation of duties?”
- “How do you separate development, testing, and production environments?”
Request concrete evidence: the change management policy document, sample change tickets (redacted for confidentiality), CAB meeting minutes for recent high-risk changes, and CI/CD pipeline configurations showing automated approval gates.
Red flags during vendor assessments include: no documented change management process, developers self-approving their own production deployments, no separation between test and production environments, and inability to produce change logs when requested.
For additional verification, review the vendor’s SOC 2 Type II report, specifically Trust Services Criteria CC8.1 (Change Management). Cross-reference their stated process against change log samples to confirm the policy is operationalized, not just documented. A vendor that can produce a well-maintained change log with consistent approval patterns demonstrates process maturity; a vendor that scrambles to compile records on request likely has a documentation problem that reflects a deeper operational gap.
Audit evidence for 8.32
Auditors evaluating control 8.32 expect both policy-level documentation and operational evidence demonstrating consistent execution. Having a policy on paper is necessary but insufficient; auditors will sample recent change tickets to verify the process is followed in practice, not just defined in theory.
| Evidence type | Example artifact |
|---|---|
| Policy | Change Management Policy defining change types, approval workflows, emergency procedures, and review cadence |
| Procedure | Change Request (RFC) template with fields for risk assessment, impact analysis, and rollback plan |
| Records | Completed change tickets showing request, approval, testing, and deployment dates |
| Logs | Version control commit history and CI/CD pipeline deployment logs |
| Meeting minutes | Change Advisory Board (CAB) review records for high-risk changes |
| Test evidence | Pre-deployment test results from staging or sandbox environments |
| Post-implementation review | Documentation of change outcomes and lessons learned |
| Continuity updates | Business continuity plan revision history showing updates after significant changes |
Cross-framework mapping
Organizations operating under multiple compliance frameworks can map 8.32 to equivalent controls, reducing duplicate assessment effort.
| Framework | Equivalent control(s) | Coverage |
|---|---|---|
| NIST 800-53 | CM-03 (Configuration Change Control) | Full |
| NIST 800-53 | CM-05 (Access Restrictions for Change) | Full |
| NIST 800-53 | SA-10 (Developer Configuration Management) | Partial |
| NIST 800-53 | SI-02 (Flaw Remediation) | Partial |
| SOC 2 | CC8.1 (Change Management) | Full |
| CIS Controls v8.1 | Control 2.5 (Allowlist Authorized Software) | Partial |
| NIST CSF 2.0 | PR.IP-3 (Configuration Change Control) | Full |
| DORA (EU) | Article 9 (ICT Change Management) | Full |
The NIST 800-53 mappings cover the broadest overlap. CM-03 addresses configuration change control processes directly, requiring organizations to document, approve, and track changes to information systems. CM-05 focuses on restricting who can make changes through access controls and role-based permissions. SA-10 and SI-02 provide partial coverage through developer configuration management and flaw remediation requirements, respectively.
SOC 2’s CC8.1 criterion aligns closely with 8.32, making organizations already compliant with one well-positioned for the other. The SOC 2 overlap is particularly relevant for SaaS vendors who face both ISO 27001 certification requirements and SOC 2 audit obligations from their enterprise customers.
For organizations subject to the EU’s Digital Operational Resilience Act (DORA), Article 9 imposes ICT change management requirements that align closely with 8.32, making compliance with one framework a strong foundation for the other.
Related ISO 27001 controls
Control 8.32 doesn’t operate in isolation. Several other Annex A controls create dependencies and reinforcing requirements that, taken together, form a comprehensive security posture around system modifications. Understanding these connections helps organizations avoid implementing 8.32 as a standalone process disconnected from related security activities.
| Control ID | Control name | Relationship |
|---|---|---|
| 8.9 | Configuration management | Changes must align with approved configuration baselines |
| 8.25 | Secure development lifecycle | Change management integrates with SDLC approval gates |
| 8.29 | Security testing in development and acceptance | Pre-deployment testing validates changes meet security requirements |
| 8.31 | Separation of development, testing, and operational environments | Environments must be isolated to prevent untested changes reaching production |
| 8.33 | Test information | Test data must be controlled when validating changes |
| 5.37 | Documented operating procedures | Procedures must be updated when changes alter operational processes |
| 5.30 | ICT readiness for business continuity | Continuity plans must reflect system changes |
| 5.23 | Information security for use of cloud services | Cloud infrastructure changes require the same rigor as on-premises |
Frequently asked questions
What is ISO 27001 8.32?
ISO 27001 8.32 is a technological control requiring organizations to subject all changes to information processing facilities and systems to a formal change management process. It covers planning, risk assessment, testing, authorization, and documentation of changes to prevent the introduction of security risks during system modifications.
What happens if 8.32 is not implemented?
Without formal change management, organizations face uncontrolled modifications that can introduce security vulnerabilities, cause outages, and create compliance gaps. Auditors will flag missing change controls as a nonconformity during certification or surveillance audits, and unmanaged changes remain a leading cause of self-inflicted security incidents.
How do you audit 8.32?
Auditors verify 8.32 by reviewing the change management policy, sampling recent change tickets for proper approval and testing evidence, and checking that emergency changes followed documented procedures. They also verify that continuity plans were updated after significant changes and that segregation of duties is enforced across the change lifecycle.
How UpGuard helps with change management monitoring
UpGuard continuously monitors your external attack surface for unauthorized changes, misconfigurations, and security risks introduced by system modifications, giving you visibility into the change-related exposures that manual processes miss.
- Breach Risk: Detects externally visible changes to your infrastructure, including exposed services, certificate modifications, and configuration drift that may indicate uncontrolled changes reaching production.
- Vendor Risk: Assesses and monitors your vendors’ change management maturity as part of continuous third-party risk evaluation, helping you identify suppliers whose change practices introduce risk to your organization.