Annex A 8.32: Change Management

Annex a 8.32: change management requirement means you must control changes to information processing facilities and systems through a defined process that assesses risk, approves work, tests outcomes, and records evidence. To operationalize it fast, standardize change types, enforce approvals in a ticketing tool, require security impact checks, and retain auditable change records. ¹

Key takeaways:

• Put every production change through documented request, risk/impact assessment, approval, testing, and closure evidence. ¹
• Auditors look for operating discipline: consistent tickets, approvals, testing proof, and traceability from change to deployment and rollback. ¹
• “Emergency change” is not a loophole; it needs expedited approval and after-the-fact review with retained artifacts. ¹

Change management is a security control because most security failures do not start with a “hack”; they start with a change that was risky, unreviewed, poorly tested, or impossible to trace. Annex A 8.32 asks you to treat changes to systems, configurations, and supporting services as controlled events with clear authorization and evidence. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to compliance is to avoid “policy-only” work. Your goal is a repeatable operational workflow that engineers will follow because it is simple, enforced by tooling, and fits delivery realities. You need defined scope (what counts as a change), defined change types (standard/normal/emergency), and a minimum evidence set that is automatically produced by the process. ¹

This page translates the annex a 8.32: change management requirement into a practical checklist: roles, steps, artifacts, audit questions, and common failure modes. It also gives a 30/60/90-day execution plan you can run with IT, Security, and Product teams without redesigning your whole SDLC.

Regulatory text

Excerpt (provided): “ISO/IEC 27001:2022 Annex A control 8.32 implementation expectation (Change Management).” ¹

Operator interpretation: You must establish and operate a controlled process for changes to information processing facilities and systems. “Operate” is the key word. A written procedure is necessary but not sufficient; the organization must consistently apply it, and you must be able to prove that application through records. ¹

What the operator must do:

• Define what constitutes a change and what is in scope (systems, applications, infrastructure, configurations, cloud resources, security tooling, and critical third-party service changes that affect your environment). ¹
• Require risk/impact assessment, approvals, testing, and documented completion for in-scope changes. ¹
• Retain evidence that the process runs as designed and catches exceptions. ¹

Plain-English interpretation (what Annex A 8.32 expects in practice)

You need a single “source of truth” workflow (usually a ticket) for changes, with enough structure to answer four audit questions quickly:

1. Who requested and approved the change?
2. What was changed, where, and why?
3. Was security and operational risk assessed before implementation?
4. Was the change tested, deployed in a controlled way, and closed with results and rollback evidence? ¹

If you can produce that story for a sample of recent production changes, you are typically in good shape for Annex A 8.32 assessment discussions. ¹

Who it applies to (entity and operational context)

Annex A 8.32 applies to organizations implementing an ISMS under ISO/IEC 27001:2022, especially service organizations where system availability, integrity, and confidentiality depend on disciplined operations. ¹

Operationally, it applies to:

• Engineering and DevOps: application releases, infrastructure-as-code, CI/CD pipeline changes, feature flags, dependency upgrades.
• IT operations: endpoint management policies, directory services settings, network device configs.
• Security teams: SIEM rule changes, firewall rule modifications, IAM policy changes, EDR policy tuning.
• Cloud operations: security groups, IAM roles, storage policies, Kubernetes manifests, secrets handling.
• Third parties (as applicable): changes by managed service providers or SaaS admins that materially affect your environment (you may not control their process, but you must control your own admin actions and validate change outcomes). ¹

What you actually need to do (step-by-step)

1) Define “change” and scope it tightly enough to run

Create a one-page scope statement that names:

• In-scope environments (production, staging, shared services).
• In-scope assets (core apps, customer data stores, IAM, network perimeter, logging/monitoring, encryption/key management).
• Out-of-scope examples (personal dev environments) with guardrails. ¹

Practical tip: If teams argue, anchor scope on “could impact confidentiality, integrity, or availability.” Keep it explicit so sampling is defensible in an audit.

2) Standardize change categories and required controls per category

Create a small decision matrix:

Change type	Example	Required pre-approvals	Required testing	Required post-change review
Standard	Pre-approved, low-risk patch to non-critical service	Auto-approval if criteria met	Automated tests	Spot-check or periodic review
Normal	Feature release to production	Peer + service owner; security review if triggers	CI tests + smoke test plan	Closeout notes + monitoring check
Emergency	Sev-1 fix, active incident	Expedited approval (on-call lead); document rationale	Minimum viable tests	Mandatory retrospective and ticket completion

This matrix is what operators follow; your policy should point to it. ¹

3) Build the workflow in your ticketing and deployment tools

Minimum ticket fields that create audit-ready evidence:

• System/service name, environment, change description, business reason.
• Security impact assessment (checkboxes + free text): data exposure, auth changes, network boundary changes, logging impact, encryption/key changes.
• Risk rating (simple: low/medium/high) and required approvers based on rating.
• Implementation plan, test plan, rollback plan.
• Approvals captured in-system (no “approved in Slack” as the primary record).
• Deployment link (CI/CD run, pull request, change set) and monitoring confirmation. ¹

Operational guardrail: Configure your CI/CD so production deploys require a linked change ticket or a tagged PR that references the ticket. This prevents “shadow changes.”

4) Define roles and approval authority (RACI that auditors can follow)

At minimum:

• Change requester/implementer: writes the plan, runs tests, executes.
• Approver(s): service owner or IT manager; add Security approval triggers.
• CAB (optional): only for high-risk or cross-cutting changes; do not create a weekly meeting for every change if you ship daily.
• Emergency approver: on-call lead with documented after-action review requirement. ¹

5) Add security review triggers that are objective

Define triggers that require Security sign-off or security checklist completion, such as:

• IAM policy changes, auth flows, or privileged access.
• Network perimeter changes (firewalls, WAF, security groups).
• Logging/monitoring reductions or SIEM routing changes.
• Changes to encryption, key management, or secrets systems.
• Production data migrations or schema changes affecting sensitive fields. ¹

6) Make emergency changes auditable, not informal

Emergency changes should still generate:

• An emergency ticket created immediately or immediately after stabilization.
• Recorded approver and rationale (what risk was accepted and why).
• Evidence of the minimal testing performed.
• Post-implementation review notes and any follow-up changes. ¹

7) Run a recurring evidence capture routine

This is the control that keeps you assessment-ready:

• Periodically export a sample of closed changes across teams.
• Check for missing approvals, missing test evidence, missing rollback plans, and missing closure notes.
• Log findings and corrective actions. ¹

Where Daydream fits: Daydream can act as the control “binder,” mapping Annex A 8.32 to your documented workflow and scheduling recurring evidence pulls so you are not assembling proof during audit week. ¹

Required evidence and artifacts to retain

Retain artifacts that prove operation, not intent:

• Change management policy/procedure and change classification matrix. ¹
• A population of change tickets for the audit period with approvals, plans, and closure notes. ¹
• Links from tickets to PRs, CI/CD runs, and deployment logs (or screenshots/exports if linking is not possible). ¹
• Test evidence: automated test results, QA sign-off, smoke test checklist completion. ¹
• Emergency change records plus after-action reviews. ¹
• Evidence of periodic oversight: sampling results, exception logs, corrective actions. ¹

Common exam/audit questions and hangups

Auditors and internal reviewers commonly press on:

• Completeness: “How do you know every production change has a record?”
• Approval integrity: “Show me approval before implementation, not after.”
• Security review: “Which changes require Security involvement? How is that enforced?”
• Emergency process: “How many emergency changes occurred, and how were they reviewed?”
• Traceability: “Can you trace a deployment back to an approved change with testing and rollback documented?” ¹

Hangup pattern: teams can show a policy, but the ticket sample has inconsistent fields, missing approvals, and no test/rollback notes. Fix the workflow and templates before you rewrite policy text.

Frequent implementation mistakes and how to avoid them

1. Policy without enforcement.
   Avoid by hardwiring ticket IDs into deploy gates or release checklists. ¹

2. Treating “standard change” as “no evidence required.”
   Avoid by requiring at least automated test output and an auditable record that the change met pre-approved criteria. ¹

3. Emergency changes living in chat threads.
   Avoid by requiring a ticket and retrospective notes as part of incident closure. ¹

4. No security triggers.
   Avoid by defining objective triggers and embedding them in the ticket form. ¹

5. No periodic oversight.
   Avoid by assigning ownership to an operations lead and tracking exceptions to closure. ¹

Enforcement context and risk implications

Public enforcement cases are not provided in the source catalog for this requirement, so this page does not cite specific actions. The operational risk is straightforward: unmanaged changes increase the chance of outages, control failures (access, logging, encryption), and audit findings due to missing traceability. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate foundation)

• Confirm scope: systems/environments and change definition. ¹
• Publish the change type matrix and approval/RACI. ¹
• Update ticket templates with mandatory fields for plan, test, rollback, approvals, and security triggers. ¹
• Start collecting a small weekly sample of closed changes to find gaps. ¹

Next 60 days (Tooling + enforcement)

• Connect deployments to change records (ticket ID in PR and pipeline metadata, or documented manual control if tooling limits exist). ¹
• Implement an emergency change workflow tied to incident management and require after-action review completion. ¹
• Train approvers on what “good” looks like (risk/impact clarity, test sufficiency, rollback realism). ¹

Next 90 days (Prove operation)

• Run a structured internal control check: sample changes across teams, record exceptions, and track remediation to closure. ¹
• Tune triggers and required evidence based on what was missing in samples. ¹
• Centralize evidence in Daydream (or your GRC system) so Annex A 8.32 has a mapped control narrative plus recurring evidence capture. ¹

Frequently Asked Questions

Does Annex A 8.32 apply to code changes, or only infrastructure and IT changes?

Treat it as applying to any change that can affect confidentiality, integrity, or availability of information processing, including application code, configurations, and cloud resources. Scope it explicitly so teams know what must be ticketed. ¹

We deploy multiple times a day. Do we need a CAB meeting for each release?

No. Operationalize approvals through peer review, service owner approval, and automated controls in your SDLC, then reserve heavier review for high-risk changes. Keep the evidence in the same workflow. ¹

What qualifies as an emergency change, and what evidence is required?

Define emergency changes as time-critical work to restore service or address active risk. Require an emergency ticket, expedited approval, minimal test evidence, and a documented post-change review. ¹

Can approvals happen in Slack or email?

They can support coordination, but your primary approval record should be in the change system (ticketing/ITSM) so it is searchable and consistently retained. Audits fail on missing or fragmented evidence. ¹

How do we handle changes made by a third party (MSP or SaaS admin actions)?

Control what you can: your own admin actions, access governance, and validation of outcomes. For third-party performed changes, require notification, record the change reference, and document your acceptance/testing where applicable. ¹

What’s the minimum evidence set auditors expect to see for a sample change?

A change record with description, risk/impact assessment, approval, test/validation evidence, implementation and rollback plan, and closure notes with links to deployment artifacts. Consistency across samples matters. ¹

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index