Vulnerability Management process
Process
- Discover: accept findings from code review, dependency review, provider advisories, VAPT, authenticated testing, monitoring, incidents, researchers, and supplier notices.
- Validate: confirm the affected asset, version, reachability, reproducibility, evidence, and whether the finding is a duplicate or false positive.
- Prioritise: consider severity, exploitability, exposure, data sensitivity, tenant isolation, known exploitation, compensating controls, and business impact.
- Assign: record an accountable technical owner, risk owner, target date, and interim controls.
- Remediate: patch, reconfigure, restrict, redesign, remove, or accept the risk through a dated exception.
- Verify: retest the exact attack path and relevant regression behavior; a code change alone is not closure.
- Close and learn: retain evidence, update related controls, and report trends and overdue risk.
Target treatment times
These are initial operating targets, measured from validated finding to verified remediation.
| Priority | Target | Escalation |
|---|---|---|
| Critical | 72 hours | Immediate management escalation and containment; shorter where actively exploited |
| High | 14 days | Weekly risk-owner review until closure |
| Medium | 30 days | Escalate when due date is at risk |
| Low | 90 days | Address through planned maintenance or accepted risk |
Contractual or regulatory deadlines override these targets when stricter.
Exceptions
Risk acceptance requires the finding, impact, reason, compensating controls, approver, expiry, and review date. Critical actively exploited exposure cannot be accepted without immediate containment and accountable management decision.
Vulnerability record schema
| Field | Purpose |
|---|---|
| Finding identity | Stable reference used across scanner, review, remediation, deployment, exception, and retest evidence |
| Affected asset and version | Exact application, dependency, provider configuration, data domain, endpoint class, or release in scope |
| Discovery source and date | SAST, dependency scan, VAPT, provider advisor, incident, review, or researcher provenance |
| Technical condition | Reproducible preconditions, trust boundary, vulnerable behavior, and evidence without publishing exploit-enabling secrets |
| Business impact | Confidentiality, integrity, availability, tenant-isolation, privacy, financial, and operational consequences |
| Priority | Base severity adjusted for reachability, exploitation, data sensitivity, known exploitation, and compensating controls |
| Ownership | Technical remediation owner, risk owner, due date, and escalation path |
| Treatment | Patch, configuration, restriction, redesign, removal, mitigation, or time-bounded risk acceptance |
| Release linkage | Corrected revision, migration, provider change, deployment, and rollback dependency |
| Retest | Tester, date, exact attack path, related regression scope, result, and residual risk |
| Closure | Risk-owner approval, evidence reference, closed date, and any follow-up monitoring |
Prioritisation rules
Known exploitation, exposed authentication bypass, cross-tenant access, privileged credential exposure, unauthorised financial action, or broad sensitive-data impact triggers immediate containment regardless of the nominal scanner score. A finding is not downgraded only because the current UI hides the vulnerable operation. Compensating controls reduce residual risk only when they are verified on the exact attack path and have an accountable owner and monitoring signal.
Current-state limitation
The process now exists, but historical closure evidence, automated SAST/DAST/dependency scanning, independent retest evidence, a consolidated vulnerability register, and demonstrated adherence to these targets were not available. Accordingly, checklist items requesting past reports remain unavailable rather than being backfilled with unperformed tests.