Document Owner: Security / Vulnerability Management
Approved By: [Senior Leadership / CISO] (simulation)
Effective Date: 2026-02-28
Version: 1.0
Status: Approved (simulation)
This policy defines the minimum requirements to identify, assess, prioritize, remediate, and validate security vulnerabilities across the organization in a consistent and measurable way.
This policy applies to:
- Servers, endpoints, and cloud assets managed by the organization (production and non-production)
- Operating systems, applications, and third-party software installed on organizational assets
- Systems owned or operated by internal teams and approved third parties where contractually applicable
- Vulnerability: A weakness that could be exploited to compromise confidentiality, integrity, or availability.
- Authenticated Scan: A vulnerability scan performed with approved credentials to improve accuracy and coverage.
- Asset Owner: The team or individual accountable for the system/service and remediation decisions.
- CAB: Change Advisory Board (used to review/approve production-impacting changes).
- The Vulnerability Management function is responsible for scanning coordination, triage support, reporting, and tracking remediation outcomes.
- Asset Owners are responsible for timely remediation or formally approved exceptions.
- Infrastructure / Platform teams support patching, configuration hardening, and deployment changes.
- Changes to production systems must follow change-control requirements (CAB where applicable).
- Vulnerability scanning must occur on a defined cadence:
- External / Internet-facing assets: at least monthly
- Internal assets: at least monthly (or per risk tier)
- After major changes: re-scan required to validate security posture
- Authenticated scans should be used whenever possible to reduce false positives and improve finding quality.
- Scan credentials must be protected using least privilege and stored securely (e.g., secrets manager / vault).
Vulnerabilities are prioritized using:
- Severity (e.g., Critical / High / Medium / Low)
- Asset criticality (business impact tier)
- Exploitability and exposure (internet-facing vs internal, known exploitation)
- Compensating controls and operational constraints
Unless otherwise approved via exception:
- Critical: remediate within 7 days
- High: remediate within 30 days
- Medium: remediate within 60 days
- Low: remediate within 90 days
Note: These targets can be adjusted by leadership for specific environments. Any deviation must be documented as an exception.
- Remediation that impacts production availability, compatibility, or customer experience must follow change-control procedures (CAB review/approval).
- All changes must include:
- Implementation steps
- Validation steps
- Rollback steps
- Owner and approver
- Remediation is considered complete only after:
- A successful re-scan verifies the vulnerability is resolved, or
- The vulnerability is documented as a false positive with evidence and approved disposition
- Evidence must be retained for audits and program metrics.
If remediation cannot be completed within SLA:
- Asset Owner must submit an exception request including:
- Business justification
- Risk description
- Compensating controls
- Expiration date / review date (time-bound)
- Approvals (Security + leadership)
- Exceptions must be reviewed at least quarterly (or earlier if risk changes).
The program maintains ongoing reporting that includes:
- Total findings by severity
- SLA compliance (on-time vs overdue)
- Mean Time To Remediate (MTTR)
- Aging vulnerabilities (30/60/90+ day buckets)
- Re-open rate (recurring issues)
Non-compliance may result in escalation to leadership and risk acceptance requirements. Repeated non-compliance may trigger additional controls, segmentation, or removal of systems from service until minimum standards are met.
- NIST SP 800-53 (Security and Privacy Controls)
- NIST SP 800-40 (Guide to Enterprise Patch Management Planning)
- CIS Controls (vulnerability management related safeguards)
This document is intentionally sanitized for public portfolio use and omits internal system identifiers, IPs, hostnames, and proprietary process details.