Traceable-Answer Reference / Threat & Vulnerability Management
TVM-02 — Malware Protection Policy and Procedures
Maintain and annually review policies to protect managed assets against malware.
Every framework that asks this
Answer TVM-02 once and it typically satisfies the equivalent control elsewhere. Altitude and confidence vary — a domain-level anchor is a starting point to verify, not an audited equivalence.
| Framework | Equivalent control(s) | Confidence |
|---|---|---|
| SOC 2 | CC6.7 | high |
| ISO 27001 | A.8.7 | high |
| NIST CSF 2.0 | ID.RA-01, ID.RA-06, DE.CM-09 (domain-level) | high |
| NIST 800-53 | RA-5, SI-2, SI-3, SI-5 (domain-level) | high |
| SIG | Threat Management (domain-level) | high |
Full provenance and NIST 800-53 mappings: the framework crosswalk.
What the reviewer is really checking
The reviewer is establishing whether known vulnerabilities in the systems handling their data get discovered and remediated fast enough to matter, or accumulate until one is exploited. They test the full loop, not any single control. Discovery: do you scan, how often, and across what (infrastructure, hosts, containers, application and dependencies), and is scanning authenticated? Prioritization and fix: do you have patch and remediation SLAs tied to severity (critical vs. high vs. medium), so a critical CVE has a committed clock rather than 'when we get to it'? Independent validation: do you get penetration testing, how often (typically at least annually and on major change), and who performs it, an internal team or a qualified third party, which the reviewer weights differently? Closure: is remediation tracked to completion with evidence, or do findings sit open? Frameworks are specific here: NIST SP 800-53 splits RA-5 (vulnerability scanning), SI-2 (flaw remediation), and CA-8 (penetration testing); ISO 27001 A.8.8 covers technical-vulnerability management; SOC 2 CC7.1 tests that you identify vulnerabilities. The reviewer is checking for a measurable cadence with owners and clocks, because a program without severity SLAs and dates is indistinguishable from no program.
What a truthful, defensible answer contains
A defensible answer describes scanning with a stated frequency and scope: what is scanned (infrastructure, endpoints, containers, application dependencies), how often, and whether scans are authenticated. It states patch and remediation SLAs by severity, meaning a committed timeframe for critical, high, and medium findings, ideally tied to a scoring system such as CVSS. It describes penetration testing with cadence and independence: how often it runs (at least annually and on significant change is the common bar), whether an external firm performs it, and that a summary or attestation is available. It describes how findings are tracked to remediation, through a ticketing or tracking system, with ownership and verification that fixes landed, rather than implying findings close themselves. Where coverage or SLAs differ by system tier, a truthful answer states the threshold. It should map to the referenced control (CCM TVM, NIST SP 800-53 RA-5/SI-2/CA-8, ISO 27001 A.8.8, SOC 2 CC7.1) and be honest where a cadence is aspirational or a capability is new. The reviewer isn't looking for a claim of zero vulnerabilities, an impossible and suspicious assertion, but for numbers: frequencies, severity clocks, and a last-test date.
Make it traceable
Anchor each number to proof. Scanning frequency resolves to your vulnerability-management policy, citing the section that states the cadence, plus a sample or redacted scan report; patch SLAs resolve to the policy table that defines them by severity plus remediation tickets showing they're met; pen-test cadence and independence resolve to the latest test's executive summary or attestation letter, with its date and the firm's name (buyers accept a summary, not the raw findings). Remediation tracking resolves to the ticketing system or a metrics export showing open-versus-closed and time-to-remediate. If a SOC 2 report tests these, cite CC7.1 and the report date. The strongest answer states the number and names the document it comes from, for example "critical findings remediated within N days per [Vuln Mgmt Policy §X]," so the SLA is auditable rather than rhetorical, and would read the same on the day the buyer verifies it.
Answer patterns that hold up
- Scanning stated as frequency, scope, and authenticated-or-not: three concrete facts, not 'we scan regularly.'
- Remediation stated as a severity-to-timeframe table (critical/high/medium), tied to a scoring system.
- Pen test stated as cadence, then performed-by (internal vs. named third party), then last date, then summary availability.
- Each finding-to-fix loop paired with the tracking system that proves closure.
- A tier threshold stated where scan scope or SLA differs by system criticality.
Evidence that backs the answer
Red flags reviewers catch
- 'We patch regularly' with no severity SLAs and no remediation timeframe.
- 'We conduct penetration tests' with no date, no cadence, and no named tester.
- Scanning claimed but no frequency, no scope, and no note on authenticated vs. unauthenticated.
- A claim of 'no known vulnerabilities', implausible and a sign the program isn't actually looking.
- Findings described as identified but with no tracking system proving they were closed.