Security Questionnaire Mapper

Vulnerability and patch management: the clause the question tests

How weaknesses are found and how fast they are fixed, by severity.

How the customer usually asks it

example

"How quickly are critical security patches applied to production systems?"

Read this question

Anchor clauses

7 frameworks
FrameworkAnchor clause
ISO/IEC 27001:20228.8 Management of technical vulnerabilities
SOC 2 (Trust Services Criteria)CC7.1 Detection and monitoring procedures for security events are in place
SIG (Shared Assessments)domain P Threat Management
CSA Cloud Controls Matrix v4.0.1TVM-03 Vulnerability Remediation Schedule
NIST Cybersecurity Framework 2.0ID.RA-01 Vulnerabilities in assets are identified, validated, and recorded
NIST SP 800-53 Rev 5RA-5 Vulnerability monitoring and scanning
PCI DSS v4.0.16.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates · 11.3.1 Internal vulnerability scans quarterly

Every framework that anchors this family is listed here; a register shows the ones ticked for the customer.

Evidence expected

The vulnerability management procedure with remediation windows by severity, the latest scan summary, and patch compliance figures for production.

The clauses, with what an assessor asks for

ISO 27001 8.8 Management of technical vulnerabilities

Obtain vulnerability information, evaluate exposure, and take appropriate remediation.

Evidence an assessor expects: Vulnerability feed logs; Risk assessment reports; Remediation ticket records; Patch deployment evidence
Where answers usually fall short: Relying on ad-hoc scans only; Missing documented risk ranking for vulnerabilities
Source: ISO/IEC 27001:2022
SOC 2 CC7.1 Detection and monitoring procedures for security events are in place

Named, not quoted: the criteria text is not held in full here.

Evidence an assessor expects: 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
Where answers usually fall short: Configuration monitored at build only, so drift introduced afterwards is never detected; Scanning performed quarterly against an environment that changes daily
Source: SOC 2 (Trust Services Criteria)
SIG domain P Threat Management

What it asks for, in one line (the standard's own text is not quoted here):

Maintain threat intelligence, vulnerability management, penetration testing, and red team capabilities to identify and remediate weaknesses in a timely manner.

Evidence an assessor expects: Threat intelligence sources and feeds; Vulnerability scan reports with remediation timelines; Annual external penetration test report; Red team or purple team exercise reports
Where answers usually fall short: Critical vulnerabilities open beyond SLA; Penetration test scope omits new applications
Source: SIG (Shared Assessments)
CSA CCM TVM-03 Vulnerability Remediation Schedule

What it asks for, in one line (the standard's own text is not quoted here):

Have defined routes for both scheduled and emergency response to a discovered vulnerability, chosen according to the risk that vulnerability carries.

Evidence an assessor expects: The documented scheduled and emergency response paths with their trigger criteria; Records of emergency responses invoked and the outcome; The risk criteria that select between the two paths; Evaluation evidence that the paths work under pressure
Where answers usually fall short: Emergency path undefined, so urgent vulnerabilities queue behind routine work; Trigger criteria absent, making the choice of path arbitrary
Source: CSA Cloud Controls Matrix v4.0.1
NIST CSF ID.RA-01 Vulnerabilities in assets are identified, validated, and recorded

Vulnerabilities in assets are identified, validated, and recorded.

Evidence an assessor expects: Vulnerability scanning coverage report; Vulnerability triage workflow with severity SLAs; Validated findings with proof and remediation status; Asset coverage exceptions register; Trend analysis on vulnerability backlog
Where answers usually fall short: Coverage gaps for cloud and container workloads; SLAs missed for high severity items
Source: NIST Cybersecurity Framework 2.0
SP 800-53 RA-5 Vulnerability monitoring and scanning

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.

Evidence an assessor expects: 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; Configuration showing authenticated or privileged scanning where required
Where answers usually fall short: Unauthenticated scanning only, which understates the real vulnerability position; Remediation timeframes defined but routinely exceeded with no risk acceptance
Source: NIST SP 800-53 Rev 5
PCI DSS 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates

What it asks for, in one line (the standard's own text is not quoted here):

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

Evidence an assessor expects: Risk appetite statement; Risk tolerance thresholds; Impact and likelihood scales
Where answers usually fall short: Criteria not approved by leadership; Impact and likelihood scales inconsistent
Source: PCI DSS v4.0.1
PCI DSS 11.3.1 Internal vulnerability scans quarterly

What it asks for, in one line (the standard's own text is not quoted here):

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.

Evidence an assessor expects: Quarterly scan reports for past 12 months; Risk ranking documentation; Remediation tickets with closure; Re-scan reports confirming fix; Coverage matrix of scanned assets
Where answers usually fall short: Coverage incomplete; Critical findings open
Source: PCI DSS v4.0.1

Other families in operations, logging and vulnerability