# Executive Incident Summary

Turns your raw incident notes into a concise summary for executives and senior leadership who need the facts without the technical detail. Use it after containment, when leadership needs to understand what happened, what you did, and what comes next.

## Prompt

## Context
You are assisting a [YOUR ROLE, e.g., security analyst, incident commander, CISO] preparing a written summary of a security incident for [AUDIENCE, e.g., the executive team, the CIO, the board]. The audience does not need technical depth. They need business impact, status, and next steps. Incident details: [INCIDENT SUMMARY, timeline, affected systems, what was confirmed, what is still under investigation]. Current status: [CURRENT STATUS, e.g., contained, ongoing, remediated]. Business impact: [BUSINESS IMPACT, e.g., service degradation, data exposure, no known customer impact]. Actions taken: [ACTIONS TAKEN]. Next steps: [NEXT STEPS].

## Task
Write a one-page executive incident summary. Include:
- A plain-language headline stating what happened and when.
- A status line: contained, ongoing, or remediated, as of [STATUS DATE].
- Business impact: what was affected, for how long, and who was involved.
- What the team did: three to five bullet points, plain language, no jargon.
- What happens next: two to four next steps with owners and target dates where known.
- A statement of what is still unknown or under investigation, if applicable.

## Standards
- Under 400 words. No technical jargon without a plain-language translation.
- Do not state systems are secure, clean, or fully remediated unless I stated that above.
- Do not name CVEs (Common Vulnerabilities and Exposures), IOCs (Indicators of Compromise), log data, hostnames, or specific vulnerabilities unless I provided them.
- Do not characterize intent or attribution unless I stated confirmed findings.
- Match the tone to the audience: calm, factual, and action-oriented.
- Do not invent impact figures, affected user counts, or data exposure details I did not supply.
- If any named input is missing or ambiguous, ask before drafting.

## Variables

- YOUR ROLE
- AUDIENCE
- INCIDENT SUMMARY
- CURRENT STATUS
- STATUS DATE
- BUSINESS IMPACT
- ACTIONS TAKEN
- NEXT STEPS

## Input checklist

- [ ] Confirm the incident timeline, affected systems, and current status from your ticketing system or incident log, not from memory.
- [ ] Gather business impact details: affected services, duration, and whether any customer or employee data was involved.
- [ ] Confirm all technical artifacts (IOCs, CVEs, hostnames, log data) come from your own tools and systems, not from the AI.
- [ ] Review next steps with the incident commander or team lead before pasting them as final.
- [ ] Redact credentials, internal IP addresses, customer data, and anything classified or under legal hold before pasting per your org policy.
- [ ] Confirm whether the incident is still under investigation and what, if anything, cannot be disclosed yet.

## Verification checklist

- [ ] Every impact figure, affected system name, and duration matches your incident documentation exactly. Do not rely on the AI to restate numbers accurately.
- [ ] No CVEs, IOCs, or specific vulnerability names appear unless you supplied them. If they do, remove them.
- [ ] The status line matches reality: do not let the AI restate an ongoing incident as contained.
- [ ] No attribution or intent language appears unless you have confirmed findings from forensics or law enforcement.
- [ ] Next steps name real owners and achievable dates, not placeholders the AI invented.
- [ ] No credentials, customer PII (personally identifiable information), or internal network details leaked into the output.
- [ ] Have a second team member read the draft before it goes to leadership.

## Sample output

Sample output. Generated by AI from sample inputs:

Security Incident Summary
Prepared for: Executive Team
Date: June 13, 2026

What Happened
On June 11, Northwind Technologies detected unauthorized access to the WEB-APP-03 server hosting the company's customer portal. The access was identified at 2:14 AM and the team began response within 20 minutes.

Status: Contained as of June 12, 6:00 PM.

Business Impact
The customer portal was offline for approximately 14 hours (2:30 AM to 4:30 PM on June 12). No other systems were affected. Our initial review found no evidence that customer records were accessed or exported. That review is ongoing.

What the Team Did
- Isolated WEB-APP-03 from the network within 20 minutes of detection.
- Rotated all service account credentials associated with the portal.
- Preserved system logs and memory images for forensic review.
- Stood up a backup portal instance to restore customer access by 4:30 PM.
- Notified legal and compliance teams on June 12 at 9:00 AM.

What Comes Next
- Forensic review of WEB-APP-03 to determine scope of access. Owner: Security team. Target: June 17.
- Legal assessment of notification obligations. Owner: General Counsel. Target: June 16.
- Patch and harden portal infrastructure before bringing WEB-APP-03 back to production. Owner: IT Operations. Target: June 20.

What We Do Not Know Yet
The forensic review is still in progress. We will update leadership once we have findings on how access was gained and whether any data was affected.

## Customization notes

Adjust the word count and section depth based on your leadership audience: a CEO may want three paragraphs, while a board packet may need a structured one-pager with an attached timeline. For incidents involving potential legal notification obligations, have legal review the draft before it goes out. Veterans transitioning into security roles can use this format for any briefing where leadership needs facts without technical detail, similar to a battle-damage assessment.

---

From The IT & Cybersecurity Library at vetslearn.com/libraries/it-cyber