ISO 27001 clauses
One paragraph decides what your ISO 27001 certificate is worth to a buyer.
The scope statement is the shortest document in the ISMS and the one read most widely. Your certification body bases the certificate wording on it, and every buyer who checks your certificate reads it. This page covers what the statement must settle, wording patterns that tend to pass, and what happens when the scope changes.
Back to ISO 27001 services01 · What it must settle
Five things a scope statement has to pin down
Clause 4.3 asks for a written scope built from your context and parties.
- Boundaries
- Which products, services, teams and processes are inside. Name them the way customers know them.
- Interfaces
- Where in-scope activity touches people or systems outside it: a group finance team, a sister company, a customer's own admins.
- Dependencies
- What the scope relies on but does not run: cloud hosting, a payment processor, an outsourced help desk.
- Locations
- Offices and sites in scope, including a note on remote work. Cloud regions can be named where buyers care.
- Exclusions
- What is deliberately outside, with a reason that makes sense to an outsider.
Exclusions here mean parts of the business left out of scope. They are different from Annex A controls marked not applicable in the Statement of Applicability.
02 · Wording patterns
Wording patterns that tend to hold up
Plain nouns, named services, and activities rather than departments.
There is no required template. These are our own illustrative patterns, built from what a reader needs to know. Your certification body has the last word on what appears on the certificate.
| Pattern | Illustrative wording | Why it works |
|---|---|---|
| Activity plus service | “The information security management system supporting the development, operation and support of the AcmePay payroll platform” | Says what is done and for which product |
| Named sites | “...delivered from the Bengaluru office and by remote staff in India” | Locations are explicit, remote work is not hidden |
| Named hosting | “...hosted on a third-party public cloud, whose own controls are outside this scope” | Dependency is visible and honestly bounded |
| Reference to the SoA | “...in accordance with the Statement of Applicability, version 3” | Ties the scope to the control set the auditor tested |
03 · Weak vs strong
A weak scope and a stronger one, side by side
Illustrative: the same company, written two ways.
Weak
“Information security management for AcmePay Pvt Ltd head office IT systems.”
- Names IT systems, not the service customers buy
- Silent on the cloud platform where data lives
- No interfaces or dependencies named
- A buyer cannot tell whether payroll processing is covered
Stronger
“The ISMS supporting the design, development, hosting operations and customer support of the AcmePay payroll platform, delivered from Bengaluru and by remote staff in India, hosted on a third-party public cloud.”
- Product named as customers know it
- Activities cover the whole service life
- Sites and remote work stated
- Hosting dependency stated, with its limit
The stronger version is longer by one line. The extra line is what makes the certificate useful in a vendor review.
04 · Out-of-scope services
What happens to the services you leave out
They carry no assurance from the certificate, and the boundary still needs managing.
Leaving a product out is allowed, and often sensible for a first certification. It has three consequences you should plan for.
- Sales cannot cite the certificate for that product. Questionnaires about it need their own answers.
- Where the excluded part shares people, code or infrastructure with the scope, those links are interfaces, and controls must hold across them. Many teams treat an excluded unit much like a supplier.
- The auditor may ask why the line sits where it does. “It was easier” is weak; “it is a separate legal entity on separate infrastructure” is strong.
05 · Changing the scope
Changing the scope before and after certification
Before Stage 1 it is your call. After the certificate, the certification body has to agree.
| When | What you do | What the certification body commonly does |
|---|---|---|
| Before Stage 1 | Redraw freely; update the risk assessment and SoA to match | Plans audit time from the scope you submit |
| Between Stage 1 and Stage 2 | Tell the body at once; changes may need fresh risk work | May re-plan Stage 2, or repeat parts of Stage 1 |
| After certification, to widen | Bring the new area to the same standard first, with evidence | Commonly audits the extension at a surveillance visit or a separate extension audit |
| After certification, to narrow | Explain why, and update the scope and SoA | Reissues the certificate with the reduced scope |
A scope change is itself a change to the ISMS, so it should go through the planned-change process described in clause 6.
06 · Certificate wording
How your scope reaches the certificate
The body writes the certificate. You can and should check the draft.
The certification body condenses your statement into the scope printed on the certificate, and certificates commonly reference the version of your Statement of Applicability. Buyers compare that line with what they are purchasing, so a vague certificate costs you deals long after the audit.
- Product names match the website. The service a buyer sees on your pricing page appears on the certificate.
- Legal entity is right. The contracting company is the one named.
- Sites are complete. Every in-scope office is listed, and none that are out.
- No overclaiming. Nothing suggests the whole group is certified when it is not.
Sources: ISO/IEC 27001:2022 clause 4.3 (title and purpose, in our own words); ISO/IEC 17021-1 and ISO/IEC 27006 on how certification bodies run audits, named only. All wording patterns and the company are Auditify's own and illustrative.
Scope statements, answered
Can we certify one product and not the others?
Yes, if the boundary is clear and honestly described.
A partial scope is allowed. The statement must make plain which product is covered, and the links between that product and the rest of the company have to be managed as interfaces.
Should the scope name our cloud provider?
Naming the dependency helps; naming the brand is your choice.
Buyers want to know data sits with a third party whose controls you do not run. Saying “hosted on a third-party public cloud” covers that. Some companies name the provider because customers ask; either works if it is accurate.
Does remote work need to be in the scope?
If in-scope people work remotely, say so.
Remote staff handle in-scope information, so remote locations are part of the picture. You do not list homes; you state that remote work is included and show the controls that cover it.
Can the scope be wider than what we certify first?
No. The scope is what gets audited.
Whatever you write is what the auditor samples. Start with the scope you can evidence fully, then widen it at a later audit once the new area is ready.
Draw a boundary your buyers will recognise.
An ISO 27001 gap analysis tests your draft scope against your products, contracts and infrastructure.