An analyst sends an initial triage report after EDR alerts show a process spawning PowerShell and a temporary file download, but no exfiltration or persistence has been confirmed. What should the report do?
Select an answer to reveal the explanation.
Short Explanation
Think of a triage report like a first-aid note: you need to say what you actually saw versus what you only suspect. If you label every odd log entry as confirmed compromise, you cry wolf; if you hide the suspicious bits, you leave leadership blind. Keep confirmed and suspected findings separate, and tell people how confident you are.
Full Explanation
Initial triage communication exists to support timely, calibrated decisions, so it must distinguish evidence-backed compromise from indicators that remain unvalidated. The report should separate confirmed findings from suspected activity and state confidence or limitations, giving leadership enough context to decide on containment without assuming that every alert has been proven. Classifying every suspicious indicator as confirmed compromise overstates incident status, erodes analyst credibility, and can trigger disproportionate containment based on unproven scope. Withholding unverified indicators until forensic confirmation understates potential exposure and delays risk decisions; initial reports are meant to communicate known unknowns, not a final verdict. Presenting only raw log excerpts without confidence labels shifts interpretation to readers, hides uncertainty, and reduces usefulness for non-technical stakeholders who need a clear assessment of what is known versus what requires validation. Exam caveat: CS0-004 expects reporting to use calibrated uncertainty language rather than forcing alerts into a binary confirmed or unconfirmed frame. Operational check: before sending, tag each finding as confirmed, suspected, or unknown and list the evidence and next validation step for every suspected item.