Vulnerability and patch management: who owns it on each service model
Finding flaws and fixing them in time. The split follows the stack: whoever runs a layer patches it.
The split by service model
| Service model | Owner | Why, and the clause |
|---|---|---|
| Infrastructure as a service | yours | You patch the guest operating system, the software on it and your images; the provider patches the hypervisor and the hardware. ISO/IEC 27017 12.6.1 |
| Platform as a service | shared | The provider patches the platform and runtime; the code, libraries and container images you deploy onto it are yours to scan and fix. ISO/IEC 27017 12.6.1 |
| Software as a service | the provider's | The provider patches the application and everything under it; you keep only the devices and integrations that reach it. ISO/IEC 27017 12.6.1 |
| Serverless functions and event services | shared | The provider patches the platform and runtime; the code, libraries and container images you deploy onto it are yours to scan and fix. ISO/IEC 27017 12.6.1 |
| Hosted AI models and AI platforms | the provider's | The provider patches the application and everything under it; you keep only the devices and integrations that reach it. ISO/IEC 27017 12.6.1 |
The clauses each framework attaches
6 quoted| Framework | Clause |
|---|---|
| Cloud Controls Matrix v4.0.1 | CCM-TVM-07 Vulnerability Identification |
| ISO/IEC 27017:2015 | ISO/IEC 27017 12.6.1 Management of technical vulnerabilities |
| SOC 2 Trust Services Criteria | SOC 2 CC7.1 Detection and monitoring procedures for security events are in place |
| ISO/IEC 27001:2022 Annex A | ISO/IEC 27001 8.8 Management of technical vulnerabilities |
| CMMC 2.0 | CMMC SI.L2-3.14.1 Flaw Remediation |
| C5 cloud criteria catalogue | C5-OPS-18 Managing Vulnerabilities, Malfunctions and Errors - Concept |
CCM-TVM-07 Vulnerability IdentificationScan organisationally managed assets for vulnerabilities at least monthly through a defined and evaluated process.
- Scan schedules and completed scan records covering the last several months
- Asset coverage evidence comparing scanned assets to the asset inventory
- Authenticated scanning configuration where applicable
- Evaluation that the scanning finds what it should
- Coverage gaps between the asset inventory and what is actually scanned
- Unauthenticated scanning only, understating the findings
- Monthly cadence claimed with gaps in the scan history
ISO/IEC 27017 12.6.1 Management of technical vulnerabilitiesTechnical vulnerabilities in a cloud service are divided between what the provider patches and what the customer patches, and the provider should give the customer information about how it manages vulnerabilities affecting the cloud service, including the parts the provider patches and the parts the customer must patch itself, and the notification it gives. The customer should manage vulnerabilities in the components it controls (its virtual machines, applications and configuration) and should track the provider's handling of the rest.
- Provider vulnerability management statement and notification channel
- Customer vulnerability process covering cloud-hosted components it controls
- Patch records for customer-managed cloud assets
- Customer assumes the provider patches guest operating systems it actually leaves to the customer
- No provider channel for vulnerability notification the customer monitors
SOC 2 CC7.1 Detection and monitoring procedures for security events are in placeTo meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities
- Defined configuration standards or baselines and evidence of monitoring for changes that introduce new vulnerabilities
- Vulnerability scanning results for the period, including scope, frequency and whether scanning is authenticated
- Evidence of monitoring for newly discovered vulnerabilities affecting the technologies in use
- Records of deviations detected, the assessment of them and the remediation taken
- Evidence the monitoring covers infrastructure, applications and cloud configuration
- Configuration monitored at build only, so drift introduced afterwards is never detected
- Scanning performed quarterly against an environment that changes daily
- Newly published vulnerabilities tracked for operating systems while application and library exposure is unmonitored
- Detected deviations recorded with no remediation timeline and no follow up
ISO/IEC 27001 8.8 Management of technical vulnerabilitiesObtain vulnerability information, evaluate exposure, and take appropriate remediation.
- Vulnerability feed logs
- Risk assessment reports
- Remediation ticket records
- Patch deployment evidence
- Relying on ad-hoc scans only
- Missing documented risk ranking for vulnerabilities
- No evidence of timely remediation verification
- Failure to retain proof of feed subscription
CMMC SI.L2-3.14.1 Flaw Remediation Level 1 and 2Identify system flaws, report them, and correct them within a timely period.
- Flaw identification sources and process
- Patch and remediation records with dates showing timeliness
- Defined timeframes for correction by severity
- Flaws identified but remediation timeframes undefined
- Patching covers operating systems only, omitting applications and firmware
- Reporting step absent so flaws are not tracked
C5-OPS-18 Managing Vulnerabilities, Malfunctions and Errors - ConceptPublish technical and organisational rules for vulnerability handling requiring regular identification of vulnerabilities, assessment of their severity, prioritised remediation or mitigation within defined timelines, and a defined treatment for components where no timely fix will be applied.
- Vulnerability policy stating the severity scale and the deadline attached to each level
- Documented handling route for components that cannot be remediated, including compensating controls
- List of approved vulnerability information sources feeding the identification process
- Risk acceptance register recording deviations from the remediation deadlines
- Severity scale defined without any corresponding remediation deadline
- No documented path for end of life components that will never receive a fix
- Rules limited to operating systems and silent on libraries, images and firmware
- Risk acceptances granted verbally, never recorded and never time limited