The scope statement is the certificate

"We are ISO 27001 certified" gets treated as a boolean, by the vendors who say it and by most of the buyers who hear it. It is not one. A certificate does not certify a company; it certifies a management system whose boundaries the company drew itself, and the authoritative statement of those boundaries a buyer will ever see is the scope stated in the certification documents, the sentence that, in our experience, few buyers stop to read. Two organizations can hold certificates from the same accredited body, display the same badge, and be making entirely different claims: one has certified the system that develops and runs the product its customers buy, the other has certified the corporate IT function at a headquarters address the customer will never interact with. Both are "ISO 27001 certified." Only one of those certificates directly establishes that the thing being sold is inside the boundary.

Our position: the scope statement is the certificate, in the sense that it carries the substantive claim the document makes, and teams that set scope by asking "what is the smallest system we can defend to an auditor" are optimizing the wrong variable. Scope is a customer-trust decision that happens to have an audit attached, not an audit-cost decision that happens to be visible to customers.

The standard is permissive on purpose

ISO/IEC 27001:2022 (third edition, published 2022-10-25; the climate-action amendment Amd 1:2024, published 2024-02-23, leaves the clause untouched) handles scoping in clause 4.3. The organization determines "the boundaries and applicability" of the ISMS to establish its scope, and in doing so it must consider the external and internal issues from clause 4.1, the requirements of interested parties from clause 4.2, and "interfaces and dependencies between activities performed by the organization, and those that are performed by other organizations." The scope must be available as documented information. That is the whole clause.

Notice what it does not say. Nothing requires the scope to cover the entire legal entity, every office, or the flagship product. The standard deliberately lets a hospital certify its records department, a conglomerate certify one subsidiary, a software company certify one platform. This permissiveness is a feature: it makes certification reachable in phases and lets organizations put assurance where the risk actually sits.

The certification side of the system then does something important with that freedom. ISO/IEC 17021-1:2015 (published 2015-06-08), the standard accredited certification bodies themselves must conform to, requires in clause 8.2.2(f) that certification documents identify "the scope of certification with respect to the type of activities, products and services as applicable at each site without being misleading or ambiguous." ISO/IEC 27006-1:2024 (first edition, published 2024-03-01) adds the ISMS-specific rules for those bodies. The design intent is clear enough: the organization may draw the boundary wherever it can justify, and in exchange the certification documents must say, precisely and legibly, where the boundary is.

The integrity of that bargain depends on the claim traveling with the boundary attached, and the machinery does try: clause 8.3 of ISO/IEC 17021-1 requires certification bodies to govern how their clients refer to their certification and use marks, and a certification body can act against misleading use. But the scope statement lives in the certification documents, while the working claim lives in sales decks, trust pages and one-word questionnaire fields, where it is often abbreviated to "certified." In our experience that gap is policed unevenly at best, and the party most likely to notice it first is the buyer who actually reads the certificate.

Why scoping to pass is rational, and where it actually breaks

The temptation to scope narrowly is not laziness; it is arithmetic. The audit-time model in ISO/IEC 27006-1:2024 (Annex C) starts from the number of persons doing work under the organization's control and then adjusts for factors such as complexity, locations and outsourcing, so a narrower scope can reduce audit effort, though it guarantees no particular reduction in audit days or cost. Fewer people and processes in scope generally mean fewer interviews, fewer documents, and a smaller implementation bill, and the messy parts of the organization, the engineering group with its own tooling, the recently acquired subsidiary, the support team in another jurisdiction, are precisely the expensive parts to bring inside. In our experience, scope is among the most effective cost levers in the whole project, and it is often pulled for exactly that reason.

And it can work, in the narrow sense: a tightly scoped ISMS can pass its audit on its own terms. The certification body assesses conformity of the system you defined, not the ambition of the definition. A certificate for "the ISMS supporting the corporate IT function" can be issued in perfect good faith by a competent auditor, because it is a true statement about a real system.

The clause pushes back harder than teams expect, though. Clause 4.3 does not let you draw the boundary in a vacuum. Under clause 4.2, customers will commonly be relevant interested parties, and their applicable security requirements can bear directly on where the boundary belongs; item (c) then forces you to account for interfaces and dependencies, so a certified function that depends on an excluded engineering organization has an interface the documentation must confront. A scope that excludes the product customers actually buy is not automatically illegitimate. But it is a position that needs defending: the interested-party analysis has to establish, with the basis documented, that the customers' requirements are not applicable or are addressed outside the ISMS, and, in our experience, how hard auditors press on 4.3(b) and (c) varies. The defense is tested the moment someone reads the sentence.

The sentence is now checkable

Reading the sentence is getting easier. The IAF CertSearch database, developed and operated by Quality Trade as a joint partner of ISO and IAF, supports verification of participating accredited certificates, including their status and scope, subject to coverage and confidentiality limitations: not every certificate is uploaded, and records can be marked confidential. (Separately, IAF and ILAC were replaced by a single organization, Global Accreditation Cooperation Incorporated, which commenced full operations on 2026-01-01.) Certification data is nonetheless consolidating: the ISO Survey, ISO's annual certificate count, moved to compiling its results from CertSearch data with its 2024 edition (published 2025), which reported 96,709 valid ISO/IEC 27001 certificates against the 48,671 of the 2023 edition. Those two figures are not directly comparable, and the difference is not evidence that certifications doubled: the 2023 result was affected by missing participation from China's accreditation body, and the collection methodology changed between editions. The consolidation is the methodology change itself, one shared database increasingly standing behind both verification and the official count.

Meanwhile the demand side is professionalizing. In our experience, security questionnaires increasingly ask for the certificate itself rather than a yes/no attestation, and the scope statement is on it. A procurement analyst who reads it does not need long to notice that the SaaS platform under evaluation is not reasonably covered by the stated activities, services and boundaries.

Here is the asymmetry that makes this a trust decision rather than a compliance one. A vendor with no certificate and an honest "we are working toward certification of the platform" is in a recoverable position. A vendor who has said "we are ISO 27001 certified," and whose certificate, on inspection, covers a back-office function in another building, is in a much weaker one, because buyers rarely file that discovery under nuance. It can read as borrowed assurance, an attempt to let the badge cover more than the certification documents support, and once a buyer reads it that way, every other answer on the questionnaire inherits the doubt. The narrow scope was legitimate. The company-wide impression built on top of it was the part that could not survive a reader, and it just met one.

Scoping to mean something

The fix is to reverse the direction of the exercise. Scope-to-pass starts from the org chart and asks what can be cut. Scope-to-mean-something starts from the sentence you need to be able to hand a customer, something like "the ISMS covering the development, operation and support of [the product they are buying]," and works backwards to the people, processes, locations and suppliers that sentence commits you to. Clause 4.3(c) then does useful work for you instead of against you: tracing interfaces and dependencies outward from the customer-facing service is exactly how you find what belongs inside the boundary.

This is not an argument that every scope must swallow the whole company. Genuinely separate business lines, with real organizational and technical segregation, are legitimate exclusions, and phased certification remains sensible. The test we would propose for any exclusion is symmetrical with the trust problem: could you explain the exclusion, in one paragraph, to the customer whose data sits closest to the boundary, and would the explanation survive their follow-up question? An exclusion that passes that test ("the industrial products division shares no systems, staff or data with the platform") was drawn for structural reasons. An exclusion that fails it ("engineering was out of scope this cycle") points to a pass-driven scope, and the paragraph you cannot write is telling you what the exclusion was really for.

Phasing, done honestly, obeys the same rule: phase one should already cover the customer-facing service, because that is the claim the market will hear. In our experience, widening a meaningful scope in later cycles is the less disruptive direction of travel, and it reads as maturity. Repairing a hollow one is harder: under ISO/IEC 17021-1:2015 (clause 9.6.4.1), the certification body reviews the application and determines what audit activity the extension requires, which may be combined with a surveillance audit, and the certification documentation is updated only if the extension is granted. The interim, in which the certificate says one thing and customers believed another, is the costliest part.

The rule worth keeping

A certificate certifies its scope and nothing else. The standard grants real freedom in where you draw the boundary, and the certification machinery's one non-negotiable that matters here, from clause 8.2.2 of ISO/IEC 17021-1, is that the boundary be stated without being misleading or ambiguous. Holding your own claims about the certificate to that same test is not a regulatory obligation. It is simply the only scoping strategy that still looks good after a prospect reads the certificate, and the reading is only getting easier.

Drawing a boundary you can defend in both rooms, the audit and the sales call, is clause 4.3 work: interested parties, dependencies, and the documented sentence that survives both readings. That is the kind of scoping question ISMS Copilot is built to work through with you, requirement by requirement. The badge is identical on every certificate. The sentence under it is the product.