CompTIA CySA+ Domain 4: Reporting and Communication

STIX is an open language and serialization format created specifically to represent and exchange machine-readable cyber threat intelligence between organizations.

• BSNMP is a protocol for monitoring and managing network devices; it is not a structured language for representing or sharing cyber threat intelligence.
• CNetFlow records metadata about network traffic flows for analysis; it does not encode threat-intelligence objects for inter-organization sharing.
• DSyslog transports event/log messages from devices to collectors; it is a logging transport, not a structured cyber-threat-intelligence exchange language.

NIST notes patching requires scheduled downtime that can disrupt operations, so an interrupted critical business process is a recognized inhibitor that legitimately delays remediation and must be documented.

• AScanner accuracy is not the issue here; the vulnerability is real and confirmed, so labeling it a false positive misrepresents a deliberate, business-driven remediation delay.
• BRisk transfer means shifting consequences to another party such as an insurer; delaying a patch internally does not move the organization's exposure to anyone outside it.
• DLaw-enforcement notification timelines apply to declared incidents, not to a planned patch deferral; treating a maintenance-window dispute as a reportable crime confuses remediation with incident handling.

NIST defines mitigation as reducing risk by deploying additional controls such as firewalls and network segmentation to isolate vulnerable assets, exactly what the interim isolation accomplishes here.

• AAcceptance means relying on existing controls or judging impact low enough to do nothing; here the team actively adds new safeguards, so the response is not acceptance.
• CTransfer shares consequences with another party, like insurance or a SaaS provider; a vendor's pending patch does not move the organization's own exposure to that vendor.
• DAvoidance would require eliminating the activity or asset outright; the server stays in production behind controls, so the exposure is reduced rather than wholly avoided.

NIST defines metrics as measures and assessment results designed to track progress, facilitate decision-making, and improve performance with respect to a set target, matching the quarterly reporting need.

• BAn unanalyzed log entry is raw data, not a metric; metrics result from measurement and analysis intended to track performance toward a defined target over time.
• CA single penetration-test finding describes one weakness at one moment; it is not a repeatable measure designed to track progress toward a target across reporting periods.
• DA contractual deadline is an obligation in an agreement, not a measurement; it may be tracked by a metric but is not itself the security metric being defined here.

NIST states measures can be applied to meet specific stakeholder requirements, strategic goals, and risk priorities, which is exactly the audience-driven selection the analyst is performing here.

• ANIST ties measures to specific stakeholder needs, so distributing one unchanged view ignores what each audience actually has to decide or act upon from the report.
• BWithholding measures from system owners undercuts accountability; system owners need measures to judge their own posture, so restricting reporting to one executive is inappropriate.
• CNIST measurement guidance explicitly covers both quantitative and qualitative assessment, so dismissing qualitative results as unsuitable for reporting contradicts the standard's stated flexible approach.

CISA requires agencies to report incidents within one hour of identification by their top-level CSIRT, SOC, or IT department, even when full details are not yet validated.

• AThe seven-day rule concerns major-incident reports to Congress under FISMA; it does not replace the agency's required one-hour notification to CISA for confirmed incidents.
• CCISA expedites initial notification and moves cause analysis to the closing phase, so waiting for recovery and root cause before reporting would violate the one-hour requirement.
• DThere is no record-count threshold for the one-hour requirement; any confirmed compromise of confidentiality, integrity, or availability triggers notification regardless of how many records are involved.

CISA advises following the cyber incident-response plan and, besides CISA and the FBI, considering local law enforcement and appropriate regulatory agencies as the situation warrants.

• AGuidance recommends following the incident-response plan as soon as signs of compromise appear; deferring external engagement until closure forfeits coordination and timely reporting benefits the plan should secure.
• BSome external notification is expected and sometimes required; confining communication to internal staff ignores obligations to report to CISA, the FBI, and relevant regulators.
• DA communication plan assigns coordinated roles, but routing notifications through marketing misplaces responsibility; technical and legal reporting duties are not a public-relations function to own.

NIST states lessons learned and root-cause analysis improve cybersecurity risk management and governance and help the organization better detect, respond to, and recover from future incidents.

• BPost-incident review aims at systemic improvement, not punishment; framing root-cause analysis as blame assignment discourages candor and undermines the learning the process is meant to produce.
• CThe one-hour clock concerns external notification, a separate activity; root-cause analysis is part of post-incident improvement and is not bound by that initial reporting deadline.
• DLessons learned strengthen continuous improvement rather than eliminating monitoring; NIST treats ongoing detection as a permanent function, not something retired after systems are recovered.

Coordinated disclosure has the finder report privately so the vendor can develop and ship a fix before details become public, exactly matching the stated reporting policy.

• AFull disclosure publishes technical details at once without a private remediation window, which is the opposite of waiting for the vendor to issue a fix first.
• BSelling the finding to a broker bypasses the vendor entirely and provides no coordinated remediation window, so it does not match the private-report-then-wait policy described here.
• DA bounty adds optional payment for findings, but the scenario describes the timing and privacy of reporting, not any obligation to pay the researcher for the report.

Article 33 requires notification without undue delay and, where feasible, not later than 72 hours after the controller becomes aware of the personal data breach.

• AThe GDPR sets no 24-hour clock; the deadline runs from awareness rather than occurrence and permits up to 72 hours, so this understates the time allowed.
• CThe clock starts at awareness, not at the end of forensics; tying it to investigation completion would let controllers delay notification well beyond the regulation's limit.
• DAuthority notification under Article 33 is independent of and not gated by individual notification under Article 34, so sequencing it after data subjects misstates the rule.

For breaches involving 500 or more individuals, the Breach Notification Rule requires notifying the Secretary without unreasonable delay and no later than 60 days after discovery.

• BAnnual submission applies to breaches affecting fewer than 500 individuals; a 1,200-patient breach crosses the 500 threshold and requires prompt Secretary notification instead.
• CThe 72-hour clock belongs to the GDPR, not HIPAA; applying an EU deadline to a US covered entity confuses two separate regulatory frameworks and their timelines.
• DCovered entities must notify the Secretary of breaches of unsecured protected health information; a large breach is reported promptly, so claiming no notice is due is incorrect.

CVSS supplies a qualitative measure of severity and is not a measure of risk; consumers must add environmental and threat context to inform their own risk decisions.

• ABase metrics capture intrinsic technical characteristics and assume a reasonable worst case; asset value belongs to environmental metrics the consumer supplies, not the base score.
• BTime-varying exploitation factors live in the Threat metric group; the base score reflects constant intrinsic characteristics, so it is not a measure of changing exploit likelihood.
• CCVSS provides severity input but imposes no legal patch mandate; remediation timing comes from organizational policy and regulatory drivers that sit outside the scoring system itself.

Guidance frames patching as preventive maintenance and a risk-based remediation strategy, letting security and business owners coordinate maintenance windows that reduce risk without surprise disruption.

• APushing patches with no testing or scheduling ignores regression risk and operational impact, which fuels the very business resistance the analyst is trying to overcome here.
• CWaiting a year leaves known vulnerabilities exposed far beyond reasonable remediation timeframes, increasing the window of opportunity for attackers against the enterprise's assets.
• DRemoving a coordinated remediation process produces inconsistent patching and conflicting priorities, the opposite of the structured maintenance scheduling that authoritative guidance recommends.

Reporting should match the audience: leadership needs business impact and risk for decisions, while responders need granular technical detail, so the same data is presented at different depths.

• BHanding executives raw captures buries decision-relevant impact in technical noise, defeating the purpose of communicating clearly with high-level members of the organization.
• CDelaying leadership communication until closure removes their ability to make timely risk and business decisions, contradicting guidance that incident communications support governance.
• DDiscarding the detailed technical record leaves responders without the granular findings needed to contain and recover, so a summary cannot substitute for that record.

A metric tracking the share of findings fixed within the SLA window measures progress against a defined target, directly communicating remediation timeliness and coverage to leadership.

• AIndustry-wide CVE counts describe the external threat landscape, not the team's own remediation performance, so they cannot show whether internal service-level targets are being met.
• BA bare backlog count omits the time-to-remediate dimension, so it cannot demonstrate adherence to a service-level window or how coverage is trending against targets.
• DA vendor's advertised detection rate says nothing about the organization's own remediation cadence or SLA adherence, so it does not measure the program's actual performance.

A key risk indicator monitors risk exposure relative to the risk appetite, the amount of risk the organization is willing to accept, whereas a KPI measures performance against a target.

• ATraining completion is a performance measure of process execution against a target; it tracks how well a control runs, not exposure relative to accepted risk.
• BTickets closed on time gauge operational throughput against a target, which is performance reporting; it does not express exposure measured against the board's risk appetite.
• CCounting closed audit findings reports remediation activity against a target rather than signaling whether current risk exposure is nearing the amount the board will accept.

The POA&M lists tasks, resources, milestones, and scheduled completion dates to correct identified control deficiencies and is then used to monitor remediation progress, matching every element described.

• AA risk register is a central record of current risks for a scope or organization, not the task-level corrective-action plan with scheduled milestone completion dates used to track fixes.
• CThe assessment report documents findings, evidence, and recommendations, but the scheduled remediation commitments with milestones and completion dates are captured separately in the plan of action and milestones.
• DA memorandum of understanding records an agreement on responsibilities between organizations and has nothing to do with tracking corrective tasks and milestone dates for control deficiencies.

A risk register is the central record of current risks and related data whose measures roll up from system and organization levels to inform enterprise leadership and risk management.

• AA POA&M tracks corrective tasks and milestones for specific control deficiencies on a system, rather than serving as the central scored record of all risks rolled up to leadership.
• BAn incident response plan defines how the team detects and handles incidents, but it does not function as the maintained inventory of scored risks reported upward to executives.
• DA business impact analysis quantifies the consequences of disruption to processes; it feeds prioritization but is not the continuously maintained scored record of individual risks and owners.

A severity score should drive incident triage and escalation, mapping each level to defined recipients and timeframes, which is exactly the predefined notification matrix the analyst should apply here.

• BSending every case to one supervisor disregards the severity thresholds that determine which higher-level stakeholders, such as executives and legal, must be notified for serious incidents.
• CWaiting for the post-incident review delays time-sensitive notification of leadership and oversight parties that severity thresholds require to occur promptly while the incident is active.
• DEscalating low and high events identically to executives removes the severity-based prioritization that determines appropriate recipients and urgency, overwhelming leadership with undifferentiated notifications.

An actionable report pairs each finding with a risk description and recommended remediation plus tracking status, so owners understand the exposure and the corrective action expected of them.

• AListing identifiers alone is the unactionable export the owners already rejected; without a risk description and recommended fix, recipients cannot prioritize or remediate the findings.
• BLicensing information about the scanning tool tells owners nothing about the weakness or how to fix it, so it does not make the vulnerability report actionable.
• CHistorical incidents unrelated to the current findings add length without telling owners which assets are affected or what corrective action to take for these vulnerabilities.