Vulnerability scan export
The shortest fixed clock in the held texts is 2,190 hours (every three months), set by PCI DSS 11.3.1. Paste one job that feeds this consumer, for example vuln_scan_export, 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: vuln, vulnerability, scan export, scanner, scan report, asv scan, vulnerability scan.
The clock each rule sets
| Regime | Clock | Clause |
|---|---|---|
| PCI DSS | 2,190h | PCI DSS 11.3.1 Internal vulnerability scans quarterlyat least once every three months |
| 2,190h | PCI DSS 11.3.2 External vulnerability scans quarterly by ASVat least once every three months | |
| SP 800-53 | no clock | SP 800-53 RA-5 Vulnerability monitoring and scanninga defined frequency |
| 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 vulnerability scan export?
Every three months (2,190 hours): PCI DSS 11.3.1, Internal vulnerability scans quarterly. Every three months (2,190 hours): PCI DSS 11.3.2, External vulnerability scans quarterly by ASV. Internal vulnerability scans are performed at least once every three months, with high-risk and critical vulnerabilities resolved per the entity's risk ranking, and re-scans confirm resolution. External vulnerability scans are performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV) with passing scans achieved.
How often does NIST SP 800-53 Rev 5 require vulnerability scan export?
The held text of SP 800-53 RA-5 (Vulnerability monitoring and scanning) sets no fixed period: a defined frequency. Requires vulnerability monitoring and scanning of the system and hosted applications at a defined frequency or randomly by a defined process and when new relevant vulnerabilities are reported, using tools and techniques that support standardised enumeration, checklists and impact measurement, with results analysed, remediation within defined response times by risk, results shared with defined personnel, and privileged scanning access where required.
How often does ISO/IEC 27001:2022 require vulnerability scan export?
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 vulnerability scan export?
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 vulnerability scan export job?
Who owns the high and critical findings in each export, and does the re-scan job exist?
The clauses in full
Internal vulnerability scans are performed at least once every three months, with high-risk and critical vulnerabilities resolved per the entity's risk ranking, and re-scans confirm resolution.
What an assessor asks to see: Quarterly scan reports for past 12 months; Risk ranking documentation; Remediation tickets with closure; Re-scan reports confirming fix. Where it usually falls short: Coverage incomplete
External vulnerability scans are performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV) with passing scans achieved.
What an assessor asks to see: ASV scan reports for past 4 quarters (passing); ASV attestation of scan compliance; Remediation tickets for failed scans; Re-scan reports confirming pass. Where it usually falls short: No passing scan
Requires vulnerability monitoring and scanning of the system and hosted applications at a defined frequency or randomly by a defined process and when new relevant vulnerabilities are reported, using tools and techniques that support standardised enumeration, checklists and impact measurement, with results analysed, remediation within defined response times by risk, results shared with defined personnel, and privileged scanning access where required.
What an assessor asks to see: Scan schedule and coverage evidence across the system and hosted applications; Scan reports with findings ranked by severity; Defined remediation timeframes by risk level and evidence they are met; Records of scan result distribution to the defined personnel. Where it usually falls short: Unauthenticated scanning only, which understates the real vulnerability position
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