ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Gap assessment scoping is the step where you decide exactly what will be assessed, against which requirements, in which parts of the organization and to what depth. It is the least glamorous part of the work and the one that most often decides whether the results are useful. An assessment with a vague scope produces findings that nobody owns, misses areas that later prove critical, or expands until it runs out of time and budget.
This guide explains how to scope a gap assessment: choosing the framework and version, setting organizational and technical boundaries, deciding applicability, selecting depth, recording exclusions, planning resources and getting sign-off.
A gap assessment compares your current state with a target set by a standard, regulation or contract. If the scope is wrong, the comparison is wrong. Scope too narrow, and you declare compliance while an unassessed system holds the real exposure. Scope too broad, and the assessment becomes a multi-year project that yields little. The scope also defines what the results mean, so a certification body, a regulator or a customer reading the report can tell what was and was not covered. Our guide to gap assessment scoring explains how findings are then rated.
Name the framework, the version and the parts of it that apply. Standards change, so specify the edition, such as ISO/IEC 27001:2022 rather than simply ISO 27001, and note any transition dates that matter to you. For regulations, name the instrument and the jurisdictions, and where several apply, decide whether you will assess against each separately or against a combined control set that maps to them. For contracts and customer requirements, list the clauses or the questionnaire that define the target. Record who chose the target and why, since the choice often reflects a commercial or legal driver that should be visible in the report.
The purpose shapes the scope. A readiness assessment before certification needs full coverage of the standard and the boundary you will certify. A due diligence review of an acquisition target focuses on material risks. A regulatory gap analysis before a new law takes effect concentrates on new obligations. Write the purpose in one sentence at the top of the scope statement, and check every scoping decision against it.
State which legal entities, business units, sites, systems, processes, data types and third parties are inside the boundary. Use concrete lists, not phrases such as the whole company. Where the boundary follows a certification scope, check that it matches the scope statement you will use with the certification body. Where it follows a regulation, follow the definitions in the law, for example the processing activities of a controller or the ICT services of a financial entity.
| Boundary element | Questions to settle |
|---|---|
| Entities and units | Which companies, divisions and teams are included? |
| Locations | Which sites, countries and remote-working arrangements? |
| Systems and data | Which applications, infrastructure and data sets? |
| Processes and services | Which activities and products are covered? |
| Third parties | Which suppliers and outsourced functions? |
| Interfaces | Where does the boundary meet other systems or organizations? |
Pay special attention to interfaces. Data flowing across the boundary, shared services and outsourced functions are the places where responsibility is easily lost. State how each will be treated: included, assessed at the interface only, or relied on through assurance from the supplier.
Not every requirement applies to every organization. Go through the framework and record for each requirement whether it applies, with a reason. A standard may include controls for activities you do not perform, such as software development or physical manufacturing. Marking these as not applicable with a reason is legitimate, and ISO management system standards expect you to justify exclusions. Do not exclude requirements simply because you fail them. Our guide to the ISO 27001 gap assessment shows how applicability is handled for that standard.
Depth can vary by requirement. A design-level review checks whether policies and procedures exist and cover the requirement. An implementation review checks that the procedures are followed, using records and samples. An effectiveness review tests whether the control achieves its aim, through technical testing or independent audit. Higher-risk requirements deserve greater depth. Decide in advance which requirements will be examined at which level, and record it, so that readers of the report can tell whether a rating of compliant means a document exists or a control has been tested. Our guide to gap assessment evidence explains how to grade proof.
List everything left out and why. Typical exclusions are recently acquired units awaiting integration, systems scheduled for retirement, third-party services assessed elsewhere and areas awaiting a decision. State the assumptions the assessment relies on, such as the accuracy of the asset inventory or the availability of people for interviews. Where an exclusion hides a material risk, flag it in the report, so that readers do not mistake a limited scope for a clean result.
Estimate effort from the scope: the number of requirements, the number of units and sites, the depth chosen and the number of interviews and samples. Identify the assessor or team, the sponsor, the owners who will provide evidence and the reviewers. Agree access to people and systems in writing, along with confidentiality arrangements. Set a timeline with milestones for evidence requests, fieldwork, draft findings and the final report, and build in time for owners to respond to draft findings. A scope that cannot be delivered with the available resources should be trimmed before starting, not after.
Present the scope in a short meeting instead of only circulating it, since people read documents late and object later.
Write the scope as a short document with the purpose, target, boundary, applicability, depth, exclusions, assumptions, resources and timeline. Ask the sponsor to approve it, and ask the owners of each area inside the boundary to confirm it. Approval prevents disputes later about whether an issue should have been found, and provides a basis for handling changes. If the scope changes during the work, record the change, its reason and its effect on time and cost.
When the target is a management system standard, the official listing on ISO/IEC 27001 on iso.org confirms the current edition. The same discipline applies to other targets, as shown in our guides to GDPR gap analysis and ISO 22301 gap analysis. After scoping, findings are ranked using the method in gap assessment prioritization.
A software company plans ISO 27001 certification for its hosted product. The gap assessment scoping statement names ISO/IEC 27001:2022 and its Annex A controls, sets the boundary as the engineering, operations and customer support teams and the two data centers hosting the product, and lists the corporate finance systems as outside the boundary with a note on the interface for payment data. It treats the physical controls of the hosting provider through the provider’s own assurance report. It sets an implementation-level review for most controls and effectiveness testing for access management and change control. The sponsor signs the scope, and a change log records the later addition of a small acquired team.
Teams scope by habit rather than purpose, use vague boundaries, leave out interfaces and suppliers, exclude areas because they are known to be weak, choose a depth without recording it, fail to get sign-off and let the scope drift. Another mistake is choosing the scope to fit a preferred result. An assessment is worth doing only if its scope reflects the real boundary of the obligation.
If you want a starting point that already has a place for scope, requirements, evidence and findings, the Gap Assessment Report and Workbook provides a structured report and working register. You can then follow the findings through to action using our guide to the gap analysis remediation plan. Whichever tool you use, make gap assessment scoping a documented decision that the sponsor has approved.
It is the process of deciding what a gap assessment covers: the framework and version, the organizational and technical boundary, applicable requirements, depth and exclusions.
The sponsor should approve it, with confirmation from the owners of each area inside the boundary. Record the approval and any later changes.
You can mark requirements as not applicable where a reason exists, such as an activity you do not perform. Do not exclude requirements only because you know you fail them.
Match depth to risk: design review for lower-risk requirements, implementation review with samples for most and effectiveness testing for the highest-risk controls.
Record the change, the reason and the effect on time and cost, and get it approved. Uncontrolled changes make results hard to interpret.
September 30, 2026
