ISO 27001 A.8.32: Change Management

🚀 Time-Constrained? Start Here

📋 48-Hour Quick Start

• Download the Change Management Policy Template (Day 1, AM)
• Customize it with your company name (Day 1, PM)
• Create 5 change request forms using the template (Day 2, AM)
• Schedule your first change review meeting (Day 2, PM)
• Done. You have the core of a change management process; an auditor will also want to see it used, with records, over time.

What the Control Asks For

Figure · Matrix

Comparison: A.12.1.2, Change to A.14.2.4, Restrictions

The Control in Plain Words

ISO 27001:2022 Annex A 8.32 asks organizations to control changes to information processing facilities and systems through change management procedures.

ISO 27002 attributes: Control type: Preventive · Properties: Confidentiality, Integrity, Availability · Concepts: Protect · Capabilities: Application security, System and network security · Domains: Protection

What Changed from ISO 27001:2013

Scope: A.8.32 covers changes to information processing facilities and information systems: infrastructure, operating systems, databases, middleware, applications, cloud services and their configuration, from early design through maintenance. ISO 27002 recommends integrating change control for ICT infrastructure and software wherever practicable.

Two things sit outside A.8.32:

• Changes to the ISMS itself (scope, policies, processes, objectives) are planned under clause 6.3, Planning of changes, which is mandatory for every ISMS.
• Updating documentation and continuity plans is not a separate scope. It is a consequence of a system change that the change procedure must handle (points (h) and (i) below).

What ISO 27002 Recommends (in Our Words)

ISO 27002 says new systems and major changes should follow agreed rules and a formal process covering documentation, specification, testing, quality control and managed implementation, with management responsibilities defined. Change procedures should be documented, enforced and applied across the whole development life cycle. They should cover:

ISO 27002 also notes that poorly controlled changes are a common cause of failures, that changes moving from development to production can affect integrity and availability, and that testing in an environment separate from both production and development (A.8.31) is good practice, including for patches and updates.

Do you need this control?

A.8.32 is selected through risk treatment like every Annex A control, and recorded in your Statement of Applicability. Almost every organisation that runs or configures its own systems, including cloud services, includes it, because uncontrolled change is one of the most common causes of outages and security failures. An organisation that only uses SaaS products it cannot change might rely on supplier controls (A.5.22) instead, and say so in its Statement of Applicability.

Multi-Framework Mapping

Annex A 8.32 Across Major Frameworks

Mapping: ISO 27001 A.8.32 → SOC 2 CC8.1

Practical note: If you're seeking dual certification (ISO 27001 + SOC 2), design one change management process that satisfies both. Both focus on changes to systems; ISMS-level changes sit under ISO 27001 clause 6.3. The SOC 2 version is more audit-evidence-focused.

Control Integration Map

Annex A 8.32 doesn't exist in isolation. Changes affect everything. Here's how it connects to other controls:

Upstream Controls (Inputs to 8.32)

Downstream Controls (Outputs from 8.32)

Parallel Controls (Happening Simultaneously)

Change Management Maturity Model

Use this maturity model to place your current practice and plan the next step:

Level 1: Ad-Hoc (Chaos)

• Changes happen without process
• No documentation, no approval
• Emergency fixes are the only "process"
• Incidents are frequent and untraceable
• Audit result: Major non-conformity
• Example: Developer pushes to production directly

Level 2: Defined (Paper Process)

• Change policy exists but is not followed
• Some changes are documented in emails/spreadsheets
• Approval is informal ("asked in Slack")
• No testing or rollback planning
• Audit result: Minor non-conformity, observations
• Example: Change request form exists but only 30% of changes use it

Level 3: Managed (Working Process)

• All changes go through formal process
• Change log is maintained
• Testing happens for major changes
• Rollback plans exist for critical changes
• Metrics are tracked manually
• Audit result: Conformity with observations
• Example: Jira workflow for changes; weekly change review meetings

Level 4: Measured (Data-Driven)

• Change metrics are tracked automatically
• Success rate, MTTR, rollback frequency measured
• Changes are categorized by risk and type
• Automated testing in CI/CD
• Post-implementation reviews are mandatory
• Audit result: Full conformity
• Example: Dashboard showing change success rate, SLA compliance, audit trail completeness

Level 5: Optimized (Self-Improving)

• Machine learning predicts change risk
• Automated approval for standard changes
• Canary deployments with automatic rollback
• Change metrics drive continuous improvement
• Process updates are automated based on lessons learned
• Audit result: Exceeds expectations
• Example: AI-powered change risk scoring; 95% of standard changes are auto-approved

Change Types and Approval Matrix

Change types decide how much approval and testing a change needs:

Approval Thresholds by Risk Level

Risk Scoring Matrix

Risk Score = weighted average. Round to nearest whole number.

Role Definitions (RACI)

Who does what:

R = Responsible, A = Accountable, C = Consulted, I = Informed

Role Definitions

The Change Management Process (Step-by-Step)

The process below covers every ISO 27002 point, (a) to (i).

Step 1: Initiation

What to include:

• Change request should include: business justification, expected benefit, risk acceptance, budget/resource estimate
• For technical changes: architecture diagram (before/after), dependency map, blast radius analysis
• For non-technical changes: stakeholder impact assessment, communication plan

Change Request Form Fields (minimum):

1. Change ID (auto-generated)
2. Requester name, department, date
3. Change title and description
4. Business justification
5. Affected systems/services/assets
6. Risk assessment (pre-filled from matrix)
7. Proposed implementation date/time
8. Testing plan
9. Rollback plan
10. Required approvals (auto-populated based on risk)

Step 2: Impact and Risk Assessment

What to include:

• Dependency mapping: Use a CMDB (Configuration Management Database) to trace what else breaks if this system changes
• Blast radius analysis: If this change fails, how many systems/users are affected? Map it.
• Security impact assessment: Does this change affect encryption, access controls, logging, or monitoring?
• Compliance impact assessment: Does this change affect PCI DSS scope, HIPAA protected data, GDPR processing?
• Performance impact: Will this change affect system performance under load?

Impact Assessment Template:

Step 3: Authorization

What to include:

• Approval quorum: For high-risk changes, require 2+ approvers from different departments (segregation of duties)
• Approval with conditions: Approver can approve with conditions (e.g., "approved if tested in staging for 48 hours")
• Approval escalation: If approver doesn't respond within 24 hours (normal) or 2 hours (emergency), escalate
• Approval revocation: Approver can revoke approval before implementation if new risk information emerges

Step 4: Planning and Scheduling

What to include:

• Change freeze periods: No changes during month-end, quarter-end, audit periods, or holiday seasons
• Change windows: Define approved change windows (e.g., Saturday 2-6 AM for production)
• Blackout dates: Maintain a calendar of blackout dates (audits, critical business periods)
• Resource planning: Ensure implementer, tester, and rollback team are available during change window
• Communication plan: Who needs to know, when, and how (email, Slack, status page, PagerDuty)

Step 5: Testing and Validation

What to include:

• Testing pyramid for changes:
  • Unit tests (automated): 70% of test coverage
  • Integration tests (automated): 20% of test coverage
  • End-to-end/UAT (manual): 10% of test coverage
• Test environment parity: Staging must mirror production (infrastructure, data volume, security controls)
• Security testing: SAST/DAST for code changes, vulnerability scan for infrastructure changes
• Performance testing: Load testing for changes that affect performance
• Regression testing: Ensure the change doesn't break existing functionality
• Chaos engineering: For critical systems, test failure scenarios (Netflix Simian Army approach)

Step 6: Implementation

What to include:

• Deployment strategies:
  • Blue-green deployment: Two identical environments, switch traffic
  • Canary deployment: Roll out to 5% of users first, monitor, then expand
  • Feature flags: Deploy code but enable feature gradually
  • A/B testing: Compare old vs. new version with real traffic
• Rollback readiness: Pre-stage rollback artifacts, have rollback command ready, test rollback in staging
• Monitoring during change: Real-time monitoring of error rates, performance, security alerts during implementation
• Communication during change: Status updates every 15 minutes for major changes

Step 7: Verification and Closure

What to include:

• Verification checklist:
  • System is operational and accessible
  • No new errors in logs
  • Performance is within acceptable parameters
  • Security controls are functioning
  • Monitoring and alerting are active
  • Backups are functioning
  • Users can access the system
  • No compliance gaps introduced
• Hold period: For major changes, hold for 24-72 hours before declaring success
• Incident correlation: Check if any incidents occurred during/after change window
• Stakeholder sign-off: Business owner confirms the change meets requirements

Step 8: Documentation and Record Keeping

What to include:

• Retention requirements: ISO 27001 sets no retention period. Set one in your policy, long enough to cover audits, investigations and sector rules (many organisations keep change records for 3 years or more)
• Immutable logs: Change logs should be tamper-proof (write-once storage, blockchain, or audit-trail-enabled system)
• Searchability: Change records should be searchable by system, date, requester, risk level, outcome
• Integration with incident records: If change caused incident, link change record to incident record
• Integration with asset inventory: Change record should reference affected assets in CMDB

DevOps and CI/CD Change Management

Annex A 8.32 in a DevOps world.

The Challenge

Traditional change management assumes:

• Changes are infrequent (weekly/monthly)
• Changes are large (full releases)
• Changes go through manual approval

DevOps reality:

• Changes are frequent (hourly/daily)
• Changes are small (microservices, commits)
• Changes are automated

Solution: GitOps Change Management

Principle: Your Git repository is the single source of truth. Every change is a commit. Every commit is traceable.

GitHub/GitLab Change Management Setup

Branch Protection Rules (production branch):

• Require pull request reviews before merging (2 reviewers for high-risk)
• Require status checks to pass (CI/CD tests, security scans)
• Require signed commits (GPG/SSH signing)
• Require linear history (no merge commits for traceability)
• Include administrators in restrictions (no bypassing)
• Allow force pushes: Never
• Allow deletions: Never

Pull Request Template (.github/pull_request_template.md):

CI/CD Pipeline Integration:

## Example GitHub Actions workflow
name: Change Management Gate
on:
  pull_request:
    branches: [main]

jobs:
  change-gate:
    runs-on: ubuntu-latest
    steps:
      - name: Check PR template completeness
        run: |
          # Script to verify PR template fields are filled
          # Fail if risk assessment is missing
      - name: Run security scan
        run: |
          # SAST/DAST scan
          # Fail if critical vulnerabilities found
      - name: Run compliance check
        run: |
          # Check if change affects PCI DSS scope
          # Check if change affects sensitive data
      - name: Require approval from security team
        run: |
          # Verify at least one security team member approved

Infrastructure as Code (IaC) Changes

Terraform, CloudFormation, Ansible, Pulumi changes.

IaC Change Management Principles

1. Infrastructure changes are code changes. Apply the same change management rigor to .tf files as to .py files.
2. Plan before apply. Always run terraform plan (or equivalent) before terraform apply. The plan is your impact assessment.
3. State file protection. Terraform state contains sensitive data. Protect it like a database.
4. Drift detection. Run drift detection daily. Unplanned infrastructure changes are incidents.

Terraform Change Management Workflow

1. Developer writes Terraform change (.tf file)
2. Create PR with terraform plan output attached
3. Security review: Does this open new ports? New IAM roles? New public access?
4. Compliance review: Does this affect PCI DSS scope? Add new data stores?
5. Run terraform plan in CI/CD (auto-generated plan output as PR comment)
6. Approval required from Infrastructure Lead + Security Lead
7. Merge PR → triggers terraform apply in CI/CD
8. Post-apply verification: Run terraform plan again to confirm no drift
9. Update CMDB/asset inventory automatically

Terraform Plan as Impact Assessment

The terraform plan output IS your impact assessment. It shows:

• What will be created
• What will be modified
• What will be destroyed
• What will be replaced

Require terraform plan output in every infrastructure change PR.

Drift Detection

## Daily drift detection workflow
name: Infrastructure Drift Detection
on:
  schedule:
    - cron: '0 6 * * *'  # Daily at 6 AM

jobs:
  drift-check:
    runs-on: ubuntu-latest
    steps:
      - name: Run terraform plan
        run: |
          terraform plan -detailed-exitcode
        # If exit code 2 = changes detected = drift = incident

Cloud-Native Change Management

Kubernetes, containers, serverless.

Kubernetes Change Management

Kubernetes changes that need 8.32 control:

• New deployments or deployment updates
• ConfigMap or Secret changes
• NetworkPolicy changes
• RBAC (Role/RoleBinding/ClusterRole) changes
• Ingress or Service changes
• PersistentVolume or StorageClass changes
• CRD (Custom Resource Definition) changes

Kubernetes Change Management Workflow:

1. Change is a YAML manifest change
2. PR with manifest diff + impact assessment
3. CI/CD validates YAML syntax, security (OPA/Kyverno policies)
4. Deploy to staging cluster first
5. Run smoke tests, integration tests, security scan
6. Canary deploy to production (5% → 25% → 100%)
7. Monitor metrics: error rate, latency, resource usage
8. If metrics degrade → automatic rollback
9. If metrics stable → full rollout + documentation

Kyverno/OPA Policy Gates (Security as Code):

## Kyverno policy: No changes without label "change-id"
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-change-id
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-change-id
    match:
      resources:
        kinds:
        - Deployment
        - ConfigMap
        - Secret
    validate:
      message: "All changes must have a change-id label"
      pattern:
        metadata:
          labels:
            change-id: "?*"

AI/ML Model Change Management

AI/ML model deployment, retraining, updates.

Why AI/ML Changes Need Special Change Management

1. Model changes are invisible. A model file update looks like any other file update, but changes behavior unpredictably.
2. Model drift. Model performance degrades over time. Retraining is a change.
3. Data pipeline changes. Training data changes, feature engineering changes, label changes.
4. Explainability requirements. GDPR, EU AI Act may require explanation of model changes.
5. Bias and fairness. Model changes can introduce or remove bias.

AI/ML Change Management Framework

AI/ML Change Management Checklist

• Model version is tagged and tracked (MLflow, Weights & Biases)
• Training data lineage is documented
• Model performance metrics are benchmarked against previous version
• Bias/fairness check is completed
• Explainability test is passed (if required by regulation)
• Security scan of model artifacts (no malicious code)
• Rollback to previous model version is tested
• Monitoring dashboard is updated for new model metrics
• Data protection impact assessment is completed (if processing PII)
• EU AI Act compliance check (if high-risk AI system)

Third-Party and SaaS Vendor Changes

When your SaaS vendor changes something.

The Problem

Your SaaS vendor (Salesforce, AWS, Office 365, GitHub) makes changes:

• Feature updates
• Security patches
• API changes
• Data center moves
• Terms of service changes

You have no control over the change, but you are affected by it.

Third-Party Change Management Process

Vendor Change Notification Template

Subject: [Vendor] Planned Change Notification — Change ID [XXX]

Vendor: [Vendor Name]
Change Type: [Feature Update / Security Patch / API Change / Infrastructure Change]
Planned Date: [Date and Time]
Affected Services: [List of your services affected]

Impact Assessment:
- Business Impact: [Low/Medium/High]
- Security Impact: [Low/Medium/High]
- Compliance Impact: [Low/Medium/High]

Required Actions:
- [ ] Review vendor change notes
- [ ] Test in non-production environment
- [ ] Update internal documentation
- [ ] Brief affected teams

Approval: [Pending/Approved/Objected]

Emergency Change Procedure

Emergency changes need their own, faster route, with full review afterwards.

Emergency Change Triggers

Emergency Change Procedure

T+0:   Incident detected or emergency identified
T+0:   Emergency CAB is convened (on-call team)
T+15m: Impact assessment completed (verbal, documented after)
T+30m: Emergency CAB approves/denies change
T+30m: Change is implemented (with minimal testing)
T+1h:   Smoke test completed
T+2h:   Post-implementation review begins
T+24h:  Full documentation completed
T+1w:   Root cause analysis completed
T+1w:   Process improvement implemented

Emergency Change Documentation (After-the-Fact)

Even emergency changes require documentation. The documentation is completed AFTER the change, within 24 hours.

Failed Changes and Incidents

A change that causes an outage or security problem becomes an incident (A.5.24–A.5.26): raise it, assess whether it is reportable (CERT-In's 6-hour rule, sector regulators), and roll back if the plan says so. Fixes made during an incident go through the emergency change route, with the after-the-fact review above. The person who implements a change should not be its only approver (see the single-person rule in A.8.31).

Worked Example: Log4j Emergency Patch

Worked example (timeline is illustrative): December 2021, the Log4j vulnerability Log4Shell (CVE-2021-44228) is disclosed.

Supplier Change Management (5.22 Integration)

Supplier changes need the same discipline (A.5.22 links here).

Why It Matters

ISO 27001:2022 has TWO change management controls:

• A.8.32: Your internal change management
• A.5.22: Monitoring and review of supplier services (includes supplier changes)

If your supplier changes something, it triggers BOTH controls.

Supplier Change Management Integration

Supplier Change Register

Maintain a separate supplier change register (or section in your main register) that tracks:

Templates and Forms

Change Request Form (Filled Example)

═══════════════════════════════════════════════════════════════
                    CHANGE REQUEST FORM
═══════════════════════════════════════════════════════════════

Change ID:              CHG-2026-0042
Date Submitted:         2026-06-15
Requester:              [Name], Senior Developer
Department:             Engineering

Change Title:           Upgrade PostgreSQL from 14 to 16

Business Justification: 
PostgreSQL 14 reaches end-of-life in November 2026. PostgreSQL 16
provides 30% performance improvement and enhanced security features
including SCRAM-SHA-256 authentication and improved encryption.

Affected Systems:
  - Production database (prod-db-01, prod-db-02)
  - Staging database (staging-db-01)
  - Backup system (automated backups use pg_dump)
  - Application servers (connection string changes required)
  - Monitoring system (PostgreSQL metrics exporters)

Risk Assessment:
  - Business impact if failed: 5 (production outage, data loss)
  - Systems affected: 4 (multiple systems, 500+ users)
  - Reversibility: 2 (rollback possible via point-in-time recovery)
  - Security impact: 2 (improves security posture)
  - Regulatory impact: 3 (affects PCI DSS data store)
  
  Risk Score: 5.2 → MEDIUM (Normal change)

Proposed Implementation:
  Date: 2026-06-20 (Saturday, 2:00 AM — low traffic period)
  Duration: 4 hours
  Window: 2:00 AM — 6:00 AM IST

Testing Plan:
  1. Upgrade staging database (completed 2026-06-10)
  2. Run full regression test suite (completed, 100% pass)
  3. Run performance benchmark (completed, 32% improvement)
  4. Run security scan (completed, no new vulnerabilities)
  5. Test backup/restore on staging (completed, 45 min restore time)

Rollback Plan:
  - Primary: Point-in-time recovery to pre-upgrade snapshot
  - Time to rollback: 45 minutes
  - Rollback tested: Yes (2026-06-12)
  - Data loss risk: 0 (PITR to exact moment before upgrade)

Required Approvals:
  - IT Lead: [APPROVED] 2026-06-15 — Rajesh Kumar
  - Security Lead: [APPROVED] 2026-06-15 — Anjali Mehta
  - Database Admin: [APPROVED] 2026-06-15 — Vikram Rao

═══════════════════════════════════════════════════════════════

Change Log Entry (Filled Example)

═══════════════════════════════════════════════════════════════
                       CHANGE LOG ENTRY
═══════════════════════════════════════════════════════════════

Change ID:              CHG-2026-0042
Status:                 COMPLETED

Implementation Details:
  Implementer:          Vikram Rao, Database Admin
  Start Time:           2026-06-20 02:00 AM IST
  End Time:             2026-06-20 05:30 AM IST
  Duration:             3.5 hours (within 4-hour window)

Verification Results:
  [✓] System operational
  [✓] No errors in logs
  [✓] Performance within parameters (32% improvement)
  [✓] Security controls functioning (SCRAM-SHA-256 active)
  [✓] Monitoring active (metrics flowing)
  [✓] Backups functioning (tested post-upgrade)
  [✓] User access confirmed (500 users tested)
  [✓] PCI DSS scope unchanged

Post-Implementation Review:
  Date: 2026-06-21
  Attendees: [Change manager], [Developer], [DBA], [Service owner]
  
  What went well:
    - Testing in staging was thorough and realistic
    - Rollback plan was tested and ready
    - Communication was clear (all teams notified in advance)
    
  What could be improved:
    - Upgrade took 3.5 hours vs. estimated 4 hours (good)
    - One monitoring exporter needed manual restart (gap in automation)
    
  Lessons learned:
    - Include monitoring exporter restart in upgrade script
    - Update runbook to include post-upgrade monitoring check
    
  Action items:
    - Update PostgreSQL upgrade runbook ([Developer], by [date])
    - Add monitoring exporter restart to CI/CD (Vikram Rao, by 2026-06-30)

═══════════════════════════════════════════════════════════════

Change Management Policy (Template Outline)

═══════════════════════════════════════════════════════════════
              CHANGE MANAGEMENT POLICY
         [Organization Name] — ISO 27001:2022 Annex A 8.32
═══════════════════════════════════════════════════════════════

1. PURPOSE
   This policy defines how [Organization Name] manages changes to
   information systems, services, software, data, and processes to
   ensure information security is maintained.

2. SCOPE
   This policy applies to all changes to:
   - Information systems and infrastructure
   - Software and applications
   - Cloud services and SaaS configurations
   - Data models, schemas, and classifications
   - Security controls and policies
   - Business processes affecting information security
   - Documentation and procedures
   - Physical facilities and hardware

3. DEFINITIONS
   - Standard Change: Pre-approved, low-risk, repeatable
   - Normal Change: Planned, moderate risk, requires approval
   - Major Change: High-impact, complex, requires CAB approval
   - Emergency Change: Critical fix, requires Emergency CAB

4. ROLES AND RESPONSIBILITIES
   [Insert RACI matrix from Section 8]

5. CHANGE MANAGEMENT PROCESS
   [Insert 8-step process from Section 9]

6. CHANGE TYPES AND APPROVALS
   [Insert approval matrix from Section 7]

7. EMERGENCY CHANGE PROCEDURE
   [Insert emergency procedure from Section 15]

8. RECORD KEEPING
   - All changes are logged in the Change Register
   - Records are retained for [3 years / as defined]
   - Change logs are immutable and tamper-proof
   - Records are available for audit review

9. SUPPLIER CHANGE MANAGEMENT
   [Insert 5.22 integration from Section 16]

10. METRICS AND REPORTING
    [Insert metrics from Section 19]

11. TRAINING AND AWARENESS
    - All staff involved in change management are trained annually
    - Change management process is part of security onboarding
    - Emergency change procedures are drilled quarterly

12. POLICY REVIEW
    - This policy is reviewed annually
    - Changes to this policy require CISO approval
    - Last review date: [Date]
    - Next review date: [Date + 1 year]

Approved by: ___________________ Date: ___________
[CISO Name]
═══════════════════════════════════════════════════════════════

Audit Evidence and Auditor Checklist

What Auditors Look For (ISO 27001)

Auditor Checklist (What to Prepare)

□ Change Management Policy exists and is approved (within last 12 months)
□ Change Register covers last 12 months (or audit period)
□ Sample of 10 changes reviewed:
   □ All 10 have change request forms
   □ All 10 have risk assessments
   □ All 10 have approvals from authorized personnel
   □ All 10 have test records (or justification for no testing)
   □ High-risk changes have rollback plans
   □ All 10 have post-implementation reviews (or are in progress)
□ Emergency changes (if any):
   □ Emergency CAB records exist
   □ Post-implementation documentation completed within 24 hours
   □ Root cause analysis completed
□ Change management metrics:
   □ Change success rate tracked
   □ Change-related incidents tracked
   □ Trends analyzed and acted upon
□ Training:
   □ All change management staff trained (records)
   □ Training is current (within last 12 months)
□ Supplier changes:
   □ Supplier change register maintained
   □ Sample of 5 supplier changes reviewed for impact assessment

Common Audit Findings (Non-Conformities)

🎯 Singahi Audit Tip: We prepare clients for 8.32 audits by running a mock audit 4 weeks before the real one. We review the same sample the auditor will review, fix gaps, and document everything. See our audit preparation service.

Metrics and KPIs

Measure the process so you can show it works:

Primary Metrics (Measure Every Change)

Secondary Metrics (Trend Analysis)

Metrics Dashboard (Example)

┌─────────────────────────────────────────────────────────────┐
│                    CHANGE MANAGEMENT DASHBOARD               │
│                         June 2026                            │
├─────────────────────────────────────────────────────────────┤
│  Total Changes: 47    │  Success Rate: 97.9%  ▲ 2.1%        │
│  Emergency: 3 (6.4%)  │  Rollbacks: 1 (2.1%)  ▼ 0.5%        │
│  Incidents: 2 (4.3%)  │  Avg Approval Time: 36 hrs           │
├─────────────────────────────────────────────────────────────┤
│  Changes by Risk Level:                                     │
│  Low: 28 (59.6%)  Medium: 15 (31.9%)  High: 4 (8.5%)        │
│                                                             │
│  Changes by System:                                         │
│  Database: 12  Web App: 15  API: 8  Network: 4  Policy: 8   │
│                                                             │
│  Changes by Type:                                           │
│  Standard: 20  Normal: 24  Major: 3  Emergency: 0           │
├─────────────────────────────────────────────────────────────┤
│  Trending: ↗ Standard changes up 15% (automation working)   │
│            ↘ Emergency changes down 40% (better planning)    │
│            ⚠ 2 post-implementation reviews overdue            │
└─────────────────────────────────────────────────────────────┘

Real Incident Illustrative Scenarios

These are real, publicly reported incidents. The "what a good process would do" notes are our analysis, not findings from the investigations.

Case 1: Equifax (2017), a Known Patch Not Applied

What happened: the Apache Struts vulnerability CVE-2017-5638 was disclosed in March 2017 with a fix available. Equifax's online dispute portal was not patched; attackers exploited it from May and the breach was found in late July. About 147 million people were affected. Investigations by the US Government Accountability Office (GAO-18-559) and the House Committee on Oversight and Government Reform (December 2018) reported that the alert did not reach the people responsible for the system, a later scan did not find the vulnerable application, and an expired certificate had stopped traffic inspection on that network segment for months.

Lessons for 8.32:

1. Critical security patches need an expedited change route with defined deadlines.
2. Change management must be fed by vulnerability management and the asset inventory, so the right owner gets the change.
3. Verify after the change that the vulnerability is actually closed.
4. Changes to security tooling (certificates on inspection devices) are changes too, with owners and expiry tracking.

Case 2: CrowdStrike (July 2024), a Content Update Released Everywhere at Once

What happened: on 19 July 2024 a Falcon sensor content configuration update for Windows caused system crashes; Microsoft estimated about 8.5 million Windows devices were affected. CrowdStrike's root-cause analysis described a mismatch between the fields a new template type expected and what the sensor supplied, which its content validation did not catch. CrowdStrike said it would add staged deployment for these content updates.

Lessons for 8.32:

1. Configuration and content updates are changes, not just code releases.
2. Test in a representative environment, then roll out in stages with monitoring and a hold at each stage.
3. Have a rollback route that works even when the change breaks the system it runs on.
4. Supplier changes that reach your estate need your own controls too (A.5.22): know which of your suppliers can push changes automatically.

Case 3: British Airways (May 2017), Power Work at a Data Centre

What happened: an uncontrolled loss and restoration of power at a data centre near Heathrow damaged IT systems and grounded flights over a bank holiday weekend. Around 75,000 passengers were affected, and BA's parent company IAG put the cost at about £80 million. Reports attributed the failure to how the power supply was disconnected and reconnected.

Lessons for 8.32:

1. Work on facilities that support critical systems (power, cooling) needs change control and a tested recovery plan.
2. Changes that touch resilience and failover need testing under realistic conditions, and post-implementation review is not optional.
3. Update continuity and recovery plans when such infrastructure changes (27002 8.32(i)).

Automation and Tooling Guide

Tooling options:

Tool Selection by Organization Size

GitHub Setup for Change Management

1. Repository Settings → Branch Protection Rules (for main/production):

✓ Require a pull request before merging
  ✓ Require approvals: 2 (for high-risk repos)
  ✓ Dismiss stale PR approvals when new commits are pushed
  ✓ Require review from CODEOWNERS (security team for security files)
  
✓ Require status checks to pass before merging
  ✓ Require branches to be up to date before merging
  
✓ Require conversation resolution before merging

✓ Require signed commits

✓ Require linear history

✓ Include administrators

✓ Allow force pushes: OFF
✓ Allow deletions: OFF

2. Pull Request Template:

3. GitHub Actions for Change Management:

name: Change Management Gate
on:
  pull_request:
    branches: [main, production]

jobs:
  change-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Check PR template completeness
        uses: actions/github-script@v7
        with:
          script: |
            const body = context.payload.pull_request.body;
            const required = ['Change ID', 'Risk assessment', 'Business justification'];
            const missing = required.filter(field => !body.includes(field));
            if (missing.length > 0) {
            }
            
            // Check risk score is filled
            const riskMatch = body.match(/score:\s*(\d+)/);
            if (!riskMatch) {
              core.setFailed('Risk score not provided');
            }
            const risk = parseInt(riskMatch[1]);
            if (risk < 1 || risk > 10) {
              core.setFailed('Risk score must be 1-10');
            }
            
      - name: Require security approval for high-risk changes
        uses: actions/github-script@v7
        if: github.event.pull_request.draft == false
        with:
          script: |
            const body = context.payload.pull_request.body;
            const riskMatch = body.match(/score:\s*(\d+)/);
            const risk = parseInt(riskMatch[1]);
            
            if (risk >= 7) {
              // Check if security team has approved
              const reviews = await github.rest.pulls.listReviews({
                owner: context.repo.owner,
                repo: context.repo.repo,
                pull_number: context.issue.number
              });
              
              const securityApprovals = reviews.data.filter(r => 
                r.state === 'APPROVED' && 
                r.user && 
                r.user.login.startsWith('security-')
              );
              
              if (securityApprovals.length === 0) {
                core.setFailed('High-risk changes (>=7) require Security team approval');
              }
            }

Implementation Roadmap

Phase 1: Foundation (Week 1-2)

Phase 2: Process Rollout (Week 3-4)

Phase 3: Automation (Week 5-8)

Phase 4: Optimization (Week 9-12)

Quick Reference

One-Page Summary: Annex A 8.32 in 60 Seconds

═══════════════════════════════════════════════════════════════
         ISO 27001:2022 ANNEX A 8.32 — QUICK REFERENCE
═══════════════════════════════════════════════════════════════

WHAT: Change management for information systems, software,
      services, data, processes, and documentation.

WHY: Uncontrolled changes cause 70% of production incidents.

9 COMPONENTS:
1. Impact assessment     6. Fallback planning
2. Authorization         7. Record keeping
3. Notification          8. Documentation review
4. Testing               9. Continuity plan update
5. Implementation

4 CHANGE TYPES:
Standard  → Pre-approved, auto-implemented
Normal    → Planned, 3-7 days, 2 approvers
Major     → Complex, 2-4 weeks, CAB approval
Emergency → Critical, < 4 hours, Emergency CAB

RISK SCORE = weighted average (business impact 30%, 
             systems affected 25%, reversibility 20%,
             security impact 15%, compliance impact 10%)

APPROVAL THRESHOLDS:
Risk 1-3:   Team Lead
Risk 4-6:   IT Manager + Security Lead
Risk 7-8:   CISO + CAB
Risk 9-10:  Emergency CAB

EMERGENCY CHANGES:
- Implement first, document within 24 hours
- Emergency CAB approves after implementation
- Root cause analysis within 1 week
- Process improvement within 2 weeks

AUDIT EVIDENCE:
□ Policy exists and approved
□ Change register complete
□ Sample of 10 changes reviewed
□ All changes have request, approval, test, review
□ Emergency changes documented
□ Training records current

KEY METRICS:
- Success rate: > 95%
- Change incidents: < 5%
- Rollback rate: < 3%
- Emergency rate: < 10%

═══════════════════════════════════════════════════════════════

Change Request Form (Minimal Version)

Change ID: ____________    Date: ____________    Requester: ____________

Title: ________________________________________________________________

Type: [ ] Standard  [ ] Normal  [ ] Major  [ ] Emergency

Risk Score: ___/10    (Business: __  Systems: __  Reversible: __  
                       Security: __  Compliance: __)

Affected Systems: ___________________________________________________

Business Justification: _______________________________________________
______________________________________________________________________

Testing Plan: ________________________________________________________

Rollback Plan: _______________________________________________________

Approvals Required:
[ ] IT Lead: ____________ Date: ________
[ ] Security Lead: ________ Date: ________
[ ] CISO: ________________ Date: ________ (if risk >= 7)
[ ] CAB: _________________ Date: ________ (if risk >= 8)

═══════════════════════════════════════════════════════════════

Indian Regulatory Context

DPDP Act 2023 and Change Management

RBI Cybersecurity Framework for Banks

The RBI Cyber Security Framework in Banks (2016) and the Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (2023) expect regulated entities to run a documented change management process. In practice that means:

SEBI CSCRF (2024)

SEBI's Cybersecurity and Cyber Resilience Framework (2024) expects regulated entities to control changes to their IT systems, with testing and approvals. For market-facing systems, stock exchange rules may also require software changes (for example trading or algorithm software) to be tested in exchange mock-trading sessions before use. Check the current exchange circulars that apply to you.

IT Act 2000 (as amended)

Expanded Illustrative Scenarios: Indian Change Management Incidents

Hypothetical scenarios: composite patterns for guidance, not real organisations or verified events.

Scenario 4: Unapproved Change to a Core Banking System

What happens: a bank's IT team changes database settings on the core banking system during business hours to speed up queries, without approval. The change causes a deadlock and the system is down for hours across branches, ATMs and digital channels.

Root causes: no approval for core-system changes; no maintenance window; no staging test; no rollback plan; a developer could change production directly.

Lessons:

• Core-system changes need approval, testing in staging and a tested rollback plan.
• Changes only in approved windows, unless they go through the emergency route.
• Segregation: the person who writes a change does not deploy it unaided (see A.8.31).
• An outage of this kind may also be reportable to the regulator and to CERT-In; check the timelines that apply.

Scenario 5: Payment Integration Released on a Sale Day

What happens: an e-commerce company releases a new payment-gateway integration on its biggest sale day without approval. A race condition charges some customers twice; reconciliation takes days.

Root causes: no blackout period; no approval for payment changes; load testing far below peak; no idempotency (see A.8.26); no monitoring for duplicate payments.

Lessons:

• Blackout periods for peak days (sales, festivals, quarter-end).
• Payment changes get the highest scrutiny and a phased rollout.
• Load-test above expected peak; monitor for duplicates and failures in real time.

Scenario 6: AI Model Updated Without Review

What happens: a health-tech company replaces its diagnostic model without review. The new model performs worse for one patient group, and clinicians notice only after weeks.

Root causes: model changes not treated as major changes; no subgroup testing; no clinical validation; no monitoring for accuracy drift; no model rollback.

Lessons:

• Treat model updates as major changes with validation, subgroup testing and a rollback version.
• Monitor model performance after release.
• Record each model version and its test results.

Continuous Improvement

Change Management Improvement Cycle

┌─────────────────────────────────────────────────────────────┐
│  PLAN                                                        │
│  • Review change metrics and trends                          │
│  • Identify root causes of emergency changes                 │
│  • Benchmark against industry standards                      │
│  • Plan process improvements                                  │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  DO                                                          │
│  • Implement process improvements                            │
│  • Update templates and tools                                │
│  • Train team on changes                                      │
│  • Deploy new automation                                      │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  CHECK                                                       │
│  • Measure improvement effectiveness                         │
│  • Review post-implementation metrics                        │
│  • Gather feedback from stakeholders                         │
│  • Audit the improved process                                 │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  ACT                                                         │
│  • Standardize successful improvements                       │
│  • Document lessons learned                                   │
│  • Update policy and procedures                               │
│  • Communicate changes to organization                        │
└─────────────────────────────────────────────────────────────┘

Improvement Metrics

Annual Improvement Agenda