ISO 27001
ISMS Scope
Internal Audit
Canada
ISO 27001 Internal Audit After an ISMS Scope Change: What Canadian Businesses Must Recheck
Added a new product, office, cloud environment, supplier, business unit, acquisition, or outsourced service? Your ISO 27001 scope may have changed — and the rest of your ISMS may need to change with it.
Your ISO 27001 Scope Changed. Did the Rest of Your ISMS Change Too?
Your ISO 27001 scope was approved six months ago.
Then the business changed.
The written scope may only need a few new lines.
The impact on the ISMS can be much larger.
An ISO 27001 internal audit after a scope change should determine whether the management system changed with the new boundary.
That means more than checking the wording of the scope statement.
You may need to reassess risks, update the Statement of Applicability, add assets and suppliers, review access, assign control owners, update evidence, and expand internal audit coverage.
Quick Answer
What Should You Recheck After an ISO 27001 ISMS Scope Change?
Scope → Context → Interested Parties → Risks → Risk Treatment → SoA → Assets → Suppliers → Access → Evidence → Internal Audit → Management Review
A significant change should trigger more than a document update.
The key question is whether the revised ISMS still reflects the real business, its risks, its dependencies, and its controls.
What Counts as an ISMS Scope Change?
Some changes are obvious. Others happen gradually.
Examples include:
Scope can also shrink.
For example, you may close an office, retire a product, outsource an internal function, or move infrastructure to another provider.
1. Recheck the Written ISMS Scope
Start with the documented certification boundary.
Review:
- Organizations and legal entities.
- Locations.
- Products and services.
- Business processes.
- Teams.
- Systems.
- Cloud platforms.
- Interfaces.
- Dependencies.
- Outsourced activities.
Example
Old scope:
Development, hosting, and support of Product A from the Toronto office.
The company then launches Product B using AWS and an external development partner.
If Product B is now within the certification boundary, changing the scope sentence is only the first step.
2. Recheck Context and Interested Parties
Scope changes can introduce new business and security requirements.
Different customers and security expectations.
Different contractual or regulatory requirements.
New stakeholders, systems, and inherited obligations.
Different dependencies and third-party risks.
Review whether your interested-party information still reflects:
- Customer requirements.
- Legal requirements.
- Contractual obligations.
- Regulatory expectations.
- Supplier dependencies.
- Security commitments.
3. Perform a New Risk Assessment Where the Change Is Significant
This is one of the most important scope-change activities.
For example, a new cloud-hosted service may introduce risks involving:
An old risk assessment may no longer represent the new environment.
4. Review the Risk Treatment Plan and Statement of Applicability
New risks may require new treatment decisions.
That may also affect your Statement of Applicability.
Ask:
- Are previously excluded controls now relevant?
- Do existing controls need to operate differently?
- Are new control owners required?
- Is new evidence required?
- Does the SoA still describe implementation accurately?
For example, a new development environment may affect:
- Secure development.
- Source-code access.
- Vulnerability management.
- Logging.
- Configuration management.
- Supplier controls.
- Cloud security.
5. Update the Asset and Information Inventory
A larger scope usually means more assets.
Do not focus only on obvious hardware.
New SaaS Product
↓
Source Code
↓
Cloud Resources
↓
Databases
↓
APIs
↓
Development Tools
↓
Service Accounts
↓
Customer Data
↓
Backup Systems
If those assets support the new in-scope service, they should be reflected in your ISMS records.
Also understand where information enters, moves, is stored, and leaves the revised scope.
6. Recheck Third Parties and Outsourced Services
Scope changes often create new supplier dependencies.
A new product may depend on:
AWS
Azure
Microsoft 365
GitHub
MSP
Developers
Payment Platform
Support Provider
Review:
- Supplier risk assessment.
- Contracts.
- Security responsibilities.
- Provider access.
- Incident notification.
- Service monitoring.
- Audit evidence.
Has Your ISMS Changed Since Your Last Internal Audit?
A new product, location, acquisition, cloud environment, supplier, or outsourced service can introduce risks that your previous internal audit never tested.
Canadian Cyber can independently test whether your revised scope, risks, controls, and evidence are ready for certification, surveillance, or recertification.
Request Your ISO 27001 Internal Audit Quote from Canadian Cyber
7. Recheck Access Control
New scope usually means new people, systems, or both.
That means access should be retested.
Ask:
8. Update Policies and Procedures Where Needed
Not every scope change requires rewriting every policy.
However, procedures supporting the changed environment should remain accurate.
For example, moving from internal infrastructure to Azure may affect:
- Backup procedures.
- Incident response.
- Change management.
- Access management.
- Logging.
- Vulnerability management.
- Configuration management.
- Supplier management.
9. Reassign Control and Evidence Owners
A scope change may add people who have never participated in the ISMS before.
A newly added product team may now own:
If nobody knows that they own these controls, evidence may disappear by audit time.
Update your responsibility matrix and make sure control owners understand which records must be retained.
10. Update the Internal Audit Program
Do not reuse the previous audit plan without considering the new scope.
If a new business unit, platform, supplier, or cloud environment entered the ISMS, audit coverage should reflect it.
Example
Previous Audit Coverage
Corporate IT + Product A
New Scope
Corporate IT + Product A + Product B + AWS + outsourced development
Repeating the old audit program unchanged could leave important areas untested.
11. Recheck Management Review
Management should understand significant changes affecting the ISMS.
That includes the impact on:
Management review should show that leadership understands the changed environment — not only that someone updated the scope document.
What Should the Internal Auditor Sample After a Scope Change?
Prioritize evidence connected directly to the change.
| Scope Change | Internal Audit Focus |
|---|---|
| New Location | Physical security, networks, employees, assets, access |
| New SaaS Product | Development, cloud, data, vulnerabilities, logging |
| New Cloud Provider | Configuration, access, backups, monitoring, supplier controls |
| Acquisition | Scope, risks, assets, people, systems, inherited controls |
| New MSP | Privileged access, responsibilities, incidents, backups |
| New Development Team | Code access, SDLC, CI/CD, change management |
| New Business Unit | Roles, awareness, assets, access, procedures |
| Scope Reduction | Asset removal, access revocation, data retention, dependencies |
What If You Are Already ISO 27001 Certified?
If your certified scope changes, contact your certification body and confirm what it requires.
Changes involving sites, products, acquisitions, legal entities, or certification boundaries may require additional review.
When Should You Hire an Independent Internal Auditor?
Consider independent support when the scope changed significantly and:
- Your internal team implemented the change.
- Your certification audit is approaching.
- A new acquisition was added.
- A new business unit entered the ISMS.
- New cloud risks were introduced.
- New supplier risks were introduced.
- The previous internal audit did not cover the new environment.
- Your team is unsure which controls need retesting.
- You need objective evidence before surveillance or recertification.
ISMS Scope Change Internal Audit Checklist
Before your next certification assessment, confirm:
☐ Updated ISMS scope is approved.
☐ Interfaces and dependencies are documented.
☐ Context was reconsidered.
☐ Interested parties were reconsidered.
☐ New legal requirements were reviewed.
☐ New contractual requirements were reviewed.
☐ Risk assessment reflects the change.
☐ Risk treatment plan was updated.
☐ Statement of Applicability remains accurate.
☐ New assets were identified.
☐ New information flows were identified.
☐ New suppliers were assessed.
☐ New privileged access was reviewed.
☐ Policies reflect the changed environment.
☐ Procedures reflect the changed environment.
☐ Control owners are assigned.
☐ Evidence owners know their responsibilities.
☐ Internal audit scope covers the change.
☐ Findings have corrective actions.
☐ Management review considers the change.
☐ Certification body was contacted where required.
Has Your ISMS Scope Expanded Since the Last Audit?
Canadian Cyber can independently test whether new products, locations, cloud platforms, suppliers, acquisitions, or business units have been properly incorporated into your ISO 27001 ISMS.
Request Your ISO 27001 Internal Audit Quote from Canadian Cyber
Frequently Asked Questions
Does every small ISMS change require a full new internal audit?
Not necessarily. Use a risk-based approach. A minor administrative change may require limited review, while a new business unit, cloud environment, acquisition, or customer-facing product may justify substantial additional audit testing.
Does an ISO 27001 scope change require a new risk assessment?
Significant changes should trigger risk reassessment so that new threats, vulnerabilities, assets, suppliers, access requirements, and dependencies can be evaluated.
Do we need to update the Statement of Applicability?
Review it whenever the scope changes. If new risks require new or different control decisions, update the SoA and related risk-treatment information.
Can we wait until the next annual internal audit?
That depends on the significance and timing of the change. If the new scope will be included in an upcoming certification, surveillance, or recertification assessment, waiting may leave too little time to identify and correct gaps.
Do we need to tell our certification body about the scope change?
If you are already certified and the change affects the certified scope, sites, legal entity, or other certification details, contact your certification body and follow its requirements.
Can an ISO 27001 scope-change internal audit be completed remotely?
Often, yes. Systems, access, cloud evidence, suppliers, risks, policies, and interviews can frequently be reviewed remotely. Physical locations or controls may still require onsite verification.
When should we schedule the internal audit after a scope change?
Schedule it early enough to identify gaps, implement corrective actions, verify important fixes, and prepare evidence before the next certification assessment.
The Takeaway
An ISMS scope change should trigger more than a document update.
The real question is:
Recheck:
A strong scope-change review follows the change from beginning to end:
Scope Change
↓
Risk Assessment
↓
Control Decisions
↓
Implementation
↓
Evidence
↓
Internal Audit
↓
Corrective Action
That gives your organization stronger assurance before certification, surveillance, or recertification.
Has Your ISO 27001 Scope Changed?
A new location, product, cloud platform, acquisition, supplier, business unit, or outsourced process can introduce risks your previous internal audit never tested.
Canadian Cyber can help independently test:
- Your revised ISMS scope.
- New risks and treatment decisions.
- Statement of Applicability updates.
- New assets and information flows.
- New suppliers and outsourced services.
- Access and privileged roles.
- Control and evidence ownership.
- Updated internal audit coverage.
- Corrective-action readiness.
Request Your ISO 27001 Internal Audit Quote from Canadian Cyber
Stay Connected With Canadian Cyber
Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, certification readiness, risk management, scope changes, and ISMS improvement.
