A gap analysis is a structured comparison of your current security and compliance practices against a target state, usually a compliance framework, a control catalog, or customer requirements, so you can see what is missing, weak, or undocumented before an audit or certification effort.
In GRC and audit readiness work, a gap analysis is a readiness exercise. It is not the audit itself. Auditors later test design and operating effectiveness with audit evidence. A gap analysis helps your team find issues early, assign owners, and plan remediation while there is still time.
In simple terms, a gap analysis answers:
- What does the target framework or customer ask us to do?
- What do we already do, and can we prove it?
- Where are the gaps, who owns fixing them, and by when?
Related practices include control mapping, corrective action plans, and CAPA. Those tools often follow a gap analysis. They are not the same as the analysis itself.
Why Gap Analysis Matters
Buying a framework binder or standing up a policy library does not mean you are ready for fieldwork. Systems, ownership, and evidence quality vary. A gap analysis makes that variance visible.
Gap analysis matters because:
- It turns abstract framework language into a concrete punch list of missing controls, weak procedures, and evidence gaps.
- It reduces surprise findings late in SOC 2 audit preparation.
- It helps leaders sequence remediation by risk instead of treating every checklist item as equal.
- It creates a shared baseline for engineering, security, and compliance owners before the audit period starts.
- It supports continuous compliance when you re-run light gap checks as systems change, rather than waiting for the next annual scramble.
Without a deliberate gap pass, teams often discover the same missing access reviews, vendor packets, or logging gaps under auditor pressure.
How a Gap Analysis Works
Teams run gap analyses with spreadsheets, GRC tools, or consultant workbooks. The operating shape is usually similar:
- Choose the target. Pick the framework or obligation set (for example, SOC 2 Security, ISO 27001 Annex A themes, or a customer security addendum) and define scope: systems, products, locations, and trust criteria if SOC 2 applies.
- Inventory what exists. Collect policies, procedures, architecture notes, control lists, recent tickets, and sample evidence from systems such as GitHub, Jira, Okta, AWS, and Google Workspace.
- Map requirements to current practice. Use control mapping so each requirement points to an owner, a control description, and expected proof.
- Rate each item. Common ratings include met, partially met, not met, or not applicable, with short notes on why.
- Document gaps and risk. Describe what is missing (policy, process, tooling, ownership, or evidence) and the business or audit impact.
- Plan remediation. Convert gaps into work: owners, due dates, and either a corrective action plan or escalation into CAPA when issues are systemic.
- Re-check before fieldwork. Confirm closed gaps have dated proof, and open items have tracked exceptions or accepted residual risk.
A gap analysis can be deep (full framework walkthrough) or focused (one domain such as access or vendors). Depth should match the decision you need: first SOC 2 readiness, a new product in scope, or a post-incident control refresh.
Gap Analysis vs Audit vs Risk Assessment
Keep these activities distinct so stakeholders know what outcome to expect.
| Activity | Primary question | Typical output | Who usually leads |
|---|---|---|---|
| Gap analysis | Where do we fall short of a target framework or control set? | Gap register, ratings, remediation plan | Internal compliance/security, sometimes with advisors |
| Risk assessment | What could go wrong, how bad, and how likely? | Risk register, treatment decisions | Security/risk owners |
| Audit / examination | Do controls exist and operate as described for the scoped period or point in time? | Opinion or report based on tested audit evidence | Independent auditor or assessor |
A risk assessment can inform which gaps to close first. An audit tests whether controls worked. A gap analysis sits in the middle as a readiness and planning tool. None of the three replaces the others.
Examples
| Activity reviewed | Gap found | Follow-up |
|---|---|---|
| Quarterly privileged access review | Reviews ran for production Okta apps, but cloud IAM admin roles were never sampled | Expand population, assign cloud owner, add to next review packet |
| Production change management | Pull requests exist, but emergency changes lack retrospective approval tickets | Update procedure, create break-glass template, train on-call leads |
| Vendor due diligence | Critical SaaS vendors on file, but SOC reports expired mid-year with no exception | Open exception management records, request bridge letters, calendar renewals |
| Security awareness training | Policy requires annual training; completion export shows 60% unfinished | Reminder campaign, manager escalation, evidence refresh before period end |
| Logging and monitoring | Alerts fire, but triage tickets omit closure timestamps | Fix ticket workflow, sample closed alerts as evidence |
| Backup restore tests | Backups configured; no documented restore test in 12 months | Schedule restore drill, retain ticket and result notes |
These examples illustrate how a gap becomes owned work with proof, not only a red cell in a spreadsheet.
Framework Notes: SOC 2 and ISO 27001
SOC 2
For SOC 2, a gap analysis usually walks Trust Services Criteria in scope (Security is common; Availability, Processing Integrity, Confidentiality, and Privacy may be added) against your system description and control set. Teams check whether each relevant criterion has a designed control, an owner, and a realistic evidence path for Type 1 design readiness or Type 2 operating effectiveness over the period. See SOC 2 Type 1 vs Type 2 when planning how deep operating evidence must go. Related reading on proof quality: What Is SOC 2 Evidence?.
Exact testing is defined later by your auditor. A gap analysis does not create a SOC 2 report and does not certify anything.
ISO 27001
For ISO 27001-oriented programs, gap work often compares current practice to the Information Security Management System (ISMS) requirements and selected Annex A controls. Typical early gaps include incomplete asset inventories, unclear risk treatment records, missing Statement of Applicability decisions, and weak linkage between risks and implemented controls. As with SOC 2, the gap register is an internal planning artifact, not a certificate.
Other frameworks (HIPAA, PCI DSS, NIST CSF themes) follow the same pattern: define target, map current state, rate gaps, remediate, re-check. Reuse mapped controls carefully rather than assuming one spreadsheet satisfies every obligation set.
Common Gap Analysis Failures
Watch for these recurring issues:
- Treating the gap analysis as a one-hour checklist read-through with no system exports or owner interviews
- Marking items "met" because a policy PDF exists, even when no operating evidence exists
- Skipping control mapping, so remediation work cannot be traced to requirements
- Creating a long gap list with no owners, due dates, or risk ranking
- Ignoring evidence quality: undated screenshots, missing populations, or narratives without system-of-record exports
- Freezing the gap register after kickoff while the environment changes (control drift)
- Confusing gap findings with audit findings, or presenting an internal gap pass as assurance to customers
- Closing gaps on paper without collecting fresh evidence collection artifacts that prove the fix
These failures often surface again during fieldwork as follow-up requests and delayed timelines.
Evidence From a Gap Analysis
A useful gap package typically includes:
- Scope statement (systems, frameworks, criteria, date of analysis)
- Requirement-to-control mapping workbook or export
- Ratings and narrative notes per item
- Gap register with owners, severity, and target dates
- Links or references to sample evidence reviewed during the analysis
- Remediation plan or tickets (and, when needed, a corrective action plan)
- Re-test notes when gaps are claimed closed
Retain this package under your record-keeping rules. Auditors may not require your internal gap workbook, but customers and leadership often do, and it becomes the backbone of readiness tracking. Prefer exports and tickets from systems of record over reconstructed stories. See audit evidence collection for operating habits that keep packets strong.
Continuous Compliance Bridge
A single pre-audit gap analysis helps you start. It is not enough on its own for a Type 2 period. Continuous compliance means you keep collecting proof as controls operate, watch for new gaps when systems change, and refresh ratings before they become period-wide misses.
Light, recurring gap checks (for example after major product launches, new cloud accounts, or vendor onboarding spikes) catch issues while remediation is still cheap. Related reading: AuditFlo's continuous compliance resource.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams practice continuous evidence collection and retain audit-period history so control proof is organized while you close gaps and prepare for fieldwork.
The focus is mapping artifacts to controls, preserving dates and ownership, and reducing last-minute screenshots across common systems such as GitHub, Jira, Okta, AWS, and Google Workspace. AuditFlo is framed here as evidence and readiness support for the gap remediation and collection process your program defines. It is not a claim that AuditFlo performs your gap analysis for you, certifies readiness, replaces auditors, or guarantees compliance.
To see the workflow for your stack, request a demo.
Key Takeaway
A gap analysis compares your current controls and evidence against a target framework or requirement set, then produces a rated list of missing or weak areas with owners and follow-up. It is a readiness and planning tool, not an audit opinion and not the same as a risk assessment. Use clear control mapping, convert gaps into corrective work (and CAPA when issues are systemic), keep dated proof of closures, and re-check as the environment changes so readiness survives the full audit period.