Home · Synthesis · cl-vuln-identification

Vulnerability management programme — discovery, prioritisation, remediation

CERT-In ISO 27001 NIST CSF 2.0 PCI DSS RBI CSF RBI ITGRCA SEBI CSCRF CIS Controls v8.1 CSA CCM v4 MeitY CSP NIS2 NIST 800-53 SOC 2

Primary statement

The vulnerability management programme operates as: (1) continuous discovery across all IT systems via scheduled scanning (critical externally-facing weekly, internal monthly, code on every build) augmented by attack surface management (ASM) for external assets and Software Bill of Materials (SBOM) for critical and customer-facing software; (2) intake from multiple sources — scans, CVD process, threat intelligence feeds, CERT-In KEV advisories; (3) prioritisation using risk-based ranking (criticality of system + exploitability + active exploitation); (4) remediation with SLA: critical 15 days, high 30 days, medium 90 days, KEV/actively-exploited within an accelerated emergency window; (5) closure tracked with re-test evidence; (6) VAPT after every major release plus periodic deeper testing.

Audit-fatigue payoff

A single vulnerability management programme — SEBI CSCRF PR.11 cadence + PR.10 patch SLAs + RBI ITGRCA RM.3 VAPT methodology + CERT-In KEV remediation discipline + SBOM register — satisfies vulnerability requirements across all 16 contributing frameworks. The auditor's typical 8–10 tests across frameworks (scanning cadence, patch SLA compliance, VAPT scope, manual pen-test depth, KEV remediation, SBOM, CVD, DevSecOps integration) collapse to one programme dashboard with one closure tracker. Without unification, each framework's vulnerability test is independent; with unification, the programme is the answer.

Strictness matrix

Scope

VAPT scope: ALL IT systems — not just cyber security controls, not just internet-facing. Frequency calibrated to risk: quarterly for critical, annual for important, ad-hoc for material change. Scanning scope per SEBI CSCRF PR.11: all systems on cadence — critical externally-facing weekly, internal monthly, code on every build. The integrated scope is universal across the IT estate. Ceiling source: rbi_itgrca:ITGRCA.RM.3 Rationale: RBI ITGRCA RM.3 specifies the broadest VAPT scope ("all IT systems, not just cyber security controls"). Other frameworks address subsets (SEBI PR.4 release-triggered; CIS scanning-focused). The ITGRCA scope is the audit-defensible superset.

Threshold

KEV (Known Exploited Vulnerabilities) — as tracked by CERT-In advisories — are the lowest-threshold trigger for emergency remediation. Any KEV affecting an in-scope system triggers emergency patch process regardless of routine SLA. For non-KEV vulnerabilities, patch SLA per criticality: critical 15 days (SEBI PR.10) / 30 days (PCI 6.3.3); high 30 days; medium 90 days. Detection-to-action threshold: continuous (within scanning cadence). Ceiling source: cert_in:CERTIN.21 Rationale: CERT-In Direction 21 with KEV remediation language is the strictest threshold articulator — it short-circuits the routine SLA when a vulnerability is actively exploited. PCI DSS 6.3.3 (critical patches within 30 days) and SEBI PR.10 (15 days) provide the routine SLA floor.

Method

Method: (1) continuous scanning per system class (external-facing critical weekly, internal monthly, code on every build); (2) intake from threat intelligence, vendor advisories, CERT-In KEV feed, internal scans, and CVD external reports (CERT-In Direction 8); (3) risk-based prioritisation considering criticality, exploitability, and active exploitation status; (4) remediation per SLA with documented closure and re-test; (5) VAPT after every major release plus periodic deeper testing; (6) DevSecOps integration where applicable — pipeline-enforced security gates on every build; (7) SBOM register for critical and customer-facing software with version-tracked dependencies. Ceiling source: sebi_cscrf:CSCRF.PR.11 Rationale: SEBI CSCRF PR.11 specifies the most prescriptive method — continuous scanning with explicit per-system-class cadences. Combined with the CERT-In CVD (Direction 8) and SBOM (Direction 6) requirements, this is the audit-defensible programme specification.

Frequency

Patch SLA cadence: critical 15 days (SEBI PR.10 — tighter than PCI's 30 days); high 30 days; medium 90 days; KEV / actively-exploited within emergency window (typically 48–72 hours from CERT-In advisory). Scanning cadence: critical external weekly, internal monthly, code on every build. VAPT cadence: after every major release plus quarterly for critical / annual for important per ITGRCA RM.3. Risk review cadence: senior management quarterly, Audit Committee half-yearly, Board annually per ITGRCA RM.16. Ceiling source: sebi_cscrf:CSCRF.PR.10 Rationale: SEBI CSCRF PR.10 patch SLAs (critical 15 days) are tighter than PCI DSS 6.3.3 (critical 30 days). The 15-day floor is the audit-defensible cadence for critical patches.

Evidence

Required evidence: (1) VAPT programme document with scope, cadence, methodology per system class; (2) recent VAPT reports (12–24 months sample) with manual-test evidence (not just scan output); (3) finding register with closure dates and re-test evidence; (4) scanning platform configuration and coverage matrix; (5) patch compliance dashboard against SLA with exception reasoning; (6) KEV-remediation tracking against CERT-In advisories; (7) SBOM for critical and customer-facing software with versioned dependency tracking; (8) CVD intake channel with sample disclosures handled; (9) DevSecOps pipeline configuration (where applicable) showing security gates enforced. Ceiling source: rbi_itgrca:ITGRCA.RM.3 Rationale: RBI ITGRCA RM.3 carries the most comprehensive evidence enumeration. The manual-test-evidence requirement (not just scan output) is uniquely strict — other frameworks accept scan reports as VAPT evidence; ITGRCA requires demonstrable manual testing of business logic, authorisation, and authentication.

Auditor test pattern

Step 1: Inspect the VAPT programme document; verify scope covers all IT systems with risk-based cadence. Step 2: Sample 1 recent VAPT report; verify manual penetration testing was performed (not just scan output) and verify the CERT-In empanelment of the testing firm. Step 3: Inspect the patch compliance dashboard; sample 3 critical vulnerabilities from the past 12 months and verify SLA compliance with re-test evidence. Step 4: Cross-check 3 recent CERT-In KEV advisories against the organisation's remediation record; verify emergency-window discipline. Step 5: Inspect the SBOM for a sample critical application; verify it is current and version-tracked. Step 6: For organisations operating DevSecOps, verify pipeline-enforced security gates fail on critical findings (not advisory only).

Common findings

Common 2024–26 findings: (1) VAPT scan reports without manual testing evidence — automated tools alone do not test business logic or authentication / authorisation flaws; (2) Lead firm not CERT-In empanelled, creating an audit credentialing gap; (3) Findings closed by self-attestation without re-test; (4) Patch compliance dashboards exist but exceptions never close out — same gaps recur quarter over quarter; (5) KEV advisories not tracked against organisational systems; emergency-window discipline absent; (6) SBOM not maintained or maintained only at first release without version tracking; (7) DevSecOps pipelines have security gates that warn but do not fail builds on critical findings; (8) CVD process exists but the disclosure channel is hard to find or unmonitored.