What Clause 4.3 Requires
Clause 4.3 requires the organization to establish the scope of the ISMS by determining its boundaries and applicability — which parts of the organization, which services, which locations, and which assets the management system covers. Three inputs must be considered when drawing that boundary: the external and internal issues identified under Clause 4.1, the interested-party requirements determined under Clause 4.2, and the interfaces and dependencies between activities the organization performs itself and activities performed by other organizations.
Uniquely within clause 4, the output here is mandatory documented information: the scope must exist as a controlled document. In practice that document carries unusual weight, because the scope statement printed on your certificate is drawn from it — it defines exactly what your certification means to every customer who reads it, and it is the first thing a certification auditor examines at Stage 1.
Why This Clause Exists
To draw a deliberate, defensible boundary around the ISMS — making explicit what the management system (and ultimately the certificate) covers, what it does not, and how the seams with everything outside are controlled.
What This Really Means
Scope is the fence around your certificate. Everything inside the fence must meet clauses 4–10 and the applicable Annex A controls; everything outside is invisible to the certification — including to every customer and procurement team that reads your certificate scope line before accepting it as assurance. Drawing that fence is the single most consequential design decision in an ISO 27001 program.
The clause names the three inputs for the decision. The 4.1 issues and 4.2 requirements tell you what the scope must serve — if certification exists because enterprise customers demand it for your SaaS platform, a scope that omits the platform production environment defeats the purpose. The third input is the one that separates real scoping from wishful scoping: interfaces and dependencies. Whatever your in-scope operation relies on — cloud providers, outsourced development or support, a parent company supplying shared IT, identity, or HR services — either comes inside the fence or must be identified, documented, and controlled across it.
Exclusions are where most scoping errors live, so the rules are worth stating plainly. You exclude organizational territory — business units, locations, services — never requirements: clauses 4–10 apply in full to whatever is in scope, and Annex A applicability is justified control by control in the Statement of Applicability, not in the scope document. You also cannot exclude things your in-scope operation depends on: the laptops your developers use, the network your in-scope office runs on, the HR process that screens in-scope staff. Scoping a single business unit is legitimate; a scope drawn to dodge the hard parts is the carve-out trap — a certificate that says less than your sales team claims it does, which is a reputational incident waiting for a customer who reads carefully.
For auditors, the heart of 4.3 is defensibility: a documented boundary that visibly responds to context and requirements, names its interfaces, and survives the separability question — can what you excluded genuinely be excluded, or do shared systems and people drag it back in?
Why It Matters
Scope errors are the most expensive category of ISMS mistake because they compound silently. Too broad, and every clause obligation and control multiplies across territory that did not need certifying — audit days, evidence load, and internal friction all scale with the fence. Too narrow, and the certificate fails its commercial purpose: enterprise procurement teams read scope statements, and a certificate that covers one office or an internal function while the product runs elsewhere gets rejected — after you have paid for it.
The certification mechanics raise the stakes further. Scope is examined first at Stage 1, and an undocumented, vague, or indefensible scope is a Stage 1 finding that typically blocks progression to Stage 2 until resolved. The scope text on the certificate is drawn from your scope document; misalignment between that text, operational reality, and your public claims can surface at surveillance as a nonconformity — and misrepresenting what a certificate covers is grounds for suspension with most certification bodies.
- •A certificate customers reject – Procurement reads the scope line; if the service they buy is not in it, your certification answers a question nobody asked
- •Unbounded audit and evidence cost – Every location, unit, and system inside the fence carries clause and control obligations forever after
- •Hidden interface risk – Undeclared dependencies (outsourced helpdesk, parent-company IT, shared identity) mean uncontrolled seams — and auditors specifically hunt for them
- •Stage 1 blockage – A missing or indefensible scope document stalls certification at the first gate
- •Misleading-claim exposure – When sales says "we are ISO 27001 certified" and the certificate covers one platform at one site, the gap is a complaint to the certification body waiting to happen
Regional Compliance Context
A scoping pattern specific to India's delivery industry: certificates scoped to a named campus or delivery center ("services delivered from the Bengaluru and Pune facilities") are common and accepted — but the interfaces with an overseas headquarters or group IT must be documented with the same rigor as any supplier seam, and remote-work reality should be stated explicitly rather than left implied by an office address. Note also that law does not follow your scope: CERT-In reporting directions and DPDP Act obligations attach to the legal entity and to India-connected systems regardless of what the ISMS covers, so a narrow certificate never narrows regulatory exposure.
In the Gulf, government and large-enterprise buyers increasingly expect the certificate scope to cover the in-country operation serving them, and Saudi PDPL data-residency expectations can force specific hosting locations into scope.
Documented Information Required
ISMS Scope document
MandatoryThe one mandatory document of clause 4: a controlled, approved statement of the services, organizational units, locations, and key assets the ISMS covers, with boundary rationale and identified interfaces and dependencies. The certificate scope text is derived from it, so precision here is commercial, not just clerical.
Interface and dependency register or diagram
RecommendedA register or architecture diagram showing every point where data, systems, or services cross the ISMS boundary — cloud providers, outsourced functions, group shared services — and how each crossing is controlled. The strongest Stage 1 packs pair the scope statement with this artifact.
In-scope asset inventory extract
RecommendedThe slice of the A.5.9 asset inventory covering in-scope systems and information, demonstrating that the words of the scope map to a concrete, owned asset list. Auditors routinely test scope claims against the inventory.
See the full ISO 27001 mandatory documents checklist for every document and record the standard requires.
How to Write Your ISMS Scope Document
The scope document is short — usually two to six pages — and disproportionately consequential: it decides what your certificate will say, what your audits will cover, and whether the certification you are buying answers the question your customers are asking. This guide covers the structure that works, the boundary decisions that matter, the drafting mistakes that recur, and what a Stage 1 auditor does with the document you hand over.
Start from What the Certificate Must Cover
Work backward from the reason certification is happening. List the customers and deals that ask for ISO 27001, identify exactly which services and platforms they buy, and treat that as the minimum viable scope — the certificate must let those customers' procurement teams tick their box.
Then choose between the two honest strategies. Small-scope-first certifies one product, platform, or delivery unit now and extends scope at later surveillance or recertification audits; it suits larger organizations where one division faces customer pressure today. Whole-organization scope suits companies — most under roughly 150–200 people — where teams, networks, and identity systems are so interconnected that drawing an internal fence costs more than including everything: the fence itself (separate access domains, network segregation, split processes) has to be built and evidenced before it can be defended.
The Anatomy of a Good Scope Statement
The internal scope document and the certificate line are different artifacts. The document needs enough precision to audit against; the certificate line needs one or two sentences a customer can parse.
A complete scope document covers:
- •Services and products – the offerings the ISMS covers, named the way customers know them
- •Organizational units and people – which teams and roles are inside, including contractors
- •Locations – offices, delivery centers, data-center or cloud regions, and an explicit statement about remote workers
- •Technology and assets – the platforms, environments, and asset groups that deliver the in-scope services
- •Interfaces and dependencies – everything in-scope operations rely on across the boundary
- •Boundary rationale – why the fence sits where it does, referencing the 4.1 issues and 4.2 requirements that shaped it
The certificate line then compresses this: the ISMS covering a named set of services, delivered by named units from named locations, in accordance with the Statement of Applicability at a stated version. Certification bodies print an SoA reference alongside the scope, so keep the two synchronized.
Define Interfaces and Dependencies Explicitly
This is the input drafters skip most and auditors probe hardest. Inventory every point where your in-scope operation depends on something outside the fence: cloud and hosting providers, outsourced development, support, or SOC services, a parent or sister company supplying IT, identity, HR, or facilities, and any customer-managed components your service connects to.
For each interface, record three things: what crosses it (data, access, infrastructure, people), who controls which side, and which mechanism governs the seam — supplier agreements under A.5.19 and A.5.20, intercompany agreements treated with the same rigor, transfer rules, technical controls. An interface that appears in your architecture but not in your scope documentation is the classic Stage 1 observation, and at Stage 2 it becomes a question about whether your risk assessment covered the seam at all.
Exclusions: What You Can and Cannot Leave Out
You exclude organizational territory, never requirements. Clauses 4–10 apply in full to whatever sits inside the fence — there is no such thing as "we excluded internal audit". Annex A control applicability is decided control by control in the SoA with justification; the scope document is not where controls get excluded.
Within those rules, scoping a single business unit, platform, or location is legitimate — but two realities constrain it. First, separability: you cannot exclude what in-scope operations depend on. The laptops your in-scope engineers use, the office network they sit on, the HR screening that hires them, the shared identity provider they log in with — dependence either drags these inside or forces a controlled, documented interface. A shared Active Directory or IdP is the most common boundary-breaker in practice.
Second, the carve-out trap: a scope drawn to dodge the hard parts produces a certificate that says less than your organization claims it does. If the certificate covers one delivery center and sales tells customers "we are ISO 27001 certified" company-wide, the mismatch is discoverable by any customer who requests the certificate — and certificate misuse complaints go to the certification body.
Common Drafting Mistakes
- •Scope too narrow to matter – covering the security team, one office, or an internal function while the revenue-bearing service lives elsewhere; the certificate verifies something, but reassures nobody
- •Certificate line as the whole document – one sentence with no locations, assets, units, or interfaces gives auditors nothing to audit against and customers nothing to rely on
- •Mismatch with public claims – website badges, sales decks, and security-questionnaire answers asserting broader certification than the scope supports
- •Forgotten remote workforce – a scope naming one office when half the in-scope team works from home; state the remote-working boundary explicitly
- •Unversioned, unapproved text – the scope is mandatory documented information and must carry Clause 7.5 document control: version, approval, review history
- •Static scope in a moving company – acquisitions, new platforms, and new delivery locations that never trigger a scope review leave the certificate describing a company that no longer exists
What Auditors Check at Stage 1
Stage 1 is substantially a scope review. Expect the auditor to verify that the scope exists as controlled documented information; that the boundary visibly responds to your 4.1 issues and 4.2 requirements rather than to convenience; that interfaces and dependencies are identified and someone can explain how each is governed; and that the scope is consistent with the SoA, the risk assessment, and the asset inventory — those four documents get read together.
They will also test separability wherever you excluded territory: can the excluded units genuinely operate independently of in-scope systems and people, or does shared infrastructure collapse the boundary? Finally, they draft the certificate scope text from your document and confirm audit logistics — sites, sampling, audit days — against it. A precise scope document makes that conversation short; a vague one converts it into findings.
How to Implement Clause 4.3
Identify the Certification Driver and Draft Candidate Boundaries
Establish why certification is happening — which customers, markets, or regulators require it, and for which services. Draft two or three candidate scopes (single platform, business unit, whole organization) and compare them on audit cost, evidence burden, separation effort, and the commercial value of the resulting certificate.
Apply the 4.1 and 4.2 Inputs
Test each candidate boundary against your context analysis and interested-party requirements: data-residency commitments, regulator expectations, and customer contracts often force specific services, locations, or environments into scope. Record which issues and requirements drove the final boundary — that rationale is what makes the scope defensible at Stage 1.
Map Every Interface and Dependency
Inventory what the in-scope operation relies on outside the boundary: cloud and hosting providers, outsourced functions, group shared services (IT, identity, HR, facilities), and customer-managed components. For each, document what crosses the seam, who controls which side, and the governing mechanism — contract, intercompany agreement, or technical control.
Test the Boundary for Separability
For every exclusion, verify genuine independence: separate networks, separate identity domains, separate management. Shared infrastructure — one Active Directory, one office network, one HR process — either pulls the excluded territory in or demands a controlled, documented interface. Fix the boundary now rather than during Stage 1.
Write the Scope Document and the Certificate Line
Produce the internal document — services, units, locations, assets, interfaces, rationale — and distill the one-to-two-sentence certificate line from it. Check the line against what sales and your website claim; the certificate must support your public statements, not contradict them.
Approve, Version, and Control It
Obtain top-management approval and place the document under Clause 7.5 document control with version history and review dates. Align the asset inventory (A.5.9) and the SoA to the final boundary so the three artifacts tell one consistent story.
Re-examine Scope on Every Significant Change
Make scope a standing management review consideration and define triggers — acquisitions, new locations or delivery centers, new platforms, major outsourcing decisions. Material changes should reach your certification body before the next surveillance audit, since scope extensions and reductions follow a defined process with most CBs.
Audit Evidence
During Stage 1 and Stage 2 of your ISO 27001 certification audit, auditors will expect the following evidence to demonstrate conformity with Clause 4.3:
Documentation
- Approved, version-controlled ISMS scope document stating services, units, locations, assets, and boundaries
- Boundary rationale referencing the 4.1 issues and 4.2 requirements that shaped it
- Interface and dependency register or architecture diagram covering every boundary crossing
- Asset inventory aligned to the stated scope
- Management review minutes showing scope was reconsidered when the business changed
Interviews
- Top management on why the boundary sits where it does and what was deliberately excluded
- ISMS manager on how interfaces and dependencies across the boundary are governed
- Owners of boundary services — the manager of an outsourced function or of group IT — on how the seam operates in practice
Observations
- Auditor compares the scope statement with observable reality: people, locations, platforms, and the systems in actual use
- Walk-through of one interface to verify data and access cross the boundary the way the documentation claims
- Cross-check of the scope text against the SoA, the risk register, and public certification claims on the website and in sales material
Practitioner Insights
Scope statements get written for sales and audited against reality, and the gap between those two is where certifications get hurt. The pattern I see repeatedly: a certificate covering "the ISMS for the SaaS platform" while incident response, HR screening, and the laptops developers use all belong to an out-of-scope corporate function with no documented interface. Separability is the question certification auditors are trained to push on. My rule for clients: every dependency is either inside the fence or governed across it by a written, evidenced mechanism — there is no third state.
For companies under about 150 people I almost always recommend whole-organization scope, and it surprises them. A narrow scope looks cheaper until you price the fence: separate access domains, network segregation, split processes, and a pile of interface evidence — all built and maintained just to keep the auditor out of rooms that were never the expensive part anyway. The other habit worth forming early is writing the certificate line for the reader: pull up the security questionnaires your customers actually send and draft a scope line that answers their question in their vocabulary.
Common Challenges & Solutions
Challenge
The organization wants to certify one product or business unit, but everything shares one network, one identity provider, and one IT team.
Solution
Choose honestly between widening the scope and building real separation. If the narrow boundary stays, the shared services become documented interfaces: define what crosses, apply controls at the seam, and prepare evidence that the separation works — because Stage 1 will test exactly that. In genuinely interwoven companies, including the shared estate is usually cheaper than fencing it off.
Challenge
Sales and the website claim company-wide certification while the certificate covers a single platform or site.
Solution
Align the claims in one direction or the other: extend scope at the next audit cycle to match the claim, or correct the claim to match the certificate. Put the exact certificate scope line into the sales enablement pack and the security-questionnaire answer bank, and have marketing route certification statements through the ISMS owner before publication.
Challenge
Dependencies on a parent or sister company — shared IT, identity, HR — exist but appear nowhere in the scope document.
Solution
Treat intercompany dependencies with supplier-grade rigor: record each in the interface register, put an intercompany agreement or documented service arrangement behind it (the A.5.19/A.5.20 pattern), and reference them in the scope document. Group structures are not exempt from the interfaces-and-dependencies requirement, and auditors know to ask.
Challenge
The company grew — acquisitions, new offices, new platforms — and the scope document still describes last year's organization.
Solution
Define scope-change triggers (acquisition, new location, new product line, major outsourcing) and make scope a standing management review item so drift gets caught on cadence. Notify the certification body of material changes ahead of surveillance: scope extensions are a routine process when planned, and a finding when discovered.
Challenge
Teams try to handle Annex A exclusions in the scope document, or to exclude requirement clauses they find burdensome.
Solution
Keep the two mechanisms separate. The scope document excludes organizational territory — units, sites, services. Control applicability is decided per control in the Statement of Applicability with justification under Clause 6.1, and clauses 4–10 can never be excluded for anything in scope. A scope document that tries either move is a guaranteed finding.
