A gap analysis answers a specific question: where do your current security controls fall short of what a framework, standard, or security baseline requires? It produces a documented map of the distance between your current state and your target state: which controls exist, which are partially implemented, which are absent entirely, and which exist on paper but have not been validated in practice.
The output is not a finding of exploitable vulnerabilities. That is a penetration test. Understanding the distinction matters because many organisations commission a gap analysis when they need a penetration test, and vice versa. The gap analysis tells you where controls are missing. The penetration test tells you whether those missing controls can be exploited.
Both are inputs to a security remediation roadmap. The gap analysis comes first.
A cybersecurity gap analysis compares your current security controls (as they are implemented and operated today) against a defined target: a compliance framework (ISO 27001, SOC 2, NIST CSF, PCI DSS, HIPAA), a regulatory baseline, or an internally defined security standard.
The methodology is review-based: documentation review, interviews with control owners, configuration inspection, and observation of processes. The output is a gap register: a structured list of control areas where the current state falls short of the target, typically including:
This document becomes the foundation of the security improvement roadmap. Every remediation project, control implementation, and policy revision flows from the gap register.
Gap analyses across all major frameworks consistently surface gaps in the same five domains. Understanding where gaps concentrate helps prioritise the assessment and shapes the remediation roadmap.
Access controls are the most consistently gapped domain across all frameworks. Common gaps include:
Privileged access management: Administrator and service accounts without formal review cycles. Shared administrator credentials with no individual accountability. Privileged access not constrained by least-privilege principles.
Access provisioning and deprovisioning: New joiner access granted without formal approval workflow. Leaver accounts not disabled within defined SLAs. Role changes that accumulate permissions without removing previous role access (permission creep).
MFA enforcement: Multi-factor authentication required by policy but not enforced on all access paths. Legacy systems and internal applications excluded from MFA enforcement. VPN and remote access without MFA.
Why this domain is consistently gapped: Access control accumulates debt. Initial configurations are reasonable; the debt builds through exceptions, legacy systems, and the friction of enforcing consistent controls across a heterogeneous environment.
The application security testing domain is frequently underdeveloped relative to framework requirements, particularly for organisations that have invested primarily in network and infrastructure security.
Code security review: No SAST in the development pipeline, or SAST configured but findings not actioned. No process for reviewing third-party code or open-source dependencies.
Penetration testing cadence: Annual penetration testing required by the framework but occurring less frequently, or point-in-time testing with no process for testing after significant code changes.
Vulnerability management for applications: CVEs managed for infrastructure but not for application dependencies. No SBOM (Software Bill of Materials) process.
Why this domain is consistently gapped: Application security requires integration with development workflows that security teams do not control. The gap is frequently not a missing policy but a missing enforcement mechanism in the CI/CD pipeline.
Logging coverage: Logs collected from some systems but not all. Authentication events, privileged access actions, and configuration changes not captured across all environments.
Detection capability: SIEM deployed but alert rules not tuned. False positive rates high enough that analysts ignore alerts. No baseline for normal behaviour established.
Incident response plan: IRP documented but not tested. No tabletop exercise in the previous 12 months. Incident classification thresholds not defined. No documented process for external communication during a breach.
Why this domain is consistently gapped: Detection requires ongoing tuning, which requires dedicated security operations capacity that many organisations have not scaled to match their environment size.
Vendor security assessment: Critical vendors not subject to security due diligence. No formal process for assessing vendor security posture before contract award. No ongoing monitoring of vendor security status.
Contractual controls: Vendor agreements without security requirements, audit rights, or incident notification obligations.
Access control for third parties: Vendor and contractor accounts with broader access than their role requires. No review cycle for third-party access. Third-party access not revoked promptly at contract end.
Why this domain is consistently gapped: Third-party risk management requires coordination between procurement, legal, and security: three functions that rarely share a coherent workflow.
Data inventory: No formal inventory of where sensitive data is stored, transmitted, and processed. Customer data, employee data, and regulated data (PCI, PHI, personal data) not classified and mapped.
Encryption coverage: Data at rest not encrypted across all storage systems. Encryption keys managed without formal key rotation schedule.
Data retention and disposal: No enforced retention policy. Data retained beyond its business purpose. No formal secure disposal process for end-of-life storage.
Why this domain is consistently gapped: Data mapping requires cooperation across engineering, product, and legal. The gap is frequently one of documentation and governance rather than missing technical controls.
A gap analysis follows a structured methodology regardless of which framework is the target.
Step 1: Define the scope and target framework. Which framework are you assessing against? Which organisational units, systems, and processes are in scope? A gap analysis for SOC 2 Type II readiness has a different scope than one for ISO 27001 certification. Define both boundaries before beginning evidence collection.
Step 2: Inventory current controls. Document what controls exist in each framework domain: not what the policy says should exist, but what is actually implemented and operating.This requires: reviewing existing policy documentation, interviewing control owners, inspecting system configurations, and observing processes. The documentation review tells you what should exist; the control owner interviews and configuration inspection tell you what does exist.
Step 3: Map current controls to framework requirements. For each framework control requirement, assess the current state against a four-level rating: fully implemented (the control meets the requirement), partially implemented (the control partially meets the requirement with specific gaps), not implemented (no control exists), or not applicable (the requirement does not apply to this scope with documented rationale).
Step 4: Document gaps with risk context. For each partially implemented or not implemented control, document the specific gap, the framework requirement it falls short of, and the assessed risk: the likelihood that the gap will be exploited and the impact if it is.
Step 5: Prioritise the gap register. Sort the gap register by risk priority, not alphabetically or by framework section number. The highest-priority gaps are those where the likelihood of exploitation is highest and the business impact of exploitation is greatest.
Step 6: Build the remediation roadmap. Convert the prioritised gap register into a time-bound remediation plan: which gaps will be addressed in which quarter, what resources are required, who owns each remediation action, and what the target state looks like for each gap.
The distinction Framework Security draws at position 2 in the SERP is worth making clearly: a gap analysis measures the distance between your current state and a framework. A framework assessment (or audit) measures whether your controls satisfy the framework. These are related but different activities.
A gap analysis is typically an internal exercise conducted before a formal certification or audit, with the goal of identifying and closing gaps before the auditor arrives. A framework assessment is conducted by an independent third party, produces formal evidence for certification, and cannot be corrected mid-engagement if gaps are discovered.
Many organisations conduct a gap analysis, build a remediation roadmap, implement the remediations, and then engage an independent auditor for the framework assessment. The gap analysis feeds the remediation roadmap; the assessment produces the certification evidence. Security audit vs penetration testing: what each one actually proves covers the distinction between these evidence types in detail.
A gap analysis is a review-based exercise. It identifies controls that are absent or insufficient by comparing documentation and configurations against a framework. It does not test whether gaps that exist are actually exploitable.
This distinction matters for prioritisation. A gap analysis that identifies 47 control gaps produces a list ranked by assessed risk, but the risk assessment is based on the analyst's judgment about likelihood and impact, not on confirmed evidence. Some gaps rated high-risk by the analyst may have compensating controls that substantially reduce actual risk. Some gaps rated medium-risk may be trivially exploitable and on active attacker radar.
Penetration testing validates the gap analysis output by attempting to exploit the vulnerabilities that identified gaps create. A gap in application penetration testing cadence identified in the gap analysis is a policy finding. A confirmed exploitable SQL injection found because the gap allowed the vulnerability to be introduced without testing is a security finding. The first tells you a control is absent. The second tells you what the absent control enabled an attacker to do.
The practical integration: after a gap analysis identifies critical control gaps, commission targeted penetration testing focused on the systems and processes where those gaps exist. The penetration test output validates which gaps are actually exploitable, which changes the prioritisation of the remediation roadmap.
Vulnerability prioritization: why exploit proof beats CVSS scores covers how exploit-confirmed findings override gap-analysis risk ratings in the remediation queue. Agentic pentesting and continuous security validation covers how continuous testing closes the gap between periodic gap analysis cycles and the ongoing security validation that frameworks increasingly require.
SOC 2: A SOC 2 readiness gap analysis assesses controls against the Trust Services Criteria. The critical gap domains for most SaaS companies are logical access controls (CC6), change management (CC8), and risk assessment (CC3). SOC 2 penetration testing: what auditors actually require covers what penetration testing evidence the SOC 2 audit requires alongside the gap analysis output.
ISO 27001: An ISO 27001 gap analysis assesses the ISMS (Information Security Management System) against Annex A controls. The gap analysis produces the Statement of Applicability (SoA): the formal document that declares which Annex A controls apply to the scope and their implementation status. ISO 27001 penetration testing: what auditors look for covers the technical testing requirement alongside the gap analysis.
NIST CSF: A NIST CSF gap analysis maps current controls against the five functions (Identify, Protect, Detect, Respond, Recover) and their component categories. It produces a current-state profile and a target-state profile; the gap between them is the remediation roadmap.
Cyber insurance: A pre-application gap analysis that assesses controls against the underwriter's questionnaire requirements can identify gaps before they affect insurability or premiums. Cyber insurance requirements: what underwriters expect from penetration testing covers the specific controls underwriters assess.
Zero trust: For organisations implementing zero trust architecture, a gap analysis against NIST SP 800-207 identifies gaps in identity controls, microsegmentation, and continuous monitoring. Zero trust architecture: how penetration testing validates what you've built covers the penetration testing that validates the zero trust controls identified as present in the gap analysis.
The gap register should be actionable, not academic. Each entry should contain enough information for a control owner to understand what the gap is and what closing it requires, without needing to refer back to the analyst who conducted the assessment.
Minimum gap register content per finding:
| Field | Purpose |
|---|---|
| Framework reference | Which control requirement is not met |
| Current state | What is actually in place today |
| Target state | What the framework or baseline requires |
| Gap narrative | The specific difference in one paragraph |
| Risk rating | High / medium / low with brief rationale |
| Recommended remediation | Specific action to close the gap |
| Owner | Who is responsible for remediation |
| Target date | When the gap will be closed |
| Evidence required | What documentation will prove closure |
The final two fields (owner and target date) are frequently omitted and consistently the reason gap analysis outputs are not actioned. A gap register without assigned owners is a document. A gap register with assigned owners and target dates is a remediation plan. Penetration testing remediation: what happens after the findings come in covers the remediation workflow structure that applies equally to gap analysis output and penetration test findings.
The CTEM framework formalises this: continuous threat exposure management treats gap analysis as the scoping input to the continuous exposure management cycle. The gap register defines what must be validated; the validation stage confirms which gaps are actually exploitable.
For penetration testing services in the US that validate gap analysis findings by confirming which identified gaps are actually exploitable, VAPT services for the combined assessment and testing engagement that addresses both gap identification and exploitability validation, and PTaaS for continuous validation that keeps pace with ongoing gap remediation, the 10x Pentest platform covers the application security validation layer. See pricing or get in touch to discuss how penetration testing integrates with your gap analysis and compliance programme.
Q1. What is a cybersecurity gap analysis?
A cybersecurity gap analysis is a structured comparison of an organisation's current security controls against a defined target: a compliance framework (ISO 27001, SOC 2, NIST CSF, PCI DSS), a regulatory baseline, or an internally defined security standard. It identifies which controls fully meet the requirement, which partially meet it, and which are absent entirely. The output is a gap register: a documented list of control shortfalls with assessed risk ratings and recommended remediation actions. A gap analysis is a review-based exercise; it does not involve active exploitation of vulnerabilities. It answers "where are your controls missing?" not "can those missing controls be exploited?"
Q2. What is the difference between a gap analysis and a penetration test?
A gap analysis reviews documentation, configurations, and processes to identify where security controls fall short of a framework or baseline. It produces a list of control gaps. A penetration test actively attempts to exploit vulnerabilities to confirm which gaps are actually exploitable and what an attacker could do. The two are complementary: gap analysis identifies where controls are absent or insufficient; penetration testing confirms whether those gaps create exploitable vulnerabilities. For compliance purposes, a gap analysis provides evidence that control gaps have been identified and remediated; penetration testing provides evidence that the controls that remain actually resist attack. Most organisations use gap analysis to build a remediation roadmap and penetration testing to validate that the remediated controls hold.
Q3. How long does a cybersecurity gap analysis take?
Duration depends on scope: the number of framework controls being assessed, the size and complexity of the organisation, and the completeness of existing documentation. A focused gap analysis for SOC 2 readiness for a SaaS company with 50-200 employees typically takes two to four weeks including documentation collection, interviews, gap register development, and report production. A full ISO 27001 gap analysis for a larger organisation with complex infrastructure may take four to eight weeks. A limited gap analysis against a specific domain (identity and access management, incident response) can be completed in days if the scope is tightly defined.
Q4. What frameworks are commonly used for a cybersecurity gap analysis?
The most commonly assessed frameworks are: ISO 27001 (international information security management standard, required for certification in many enterprise procurement processes), SOC 2 (US-originated trust services criteria, required by many enterprise customers of SaaS companies), NIST CSF (US National Institute of Standards and Technology Cybersecurity Framework, widely used as a voluntary baseline), PCI DSS (required for organisations handling payment card data), and HIPAA Security Rule (required for US healthcare organisations handling protected health information). CIS Controls and NIST 800-53 are also used as gap analysis baselines in US federal and defence contexts. The choice of framework depends on the organisation's regulatory environment, customer requirements, and target certifications.
Q5. What should happen after a cybersecurity gap analysis?
After the gap analysis produces a prioritised gap register, the organisation should: assign ownership of each gap to a named individual or team, set target remediation dates by risk priority (high gaps before medium gaps, medium before low), implement the recommended remediations in priority order, and collect evidence that each remediation has been completed. After remediating high-risk gaps (particularly gaps in application security testing and access control), commission penetration testing to validate that the remediations are effective and that the gaps identified in the analysis do not enable exploitable vulnerabilities. The penetration test output confirms which remediations closed the exposure and identifies any remaining vulnerabilities the gap analysis's review-based methodology could not detect.
A security audit proves your controls exist and are operating. A penetration test proves whether those controls hold under attack. A vulnerability assessment identifies what could be exploited. These are different types of evidence for different questions.
Tejas Dhokane Oct 12, 2026 
CVSS scores rate how severe a vulnerability could be. Exploit proof shows what an attacker can actually do to your systems right now. They are different types of evidence, and prioritization should treat them differently.
Tejas Dhokane Oct 9, 2026 
ASPM consolidates AppSec tool findings into a unified risk view. But the tools it aggregates mostly identify potential vulnerabilities not confirmed ones. Continuous pentesting fills the validation gap that ASPM platforms reference but do not provide.
Tejas Dhokane Oct 9, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
