Reporting and Communication practice questions

Vulnerability scan reports are sensitive: they are a map of exploitable weaknesses. Detail is shared on a need-to-know basis; broad audiences get summaries.

A full report lists exactly which systems are exposed and how. The transparency goal is met just as well by summary metrics (open findings, SLA performance, trend) published widely, while the asset owners and remediators receive the full technical detail. A per-host list of critical CVEs is still a target list, delaying publication still exposes the remaining weaknesses, and limiting access to all managers grants it by rank rather than by need.

1. Recognise that a full scan report is sensitive information.
2. Separate what everyone needs (progress) from what fixers need (detail).
3. Share summaries broadly and technical detail only with owners and remediators.

Exam tip: Share vulnerability detail on a need-to-know basis; share progress as metrics.

Compliance findings measure conformance to a required standard or policy; vulnerability findings measure exploitable weaknesses. Being compliant does not mean being secure.

Compliance scans check settings against a benchmark or regulation; vulnerability scans check for known flaws such as missing patches. The two can disagree legitimately, so each is reported on its own terms. Folding one into the other either hides real risk or misstates the compliance position.

1. Note what each scan measures: configuration conformance versus known flaws.
2. Accept that both results can be true at once.
3. Report the compliance status and the open vulnerabilities side by side.

Exam tip: Compliant is not the same as secure: report compliance findings and vulnerabilities separately.

Compliance findings carry obligations (a required control, an audit date) that can make them more urgent than a higher-scored technical finding in a low-exposure context.

A severity label alone does not decide order. The cardholder finding fails a required control in scope for an assessment that is about to happen, so leaving it open has a direct regulatory consequence. The lab flaw is high severity but isolated with no sensitive data, so its practical risk is low and it can follow in the next window. Accepting a failed required control does not meet the standard, and a last-minute compensating control needs formal documentation and assessor validation, which is a weaker bet than fixing the configuration itself.

1. List the consequence of leaving each finding open.
2. Weigh the regulatory deadline and scope against the severity label.
3. Fix the finding whose delay causes the larger business consequence, and schedule the other.

Exam tip: A compliance finding with a deadline can outrank a higher-severity finding on a low-exposure asset.

A risk scorecard condenses vulnerability data into ratings per business unit, system or asset group so leaders can compare and track exposure.

The request has the signature of a scorecard: a summary rating per unit, color coding, a comparison with an earlier period, and an executive audience. Scan reports and compliance logs hold the detailed findings; an action plan describes how fixes will be delivered.

1. Note the audience (executives) and the format (one page, ratings, color).
2. A rating per unit compared over time is a scorecard.
3. Detailed findings and task plans serve other audiences.

Exam tip: One-page ratings per unit, tracked over time, for leaders: that is a risk scorecard.

A scorecard is only meaningful if its rating reflects risk, which depends on how severe each finding is and how important the affected asset is, not on raw volume.

Raw counts reward units with few findings and punish units with many trivial ones. Risk combines likelihood and impact, so the scorecard should weight each finding by both its severity and the criticality of the asset it sits on. Weighting by asset alone ignores how serious each finding is, an average CVSS score ignores asset value and volume, and counting only overdue findings measures SLA performance rather than exposure.

1. Spot why the ranking is wrong: counts treat every finding equally.
2. Risk depends on both the finding's severity and the asset's business value.
3. Reject options that weight by only one of the two, or that measure something else such as timeliness.

Exam tip: Scorecards should weight findings by severity and asset criticality, never rank by raw counts.

Scorecards for leaders show a summary rating, its trend and accountability measures such as SLA performance, in terms the reader can act on.

Business-unit heads respond to where they stand, whether it is getting better, and what they own that is late. A rating with its change over time and the count of overdue criticals against SLA give exactly that. An organization-wide top-ten list is not about their unit, a raw finding count misleads by volume, and scan-coverage data is a quality check for the vulnerability team.

1. Identify what the audience can decide: budget and staffing.
2. Choose elements that show position, direction and overdue obligations.
3. Leave technical scan detail to the technical report.

Exam tip: Leader scorecards show rating, trend and SLA breaches, not scanner detail.