Updated:
September 24, 2026
September 24, 2026
TL;DR: A useful gap-analysis record connects a requirement to the current evidence, assessment, action, owner and deadline, then records how the fix was verified. The fields are the easy part. What decides whether the record reduces risk is defining what counts as a verified fix before the work starts, and keeping the record true as the systems it describes change. Use the inline fields, two completed examples and closure record below. Adapt the scope and interpretation to your framework; no single table establishes compliance on its own.
Open last year's gap analysis. Somewhere in it is a row marked closed that isn't closed anymore. The control lapsed months ago, nothing in the file noticed, and the first you hear of it is the assessor's question.
That is not a template problem. A gap record measures a state on the day you took it, then reads as something permanent: a requirement matched to a status, an owner, a date, filed once and closed. The state keeps moving. The record doesn't move with it.
So the first job of a gap record is the one no template can do for you: let the next person understand the finding without reconstructing your investigation, and still trust what it says when they read it.
Write it to answer four questions. Which requirement did you assess? What did the evidence show? What must change, and what will count as a verified fix? And how will you know when that answer stops being true? The first three shape the fields below. The last one keeps the record a measurement you can act on rather than a memory of work you once did.
Use the blank structure below to record the assessment, then compare it with two completed examples and a closure record. The examples are fictional: their people, systems, priorities and deadlines illustrate the method rather than prescribe a legal requirement.
If you first need to establish the assessment scope and process, read how to run a compliance gap analysis. This page picks up at the working record: turning what you found into an action another person can verify.
The template: context, nine core fields and closure
Nine fields capture the core finding, but they need an assessment context. Without the framework version, scope and evidence reference, a clear-looking row can describe the wrong system or an earlier state. Record that context once for the assessment, then note exceptions on individual findings.
Finish the record with closure evidence, verifier, verification date and result, and the next review trigger. Keep the initial assessment and the later decision apart. Replacing “gap” with “met” without retaining the history erases the reason the work happened.
This is a working convention, not a universal auditor-mandated set of columns. Add fields your assessment needs. A framework-specific Statement of Applicability, risk assessment or regulatory register may require a different structure and remains a separate record.
How to assign a status without hiding uncertainty
The status summarizes a conclusion; it is not the conclusion's evidence. Use met when the assessed evidence supports the requirement in scope, partially met when only part is satisfied, and unmet when the assessment establishes that the required condition is absent. Use not assessed when the work or evidence is insufficient to conclude. Not applicable needs an applicability reason and the appropriate review.
A control without an automated feed may still operate effectively. A record without evidence may still describe a real control, but the assessor cannot assume it meets the requirement. A table that collected cleanly still fails if it excludes the population the requirement covers.
A status also carries a date it does not print: it is only as current as the last time someone checked the evidence beneath it. Copy a status forward into a new cycle without rechecking that evidence, and you have recorded a past conclusion as a present fact. That is the quiet way a clean-looking record slips out of step with the systems it describes.
Keep the type of gap in the description when it helps assign the work. Missing implementation calls for a different fix from missing documentation; partial coverage differs from an overdue review or missing approval. Don't force one finding into a single category.
Two completed gap records
The examples use relative dates: Day 0 is the fictional assessment date. In a real record, replace those labels with calendar dates and link to the actual artifacts. The priorities are the example team's decisions, not ratings supplied by a regulation.
Example 1: privileged authentication misses the internal policy
Assume the organization has adopted an internal policy requiring phishing-resistant authentication for all interactive privileged accounts in its production identity tenant. That is the explicit baseline assessed below. NIS2’s Article 21(2)(j) refers to MFA or continuous authentication where appropriate; it does not by itself establish this specific universal phishing-resistant requirement. The applicable national rules and the organization's risk-based implementation still need their own review.
The wording matters. “NIS2 MFA gap” would obscure which requirement the team actually tested and could overstate what the directive says. A specific policy reference makes the action clear while preserving the separate regulatory judgment.
Example 2: a new service has no established security-testing process
Assume a new service processes sensitive personal data. The team has identified restore testing and review of security measures as appropriate for that processing, but the service was omitted from the existing testing program. GDPR Article 32(1)(d) calls for a process of regular testing, assessment and evaluation in the context of risk-appropriate security. The problem here is the missing process and scope, not an unsupported claim that every annual test is too infrequent.
Both examples separate a finding from a general statement that a framework is satisfied. Closing one authentication or testing gap does not establish compliance with every requirement in that framework.
What a completed closure record looks like
Return to the privileged-authentication finding. On Day 8, Alex reports that the two users are enrolled. That is a progress update. Jordan still needs to inspect whether the fix meets AC-7 in the defined scope.
The closure standard was written into the action before implementation. That makes disagreement useful: if the verifier cannot confirm the population or policy enforcement, the record identifies what remains to be done. A due date and a completed ticket cannot substitute for that check. This is the line between a record that reduces risk and one that only performs the work. Closing a finding on its due date with the evidence left out is compliance theater at the scale of a single row: the ticket reads done, and nothing in the record shows the required state is in place.
Adapting the record to different frameworks
You can reuse the record structure across frameworks, but each finding needs its own assessment. Keep the applicable requirement, terminology and review expectations visible rather than treating every framework as another column with the same answer.
Read the four that follow together and a pattern shows through. Each expects its answer kept current in response to change and risk, not settled once on a calendar date: DORA names explicit review triggers, NIS2 resists a single fixed cadence, and GDPR ties appropriate security to context rather than a fixed interval. That is the same reason the record cannot be a once-a-year artifact. It has to show the answer is still current at the moment each framework expects it refreshed.
DORA
DORA Article 6(5) requires review of the ICT risk-management framework at least annually, or periodically for microenterprises, with additional triggers including major ICT-related incidents and relevant testing or audit conclusions. Record the applicable trigger and review evidence. Article 28's ICT third-party register is a separate obligation with prescribed register templates; this gap record can track a deficiency in it, but cannot replace the register.
NIS2
NIS2 Article 21 includes policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Identify the national implementing requirements and any applicable implementing rules for the entity, then document how the assessed measure answers them. An EU transposition deadline alone does not determine every entity's current national obligations or a single testing cadence.
GDPR
GDPR Article 32 places security measures in the context of processing risk, available technology, implementation costs and the nature of the processing. Record that rationale alongside the assessment. A fixed checklist or testing interval cannot establish appropriate security for every organization.
SOC 2
Use the applicable Trust Services Criteria, report scope and period. Security criteria are always included; other categories depend on scope. SOC 2 is an attestation, not a certification, and a closed readiness finding does not determine the CPA's report. Keep the criterion and evidence period in the record.
For framework-specific assessment detail, the HIPAA gap-analysis checklist explains Security Rule requirements and the separate risk analysis, while the ISO 27001 gap-analysis article covers management-system requirements, controls and the Statement of Applicability. Use this record to track their findings without replacing those distinct requirements.
Keeping the record useful as evidence changes
A record is true on the day you write it and begins to age the moment the systems it describes change. The two administrator accounts in the first example can regress the next time access is provisioned; the testing process in the second can lapse when the service is re-platformed. Nothing in the table notices. This is control drift, and it is why a record stays useful through the freshness of its evidence, not the number of its columns. Revisit it when scope, requirements or controls change, and when a scheduled review comes due. Shared evidence can reduce duplicate work, but the control-to-requirement mapping must still explain where that evidence applies.
There is a fast way to see how far a record has already aged. Take your last one and mark, beside each row, the date the evidence behind it was produced, not the date you filled the row in. The spread you find is the real output of the exercise: it sorts the findings you have measured recently from the ones you are carrying on memory, and the oldest evidence is usually where a closed gap has quietly reopened.
This is where the source of your evidence matters more than the shape of your table. In Anecdotes, evidence collected from 230+ plugins is normalized into records that analysis rules recheck against configured conditions, so a row that passed once surfaces again when the data beneath it moves. Findings management can link the issue to its supporting records and assign an owner; configured playbooks determine which events open findings, and finding events can also create tasks. Those mechanisms keep the evidence and action fields current between reviews. They do not make a rule result equivalent to the full assessment, and they do not remove the person who confirms that a gap is closed.
When keeping these records synchronized across sources and frameworks becomes difficult, use the gap-analysis software comparison to test that workflow. Bring a completed example, including a partial result and closure evidence, so the demonstration follows the work your team actually needs to maintain.
The goal is a smaller version of this every year
A gap record exists because a program cannot otherwise answer a question on demand: where do we actually stand, right now. Every field in the table above is a workaround for not knowing.
So the measure of a good record is not how complete it is. It is how much of it you have to fill in by hand next cycle. When the evidence behind a row refreshes on its own, and a change reopens the finding without anyone remembering to look, the record stops being an artifact you produce and becomes a view of something already true.
You will still assess. You will still decide what counts as a verified fix, and you will still be the one who closes it. There is just less reconstruction between the question and the answer.
Common questions
What fields should a compliance gap analysis template contain?
Include the requirement, expected outcome, current state, assessment, gap, priority, action, owner and deadline. Keep scope, evidence references and assessment responsibility alongside them, then record verification and the next review. Adapt the structure to the relevant framework and program.
Is missing evidence the same as a failed control?
No. It may mean the assessment is incomplete. Record what is known, request what is missing and distinguish an unknown conclusion from a confirmed failure. A missing mapping also does not prove that no control operates.
When is a gap ready to close?
When the agreed verification establishes that the corrective action addresses the finding in scope, with the evidence and review decision retained. If the control needs a period of operation to demonstrate effectiveness, a successful configuration change alone is not enough.
