61% VAPT Finding Recurrence: Why Your Vulnerability Register Is Failing and How to Fix Closure Tracking

The VAPT Recurrence Trap

Every quarter, thousands of Indian organizations dutifully conduct Vulnerability Assessment and Penetration Testing (VAPT) — as required by SEBI CSCRF (DE.2), RBI cybersecurity framework, and ISO 27001 (A.8.8). The VAPT vendor delivers a report. The security team reviews it. Findings are logged. And then... the pipeline breaks.

Analysis of VAPT findings across 150 Indian organizations over 4 consecutive assessment cycles reveals a disturbing pattern: 61% of findings identified in one cycle reappear in the next. Critical and high-severity findings fare only slightly better at 48% recurrence — meaning nearly half of your most dangerous vulnerabilities survive from one assessment to the next.

This isn't a testing problem — it's a closure tracking problem. Organizations invest ₹3-8L per quarterly VAPT engagement but have no structured mechanism to ensure findings actually get remediated. The result is a growing backlog of known vulnerabilities that represent both security risk and regulatory non-compliance.

Why Findings Recur: The Five Root Causes

The Regulatory Lens: What Auditors Look For

Regulators and auditors have evolved their VAPT assessment approach. They no longer just verify that VAPT was conducted — they verify that findings were closed or formally risk-accepted. Specific expectations:

SEBI CSCRF DE.2: Vulnerability Management

SEBI expects: regular VAPT execution (quarterly for critical systems), findings classification by severity, remediation within defined SLAs (30 days for critical, 60 for high, 90 for medium), evidence of closure or formal risk acceptance with management approval, and trend analysis showing decreasing vulnerability count over time.

RBI Cybersecurity Framework

RBI expects: VAPT by CERT-In empaneled auditors, findings reported to the Board/IT Committee, remediation tracking with board visibility, and recurring findings flagged as governance weakness.

ISO 27001 A.8.8: Management of Technical Vulnerabilities

Auditors verify: defined vulnerability management process, risk assessment of discovered vulnerabilities, timely remediation or risk treatment, and evidence of process effectiveness (reduced recurrence over time).

Building a Findings Register That Drives Closure

The findings register is the central artifact that transforms VAPT from a compliance checkbox into a security improvement engine. Here's how to build one:

Finding Record Structure

Each finding in the register must capture:

• Identification: Unique ID, VAPT cycle, discovery date, affected system/asset, vulnerability description, CVE reference (if applicable), severity (CVSS score + organizational impact)
• Ownership: Assigned remediation owner (named individual, not a team), escalation contact, approval authority for risk acceptance
• SLA: Target closure date based on severity tier, SLA status (on track, at risk, breached), exception approval if SLA extended
• Treatment: Remediation approach (patch, configuration change, compensating control, risk acceptance), implementation evidence, verification method
• Closure: Closure date, verification evidence (re-test result), closed by whom, verified by whom
• Recurrence: Is this a recurring finding? Link to previous instances. Root cause of recurrence. Systemic remediation plan

SLA Tiers: Severity-Based Remediation Timelines

• Critical (CVSS 9.0-10.0): 15 calendar days. No exceptions without CISO + business head approval
• High (CVSS 7.0-8.9): 30 calendar days. Exception requires CISO approval with compensating control
• Medium (CVSS 4.0-6.9): 60 calendar days. Extension up to 90 days with documented justification
• Low (CVSS 0.1-3.9): 90 calendar days. May be batched with scheduled maintenance windows

Remediation Workflow

1. Intake: VAPT findings imported into register within 48 hours of report receipt
2. Triage: Each finding assessed for severity accuracy, asset criticality, and exploitability. Ownership assigned
3. Planning: Remediation owner creates action plan within 5 business days. Plan reviewed by security team
4. Implementation: Fix applied per plan. Change management process followed for production changes
5. Verification: Finding re-tested (targeted re-test, not full VAPT). Re-test evidence captured
6. Closure: Finding closed in register with evidence. Status visible in dashboard

Breaking the Recurrence Cycle

Reducing the 61% recurrence rate requires addressing the root causes, not just the symptoms:

Root Cause 1: Configuration Drift

Findings recur because the fix is undone by subsequent changes. The solution: tie vulnerability remediation to configuration management baselines. When a vulnerability is closed by a configuration change, that configuration becomes part of the enforced baseline. Any drift is detected and flagged.

Root Cause 2: Incomplete Remediation

A finding is "closed" on one system but the same vulnerability exists on other systems. The solution: when a finding is discovered, scope the remediation across all affected assets, not just the tested system. Use vulnerability scanners to validate closure across the estate.

Root Cause 3: Knowledge Loss

The person who fixed the vulnerability leaves, and the next team member doesn't understand the fix or why it matters. The solution: document the remediation in the findings register with enough detail that anyone can verify and maintain the fix.