Scope, Exclusions and a Statement of Applicability Built Backwards

The scope is too broad because it is unbounded. 'All information systems supporting operations worldwide' names no legal entities, no sites, no services and no interfaces. Nobody - including the auditor - can determine what is inside it, so it cannot be audited or defended. Scope needs organisational units, locations, technologies and, critically, the interfaces and dependencies that cross the boundary.

It is too narrow because the exclusions are artificial. The Mexican subsidiary is excluded as 'not integrated', yet it almost certainly depends on group identity, email, network links or shared customers, and group risk decisions affect it. If it is genuinely outside the certification scope, the interface to it must still be described and the dependency risk managed; if it is inside, it must be assessed. An exclusion that leaves a live dependency undescribed is an unmanaged boundary.

The provider exclusion is a category error. Outsourcing an operation does not outsource accountability. A supplier certificate is an input to supplier assurance - useful evidence about the provider's own management system - not a substitute for Meridian's controls over that service. Meridian still needs contractual security requirements, service monitoring, change notification, incident interfaces and exit provisions. Excluding the SAP service while scoping 'all systems supporting operations' is also internally inconsistent, since the dependency plainly supports operations.

What a defensible boundary looks like: named entities and sites; named services and platforms; documented interfaces to excluded parties; an explicit statement of dependencies (cloud, identity, network, suppliers); and a rationale for each exclusion that a reader can test against the business.

Methodology. A 5x5 matrix is not the problem - undefined or misdirected scales are. Scoring likelihood as the probability that an auditor finds an issue measures audit exposure, not the occurrence of threats. It creates two systematic errors: it under-rates rare, high-impact events (ransomware on the ERP, sabotage of operational technology) because they have not been raised before, and it over-rates well-audited but low-impact areas. The result is a treatment plan optimised for passing an audit rather than for managing risk. The anchors also say nothing about threat capability, vulnerability exposure or the effectiveness of existing controls, and there is no stated link between impact scores and business consequences.

What defensible looks like: risk criteria defined and approved before assessment, with impact expressed in business terms (safety, regulatory, financial, service) and likelihood grounded in threat and vulnerability, not audit history. Assets, threats and vulnerabilities identified consistently across all three sites; existing controls considered so that scores are residual, not inherent; risk owners named and accepting; and the output traceable to the treatment plan.

The statement of applicability. 'No evidence of need' is not a justification - it is an absence of analysis. Each exclusion needs a positive rationale: either the control objective is met by another means (say so, and name it), or the risk scenario genuinely does not arise in this scope (say why, and show the reasoning). Twenty-one exclusions from 93 is plausible only if each is individually argued; excluded controls are the first thing an auditor will sample. Expect at minimum that development, threat intelligence and some cloud-service controls need real justification given the SAP estate.

Sequence, with reasoning:

1. Governance and roles first (weeks 1–2). Confirm the accountable owner, the risk owner community and who signs off scope and risk acceptance. Without this, every later artefact is unowned and will be rewritten at stage 1.
2. Scope, then context (weeks 2–4). Rewrite the scope around named entities, sites, services and interfaces; document the Mexican dependency and the SAP service explicitly. Identify interested parties and their requirements, including the client and regulatory obligations that drive impact criteria. Scope comes before risk because risk assessment needs a defined population.
3. Risk criteria, then assessment (weeks 3–7). Rewrite the likelihood and impact scales in business terms, get them approved, then run the assessment across the defined scope with asset, threat and vulnerability inputs. This is the longest step and will run in parallel with scope finalisation at the edges.
4. Risk treatment and the statement of applicability (weeks 6–9). Derive controls from the treatment decisions, then justify every inclusion and exclusion individually. The SoA must be an output of this work, not a form filled in afterwards.
5. Documented information and readiness review (weeks 9–11). Consolidate policies, records and evidence; run an internal pre-assessment against the scope so stage 1 findings are known, not discovered.

Deliberately not attempted yet: certification of all sites at once. A staged scope (Poland and the group SAP first, Vietnam and Mexico at a defined later date) is more credible than a worldwide claim that nobody can evidence in eleven weeks.