Definition

The Statement of Applicability (SoA) is the mandatory ISO 27001 document (clause 6.1.3d) that lists all Annex A controls, records whether each is applicable, provides justification for exclusions, and links implementation status to the risk treatment plan. Stage 1 auditors use the SoA as the primary lens to assess ISMS design completeness before granting Stage 2 access.

Why it matters

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

• A Major NC on the SoA at Stage 1 halts the entire audit cycle; CB reschedules Stage 2 only after closure evidence is accepted, adding 4–12 weeks and AED 15K–40K in re-audit fees.
• DIFC PDPL and ADGM DPR require documented control applicability for personal data processing — an incomplete SoA creates dual-framework exposure beyond ISO certification risk.
• Investors and acquirers during M&A due diligence in GCC SaaS deals (Series B+) now request the SoA as a standalone artefact; gaps discovered at that stage can reduce valuation multiples.
• Auditors from BSI and Bureau Veritas have publicly noted that SoA version drift (SoA not updated after organisational changes) is the single most common Stage 1 finding across MENA-region clients.

Evidence sources to capture

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

• SoA document — version history tab showing date, author, change description and approver for each revision
• Risk Treatment Plan — cross-reference table linking each applicable control ID to ≥1 risk ID and a named control owner
• Policy register — hyperlinks from SoA rows to the live policy/procedure document with last-reviewed date
• Organisational chart and asset register — used to demonstrate scope boundary decisions that justify any excluded controls (e.g. A.7.x physical controls excluded for cloud-only ISMS)
• Management Review minutes — evidence that SoA was formally reviewed and approved by senior management within the past 12 months (clause 9.3)

Recommended next actions

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

• Day 0–30: ISMS Manager audits every SoA row for the five most common errors: missing justification for excluded controls, orphaned controls not linked to any risk, version not matching current org structure, applicability not updated after cloud migration, and implementation status marked 'planned' older than 6 months.
• Day 31–60: Control owners validate that each 'implemented' row has a live evidence artefact (policy, screenshot, ticket) hyperlinked directly in the SoA; ISMS Manager removes stale 'in progress' statuses.
• Day 61–90: Legal/Compliance team cross-checks SoA exclusions against any contractual or regulatory obligations (SAMA CSF 3.3.5, NCA ECC-1 2-1) that mandate specific controls regardless of risk assessment outcome.
• Day 90+: ISMS Manager submits updated SoA to CB at least 2 weeks before Stage 1 date; retains version-controlled copy in SharePoint/Confluence with access log.
• Ongoing: Any ISMS change (new system, new supplier, new jurisdiction) triggers a SoA impact assessment within 15 business days per defined change management procedure.

Example metrics

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

• SoA completeness: 100% of 93 Annex A:2022 controls with non-blank justification field before Stage 1
• Orphaned controls (no linked risk ID): 0 at Stage 1 submission
• Implementation status accuracy: ≤5% of 'implemented' rows found without valid evidence artefact during internal audit
• SoA review cycle: reviewed and re-approved within 12 months — target 100% compliance with clause 9.3 cadence
• Stage 1 Major NCs attributable to SoA errors: target 0 across consecutive certification cycles

How it played out

The engagement began the way these always do — a specific trigger (pattern recognition from 80+ isms audits — the soa errors that cost teams a clean stage 1 opinion.) and an executive sponsor with limited patience for theoretical answers.

The first instinct on the client side was to add tooling. The first instinct on our side was to fix the internal audit programme so that whatever tooling was added would have somewhere defensible to land.

What surprised the team — and worth noting for anyone running similar ISO/IEC 27001 work — is how much of the value came from re-sequencing existing activities rather than introducing new ones.

• Trigger. The work was sponsored after a near-miss the executive team could no longer rationalise.
• First week. Stabilise the nonconformity log; pause anything that risked making it worse.
• Weeks 2–6. Rebuild the working evidence cadence; the regulator-facing story followed naturally once the internal cadence was honest.
• What we'd do differently. Engage the executive sponsor for certification on day one, not after the diagnostic.

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: internal audit programme without independence from the function audited. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• 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.

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 field note 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.