Building a Vulnerability Management Program in India

A vulnerability management program is the continuous, owned process of finding, prioritising, fixing, and verifying security weaknesses across every asset an organisation runs — not a once-a-year pentest report that sits in a shared drive. For an Indian SMB that has outgrown one-off testing, building one means four connected pieces: a live asset inventory, continuous scanning, risk-based prioritisation using CVSS and EPSS together with exploitability and asset value, and remediation SLAs by severity with real verification. Get these four right and CERT-In and DPDP Act expectations around timely remediation and data safeguarding become a natural by-product, not a scramble.

Why a One-Off VAPT Test Is Not a Vulnerability Management Program

A point-in-time penetration test answers one question: what did an attacker find on the day of the test? It says nothing about the vulnerability introduced three weeks later by a new deployment, the cloud storage bucket a developer forgot to close, or the CVE disclosed against a library already in production. Most Indian SMBs start their security journey with an annual or contractual VAPT engagement — often because a customer, insurer, or regulator asked for one — and stop there. That satisfies a checkbox; it does not reduce risk, because risk changes daily and the assessment does not.

A vulnerability management (VM) program closes that gap. It is not a bigger scanner or a more frequent test; it is a cycle with an owner, a cadence, and a measurable outcome: fewer exploitable vulnerabilities exposed for shorter periods of time.

Step 1: Build and Maintain an Asset Inventory

Every VM program fails at the same first step: an inventory that is out of date the day it is written. An asset inventory needs to cover more than the servers IT remembers:

1. Infrastructure — cloud instances, containers, load balancers, VPNs, and any shadow IT spun up outside a formal change process.
2. Applications — production web apps, internal admin panels, mobile apps, and every API endpoint they expose, including ones built by a vendor or contractor.
3. Third-party and SaaS dependencies — libraries, frameworks, and SaaS tools that hold customer or employee data, since a vulnerability in a dependency is still your exposure.
4. Ownership metadata — who owns each asset, what data it touches, and how business-critical it is. Without this, prioritisation in Step 3 has nothing to weight against.

Step 2: Continuous Vulnerability Scanning

Scanning cadence is where most SMBs under-invest. A single annual scan finds what existed on scan day and misses everything introduced afterward — new CVEs, misconfigurations from a deployment, or a certificate that quietly expired. A working program runs:

1. Authenticated internal and external scans on a scheduled cadence (weekly or continuous, not annual), covering network, host, and configuration layers.
2. Application-layer scanning integrated into the software development lifecycle, so vulnerable code is caught before it reaches production, not after.
3. Cloud configuration scanning, since misconfigured storage, IAM, and network rules are now a larger share of real-world breaches than unpatched software in many environments.

Step 3: Risk-Based Prioritisation — CVSS, EPSS, Exploitability, and Asset Value

Scanners routinely return hundreds or thousands of findings. Triaging by CVSS score alone is a common and costly mistake: CVSS measures theoretical severity, not the likelihood that a specific vulnerability will actually be exploited in the wild. A mature program combines four signals:

1. CVSS base score — the industry-standard measure of technical severity (confidentiality, integrity, availability impact), maintained by FIRST.
2. EPSS (Exploit Prediction Scoring System) — a probability score estimating the likelihood a vulnerability will be exploited in the next 30 days, based on observed exploitation activity. A high-CVSS, low-EPSS finding may wait; a moderate-CVSS, high-EPSS finding on an internet-facing asset should not.
3. Exploitability evidence — whether a public exploit, proof-of-concept, or active exploitation (from threat intel or CERT-In advisories) exists for the specific CVE.
4. Asset value and exposure — a critical vulnerability on an internal, air-gapped test server is not the same risk as a moderate one on a customer-facing payment API. Asset ownership data from Step 1 is what makes this weighting possible.

Step 4: Set Remediation SLAs by Severity

Once findings are triaged by combined risk, they need a deadline with teeth. Without an SLA, "we'll get to it" becomes the default status for months. A defensible SLA table looks like this:

These windows should be documented in policy, tracked automatically against the ticketing system, and reported on — not left as an informal team norm. SLA misses are themselves a metric worth reporting to leadership, since a pattern of missed Critical SLAs is a governance failure, not just a technical one.

Step 5: Patch Management Workflow

Prioritisation and SLAs mean nothing without an operational path to actually apply the fix. A working patch management workflow needs:

1. A defined patch owner per asset class (infrastructure, application, third-party SaaS), so nothing sits unassigned in the backlog.
2. A staging/testing step before production patching, to catch the rare cases where a patch itself breaks functionality — this is what stops "we're afraid to patch" from becoming a valid excuse.
3. Emergency patching procedure for actively exploited vulnerabilities that bypasses the normal change window, aligned to the Critical SLA above.
4. Compensating controls (WAF rules, network segmentation, temporary access restriction) for cases where the vendor patch is not yet available and the SLA clock is still running.

Step 6: Verification and Retesting

A ticket marked "resolved" is a claim, not evidence:

1. Automated rescan confirms the specific finding no longer triggers on the asset.
2. Manual retest for Critical and High findings, especially logic-based application vulnerabilities that automated scanners cannot reliably re-verify on their own.
3. Regression check to confirm the fix did not introduce a new issue or silently disable a control elsewhere.

Step 7: Metrics, Reporting, and Ownership

A VM program needs an accountable owner — typically a CTO or security lead in an SMB without a dedicated security team — and metrics that leadership actually reviews:

1. Mean time to remediate (MTTR), broken down by severity, against the SLA table.
2. SLA compliance rate — the percentage of findings closed within their assigned window.
3. Open vulnerability count by severity and age, trending over time, not just a snapshot.
4. Recurrence rate — how often a previously closed finding reappears, which points at process gaps rather than one-off misses.

Mapping to CERT-In and DPDP Expectations

CERT-In's directions and periodic advisories push toward exactly the behaviours a VM program formalises: timely visibility into what is running, timely reporting of significant incidents, and retained logs to support investigation. A continuous scanning and inventory practice is what makes six-hour incident reporting operationally possible rather than theoretical.

The DPDP Act 2023 does not prescribe a specific technical control set, but its "reasonable security safeguards" language is regularly interpreted — consistent with global practice — to include timely patching of known vulnerabilities that could expose personal data, and demonstrable evidence of a security process rather than an ad-hoc response after an incident. An SMB that can show an asset inventory, a scanning cadence, a documented SLA table, and retest records has a materially stronger position if a breach involving personal data is ever investigated than one that can only point to last year's pentest PDF.

For regulated or high-assurance engagements — tenders, insurer requirements, or enterprise customer due diligence — the underlying VAPT and validation work is typically delivered with a CERT-In empanelled partner where a formal empanelment certificate is specifically required.

Indian SMBs maturing beyond one-off testing can start by mapping their current asset inventory and scan coverage against the steps above, then closing the biggest gap first — usually inventory or SLA enforcement. A free VAPT scan is a practical way to establish a current-state baseline before building out the full program, and Dhisattva AI Pvt Ltd's guidance on safeguarding obligations is covered in more depth in the DPDP compliance resource. Further implementation detail on scanning, prioritisation, and reporting is available on the Bachao.AI blog.

Sources

1. CERT-In Cyber Security Directions, April 2022
2. MeitY — Digital Personal Data Protection Act, 2023
3. NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning