Change management

ISO/IEC 27017 Clause 12.1.2 requires you to control any change that could affect information security, including cloud configuration, deployments, and infrastructure changes. To operationalize it, you need a documented change process with risk assessment, approvals, testing, controlled implementation, and auditable evidence across both your organization and relevant cloud provider/customer touchpoints.

Key takeaways:

• Scope includes organizational/process changes and technical changes, with explicit attention to cloud configurations and deployments.
• Auditors will look for consistent change records: security impact, approvals, testing, rollback, and post-change verification.
• The hard part is shared responsibility; define who approves, implements, and validates changes across CSP and customer teams.

“Change management” under ISO/IEC 27017 is not a DevOps preference or an ITIL checkbox. It is a security control: changes that can affect confidentiality, integrity, or availability must be controlled so you don’t introduce vulnerabilities, misconfigurations, outages, or compliance gaps by accident.

For a Compliance Officer, CCO, or GRC lead, the quickest win is to turn this requirement into a small set of non-negotiables that apply everywhere: a standard change record, a security impact check, defined approvals, and evidence that the change was tested and verified. Then map those non-negotiables to how engineering actually ships work (CI/CD, infrastructure-as-code, feature flags, emergency changes) and how cloud changes happen (IAM, security groups, storage policies, Kubernetes changes, SaaS admin settings).

ISO/IEC 27017 also forces a shared-responsibility view. Cloud Service Providers and Cloud Service Customers both have change risks, and both need coordination on changes that could impact security. Your goal is to prevent “silent changes” and to prove control operation with artifacts you can produce on demand.

Regulatory text

Requirement (operator meaning): You must control changes that affect information security, including changes to cloud service configurations and deployments. That means you define a change process, apply it consistently, and retain evidence that each security-relevant change was assessed, approved, tested, implemented in a controlled way, and reviewed. ¹

Regulatory excerpt: “Changes to the organization, business processes, information processing facilities and systems that affect information security shall be controlled.” ¹

Plain-English interpretation (what the requirement really demands)

You need a repeatable way to prevent security-impacting changes from being made ad hoc.

“Controlled” should translate into these operational outcomes:

• Visibility: you can identify what changed, who changed it, when, and why.
• Risk awareness: you evaluate security impact before implementation.
• Authorization: the right people approve based on risk (not seniority).
• Quality gates: changes are tested and reviewed using defined criteria.
• Safe execution: you have a plan to implement, monitor, and roll back.
• Cloud coverage: the same discipline applies to IAM, network rules, encryption settings, logging, and deployment pipelines, not just on-prem servers.

Who it applies to (entity and operational context)

This requirement applies to:

• Cloud Service Providers (CSPs): organizations providing cloud services where platform changes, infrastructure updates, and configuration baselines can affect customer security. ¹
• Cloud Service Customers: organizations consuming cloud services where tenant configuration, deployments, identity policies, and integration changes can affect security. ¹

Operational contexts that routinely fall in scope:

• CI/CD releases, hotfixes, and infrastructure-as-code updates
• Cloud console/admin changes (IAM roles, MFA policies, firewall/security groups, storage public access settings)
• SaaS configuration changes (SSO settings, admin roles, audit logging toggles)
• Organizational or business process changes that alter access paths or data handling (outsourcing, new third parties, new support workflows)

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

Use this as a minimum operating procedure. You can scale the depth based on risk, but don’t skip steps for “small” changes without a defined rule.

1) Define “security-impacting change” and scope

Create a short scoping standard that classifies changes into:

• Standard changes: pre-approved, low-risk, repeatable (example: routine patching with proven rollback).
• Normal changes: require risk review and approval before execution.
• Emergency changes: expedited path with after-the-fact review and tighter evidence requirements.

Include cloud-specific examples in scope language: IAM policy edits, network routing changes, disabling logs, encryption setting changes, production secrets rotation, changes to CSP-managed services configuration.

2) Establish a single change intake and record format

Pick one system of record (ticketing system, change module, or GRC workflow). Require fields that auditors care about:

• Requestor, system/service, environment, change type
• Business justification
• Security impact assessment (what security properties could change)
• Testing/validation plan
• Implementation plan and rollback plan
• Approver(s) and approval timestamp
• Evidence links (PR, pipeline run, test results, monitoring screenshots, config diff)

If you support both CSP and customer roles, include a field for shared-responsibility owner: “CSP-owned,” “customer-owned,” or “shared,” plus a named contact.

3) Embed security impact assessment as a gate

Your security impact assessment should answer, in plain terms:

• Does this change modify identity/auth, network exposure, data protection, logging/monitoring, or availability controls?
• Does it create or expand internet exposure?
• Does it change encryption, key management, or secrets handling?
• Does it touch regulated or sensitive data flows?

Keep it lightweight for low-risk changes, and require deeper review for changes that alter access controls, perimeter rules, or audit logging.

4) Define approval rules that match risk

Write approval rules that engineers can follow without debate:

• Normal change approvals: service owner + security reviewer for defined high-risk categories (IAM, network exposure, logging, encryption).
• Segregation of duties: the implementer should not be the only approver for high-risk changes. If your org is small, use compensating control: independent review post-implementation with documented sign-off.

5) Require pre-production testing and peer review

For code and IaC:

• Require pull request review and automated checks.
• Require evidence of successful pipeline run for the deployment artifact. For console-based changes (the risky ones):
• Require either an IaC conversion plan or a documented screenshot/config export before and after, with reviewer sign-off.

6) Control implementation: planned windows, comms, and monitoring

For production changes:

• Communicate expected impact to stakeholders (including customers if you’re the CSP and it affects them).
• Monitor during and after change. Define what “success” means (service health, error rates, security alerts baseline).
• Execute rollback if predefined failure conditions occur.

7) Post-change verification and closure

Close the change only when you can show:

• Change implemented as approved (no scope creep)
• Security controls still function (logging still on, alerts still firing, access still least-privilege)
• Any incidents or near-misses documented
• Lessons learned captured for repeat issues

8) Coordinate CSP/customer changes explicitly

Where responsibility is shared, define:

• How customers are notified of CSP-side changes that can affect security posture
• How customers request changes (and what approvals the CSP expects)
• What security-impacting changes require joint review (example: enabling new integrations, changing logging sinks, changing identity federation settings)

This is where many programs fail: changes happen, but no one can show who accepted the risk on the other side.

Required evidence and artifacts to retain

Auditors will not accept “we follow a process” without proof. Retain:

• Change management policy and change classification standard
• Role/approval matrix (who approves what)
• Change records (tickets) with required fields completed
• Security impact assessments (embedded in tickets or attached forms)
• PR reviews, code diffs, and IaC plan outputs (where applicable)
• Testing evidence (unit/integration results, staging sign-off)
• Deployment logs (CI/CD job logs) and release notes
• Rollback plans and evidence of execution if rollback occurred
• Post-change verification evidence (monitoring checks, alert validation)
• Emergency change records with retrospective review and approvals

Practical tip: for cloud configuration changes, keep before/after configuration snapshots or exported policies, plus change rationale.

Common exam/audit questions and hangups

Expect these questions, and prepare “show me” answers:

• “How do you define a security-impacting change, and who decides?”
• “Show a sample of production changes and evidence of approvals and testing.”
• “How are emergency changes handled, and where is the after-action review?”
• “How do you control cloud console changes versus IaC-controlled changes?”
• “How do you ensure changes to logging, IAM, and network rules receive security review?”
• “How do you coordinate changes between cloud provider responsibilities and customer responsibilities?”

Hangups that trigger findings:

• Inconsistent fields across change tickets
• Approvals after implementation
• No evidence of testing or verification
• No story for console changes (“tribal knowledge” execution)

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating change management as only releases.
  Fix: explicitly include cloud configuration, IAM, logging, and network controls in scope.
• Mistake: A single generic approval for everything.
  Fix: risk-based approvals, with security review required for defined categories.
• Mistake: Emergency process becomes the default.
  Fix: require retrospective review and track patterns; convert repeat emergencies into standard changes.
• Mistake: No linkage between tickets and technical evidence.
  Fix: require artifact links (PR, pipeline run, config diff) before closure.
• Mistake: CSP/customer coordination is implied, not documented.
  Fix: add shared-responsibility fields and notification requirements to the change workflow.

Enforcement context and risk implications (what goes wrong)

No public enforcement cases were provided in the source catalog for this requirement, so don’t anchor your program on specific penalties. Operationally, weak change control increases the chance of misconfigurations, access control drift, logging gaps, and outages. Those issues turn into security incidents and audit findings quickly because the evidence trail is thin.

Practical execution plan (30/60/90)

Use a fast, operator-focused rollout. Adjust sequencing based on your release cadence and cloud footprint.

First 30 days (stabilize and define)

• Publish change policy, scope, and change types (standard/normal/emergency).
• Implement a single change record template with mandatory security-impact fields.
• Define high-risk change categories requiring security approval (IAM, network exposure, logging, encryption).
• Identify where cloud changes happen today (IaC repos, CI/CD, console paths) and name owners.

Next 60 days (embed in workflows)

• Integrate change records with engineering workflow (PR template, pipeline evidence links).
• Implement approval matrix in the ticketing/work management tool.
• Create a console-change procedure (pre/post evidence, independent review, and migration plan to IaC where feasible).
• Start monthly sampling: pick recent changes and verify evidence completeness.

Next 90 days (prove operation and tighten control)

• Run a tabletop exercise for an emergency change and require retrospective review artifacts.
• Define CSP/customer change notification and coordination triggers if applicable to your role.
• Track exceptions (missing evidence, late approvals) and remediate with coaching and tooling.
• Consider using Daydream to standardize evidence capture, map change records to ISO/IEC 27017 requirements, and keep an audit-ready trail without chasing teams for screenshots and links.

Frequently Asked Questions

Do we have to control “business process” changes too, or only IT changes?

Yes, if the change can affect information security. Examples include outsourcing support, changing onboarding/offboarding steps, or altering how sensitive data is handled in operations.

Are cloud console changes automatically non-compliant?

No, but they are hard to evidence and easy to bypass review. If you allow them, require pre/post configuration evidence, defined approvals, and a plan to move repeatable changes into infrastructure-as-code.

What counts as “controlled” for ISO/IEC 27017 change management?

A consistent process that covers security impact assessment, approvals, testing, controlled implementation, and post-change verification, with records you can produce on demand. ¹

How should we handle emergency changes without failing audits?

Permit an expedited path for urgent fixes, but require documentation, named approvals as soon as practical, and a retrospective review that confirms security controls were not degraded.

We’re a small team; how do we handle segregation of duties for approvals?

Use an independent reviewer when possible. If that’s not feasible, document a compensating control such as post-implementation review by someone outside the implementer chain, with evidence attached to the change record.

What evidence do auditors ask for most often?

A sample of recent production changes with tickets, approvals, security impact notes, testing results, deployment logs, and post-change verification. Cloud config changes often require extra evidence like policy exports or configuration diffs.

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services