From gap report to project plan: owners, evidence and timelines

Running a gap analysis is the easy part. Our step-by-step guide gets you to a tracker with every unmet requirement listed. What happens next decides whether the programme lands: too many trackers stay as long spreadsheets of rows marked "not met" that nobody owns.

Step 1: group rows into workstreams

Requirements are numbered by the framework's logic, not yours. Regroup unmet rows by what will fix them:

• Governance and policy (scope, roles, policies, management approval)
• Identity and access
• Vulnerability and patch management
• Logging and monitoring
• Incident response and reporting
• Supplier management
• Business continuity and backup
• Secure development
• Physical security

One workstream often closes ten or twenty rows. Writing supplier security terms into contracts, for example, can satisfy requirements in ISO 27001, PCI DSS, GDPR and NIS2 at once.

Step 2: sequence by dependency and risk

1. Unblockers first: scope, governance, policy and risk assessment. Technical work without them gets redone.
2. High-risk gaps next: exposed systems without MFA, unpatched internet-facing services, untested backups.
3. Then the rest, with documentation and evidence collection running alongside, not at the end.

Step 3: estimate honestly

For each workstream: the work, who does it, how long, and what it costs (people, tools, external help). Hidden costs usually sit in running the control afterwards (a quarterly review is four meetings a year, forever), not in setting it up.

Step 4: assign owners who will run the control

The owner of a remediation task should be the person who will operate the control afterwards: the IT manager for patching, procurement for supplier contracts, HR for screening. The compliance lead coordinates, checks evidence and reports progress, but can't own everything.

Step 5: define "done" as evidence

A task is done when the control operates and produces evidence: the first access review signed off, the first restore test recorded, the policy approved and communicated. Put the evidence reference in the tracker as you go; at audit time, the tracker is your evidence index.

A worked example

Suppose an ISO 27001-certified company needs NIS2. The ISO 27001 → NIS2 gap report maps every NIS2 point to something in ISO, but validation against reality finds a dozen points only partly met. Grouped by fix, they collapse into four workstreams:

• Governance: management approval of the measures and management training (one board session, one training course, recorded).
• Reporting: a significant-incident procedure with 24- and 72-hour deadlines, templates and an exercise.
• Suppliers: selection criteria, contract clauses and a review of the top twenty suppliers.
• Technical depth: vulnerability disclosure, a cryptography policy and effectiveness metrics.

Four owners, four plans, each with a date and an evidence list, instead of a dozen unrelated rows. Governance and reporting go first because supervisors will ask about them first; the technical depth follows over the next quarter.

Key takeaways

• Regroup unmet requirements by what will fix them, not by requirement number.
• Do governance, scope and policy first; they unblock everything else.
• Give each workstream an owner who will run the control afterwards.
• Define done as a control that operates and produces evidence.

Step 6: report progress simply

Leadership wants three numbers: requirements met, in progress and not started, by workstream, plus the risks that are late. Re-run the gap analysis periodically; when it's computed from live data, as ours is, the coverage figures move as you close gaps and as frameworks change.

For the starting point, run the gap analysis between the framework you have and the one you need, and export it. The comparisons show the most common pairs in both directions.

Questions

How should compliance gaps be prioritised?

By risk and dependency: first the gaps that block others (governance, scope, policy), then high-risk technical gaps, then documentation and evidence. Requirement numbering is a poor guide to order.

Who should own compliance remediation tasks?

The people who will run the control afterwards, not the compliance team. Compliance coordinates and checks evidence; control owners deliver.

How detailed should a compliance project plan be?

Detailed enough that each workstream has an owner, a deliverable, a date and an evidence list. Requirement-level detail belongs in the tracker; the plan should fit on a page or two.