How do you set the ISO 27001 ISMS scope?
The organization sets its own ISMS scope under clause 4.3, after it has considered the internal and external issues in clause 4.1 and the interested parties and their requirements in clause 4.2. The scope can be narrowed by organization, location or service, but no requirement in clauses 4 to 10 can be dropped, so a team cannot certify its product while leaving out the leadership, planning or performance evaluation clauses. The scope also decides which people, sites and services an auditor must test, so it directly sets audit time and tells customers what the certificate covers. Start by listing the customer demand that triggered the work, then map which systems, teams and locations hold or process that data.
The organization owns the scope decision. A consultant or implementation partner can draft the scope statement and test it against the customer's requirements, but management must approve it and be able to explain why each excluded location or service sits outside the ISMS. Ask the drafter to show how the interested-party analysis drove each boundary. Only the certification body accepts the scope during the stage 1 review, and it can challenge a boundary that looks drawn to shrink audit time or hide a risky service.
Before the first audit quote, confirm three points with the certification body: how it counts persons doing work under the organization's control, whether remote staff and contractors are included, and how it treats each site named in the scope. The scope statement that appears on the certificate is the phrase customers will read and compare with their own contract, so write it in plain terms that name the service, the locations and any hosted or cloud environments included. Keep the wording consistent with the Statement of Applicability so the two documents do not contradict each other.
Which parts of the business go inside the scope
The scope has to settle who, where and what sits inside the ISMS before any control is tested. Each decision below changes the people, sites and systems an auditor samples, and each one needs a written justification that matches what the organization actually runs.
Business units and legal entities
Decide which business units, subsidiaries and legal entities operate under the ISMS. An auditor will check that the scope matches the organization's real structure, so a parent company cannot exclude a subsidiary that shares staff, systems or customer data. Write down which entities are in, which are out, and why. Confirm that any excluded entity has no shared infrastructure with the certified scope.
Physical locations and sites
List every office, data center, colocation facility and home-based location that handles in-scope information. Under the audit time rules, the people working at each location count toward audit effort, so a site left out of the scope still affects the audit if it touches the in-scope service. Record each site by name and address, and state which controls are run there and by whom.
Products and services
Name the products, services or processes that fall inside the ISMS, such as a particular SaaS platform or a support function. The scope may be narrowed by service, but the auditor will test whether the excluded services share people, code or data with the certified one. Document the boundary in a diagram and in the scope statement so that customers can see exactly what the certificate covers.
Cloud and hosted systems
Decide which cloud accounts, hosted platforms and infrastructure as code repositories are in scope. A self-hosted open-source platform running in a client's cloud account or on-premises network needs its own boundary definition, including who holds administrative access. Confirm with the certification body how it will treat inherited controls from a cloud provider's own certificate, and record the shared responsibility split in writing.
Third parties under organizational control
Identify suppliers and contractors whose staff work under the organization's direction, such as outsourced developers or managed service providers operating in its systems. The standard counts persons doing work under the organization's control, so contractors who log in to in-scope systems can add to audit time. Record which third parties are included, how their access is governed, and which suppliers are assessed only as external dependencies.
Remote and home-based staff
Decide how remote employees are included, since they often hold the same access as office staff. Under the 2024 audit rules, certificates for clients with few or no physical sites must state that activities are conducted remotely. Document where remote work happens, which devices and networks are permitted, and how the organization verifies that controls apply outside the office. Confirm the wording with the certification body before stage 1.
Which clauses cannot be excluded from scope
Clauses 4 to 10 cannot be excluded from an ISO 27001 scope. Clause 1 of ISO/IEC 27001:2022 states that excluding any requirement in clauses 4 to 10 is not acceptable if you want to claim conformity. The scope statement can narrow what the ISMS covers by organization unit, physical location or service, but it cannot be used to drop context, leadership, planning, support, operation, performance evaluation or improvement. In practice, a scope that says "we do not do clause 9 for the payments team" is not a valid scope. Before you finalize the boundary in clause 4.3, confirm with your certification body how it reads the scope wording, and check that every excluded unit is one you can justify in writing against the requirements of clauses 4.1 and 4.2.
Annex A controls are a different matter. Annex A is normative, but the standard allows you to decide which of the 93 controls are necessary for your risk treatment. Any control you leave out must be recorded in the Statement of Applicability with a justification, and the justification must be a real reason, such as the control being irrelevant to your activities, not a convenience. Clause 6.1.3 links these decisions to your risk treatment plan, so an exclusion that conflicts with an identified risk will be challenged at audit. An illustrative example: a SaaS company that does not operate physical data centers may exclude physical controls for sites it does not run, but it still needs to address the physical protection of its own offices and equipment if they hold in-scope information.
Watch for quiet omissions. The most common scope problem is leaving out a business area that customers rely on, such as a support desk, a hosted product line or a cloud environment that stores customer data. An auditor will compare the scope with your product descriptions, contracts, data flows and the list of services you describe in security questionnaires, and any mismatch will be raised. Before audit, list every service and location that touches in-scope information, and confirm each one is either inside the boundary or excluded for a stated reason that your customers would accept. The scope on your certificate is the one buyers will check, so an omission found later can damage trust more than a larger scope would have.
How scope changes for multi-site, remote and SaaS organizations
A single office is the simplest case. The scope boundary usually follows the building or floor plus the business activities run from it, and the scope statement names the services, products or processes the ISMS covers. The organization still has to address clause 4.3 and the interested parties identified under clause 4.2, so the boundary should reflect what customers and regulators actually rely on, not only the walls that are physically controlled.
- Boundary definition: Name the location, the business unit and the services in one sentence that a customer can read without a glossary.
- Audit sample: Auditors typically walk the premises, review access controls for the office and sample staff and processes that fall inside the boundary.
- Head count: The persons doing work under the organization's control set the starting point for audit time, so contractors and shared staff who work in the office count.
- Certificate wording: The certificate reflects the scope as defined, so any service carved out of the office must be stated explicitly.
- Illustrative example: A 40-person consultancy certifies its head office and its client delivery service, and excludes an unrelated product line run from a different company.
Before stage 1, confirm the scope statement with your certification body and check it against the customer contracts that cite the certificate.
A multi-site organization runs one management system across several locations. The scope must state which sites are in, and the certification body samples across them. The starting point for on-site audit time is the total number of persons doing work under the organization's control, wherever they are located, so adding sites does not reduce the head count base. Global ACI-TECH-3-001 (M) governs how several-site certification is audited, though scheme-specific rules in ISO/IEC 27006 take precedence where they apply.
- Central function: Identify the head office or central team that owns the ISMS, the policies and the risk assessment, since those cannot be delegated to individual sites.
- Sampling by risk: Auditors may sample sites based on risk and differences between them, but the sampling rules and the head count basis come from the certification body's contract and the applicable standard.
- Identical groups: A group of staff performing identical activities can have its head count reduced by risk, but not below the square root of that group's head count.
- Scope extensions: Adding a site later is a scope change that brings its own audit time under ISO/IEC 27006-1:2024 clause C.7.
- Illustrative example: A logistics firm with four depots certifies all four under one ISMS, with the central IT team as the audited owner.
Ask the certification body how it will sample sites, how it counts head count across shifts and how it will treat any site that is not yet operational.
A remote or SaaS company may have few or no physical sites, and its production environment often sits in a cloud provider's data centers. The scope boundary is drawn around the people, the cloud accounts, the services and the processes that deliver the product, not around a building. Where the company has few or no relevant physical sites, IAF MD 29:2024 requires the certificate to state that the activities are conducted remotely, so customers reading the certificate will see that wording.
- Service boundary: Define the product, the environments (production, staging, corporate identity systems) and the teams that operate them.
- Remote statement: The certificate must state that activities are conducted remotely where the IAF rule applies, so confirm the wording with the certification body before stage 1.
- Audit sample: Auditors commonly review cloud account configuration, identity and access records, change logs, incident records and the evidence of staff remote working controls.
- Cloud provider responsibility: The provider's certificates or reports can support the supplier controls, but they do not replace the organization's own scope statement.
- Illustrative example: A SaaS vendor with staff in several countries scopes its production platform, support tooling and engineering workflow, and excludes a marketing website hosted by a third party.
Confirm with your certification body how remote staff are counted and whether any hosting provider needs to be named in the scope statement.
How the people in scope set ISO 27001 audit time
The number of people inside your ISMS scope is the starting point for how many audit days a certification body will plan. Under ISO/IEC 27006, the total number of persons doing work under the organization's control, across all shifts, is the basis for calculating ISMS audit time, as European Accreditation FAQ 35.3 explains. That means contractors and temporary staff who work under your control count, not only employees on the payroll. Before you request a quote, list every group that falls within the scope you have drawn, and record how many people sit in each group and on which shifts they work.
Where the organization operates several sites, the calculation does not simply fall to the sites in scope. European Accreditation FAQ 48.5 cites clause C.6 of ISO/IEC 27006-1:2024, which generally bases on-site audit time on the total number of persons doing work under the organization's control, wherever they are located. A narrower site footprint can therefore leave the audit time largely unchanged. Clause C.3.4 allows a risk-based reduction in the head count of a group performing identical activities, but European Accreditation FAQ 48.6 notes that the reduced figure may not fall below the square root of that group's head count. A group of 100 identical staff, for example, cannot be reduced below 10 for audit purpose (illustrative).
Scope changes made later also carry their own audit time under clause C.7 of ISO/IEC 27006-1:2024, so adding a business unit or service mid-cycle has a cost beyond the original quote. The certification body calculates the audit time, not your consultant or your internal team, so ask for the calculation in writing: the head count used, the shifts counted, any reduction applied under clause C.3.4 and the extra time for each scope extension. Confirm these figures in the written quote before you sign, and check that the people you counted match the people your scope statement describes.
Why customers check the certificate's scope, not the logo
A buyer who wants proof of ISO 27001 certification should read the scope statement on the certificate, not the logo or the phrase "ISO 27001 certified" in a sales deck. The scope text names the products, services, sites and locations the ISMS covers. If the service you are buying sits outside that text, or is covered only by a narrower or different scope, the certificate does not show that the service is certified, however genuine the certificate is. Customers who check this carefully compare the scope wording line by line against the service described in the contract, the statement of work or the security questionnaire.
Verify the certificate in the IAF CertSearch database, which ISO points to for checking accredited certificates. Search for the organization, confirm that the certificate is current, and compare the scope text shown in the database with the copy your supplier sent you. Do not rely on a PDF or screenshot alone, because a copy can be out of date or altered. If the wording is unclear, or the database and the copy differ, ask the certification body named on the certificate to confirm the scope in writing. Confirm the certification body itself as well, including whether it is accredited for ISO/IEC 27001, since the scope check only means something when the body that issued the certificate is accredited.
When you write the contract, ask the supplier to name the certified scope, the certificate number and the certification body, and to notify you if the scope changes or the certificate is suspended or withdrawn. If a service you depend on, such as a hosting environment or a remote support team, is not in the certified scope, decide whether you accept that gap, request a scope extension, or require a different control in the contract. Ask for these details to be restated at each renewal, since the certificate's scope can change between audit cycles.
Scope mistakes that delay the audit or inflate its cost
Most scope problems show up late, when the certification body reads the scope statement or counts people during audit planning. The pitfalls below share one root cause: the boundary was drawn around what the organization sells, not around what its people and systems actually do to deliver it.
Boundary around the product, not the operators
A scope that names a product but leaves out the engineering, support and operations teams that build and run it leaves auditors asking why people who change production are outside the ISMS. Those teams often hold the access and change controls that matter most. Check that every team with access to the product's data, code or infrastructure is inside the scope or explicitly justified as an interface to it.
Counting only full-time staff
Audit time under the accreditation rules for certification bodies starts from the total number of persons doing work under the organization's control, not from payroll. Contractors, temporary staff and outsourced operators who touch in-scope systems count. Ask your certification body how it will treat contractors and build a current roster that includes them before requesting a quote.
Leaving out a dependent cloud environment
If the service runs in a cloud account, cluster or region that the scope does not name, the scope describes a system that does not exist in production. Auditors will trace data flows to wherever they land, including backups, logging pipelines and build systems. Map each production dependency and decide, with reasons, whether it is in scope or covered by a supplier relationship that is.
Changing scope mid-cycle without notice
Adding a product, site or service after certification can require the certification body to audit the change, and the rules for scope extensions were tightened in the 2024 revision of the accreditation requirements for certification bodies. Quietly changing what the organization runs and only updating the internal document creates a gap between the certificate and reality. Route every scope change through the certification body before it takes effect.
A scope statement customers cannot map
A scope written in internal shorthand, such as a code name or a team label, gives a customer nothing to match against its contract, data processing terms or vendor record. The certificate's scope is the text buyers check. Write it using the service name the customer buys, the locations and the activities covered, and test it by asking a procurement reviewer to say which contract it covers.
Excluding clauses instead of narrowing the boundary
Teams sometimes try to shrink the scope by dropping a requirement, such as the leadership or performance evaluation clauses, rather than by reducing the organization, location or service covered. Clause 1 of the 2022 edition does not allow excluding requirements in clauses 4 to 10 for a conformity claim. Narrow the boundary by organization, location or service, then confirm with the certification body that the remaining scope is acceptable.
Steps to set and document the scope
This sequence turns a loose idea of what is in scope into a written ISMS scope statement, a people and site list, and an agreed draft that a certification body can price for audit time.
Inventory services, products and locations
List every service, product, system and business unit that could fall within the ISMS, and every physical site, office, data center, home-working arrangement and cloud account that supports them. The owner is the person accountable for the business the ISMS will protect, usually with IT and operations support. The step is done when each service and location appears on one register, with a note on which ones are owned or operated by a third party. Keep the register in a form you can update, because it will feed the Statement of Applicability later.
Identify interested parties and their requirements
Under clause 4.2, record the interested parties that matter for information security, such as customers, regulators, contract counterparties, employees and suppliers, and note the requirements each one places on the ISMS. Record which of those requirements the ISMS will address. The output is a table linking each party to its relevant requirements and to the services or locations those requirements touch. The 2024 amendment added a note that interested parties can have climate-related requirements, so confirm whether any apply to your context. This step shapes the boundary because it shows which services customers actually depend on.
Draft the scope statement
Write a short scope statement under clause 4.3 that names the services, products, locations and organizational units inside the ISMS, and states any boundaries or exclusions by organization, location or service. Do not exclude any requirement in clauses 4 to 10, since clause 1 does not allow that for a conformity claim. Check that each exclusion you name is a boundary of the business and not a requirement you wish to avoid. The output is a draft statement that a reader outside your team can understand without further explanation.
List people and sites in scope
Build the list of people doing work under the organization's control within the scope, including employees, contractors and temporary staff, and count them by location and by shift. Note which roles perform identical activities, because certification bodies may apply risk-based reductions to those groups under ISO/IEC 27006-1. Record remote workers and sites where few or no staff are based. The output is a headcount table by site, role group and shift. This table is the main input the certification body uses to calculate audit time, so reconcile it against HR records before you share it.
Agree the scope with the management review owner
Take the draft statement and headcount table to the executive who owns the management review under clause 9.3, and get a documented decision on the boundary. Ask them to confirm that the scope matches the business commitments customers see, and that the exclusions are defensible. Record the approval date, the approver and any open questions in the ISMS documentation. The step is complete when the scope has a version number and an approval record. Changes after this point should go through the same approval.
Hand the draft to the certification body for a quote
Send the approved scope statement, the headcount table and the site list to one or more accredited certification bodies and ask each for an audit time quote based on those figures. Ask them to state how they calculated the number of persons in scope, how they applied any reductions for identical activities, and how they would audit remote and multi-site locations. Compare quotes on the same inputs. The output is a written quote tied to a fixed scope. If the certification body later finds the scope or headcount differs from what you sent, expect the quote and timing to change.
Who owns the scope and who only prepares it
The organization decides its ISMS scope and owns its interpretation of clause 4.3, including which internal and external issues (clause 4.1) and which interested parties and their requirements (clause 4.2) shape the boundary. No consultant, implementation partner or certification body can make that decision for the organization. Leadership has to record the scope, approve it, and be able to explain why each location, business unit, service and system is inside or outside it. That explanation is what an assessor will ask for first.
An implementation partner such as DeployOpen can prepare the materials that support that decision. In practice this means a draft scope statement, an inventory of the people, sites, cloud accounts, self-hosted platforms and suppliers that fall inside the boundary, and evidence that the boundary is enforced, such as network segmentation records, access lists and asset registers that match the scope. The partner can also check that the draft is consistent with the risk assessment and the Statement of Applicability. The organization still signs off each item and remains responsible for the accuracy of what it submits, and a partner's preparation does not guarantee the outcome of any audit.
Only an independent certification body audits the scope and decides whether the ISMS, as scoped, conforms to ISO/IEC 27001:2022. Only that body issues the certificate, and the scope printed on it is the statement customers compare against their own requirements. Confirm with your chosen certification body how it will review the scope before stage 1, which documents it expects, and whether the same people who prepared the inventory are allowed to act as the organization's internal audit or interview contacts. Keep the roles documented so the separation is visible to the auditor.
ISO 27001 scope questions buyers ask
Can we exclude a department from our ISO 27001 scope?
Yes, the scope can be narrowed by organization, location or service, but you cannot exclude a department's obligations under the management system clauses. Clause 1 of ISO/IEC 27001:2022 makes clear that dropping any requirement in clauses 4 to 10 is not acceptable for a conformity claim. The practical question is which people, sites and services the ISMS covers. If a department handles customer data or supports systems that do, it usually belongs inside the scope, because customers will ask whether the data they send you is protected. Excluding a business unit that shares your network, identity system or staff is hard to defend to an assessor. Before you decide, confirm with your certification body how it reads your proposed boundary, and ask for that reading in writing before stage 1.
Can we certify one product instead of the whole company?
You can certify a defined part of the organization, but ISO 27001 certifies an information security management system, not a product. The scope must describe the organization, location or service the ISMS covers, and the certificate states that scope. A narrow scope for one product is possible when that product's information, people and supporting infrastructure can be bounded clearly. The risk is that shared infrastructure, staff who support several products, and common cloud accounts pull the boundary wider than the product name suggests. Customers will read the certificate scope literally, so a scope that names only one product may not satisfy a buyer who expects the whole service to be covered. Ask the certification body how it treats shared services before you commit.
How does headcount change the certification audit cost?
Certification body audit time for an ISMS starts from the total number of persons doing work under the organization's control, which is why headcount in scope drives the quote. European Accreditation FAQ 35.3 cites ISO/IEC 27006 as the starting point for calculating ISMS audit time, counting people across all shifts. For multi-site organizations, European Accreditation FAQ 48.5 cites clause C.6 of ISO/IEC 27006-1:2024, which calculates on-site time from the total number of people wherever they are located. Clause C.3.4 can reduce the head count for groups doing identical activities, but not below the square root of that group's head count. Ask your certification body to show the headcount it used, the reduction it applied and the audit days that follow from them.
Do contractors and temporary staff count toward the ISMS scope?
Contractors count when they do work under the organization's control, and that work falls inside the ISMS. The test is who performs work for you, not whose payroll they sit on. Temporary staff, outsourced support engineers and contractors with access to your systems or data usually belong in the head count and in the risk assessment. Some organizations handle this by requiring contractors to follow the same controls through contracts and access rules, which is the control approach the Annex A supplier and people controls describe. Whether a given contractor is inside the scope is a judgment to record in your scope statement, and the certification body will test that record against what it sees on site. Confirm the treatment with the certification body before stage 1.
What happens when our scope changes during the three-year cycle?
Scope changes during the certification cycle must be reported to the certification body, which decides whether the change needs an audit before the certificate's scope is extended. Adding a site, a service or a large group of staff can change audit time, so the certification body may need to assess the extension. ISO/IEC 27006-1:2024 added audit time requirements for scope extensions in clause C.7, and IAF MD 29:2024 confirms that transition. Shrinking scope can also reduce what the certificate covers, and customers who relied on the old scope will need to know. Plan scope changes before they happen, record the reason and the risk assessment that supports the change, and ask the certification body for its process in writing.
Can we set the ISMS scope ourselves or do we need a consultant?
You can set the scope yourselves, and the standard expects the organization to own that decision. Clause 4.3 requires the organization to determine the scope by considering the internal and external issues in clause 4.1 and the interested parties and their requirements in clause 4.2. A consultant can help you work through those inputs, but the scope statement must reflect your own business and be approved by your leadership. An implementation partner can prepare the asset inventory, network diagrams and access records that show where information flows, and DeployOpen does this kind of preparation on client-owned infrastructure. It does not decide your scope or issue any certificate, and only an independent certification body can accept your scope. Ask any outside helper to put its role and deliverables in a written scope of work.
How DeployOpen prepares systems and evidence for a defined ISMS scope
DeployOpen works on the ISMS scope as a written, bounded piece of work inside your own infrastructure. We prepare the systems, controls and evidence that sit within the scope you set, so the people, locations and services your certification body will examine are documented and traceable from the start.
How we scope
- Agree the written scope covering the locations, services, systems and people your ISMS will include
- Map the in-scope asset inventory and the interested party requirements that shape the boundary
- Record exclusions by organization, location or service only, with no dropped clauses from 4 to 10
How we build
- Deploy self-hosted open-source platforms inside your cloud accounts, data centers or air-gapped networks
- Configure access, logging, backup and monitoring controls for the in-scope systems only
- Keep infrastructure as code and configuration baselines under version control as scope evidence
How we hand over
- Deliver scope documentation, system diagrams and asset registers that match the certificate scope wording
- Provide control evidence packs for the in-scope systems, ready for your internal audit and certification body
- Hand over runbooks and ownership records so your own staff can run and maintain the ISMS
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Confirm with your certification body how scope changes, new sites and new people will be handled
