13. Vulnerability and Patch Management #

13.1 Scope and objective #

This section defines how vulnerabilities and misconfigurations are discovered, assessed, prioritized, remediated, and verified for Applications, supporting infrastructure, container images, IaC templates, and third‑party components used by vendors on CLD’s behalf. The objective is to minimize exploitable exposure and provide auditable evidence of timely remediation.

13.2 Discovery and intake #

Vendors must operate continuous, credentialed scanning for internet‑facing assets and at least monthly scanning for internal assets associated with the Application. Discovery sources include authenticated scanners, container/IaC scanners, SAST/SCA (library CVEs), cloud configuration posture checks, vendor advisories, and exploit intelligence. Newly disclosed issues affecting the Application stack (libraries, frameworks, platforms) must be assessed promptly; issues indicating likely or active exploitation must be escalated immediately to the ISO and handled under the Incident Response Plan.

13.3 Risk rating and prioritization #

Each finding must be risk‑rated using a recognized method (e.g., CVSS v3.x), adjusted by environmental factors: exploit availability, internet exposure, data sensitivity (Restricted), control compensations (WAF rules, isolation), and business criticality. Group findings by asset/component and owner, and produce a remediation plan with target dates.

13.4 Remediation SLAs and emergency handling #

Proposed maximum remediation intervals are:

• Critical: 7 calendar days

• High: 30 calendar days

• Medium: 60 calendar days

• Low: 90 calendar days

  PENDING: Confirm or adjust SLA values; define notification thresholds (e.g., notify CLD when Critical > 48 hours open or when compensating controls are applied)

Actively exploited or weaponized issues require immediate containment (e.g., WAF rule, feature flag off, token/key rotation, segmentation) and an out‑of‑band fix as soon as feasible. Containment steps and timelines must be documented and communicated to CLD.

13.5 Changes and safety #

Patching and configuration changes must follow change control (Section 11/Section 18): test in staging, define rollback criteria, and communicate operational impacts. For risky platform changes, prefer canary/blue‑green deployment. Library upgrades must pin to secure versions and update SBOMs.

13.6 Verification and closure #

All remediations must be verified by re‑scan or re‑test and recorded with evidence (scan job IDs/reports, screenshots/log excerpts, version numbers). Findings remain open until verification passes. Where compensating controls are used, define their monitoring and review cadence and keep the finding open in the POA&M until the durable fix is deployed.

13.7 Tracking and reporting #

Maintain a POA&M capturing each finding’s identifier, asset/component, severity, owner, remediation steps, compensating controls (if any), target date, current status, and closure evidence. Provide CLD with periodic status reports that include open findings by severity and age, SLA adherence, mean time to remediate by severity, and repeat findings. PENDING: Reporting cadence (e.g., monthly/quarterly) and format (dashboard/PDF/CSV)

13.8 Third‑party and supply‑chain issues #

Vendors must monitor and address vulnerabilities in third‑party components (SCA findings) and services (subprocessors). For libraries, upgrade to patched versions within SLA or apply safe mitigations; update SBOMs accordingly. For subprocessors/platform CVEs, obtain and share vendor advisories and remediation timelines, and apply local mitigations as needed. Flow down the remediation SLAs and evidence requirements to subprocessors contractually.

13.9 Configuration and cloud posture #

Cloud and platform misconfigurations (e.g., public buckets, overly broad IAM roles, weak TLS ciphers) must be treated as vulnerabilities and remediated within the same SLAs. High‑risk posture checks should alert in near real time and trigger immediate containment when exposure is public or impacts Restricted Data.

13.10 Notification triggers #

The vendor must notify CLD promptly when:

• A Critical vulnerability is open beyond PENDING: __ hours/days without effective containment.

• An actively exploited issue affects the Application or its components.

• A remediation requires a functional change or downtime outside approved windows.

• A subprocessor/platform advisory indicates material risk to CLD data/services.

13.11 Exceptions #

Any deviation from these requirements (e.g., SLA deferral due to vendor patch unavailability) requires an ISO‑approved exception with scope, risk assessment, compensating controls, owner, and expiry. Exceptions must appear in the POA&M and be reviewed at the Post‑Go‑Live review.