Quick Read
Many organisations assume ISO 37301 certification means certifying the entire compliance function across every law that applies to them. It does not. Clause 4.3 requires the organisation to determine the boundaries and applicability of its compliance management system, and those boundaries can be drawn around a single compliance domain — sanctions and export controls, data protection, a regulator-mandated compliance monitoring function — provided the scope is deliberate, justified and not misleading. A tightly scoped system operated rigorously delivers more value, and survives an audit better, than a sprawling one operated on paper. This paper explains how to scope well, the models that work, the traps that do not, and how to expand over time.
Executive Summary
The single most common reason organisations delay ISO 37301 is the belief that certification must cover everything. Faced with hundreds of laws across dozens of jurisdictions, the project looks impossibly large, and so it never starts.
ISO 37301 does not require that. Like every management system standard built on the harmonised structure, it requires the organisation to determine the scope of its management system, considering its context, the needs of interested parties and its compliance obligations, and to make that scope available as documented information. The scope can be enterprise-wide. It can also be limited to particular entities, sites, activities or compliance domains.
A domain-limited scope is not a lesser certification. A certificate covering the sanctions and export control compliance management system of a manufacturing group, operated with real rigour, says something precise and verifiable to customers, banks and regulators. A certificate covering “compliance” in general, supported by a thin register and untested controls, says very little — and will not survive a competent audit.
This paper explains what Clauses 4.1 to 4.3 require, describes five scoping models, sets out the rules that keep a scope honest, and shows how organisations can expand their certified scope as the system matures.
CORE ARGUMENT Scope is a strategic decision, not an administrative one. The question is not “how much can we certify?” but “where would independent assurance of our compliance system create the most value, and where can we operate a genuine system now?” |
1. What the Standard Requires
Scoping in ISO 37301 rests on three linked clauses.
Clause | Requirement in substance | Role in scoping |
|---|---|---|
4.1 Context | Determine the external and internal issues relevant to the organisation’s purpose that affect its ability to achieve the intended outcomes of the compliance management system | Identifies where compliance matters most to the organisation |
4.2 Interested parties | Determine the interested parties relevant to the system and their relevant requirements | Identifies who needs assurance, and about what |
4.3 Scope | Determine the boundaries and applicability of the system, considering the issues in 4.1, the requirements in 4.2, the compliance obligations in 4.5 and the compliance risk assessment in 4.6, and make the scope available as documented information | Records the decision and its justification |
Clause 4.5 then requires the obligations within that scope to be identified, and Clause 9.3 requires management review to consider changes in external and internal issues — which is where scope expansion decisions are naturally made.
The note to Clause 4.3 explains that the scope is intended to clarify the main compliance risks the organisation faces and the geographical or organisational boundaries, or both, to which the system applies. Annex A.4.3 adds that the organisation has the freedom and flexibility to implement the system within the entire organisation, a specific unit or specific functions, and that the scope should be reasonable and proportionate to the nature and extent of its compliance risks.
WHAT ANNEX A SAYS Annex A.4.3 observes that a compliance management system will typically be implemented across the entire organisation — and across an entire group — to avoid double standards of ethical conduct and compliance. A narrower scope is permitted, but the organisation should be able to explain why it is reasonable and proportionate, and how it avoids creating a double standard between what is in scope and what is not. Speeki’s auditors ask exactly that question at Stage 1. |
1.1 What “scope” actually contains
A complete scope statement for an ISO 37301 system describes four dimensions:
Organisational boundary — which legal entities, divisions or business units.
Physical boundary — which sites, facilities or countries.
Activity boundary — which activities, products and services.
Obligation boundary — which compliance domains or sets of obligations.
ISO 37001 users will recognise the first three. The fourth matters most in ISO 37301. Because the standard can cover any compliance obligation, and because Clause 4.3 requires the scope to take account of the compliance obligations and the compliance risk assessment, the organisation should state which obligations its system manages. That is what makes a domain-level scope possible — provided it remains reasonable and proportionate.
2. Five Scoping Models
In practice, ISO 37301 scopes fall into five broad models. None is inherently better; the right model depends on where assurance creates value and where a genuine system can operate.
Model | Description | Typical drivers | Watch-outs |
|---|---|---|---|
1. Single domain | One compliance domain across the organisation — e.g. sanctions and export controls, or data protection | Customer or bank demands; regulator focus; recent incident | Interfaces with uncertified domains; shared controls |
2. Domain cluster | Related domains managed by one function — e.g. financial crime (sanctions, anti-money laundering, fraud) | Single accountable function; shared controls and data | Uneven maturity across domains in the cluster |
3. Regulatory compliance monitoring | The system by which the organisation monitors its compliance with a regulator-mandated operational framework | Sector rules requiring an independent compliance monitoring function | Confusing certification of the monitoring system with certification of the operational system |
4. Entity or site-limited | All in-scope domains, but for selected entities or countries | A regulated subsidiary; a high-risk market; a joint venture | Shared services provided from outside scope |
5. Enterprise-wide | All compliance obligations across the organisation | Mature function; integrated GRC; board ambition | Breadth outrunning depth; thin evidence |
2.1 Model 1: the single domain
The single-domain model suits organisations under concentrated pressure in one area. A manufacturer exporting dual-use goods, a payments business whose banking partners demand sanctions assurance, or a software company whose enterprise customers require evidence of data protection management are typical. The obligations register covers one domain deeply; the risk assessment, controls, indicators and reporting are built for that domain. The certificate states exactly what it covers.
The main design issue is interfaces. A sanctions compliance system relies on controls run by procurement, finance and logistics. Those controls are in scope for the purposes of the domain, even if the functions are not otherwise certified. The scope statement and the system documentation must make that clear.
2.2 Model 2: the domain cluster
Where one function manages several closely related domains with shared controls and data — financial crime, product regulatory compliance, workplace compliance — clustering is efficient. The risk is uneven maturity: if one domain in the cluster is weak, the finding affects the certificate for all. Organisations should cluster domains of similar maturity, or scope the weaker domain in at a later surveillance or recertification cycle.
2.3 Model 3: the regulatory compliance monitoring system
Several regulated sectors require organisations to operate a compliance monitoring function that checks whether an operational management system — for example a safety management system — complies with the applicable rules. ISO 37301 is well suited to certifying that monitoring function.
Consider an aerodrome operator. Its safety management system is built and run by its safety team against aviation safety rules. Separately, the applicable regulatory framework requires the operator to run a compliance monitoring function over that safety management system. The operator’s compliance team builds a compliance management system around that monitoring obligation: its obligations register covers the aviation safety rules, workplace health and safety law and the operator’s own aerodrome manual; its controls are the monitoring audits and inspections; its indicators track findings and closure; its reporting runs to the accountable manager and the board.
PRECISION MATTERS In this model, what is certified is the compliance management system through which the organisation monitors its operational system — not the operational system itself. The scope statement and the certificate must say so explicitly, so that no one reads an ISO 37301 certificate as an endorsement of the safety system’s technical adequacy. |
2.4 Model 4: entity or site-limited
A regulated subsidiary, a newly acquired business or a high-risk country operation may be scoped on its own. The common trap is shared services. If the subsidiary’s screening, training or investigations are delivered by a group function outside the scope, those services are part of the subsidiary’s system and the auditor will need to see them. Out-of-scope does not mean out of sight.
2.5 Model 5: enterprise-wide
Enterprise-wide implementation is the case Annex A describes as typical, and it is the right end state for most organisations. As a starting point for certification, it works only where the system is already mature. It is achievable where the compliance function is mature, the obligations register is integrated across domains, and controls generate evidence consistently. Where those conditions are absent, breadth outruns depth: the register is thin, the risk assessment generic and the evidence patchy.
3. Rules That Keep a Scope Honest
Narrow scope is legitimate. Misleading scope is not. Certification bodies will not certify a scope that excludes the very activities that create the risk interested parties care about, and the scope wording on a certificate must describe precisely what has been assessed. Five rules keep a scope honest.
Justify exclusions by reference to context, not convenience. “We excluded our highest-risk market because it was not ready” is not a justification an auditor can accept for a scope that claims to cover the region.
Do not exclude risk while claiming the domain. A sanctions scope that omits the business unit responsible for most cross-border sales is misleading.
Include the controls the domain depends on. If the domain’s controls are operated by other functions, those controls are in scope for that purpose.
Describe the scope in words a reader outside the organisation will understand. The certificate will be read by customers, banks and regulators, not just the compliance team.
Communicate the scope accurately. Marketing claims must not imply that the whole organisation, or every compliance obligation, is certified when only part is.
Scope statement | Assessment |
|---|---|
“Compliance management” | Too vague; does not identify the obligation boundary |
“Compliance management system for sanctions and export controls covering the design, manufacture and worldwide sale of industrial control products by [Group] and its subsidiaries” | Clear organisational, activity and obligation boundaries |
“Compliance management system for the monitoring of compliance of the aerodrome safety management system with applicable aviation safety and workplace safety requirements at [sites]” | Clear; makes plain that the monitoring system, not the safety system, is certified |
“Compliance management for all operations” where two regulated subsidiaries were not audited | Misleading; not certifiable as worded |
4. Choosing Where to Start
The best first scope sits where three things overlap: interested parties want assurance, the organisation faces real risk, and a genuine system can be operated now.
Question | What it reveals |
|---|---|
Which customers, banks, insurers or regulators are asking for evidence of compliance management, and about what? | Where external assurance creates commercial value |
Where would a breach be most damaging — licence, criminal, contractual, reputational? | Where the system protects the most value |
Which domain already has an owner, a register, controls and data? | Where a genuine system can operate within months |
Which domain shares controls with an existing ISO 37001 or other certified system? | Where integration reduces effort |
Where has the organisation recently had an incident, finding or near miss? | Where the board will support investment |
A PRAGMATIC PATTERN Organisations already certified to ISO 37001 often start ISO 37301 with an adjacent financial crime domain — sanctions, fraud or anti-money laundering — because the leadership, compliance function, speak-up channel, investigation process, internal audit and management review already exist and can simply be extended. |
5. Expanding the Scope Over Time
A domain-level certificate is a beginning, not a ceiling. Scope can be extended at surveillance or recertification audits once the additional domains are operating as part of the system. A typical expansion path looks like this.
Phase | Scope | What the system gains |
|---|---|---|
Year 1 | Single priority domain | Core architecture: register, risk method, controls, indicators, reporting, review |
Year 2 | Add adjacent domains sharing controls | Integrated register; shared controls tested once, relied on many times |
Year 3 | Add further domains and entities | Consolidated compliance reporting across domains |
Year 4+ | Enterprise-wide | One system, one register, one board view of compliance performance |
Each extension should be decided at management review, documented as a change to the system under Clause 6.3, and preceded by enough operating history in the new domain for an auditor to see the system working there.
6. Common Failures
A narrow scope is a legitimate strategy. A misleading scope is not. These are the scoping failures that cause problems at Stage 1, at surveillance or, worse, in the market after certification.
Failure | Consequence | What an honest scope does instead |
|---|---|---|
Scope statement broader than the evidence | Findings at Stage 2 or surveillance; risk of misrepresentation if the certificate is used commercially. | States exactly which obligations, entities, sites and activities are covered. |
Excluding the area where the real risk sits | The certificate covers what is easy, not what matters; stakeholders eventually notice. | Justifies exclusions against the context and compliance risk assessment, and records them. |
Domain scope with an enterprise-wide claim in marketing | Customers and regulators are misled about what was audited. | Uses certificate wording precisely in all external communication. |
Shared services left undefined | Central functions (legal, HR, IT) operate controls for the scoped domain but sit outside the scope. | Treats shared services as in scope for the controls they operate, or as controlled outsourced processes. |
Expansion planned but never executed | The first scope becomes permanent and the system stops growing. | Sets an expansion roadmap reviewed at management review, with target dates. |
7. What Speeki’s Auditors Test
Scope justification. Does the documented scope follow from the context and interested-party analysis? Are exclusions justified?
Scope integrity. Does the scope exclude activities that create the risk the domain is meant to address?
Interfaces. Are controls operated by out-of-scope functions identified, and is there evidence they operate?
Register alignment. Does the obligations register match the obligation boundary in the scope — no more, no less?
Certificate wording. Will the scope statement on the certificate be accurate and not misleading to an external reader?
Communication. Is the organisation describing its certification accurately to the market?
Scope is examined at Stage 1, so that the Stage 2 audit tests the right system. Organisations that agree their scope wording with Speeki early avoid the most common source of delay in ISO 37301 certification.
Conclusion
ISO 37301 is often described as too broad to certify. That reflects a misunderstanding of how scope works. The standard asks the organisation to decide what its compliance management system covers, to justify that decision, and to describe it honestly. A single compliance domain, managed rigorously, is a legitimate and valuable scope.
Organisations that start narrow and deep build the architecture once, prove it works, and then extend it. Organisations that start broad and shallow tend to discover at audit that they have built a programme, not a system. Scope is where that choice is made.
About Speeki
Speeki is an accredited certification body operating across more than 100 countries, providing ISO management system certification, ESG and sustainability assurance, and executive education. Speeki provides no consulting of any kind. Our independence is structural, not a promise.
Speeki delivers its audits through AI working alongside a body of experts. Nicole, Speeki’s AI team member, works with our auditors to test full populations of evidence rather than samples, so that certification reflects how a management system actually performs, not how it looks on the day of the audit.
To learn more, see ISO 37301 certification with Speeki.
Related Reading
Paper 1 — A Compliance Programme Is Not a Compliance Management System
SPK CSMS1000:2026 and ISO Management System Standards Integration Guide
This whitepaper provides general information on ISO 37301:2021 and does not reproduce the text of the standard. Organisations should refer to the published standard for its exact requirements.