Reporting vulnerability management to the people who act on it

Key: A

1. ACorrect: The two unpatched hosts are internet-facing with CVSS 9.8 and 9.1, so the highest-risk exposure is still open even though 8 of 10 assets are patched.
2. BPatched internal databases do not offset unpatched critical flaws on the internet-facing web servers, which attackers can reach directly.
3. CVolume of patched systems does not remove risk; one exposed critical vulnerability can be enough for a breach.
4. DA patch percentage counts systems equally and ignores exposure and severity, so 'most systems are secured' hides the two riskiest assets.

Key: B

1. ATopology diagrams and incident timelines are background material, not what an owner needs to find and fix the flaw.
2. BCorrect: The owner needs the exact CVE IDs and affected software versions to identify the vulnerable component and apply the right fix.
3. CMemory dumps and chain-of-custody records are incident forensics artifacts and have nothing to do with a patch request.
4. DRoot cause analysis and attribution come after an incident; they are not needed to remediate a known vulnerability.

Key: D

1. APeer benchmarking can put a program in context for leadership, but engineers cannot use it to apply or verify a specific fix.
2. BRegulatory fines and SLA breach impacts are business framing for the executive section, not technical detail for engineers.
3. CRaw counts of vulnerabilities per subnet are aggregate numbers that don't tell an engineer what to change on which system or how to confirm it.
4. DCorrect: A technical appendix should give engineers exact, checkable artifacts (log queries, registry keys, file hashes) so they can apply the fix and confirm it worked.

Key: D

1. AAlerts speed things up, but with no verification step nobody confirms the fix held, so there is no evidence to show an auditor.
2. BSLA monitoring shows which items run late, but without a documented closure there is no record that the fix was made and checked.
3. CPlaybooks make fixes faster and repeatable, but leaving out post-remediation verification means the closure is never proven.
4. DCorrect: playbooks shorten each fix, automated SLA alerts keep items from going stale, and verified closure records are the compliance evidence.

Key: D

1. ARecommending a full replacement of legacy systems right away is rarely feasible and skips interim steps such as compensating controls.
2. BClosing easy low-severity items to raise the compliance percentage makes the metric look better while the real risk stays open.
3. CRanking by CVSS alone ignores asset value, exposure and active exploitation, which is the context executives need to judge risk.
4. DCorrect: Reporting the high-severity legacy backlog openly, with a realistic plan to mitigate it, shows the risk the percentage hides.

Key: D

1. ADeveloper contacts may help coordination, but they don't protect anyone while no patch exists.
2. BPast vulnerability data is background and does not tell readers how to reduce exposure to a flaw with no fix yet.
3. CThe purchase date of the system has no bearing on how to protect it from an unpatched flaw.
4. DCorrect: A zero-day has no vendor patch yet, so the report must give temporary mitigations or compensating controls that reduce exposure until a fix arrives.

Key: D

1. ADeleting results after review destroys evidence that regulators and auditors may require, and breaks remediation tracking and trend reporting.
2. BPlain-text storage exposes a map of the organization's weaknesses to anyone who reaches the file, and can breach regulatory protection requirements.
3. CScan results are sensitive and should reach only the people who need them, which rules out sending them to all IT staff.
4. DCorrect: Scan results are a roadmap for attackers and may include regulated data, so encrypt them, restrict access to those who need it, and keep them as the regulations require.

Key: A

1. ACorrect: A PCI DSS dispute or resubmission needs the ASV scan summaries, evidence of remediation and passing ASV rescans within the required quarterly cycle.
2. BA findings list with no remediation timestamps or rescan results doesn't show the vulnerabilities were fixed, so it can't support a dispute or a passing result.
3. CInternal scan reports and change tickets are useful supporting evidence, but PCI DSS external scans must be run by an Approved Scanning Vendor (ASV).
4. DNetwork diagrams and policies show design and intent but do not prove the specific vulnerabilities were fixed, and there is still no ASV rescan.

Key: D

1. AA self-attestation letter is not evidence that the vulnerability is gone; the external scan result has to be a passing ASV scan.
2. BAn internal scan doesn't replace the external ASV scan requirement, and the ASV finding shows the fix didn't hold or didn't cover the external view.
3. CWaiting for the next quarterly cycle leaves a failed external scan on record and the CDE host exposed in the meantime.
4. DCorrect: The host must be fixed (again) and an ASV rescan run to get a passing external result, with the remediation documented.

Key: B

1. AA weekly CAB report is too slow and goes to the wrong audience to catch items close to their deadline.
2. BCorrect: Escalating automatically at 75 percent of the SLA window gives owners time to act before the deadline, and live dashboard updates keep executives informed.
3. CDaily emails only to security don't reach the owners who have to remediate, and they don't feed the executive dashboards.
4. DAlerting only after the SLA expires records breaches instead of preventing them.

Key: D

1. ARaw ticket logs and alert counts are exactly the operational noise auditors don't want, and they don't show compliance against requirements.
2. BA narrative without scan evidence can't be verified, so it doesn't meet audit or regulatory evidence needs.
3. CAn annual summary does not meet a monthly reporting requirement and is too coarse to show ongoing remediation.
4. DCorrect: A monthly package of scan reports, ASV attestations, verification evidence and KPIs mapped to each regulatory requirement gives auditors verifiable evidence without raw operational detail.

Key: B

1. ADeltaCorp patches a medium-risk component in 10 days against a 14-day SLA, so it meets its contract.
2. BCorrect: BetaTech supplies a critical component under a 48-hour patch SLA yet averages 14 days, a consistent breach on the highest-risk item and so the greatest legal exposure.
3. CAlphaSoft releases patches in 3 days against a 7-day SLA, well ahead of its contract.
4. DGammaSystems takes 20 days against a 30-day SLA on a low-risk component, which is inside its contract.

Key: B

1. AA count of low-severity findings says nothing about the urgent, mandated fixes the team is missing.
2. BCorrect: mean time to remediate for KEV-listed vulnerabilities measures speed on exactly the flaws federal directives set due dates for, so it shows management the gap directly.
3. CTime from initial access to detection is a detection metric (MTTD) and says nothing about patching speed.
4. DRaw SIEM alert volume measures detection noise and is unrelated to how quickly the database team patches.

Key: A

1. ACorrect: Escalating as the contract specifies, recording the risk in the risk register and keeping change records with the vendor deals with the breach and leaves an audit trail.
2. BA public statement before escalating through the contract is premature; disclosure decisions belong to legal and the communication plan.
3. CTerminating the contract without legal advice can breach the contract itself, and a rushed migration creates new operational risk.
4. DWaiting and not updating the risk register leaves regulated data exposed with no documentation, which is a governance failure.

Key: D

1. ACVSS-only prioritization ignores asset context such as exposure, criticality and active exploitation, which matters most when you can't patch everything.
2. BPatching against a change freeze ignores governance and risks outages, because a freeze needs an approved emergency exception instead of a workaround.
3. CReporting a compliance percentage without the overdue list hides the risk from the people who have to decide.
4. DCorrect: Escalate items that face imminent exploitation (for an emergency change), and cover the rest with documented compensating controls until the freeze ends.

Key: C

1. AAnalyst time per patch measures effort, while the question asks how long vulnerabilities stay open compared with expected performance.
2. BA raw monthly count of patches can rise even while old critical vulnerabilities pile up, so it can mislead about patching performance.
3. CCorrect: Plotting vulnerability age as a trend against an established baseline shows whether performance is actually improving, which a single raw number cannot.
4. DA heat map of open vulnerabilities by asset tag shows where the risk is but hides how fast the team is closing vulnerabilities over time.

Key: B

1. AExternal mean time to remediate measures how fast fixes happen instead of how many vulnerable services are still exposed, and it barely changed (15 → 12 → 14 days).
2. BCorrect: The count of exposed assets with Known Exploited Vulnerabilities (KEV) directly measures internet-facing vulnerable exposure, and it fell steadily from 42 to 15.
3. CInternal mean time to remediate is about internal systems, so it says nothing about the external attack surface.
4. DTotal vulnerabilities mixes internal and external findings and actually rose in Q3, so it doesn't isolate internet-facing exposure.