What “authorized change” means in ISO 27001
ISO 27001 expects you to manage changes in a way that protects confidentiality, integrity, availability, and compliance. In cloud SaaS, that does not mean a CAB meeting for every single deployment. It means the right changes are approved by the right people using a defined process, and the records prove it.
A SaaS change is “authorized” when these are all true:
- the change is requested and tracked
- it is reviewed and approved by an appropriate authority
- risk is assessed at the right level
- the change is executed through a controlled pipeline
- there is traceability from request to code or config to deployment
- post-change validation happened
- emergency changes follow a defined emergency path
Plain-English rule: authorized change in SaaS means controlled delivery with records, not bureaucratic theatre.
The 4 types of SaaS changes (and what evidence each needs)
Auditors do not expect the same paperwork for every deploy. You should not either. What they do expect is that your change evidence scales with risk.
Type A: Standard low-risk changes
Examples: UI text change, minor refactor, low-risk feature toggle
Authorization evidence: PR approval, automated tests, deployment log
Audit expectation: light, but consistent
Type B: Security-impacting changes
Examples: auth logic, access control, encryption settings, logging, export behavior
Authorization evidence: PR approvals, security review note, change record, validation proof
Audit expectation: explicit approvals and extra checks
Type C: Infrastructure and config changes
Examples: IAM changes, firewall rules, WAF updates, DB parameter changes
Authorization evidence: IaC PR approval, peer review, environment promotion record, before/after snapshot
Audit expectation: clear control over who can change cloud settings
Type D: Emergency changes
Examples: zero-day mitigation, outage fix, time-critical hotfix
Authorization evidence: emergency ticket, approval record, hotfix evidence, post-implementation review
Audit expectation: speed is fine, undocumented speed is not
Quick audit check
Can your team trace one production change from request to PR to deploy to validation in under two minutes? If not, your evidence is probably weaker than you think.
What auditors accept as “authorization” in modern SaaS
The good news is that auditors usually accept cloud-native change evidence when it is consistent, enforced, and traceable.
1) Pull request approvals
Pull request review is the most common authorization artifact in SaaS. It works well when review is enforced by platform settings and not left to optional team habit.
Auditor-friendly PR evidence usually includes:
- at least one reviewer, or two for high-risk components
- required CI status checks
- branch protection preventing direct pushes to main
- a linked ticket or issue describing the change
2) Change tickets
Tickets are especially useful when they classify risk, identify owner and approver, record maintenance windows, and link to PRs and deployments.
Practical pattern:
require tickets for infrastructure and security-impacting changes, and allow routine app changes to rely on PR plus CI if that control path is strong.
3) Pipeline controls and deployment logs
Auditors like deployment evidence because it shows the change moved through a controlled process instead of being manually edited into production.
Useful deployment evidence
- CI/CD pipeline logs from build to test to deploy
- release tags or version identifiers
- environment promotion records
- logs showing who triggered the deployment
4) Access control to production changes
You also need to prove that unauthorized people cannot ship to production. This links change management to access control, which auditors usually like because it makes the control environment feel complete.
Good supporting evidence
- list of who can deploy to production
- role-based permissions in CI/CD tooling
- quarterly admin access reviews
- MFA for privileged accounts
Evidence patterns that pass ISO 27001 audits
The easiest way to answer audit questions is to package change evidence into repeatable patterns.
Evidence Pattern 1: Request → PR → Deploy
- ticket or request record
- PR with approval and passing CI
- deployment log showing production release
- post-deploy validation evidence
Evidence Pattern 2: Security-impacting pack
- ticket marked security-impacting
- PR approvals, ideally two for high-risk areas
- security review note or checklist
- test evidence and verification proof
Evidence Pattern 3: IaC-only change control
- IaC PR approval
- plan/apply logs where relevant
- change ticket if your process requires it
- before and after snapshot of the setting
Evidence Pattern 4: Emergency change proof
- emergency ticket created at the time
- approver name and timing
- hotfix or PR evidence
- post-incident review or retrospective approval
The minimum controls auditors look for
| Control |
What “good” looks like |
Why it matters |
| Defined change categories |
low, medium, high, emergency with different approval paths |
proves the process is risk-based |
| Branch protections |
PR required, CI checks required, direct pushes restricted |
turns approval into enforced control |
| Production deployment permissions |
limited deployers, MFA, quarterly access review |
shows unauthorized deployment is harder by design |
| Rollback and validation |
documented rollback and post-deploy checks |
proves the team manages operational risk, not just approval |
| Evidence retention |
sampled change evidence stored for audit period |
lets you answer audit requests quickly |
What does not count as authorized change
- “we talked about it in Slack” with no retained record
- “it was approved in a meeting” with no minutes, ticket, or action trail
- direct production edits outside the normal pipeline
- a policy document with no sampled operating evidence
- CI that exists but is optional
- one person doing every production deployment with no backup or review path
Audit reality:
auditors do not usually punish fast delivery. They punish undocumented delivery and unenforced control.
How to make this easy in SharePoint
If your ISMS lives in SharePoint, the goal is simple: make evidence retrieval painless. You should be able to answer “show me authorized change evidence” in minutes, not hours.
Basic structure
- Change Management Policy
- Change Procedure
- evidence folder by month or quarter
- 3–5 sampled changes per quarter
- emergency change folder with PIR records
Useful tags
- period, such as 2026-Q1
- change type: standard, security, infra, emergency
- system: app, cloud, identity
- control mapping to ISO clauses or internal controls
Next steps
If your team ships quickly and you’re preparing for ISO 27001, you do not need to slow down. You need a clearer approval path and better evidence.
Final takeaway
Authorized change in SaaS is not about adding heavyweight approvals to every release. It is about proving that changes are requested, reviewed, approved, deployed through controlled paths, and validated afterward.
When that evidence is easy to sample and easy to explain, ISO 27001 change management stops feeling vague. It becomes a practical operating control that both delivery teams and auditors can live with.
The goal is not slower delivery. The goal is traceable delivery with evidence that shows the right changes were approved the right way.
Follow Canadian Cyber
Practical cybersecurity + compliance guidance:
