Gap Analysis for Regulatory Change: The Method That Survives Scrutiny

Gap analysis is one of those techniques that sounds straightforward until you actually try to run one on a regulated programme. You map the current state, you map the target state, you list the gaps, you plan the remediation. In practice the exercise either takes so long that the target state has moved by the time you finish, or it produces a list of gaps that are too vague to act on, or it discovers at the end that the current state was documented differently by three different teams and the gaps differ depending on whose map you believe.

This post covers a gap analysis method that we have seen work in regulated programmes: DORA implementation, Consumer Duty embedding, Operational Resilience, AI governance rollouts, and target operating model redesigns. The method trades some elegance for robustness. It produces an artefact that holds up under scrutiny and drives a remediation plan that actually runs.

What gap analysis is for

Gap analysis answers a specific question: given where we are today and where we need to be, what specifically has to change and in what order. Every word in that sentence matters.

• Specifically: gaps are concrete things that can be remediated, not abstract shortfalls.
• Has to change: not "might change", not "could change". The deltas that the target state demands.
• In what order: the remediation sequence is part of the output, because gaps often depend on each other.

A gap analysis that produces a list without priorities is a half-finished analysis.

The method

The method has six steps. Each step is compulsory. Skipping any one of them produces a gap analysis that looks complete but fails when acted on.

Step 1: define the scope boundary

Before anything else, define what the analysis covers. The scope of a gap analysis is usually set by the regulation or strategic decision that triggered it: the Operational Resilience requirement, the Consumer Duty outcomes, the AI governance framework, the target operating model for a specific business unit.

Define scope along three dimensions: the regulatory or strategic framework, the organisational perimeter (which entities, business units, regions), and the artefact perimeter (which processes, systems, controls are in scope). Scope creep in a gap analysis is fatal because each new item multiplies the effort.

Step 2: define the target state

The target state is the first thing you define, not the current state. This is counter-intuitive but matters. If you define the current state first, you tend to describe the target state in terms of the current state's vocabulary and structure, which means the comparison is skewed.

The target state comes from the regulation (for example, the DORA articles the firm must comply with by 17 January 2025), the strategic decision (for example, the target operating model for wealth management), or the architectural principles (for example, the target data architecture). The target state is described in its own vocabulary, with its own structure.

For each target-state element, capture:

• The description of the element
• The source (regulatory article, strategic document, architectural principle)
• The acceptance criteria (how will we know this element is in place)
• The evidence required (what artefact or test demonstrates it)
• The owner accountable for the target state in operation

This is where many gap analyses go wrong. The target state is described too loosely. "Implement DORA Article 8 ICT risk management framework" is not a target state description. The target state decomposes Article 8 into its specific requirements, each with acceptance criteria and evidence.

Step 3: map the current state

Now map the current state, using the same structure and vocabulary as the target state. For every target-state element, describe what exists today.

Three honest answers are possible:

• In place: the element exists, meets the acceptance criteria, and has the evidence.
• Partially in place: the element exists but does not fully meet the acceptance criteria or the evidence is incomplete.
• Not in place: the element does not exist.

Avoid gradations beyond these three. "75 percent in place" is a phrase that lets a team avoid a decision. Either it meets the acceptance criteria or it does not. If it partially meets them, document what is missing.

This is the step where most gap analyses have quality problems. The current state is described by the teams that operate it, who have strong incentives to describe their area as "in place". The counterweight is a consistent definition of "in place" and a cross-team reviewer who applies the definition uniformly.

Step 4: articulate the gaps

For each target-state element that is not fully in place, describe the gap in specific, actionable terms. A good gap description says what exists, what is missing, and what the missing piece looks like.

Bad gap: "AI governance framework gap."

Good gap: "Under DORA Article 15, the firm must maintain a register of ICT third-party arrangements that includes AI vendor arrangements with a concentration risk assessment. The existing third-party register covers ICT vendors but does not identify AI vendors as a category, does not include concentration risk assessment for AI, and does not link to the exit strategies required. Remediation requires (a) extending the register schema to capture AI-specific attributes, (b) populating the register for existing AI vendors, (c) conducting concentration risk assessment for identified AI vendors, (d) documenting exit strategies for each."

The good gap description can be turned directly into a workstream. The bad one cannot.

Step 5: prioritise and sequence

Gaps are not equal. Some are mandatory by a hard deadline. Some are enabling (must happen before others can start). Some are discretionary in timing. Prioritisation uses four inputs:

• Regulatory deadline: when does the target state have to be in place.
• Dependencies: which gaps must be closed before other gaps can be worked on.
• Risk impact: the consequence of leaving the gap unremediated.
• Effort: approximate cost and timeline to close.

Priority is not a single score. It is a view across these four inputs, often captured in a priority matrix. The output of Step 5 is a remediation sequence: which gaps are closed first, which concurrently, which later.

Step 6: establish the remediation plan

For each gap or group of gaps, establish a remediation workstream with an owner, a timeline, a budget estimate, key milestones, and a definition of done that matches the target-state acceptance criteria. This step is where the gap analysis artefact turns into the programme plan.

The remediation plan references the RAID log (see our RAID log post) for the risks, assumptions and dependencies specific to remediation. It references the change impact assessment for the change management workstream. It references the stakeholder register for the engagement plan.

The artefact

A gap analysis produces a structured artefact, not a narrative document. The core of the artefact is a table or structured list with, per gap:

• Gap ID
• Target-state element reference
• Current-state description
• Gap description
• Regulatory or strategic source
• Priority (high/medium/low with justification)
• Owner
• Remediation workstream reference
• Target close date
• Dependencies (other gap IDs)
• Evidence of closure (what will be retained)

Supporting sections cover the scope, the target-state description, the method, the prioritisation approach, and the remediation plan overview. The structured data is the part that drives operations. The narrative sections frame it.

Common failure modes

Failure: the narrative-only analysis

The analysis is a 40-page Word document. It reads well. It does not have a structured gap list. Acting on it requires each reader to extract gaps themselves, and different readers extract different gaps. Fix: the gap list is structured data, not prose. Prose explains. Structure operates.

Failure: the optimistic current state

Teams describe their areas as "in place" when the evidence is incomplete. The gap analysis understates the work needed. The remediation plan is too small. At go-live the firm is not actually compliant. Fix: independent review of current-state descriptions against documented acceptance criteria and evidence. Cross-team reviewers rather than self-assessment.

Failure: the scope that grows

The analysis starts scoped to DORA. A stakeholder asks to add Consumer Duty. Another asks to add EU AI Act. By month three the scope is four regulations and the analysis is late. Fix: scope decisions are locked at the outset. New regulations are separate analyses, potentially running in parallel, not additions to the first.

Failure: the gap without a remediation owner

Gaps are identified without clear ownership. The remediation workstream never forms because no one is accountable. Fix: the gap is not closed in the analysis until an owner is assigned. Unassigned gaps are escalated.

Failure: the static analysis

The gap analysis is completed, signed off, and filed. The regulatory interpretation evolves, the current state changes through business-as-usual work, the target state is revised. The analysis is never updated. Six months later it describes a world that no longer exists. Fix: the analysis is maintained as a live artefact for as long as remediation is in progress. When a gap is closed, it is closed in the artefact. When the target state changes, the analysis is re-run against the new target state.

Worked example: DORA ICT third-party register gap analysis

Scope: DORA Article 28 on ICT third-party arrangements, as applied to the firm's UK and EU legal entities.

Target state: register covering all ICT third-party arrangements, with criticality classification, contractual terms, exit strategy, and concentration risk assessment.

Current state: partial register covering IT infrastructure vendors. Does not include AI vendors, does not include SaaS providers below a materiality threshold, criticality classification is ad hoc, contractual terms are not consistently linked, exit strategies are not documented for most arrangements.

Gap list (abbreviated):

• G-001: AI vendors missing from register. Regulatory source: Article 28(1)(a). Priority: high (DORA effective Jan 2025). Owner: CIO Office.
• G-002: Below-threshold SaaS providers missing. Regulatory source: Article 28(1)(a). Priority: medium. Owner: Procurement.
• G-003: Criticality classification inconsistent. Regulatory source: Article 28(2). Priority: high. Owner: Head of ICT Risk.
• G-004: Contractual terms not linked in register. Regulatory source: Article 30. Priority: medium. Owner: Legal.
• G-005: Exit strategies missing. Regulatory source: Article 28(8). Priority: high. Owner: Head of ICT Risk.
• G-006: Concentration risk assessment not conducted. Regulatory source: Article 29. Priority: high (depends on G-001, G-002, G-003). Owner: CRO.

Remediation plan: establish a register remediation workstream, sequence G-001 to G-005 before G-006, target closure by end Q3 2024 before the 17 January 2025 DORA effective date.

This is the level of specificity that makes a gap analysis actionable. Vaguer descriptions would collapse in the first steering committee review.

External references

The FCA Handbook SYSC covers systems and controls requirements that often appear in gap analyses for UK financial services firms. The ECB supervisory expectations provide the European equivalent. For DORA specifically, the ESAs joint guidelines on DORA are the canonical interpretation.

The short version

A gap analysis that works is structured, not narrative. It defines target state first, describes current state consistently, articulates gaps at a level of specificity that can be operated on, prioritises against regulatory deadlines and dependencies, and transitions into a remediation plan with accountable owners.

Programmes that invest in the method we have described here produce an artefact that survives scrutiny and a remediation plan that runs. Programmes that shortcut the method produce documents that look complete and fail when tested.

Our regulatory compliance transformation service includes gap analysis as part of the regulatory change toolkit. For the adjacent artefacts, see the regulatory change readiness resource and the target operating model framework.