Patch compliance report
None of the held texts sets a fixed period on this consumer; every row below reads no period set by the text. Paste one job that feeds this consumer, for example patch_compliance_report, weekly, and the register reads its period against the clocks below, names the gap in hours, and carries the question for its owner.
Matched on the job name or the consumer column by these words: patch, patching, update compliance, missing patches, patch status, patch report.
The clock each rule sets
| Regime | Clock | Clause |
|---|---|---|
| PCI DSS | no clock | PCI DSS 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within onethe held text sets a period for critical patches; the figure is not in the copy held |
| SP 800-53 | no clock | SP 800-53 SI-2 Flaw remediationan organization-defined period |
| ISO 27001 | no clock | ISO 27001 8.8 Management of technical vulnerabilities |
| NIS2 | no clock | NIS2 Art.21.2.e Security in acquisition, development and maintenance, including vulnerability handling and disclosure |
Questions this page answers
How often does PCI DSS v4.0 require patch compliance report?
The held text of PCI DSS 6.3.3 (All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one) sets no fixed period: the held text sets a period for critical patches; the figure is not in the copy held. All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one
How often does NIST SP 800-53 Rev 5 require patch compliance report?
The held text of SP 800-53 SI-2 (Flaw remediation) sets no fixed period: an organization-defined period. Requires system flaws to be identified, reported and corrected, updates related to flaw remediation to be tested for effectiveness and side effects before installation, security relevant software and firmware updates to be installed within an organization-defined period of release, and flaw remediation to be run through the configuration management process.
How often does ISO/IEC 27001:2022 require patch compliance report?
The held text of ISO 27001 8.8 (Management of technical vulnerabilities) sets no fixed period: no period set by the text. Obtain vulnerability information, evaluate exposure, and take appropriate remediation.
How often does NIS2 Directive require patch compliance report?
The held text of NIS2 Art.21.2.e (Security in acquisition, development and maintenance, including vulnerability handling and disclosure) sets no fixed period: no period set by the text. Two duties travel together in this point. The first is that security is built into how systems are acquired, developed and maintained: security requirements set before purchase or build, secure development practice, change control, and maintenance that does not quietly reintroduce weakness. The second is vulnerability handling and disclosure, meaning the entity can receive a vulnerability report about its own products or systems, triage it, fix it on a timescale that reflects severity, and handle disclosure. A published route for a finder to reach the entity is the part most often missing, and its absence is visible from outside. Note that the coordinator role and the European vulnerability database in Article 12 belong to the CSIRTs and ENISA; what binds the entity is its own handling and disclosure capability.
What does the register ask the owner of a patch compliance report job?
Which systems in the report are outside the period your risk ranking sets for critical patches?
The clauses in full
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one
What an assessor asks to see: Risk appetite statement; Risk tolerance thresholds; Impact and likelihood scales. Where it usually falls short: Criteria not approved by leadership
Requires system flaws to be identified, reported and corrected, updates related to flaw remediation to be tested for effectiveness and side effects before installation, security relevant software and firmware updates to be installed within an organization-defined period of release, and flaw remediation to be run through the configuration management process.
What an assessor asks to see: Defined installation timeframes for security relevant updates by severity; Patch deployment records measured against those timeframes; Test evidence for updates before production installation; Change records showing remediation passed through configuration management. Where it usually falls short: Timeframes defined but routinely missed with no risk acceptance recorded
Obtain vulnerability information, evaluate exposure, and take appropriate remediation.
Guidance beside it, ISO 27002 8.8: Requires information about technical vulnerabilities in the information systems in use to be obtained, the organisation's exposure to them to be evaluated, and appropriate measures to be taken. Older source material sets out the surrounding process: named roles and responsibilities, identified information sources, a defined reaction timeline, assessment of the risk posed by the vulnerability against the risk of applying the patch, testing before deployment, alternative measures where no patch exists, an audit log of actions taken, and highest risk systems addressed first.
What an assessor asks to see: vulnerability_feed_logs; risk_assessment_reports; remediation_ticket_records; patch_deployment_evidence. Where it usually falls short: Relying on ad-hoc scans only
Two duties travel together in this point. The first is that security is built into how systems are acquired, developed and maintained: security requirements set before purchase or build, secure development practice, change control, and maintenance that does not quietly reintroduce weakness. The second is vulnerability handling and disclosure, meaning the entity can receive a vulnerability report about its own products or systems, triage it, fix it on a timescale that reflects severity, and handle disclosure. A published route for a finder to reach the entity is the part most often missing, and its absence is visible from outside. Note that the coordinator role and the European vulnerability database in Article 12 belong to the CSIRTs and ENISA; what binds the entity is its own handling and disclosure capability.
What an assessor asks to see: Security requirements applied in procurement and in the development lifecycle, with gate evidence; Secure development practices in use, such as design review, code analysis and dependency scanning, with output; Change and maintenance control records for in-scope systems; A published contact route for vulnerability reports, and the triage procedure behind it. Where it usually falls short: Security requirements defined for new build only, leaving acquired and inherited systems untouched
Requirement text quoted from the standards themselves, published at compliance.theartofservice.com, the same publisher as this register, read against the held text of each standard: our statement of each clause, not the instrument verbatim. Run this job through the register