Definition

ISO 22301:2019 is the international standard for Business Continuity Management Systems (BCMS), requiring organisations to identify disruption impacts through a Business Impact Analysis (BIA), develop plans covering personnel, facilities, technology, and supply chain, and validate those plans through regular exercises. A BCMS that 'doesn't sit on a shelf' is one whose plans are exercised at minimum annually, updated after every material change or incident, and owned by operational managers rather than a central BCP team.

Why it matters

The pressure on GRC Advisory programmes is shifting in specific, observable ways:

• SAMA CSF 3.6.1 and NCA ECC-1 3-1-1 require a certified or compliant BCMS with documented BIA, tested plans, and board-approved recovery objectives; non-compliance attracts supervisory letters with remediation deadlines of 90–180 days.
• ISO 22301 Clause 8.4.5 mandates that exercises test actual recovery capability, not just plan awareness; table-top exercises alone (the most common approach) do not satisfy this clause — at least one technical recovery exercise per 12 months is required.
• The average cost of an unplanned IT outage for a mid-market UAE financial institution is AED 850K–3.2M per hour (including regulatory penalty, revenue loss, and reputational cost); BIA-validated RTO/RPO targets directly influence recovery investment decisions.
• Cyber-induced disruptions (ransomware, DDoS) are now the primary BIA scenario in GCC regulated sectors — plans that reference only data-centre failure scenarios fail the realism test in ISO 22301 Clause 8.2 (business impact analysis) and examiner review.

Evidence sources to capture

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

• BIA register — process name, Maximum Tolerable Period of Disruption (MTPD), RTO, RPO, dependencies, owner, last-reviewed date.
• Business continuity plan documents — version number, approval date, distribution list, exercise history log.
• Exercise report — exercise type (table-top / simulation / full technical), date, participants, gaps identified, remediation actions with owners and due dates.
• Post-incident review report — incident date, BCP invocation decision, plan sections used, deviations noted, plan update triggered.
• ISO 22301 certification or surveillance audit report — non-conformities, observations, closing actions.

Recommended next actions

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

• Day 0–30: BCMS Manager runs structured BIA workshops with the top 10 business processes by revenue impact; captures MTPD, RTO, and RPO for each; validates cyber-disruption scenario explicitly (ransomware, data-centre isolation).
• Day 31–60: Recovery plans updated to reflect BIA outputs; technical recovery runbooks written for top-3 critical systems (core banking, payment gateway, identity provider) with step-by-step owner-assigned tasks.
• Day 61–90: Conduct one unannounced table-top exercise (ransomware scenario); follow with a technical recovery test for one non-production critical system; document gaps and assign remediation owners.
• Day 90+: ISO 22301 gap assessment against Clause 8 (operations) by internal BCMS lead; remediate all majors before next surveillance audit; CISO presents BIA results and exercise outcomes to board.
• Ongoing: Annual full exercise cycle (table-top Q1, technical recovery Q3); BIA reviewed within 30 days of any material technology or organisational change; BCMS Manager submits exercise reports to risk committee within 15 business days of exercise completion.

Example metrics

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

• Percentage of critical processes with BIA-validated RTO/RPO documented and board-approved — target 100%.
• Exercise completion rate vs. annual plan — target 100% (all scheduled exercises executed).
• Plan activation test success rate (critical systems recovered within RTO during technical exercise) — target ≥90%.
• Time from material change to BIA/plan update — target ≤30 calendar days.
• ISO 22301 surveillance audit major non-conformities — target 0; minor non-conformities ≤2 per cycle.

A the next two quarters working plan

MAST Consulting Group runs this GRC Advisory work in four moves. Each move is short, evidence-producing, and signed off by a Lead Practitioner before the next begins.

• Frame (week 1). Confirm scope, regulators in play, and the decisions the work has to enable — referenced against the three lines of defence. Without that framing, the rest becomes a documentation exercise the audit committee will not read.
• Diagnose (weeks 2–4). Walk through control testing programme and KRI dashboard as they exist today. Capture not just gaps but the design decisions behind every existing control — those are usually where audit findings hide.
• Design (weeks 5–8). Make the contested choices early and pre-clear them with sector regulators (CBUAE, SAMA, DFSA, RBI, SEBI, IRDAI). Document the rationale; GRC Advisory reviewers care more about reasoned decisions than perfect ones.
• Operate (weeks 9–12). Move evidence collection into BI tools (Power BI, Tableau) for board dashboards and GRC platforms (Archer, ServiceNow IRM, OneTrust). A control that depends on a separate GRC tool nobody opens will fail within two cycles.

Pitfalls we keep seeing

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

• Pattern: issue tracker maintained in parallel by audit, risk and compliance. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: risk appetite statement that the second line cannot operationalise. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: duplicate controls across ISO/SOC/PCI catalogues with no master mapping. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: KRIs that move but no one is accountable for the response. 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 GRC Advisory engagements because the integrations are cheap and the evidence is defensible:

• BI tools (Power BI, Tableau) for board dashboards — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• GRC platforms (Archer, ServiceNow IRM, OneTrust) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• or a deliberately spreadsheet-and-Confluence stack for early-stage programmes — 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 GRC Advisory 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 playbook 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 GRC Advisory programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.