Definition

ISO 27001 clause 4.3 requires organisations to define the ISMS scope, including all sites and legal entities sharing common processes, systems and information assets. Multi-site, multi-entity groups (banks with branches, hospital networks, conglomerates) can pursue a single certificate covering all sites or separate certificates per entity; scope decisions directly drive audit days, control applicability and shared-service treatment.

Why it matters

The pressure on ISO/IEC 27001 programmes is shifting in specific, observable ways:

• CBUAE and SAMA licensing conditions for banking groups require that information security frameworks cover all regulated entities — a single-entity ISO 27001 scope does not satisfy group-level supervisory expectations.
• Incorrect scope exclusion of a shared IT service centre that processes data for in-scope entities creates a Major NC at Stage 2; auditors from BSI/SGS specifically test data flow diagrams against the scope statement.
• GCC conglomerates operating across ADGM, DIFC and KSA jurisdictions face triple-framework pressure (NCA ECC, DIFC PDPL, SAMA CSF) — a unified multi-site ISMS reduces duplicate audit fees by AED 200K–600K annually.
• India listed entities with subsidiaries must comply with SEBI CSCRF at group level; a multi-entity ISMS scope documented per clause 4.3 provides the audit trail SEBI inspectors require during on-site reviews.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• Scope statement document — exact wording referencing site addresses, legal entity names, included/excluded processes and the rationale for any exclusions per clause 4.3
• Network topology and data flow diagrams — showing information flows between in-scope and out-of-scope entities, used by auditors to validate boundary completeness
• Asset register — tagged by site/entity with asset owner, classification level and processing location (on-premises / cloud region)
• Shared-service agreement (SLA/OLA) — between group IT and subsidiary entities, defining security responsibilities and audit access rights
• Multi-site audit schedule — listing each site, assigned audit days (IAF MD1 formula), auditor name and last audit date

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: ISMS Manager and Legal counsel map all legal entities in the group, identify shared IT services (e.g. centralised SOC, ERP, Active Directory) and draft a scope boundary diagram; confirm with CB whether IAF MD1 multi-site sampling applies.
• Day 31–60: Conduct interface analysis for each entity boundary: document data flows, supplier contracts touching multiple entities and any carve-outs with written justification; Legal validates regulatory perimeter per CBUAE / SAMA / SEBI requirements.
• Day 61–90: Update asset register and risk assessment to reflect all in-scope sites; assign control owners per entity; calculate additional audit days using IAF MD1 table and budget accordingly (add AED 8K–20K per additional site).
• Day 90+: Submit multi-site scope statement to CB with data flow diagrams; request pre-audit scope confirmation meeting to avoid scope disputes at Stage 1.
• Ongoing: Trigger scope review within 30 days of any acquisition, divestiture or new branch opening; update scope statement and notify CB per accreditation body change-notification requirements.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• Scope coverage: 100% of regulated entities identified in CBUAE/SAMA licensing register included or formally excluded with documented rationale
• Data flow diagram accuracy: ≤2 undocumented cross-boundary data flows found during Stage 2 audit
• Multi-site audit days: calculated per IAF MD1 — base days + 30–50% of the theoretical additional-site days for each sampled site
• Scope change notification lead time: CB notified within 30 calendar days of any material organisational change
• Shared-service SLA coverage: 100% of in-scope shared IT services covered by a formal OLA with defined security obligations

The working checklist

Use this list during your next ISO/IEC 27001 review cycle. The phrasing is intentionally observable — every item is something a reviewer can sample for, not an aspiration.

• Verify: management review minutes that skip the required inputs in Clause 9.3.2.
• Verify: ISMS scope.
• Verify: SoA.
• Verify: risk register.
• Verify: risk treatment plan.
• Verify: management review minutes.

Pitfalls we keep seeing

Across MAST Consulting Group's ISO/IEC 27001 portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: asset inventory that does not reconcile to the risk register. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: management review minutes that skip the required inputs in Clause 9.3.2. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: scope statement that excludes a customer-facing platform. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: SoA justifications that copy the control text. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on ISO/IEC 27001 engagements because the integrations are cheap and the evidence is defensible:

• Jira / ServiceNow for nonconformity tracking — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• Entra / Okta for access evidence — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• Confluence or SharePoint for the documented information set — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs ISO/IEC 27001 programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this checklist is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for ISO/IEC 27001 programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.