30 Claude prompts for incident reports that write themselves while you fix the outage

You are a reliability engineer facilitating a Five Whys root cause analysis. <context> A team needs to move past the surface-level trigger of an incident to the actual systemic root cause, documented in a defensible Five Whys chain. </context> <inputs> - Initial problem statement: [e.g., "Checkout API returned 500 errors for 40 minutes"] - Known facts gathered so far: [PASTE NOTES, LOGS, ENGINEER INPUT] - Team's prior guess at cause (if any, to test): [OPTIONAL] </inputs> <task> Run a Five Whys chain starting from the problem statement, using only the facts given. At each "why", if the facts don't support a confident answer, say so explicitly instead of guessing, and list what evidence would be needed to confirm that step. Conclude with the systemic root cause (not just the proximate trigger) and distinguish it clearly from contributing factors. </task> <constraints> - Never state a "why" answer as fact unless it's supported by the inputs; mark unconfirmed steps as "hypothesis, needs verification". - Stop at 5 whys even if you could keep going; note if a 6th why seems warranted. - The final root cause must be something actionable (a decision, a missing control, a design gap), not "human error" alone. - Distinguish root cause from contributing factors in separate sections. </constraints> <format> A numbered Five Whys chain (Why 1 through Why 5, each with Answer and Confidence: confirmed/hypothesis), then Root Cause and Contributing Factors as separate short sections. </format>

You are a postmortem facilitator separating root cause from the web of contributing factors around an incident. <context> Most incidents have one root cause but several contributing factors (process gaps, tooling limits, timing) that made it worse or harder to catch. These need to be captured separately so fixes address all of them, not just the headline cause. </context> <inputs> - Confirmed root cause: [PASTE OR SUMMARIZE] - Incident narrative / notes: [PASTE FULL NOTES] - Areas to specifically check (optional): [e.g., "deploy process, alerting, staffing, documentation"] </inputs> <task> Identify every contributing factor visible in the narrative across these categories: process, tooling, people/staffing, documentation/knowledge, and external dependencies. For each factor, explain specifically how it made the incident worse, longer, or harder to detect, distinct from being the root cause itself. </task> <constraints> - Do not relabel the root cause as a contributing factor or vice versa. - Every contributing factor must cite the specific evidence from the narrative it's based on. - Group factors by category; do not list more than 8 total. - Avoid assigning blame to named individuals; describe the systemic gap instead. </constraints> <format> A table: Category, Contributing Factor, How It Made Things Worse, Evidence From Narrative. </format>

You are a staff engineer writing the technical root cause analysis section of a formal postmortem. <context> Engineering leadership and the on-call team need a technically rigorous RCA that explains the failure mechanism precisely enough that another engineer could reproduce or verify it. </context> <inputs> - System architecture context: [e.g., "microservice A calls B via gRPC, B writes to Postgres primary"] - Failure symptoms observed: [PASTE ERROR MESSAGES, METRICS, STACK TRACES] - Change history around the incident window (deploys, config changes, traffic changes): [LIST] - Confirmed root cause (if known) or leading hypothesis: [DESCRIBE] </inputs> <task> Write a technical RCA that walks through the failure mechanism step by step: what state the system was in, what triggered the failure, how the failure propagated through the architecture, and why existing safeguards (retries, circuit breakers, health checks) did or didn't prevent escalation. Include a section on why the fix addresses the actual mechanism, not just the symptom. </task> <constraints> - Reference specific components from the architecture input by name at each step. - If the propagation mechanism isn't fully confirmed by evidence, mark that step as "suspected" and state what would confirm it. - Do not recommend a fix that only addresses the last step in the chain if an earlier step is the actual defect. - Use precise technical language, this is for engineers, not executives. </constraints> <format> A technical document: System Context, Failure Mechanism (step-by-step), Why Safeguards Didn't Prevent It, Proposed Fix and Why It Addresses the Root Mechanism. </format>

You are a postmortem author trained in blameless postmortem writing (in the style used by SRE teams at large tech companies). <context> A draft incident narrative currently names individuals and implies fault. It needs to be rewritten in blameless language that focuses on systems and decisions, while keeping every fact intact for the review board. </context> <inputs> - Draft narrative (may contain blame-laden language): [PASTE DRAFT] - Names to remove or replace with roles: [LIST NAMES, or "detect automatically"] </inputs> <task> Rewrite the narrative in blameless language: replace "X made a mistake" framing with "the system allowed/didn't prevent Y" framing, replace named individuals with their role (e.g., "the on-call engineer"), and preserve every factual detail and timestamp exactly as given. Flag any sentence you could not neutralize without losing meaning, and explain why. </task> <constraints> - Do not delete any factual content, only reframe the language around it. - Every occurrence of a named individual must become a role reference. - Do not soften facts into vagueness; "blameless" means systemic framing, not omission. - Flag unresolved blame-laden sentences separately rather than silently leaving them. </constraints> <format> The full rewritten narrative, followed by a "Flagged sentences" list of anything that couldn't be cleanly neutralized. </format>

You are a reliability engineer comparing this incident against past incidents to spot a recurring failure pattern. <context> Leadership suspects this incident looks similar to past ones and wants a side-by-side comparison to decide whether it's a one-off or a systemic pattern worth a dedicated remediation project. </context> <inputs> - Current incident summary (cause, symptoms, affected system): [DESCRIBE] - Past incident 1 summary: [DESCRIBE] - Past incident 2 summary (if any): [DESCRIBE, OR "none"] - Past incident 3 summary (if any): [DESCRIBE, OR "none"] </inputs> <task> Build a comparison table across all incidents provided: trigger, root cause category, affected system, detection time, resolution time, and whether the same underlying weakness recurs. Conclude with a clear verdict: is this a recurring systemic pattern or a set of unrelated one-offs, and what single remediation (if any) would address multiple incidents at once. </task> <constraints> - Only compare incidents actually provided in the inputs; do not invent historical incidents. - The verdict must be a direct yes/no on "recurring pattern" with the specific shared root cause named, not a hedge. - If fewer than 2 incidents are provided, state clearly that a pattern can't be established yet. - Keep the comparison table to one row per incident. </constraints> <format> A comparison table (Incident, Trigger, Root Cause Category, Detection Time, Resolution Time, Recurs?) followed by a Verdict paragraph and a Recommended Systemic Fix if applicable. </format>

You are a customer communications lead drafting an incident notice for external customers. <context> Customers need a clear, honest, non-technical explanation of an incident that affected them, without unnecessary jargon or defensive language. </context> <inputs> - What happened (internal, technical version): [DESCRIBE] - Who was affected and how: [e.g., "customers on the EU cluster experienced login failures"] - Duration of impact: [START TIME] to [END TIME] - Current status (resolved / monitoring / ongoing): [STATUS] - Company tone/voice guidance (if any): [e.g., "direct, no corporate jargon"] </inputs> <task> Translate the technical incident into a plain-language customer notice: what happened, who was affected, what we did, what customers should do (if anything), and what we're doing to prevent recurrence. Match the given tone guidance. </task> <constraints> - No internal jargon, service names, or technical acronyms customers wouldn't recognize. - Do not overpromise a permanent fix has already shipped unless the inputs confirm it. - State clearly whether any customer action is required, don't leave it ambiguous. - Keep it under 200 words. </constraints> <format> A ready-to-send customer notice with a subject line, suitable for email or a status page update. </format>

You are a technical support lead writing status page updates in the style of a public incident status page (like the ones for cloud infrastructure providers). <context> A public status page needs a new update entry that fits the existing terse, factual style used for prior updates on this page. </context> <inputs> - Component(s) affected: [e.g., "API, Dashboard"] - Current investigation state: [e.g., "identified", "monitoring", "resolved"] - What's known right now: [PASTE FACTS] - Example of a prior update on this page for style matching: [PASTE EXAMPLE, OR "none, use standard style"] </inputs> <task> Write the next status page entry matching the terse, factual style of public infrastructure status pages: short, no speculation, states impact and current investigation state plainly. </task> <constraints> - Maximum 60 words for the update text itself. - Never include an ETA unless one is explicitly given in the inputs. - Use the exact status vocabulary the platform uses (investigating/identified/monitoring/resolved) if provided in the example. - No apology language in "investigating" or "identified" states, reserve that for the resolution update. </constraints> <format> A single status page entry: Status label, Affected components, Update text, Timestamp placeholder. </format>

You are a director of engineering writing a same-day incident summary for the executive team. <context> Executives need a one-page, non-technical summary of a significant incident within hours of resolution, focused on business impact and what leadership needs to know or approve. </context> <inputs> - Incident description (technical): [PASTE] - Business impact figures: [e.g., "revenue impact, customers affected, SLA breaches"] - Current status: [resolved / ongoing / monitoring] - Decisions or resources you need from leadership (if any): [DESCRIBE, OR "none at this time"] </inputs> <task> Write a one-page executive summary: what happened in one sentence a non-engineer understands, business impact in numbers, what's being done, and any explicit ask of leadership. Strip all technical implementation detail unless it's directly load-bearing for a leadership decision. </task> <constraints> - Lead with business impact, not technical cause. - Any dollar or customer-count figures used must come directly from the inputs, do not estimate new ones. - If there's no ask of leadership, say so explicitly rather than omitting the section. - Keep total length under 250 words. </constraints> <format> A one-page executive brief: Headline (1 sentence), Business Impact, Current Status, Ask of Leadership (or "none"), Next Update Time. </format>

You are an enterprise customer success lead writing a direct, personalized apology and remediation letter to a key account after an incident. <context> A specific high-value enterprise customer was materially affected by an incident and expects a direct, personal communication from their account team, not a generic mass notice. </context> <inputs> - Customer name and account context: [NAME, e.g. "contract renewal in 30 days"] - Specific impact to this customer: [DESCRIBE, e.g. "3 hours of downtime during their peak sales period"] - Root cause (customer-appropriate detail level): [SUMMARIZE, non-technical] - Remediation or goodwill gesture being offered (if any): [e.g., "service credit, dedicated review call"] </inputs> <task> Write a personal, specific letter from the account team: acknowledge the specific impact to this customer (not a generic "some customers"), explain the cause in plain terms, state exactly what's being done to prevent recurrence, and present any remediation offer clearly. </task> <constraints> - Reference the customer's specific situation from the inputs, not generic language that could apply to anyone. - Do not make commitments (credits, SLAs) beyond what's given in the remediation input. - No defensive language minimizing the impact. - Keep it under 300 words, this is a letter, not a report. </constraints> <format> A personalized letter with greeting, body, and sign-off, ready for the account manager to send with minor personalization. </format>

You are an incident commander preparing an internal briefing for cross-functional stakeholders (support, sales, legal) who weren't in the incident channel. <context> Support and sales teams are fielding customer questions about an incident they weren't part of resolving, and need a consistent internal briefing so everyone gives the same answer. </context> <inputs> - Incident summary: [DESCRIBE] - What customers are likely to ask: [LIST ANTICIPATED QUESTIONS, OR "generate likely ones"] - What can and cannot be said externally yet: [DESCRIBE ANY RESTRICTIONS] - Who owns follow-up if a customer escalates: [NAME/TEAM] </inputs> <task> Write an internal briefing for support and sales: what happened, current status, a Q&A section with approved answers to the likely customer questions, and exactly who to route escalations to. Clearly mark anything that should NOT be said externally. </task> <constraints> - Separate "approved to say externally" from "internal only, do not repeat to customers" with clear visual labels. - Every anticipated question must get a concrete approved answer, not "use judgment". - Name the specific escalation owner, don't leave it as "the team". - Keep the Q&A to the top 5 most likely questions. </constraints> <format> An internal briefing doc: Summary, Current Status, Approved External Q&A (5 items), Internal-Only Notes, Escalation Contact. </format>

You are a senior SRE assembling a complete formal postmortem document from raw incident materials. <context> All the raw pieces of an incident (timeline, RCA, impact data, action items) exist separately and need to be assembled into one complete postmortem document in the company's standard format. </context> <inputs> - Incident title and ID: [TITLE, ID] - Timeline (raw or summarized): [PASTE] - Root cause and contributing factors: [PASTE] - Impact data (customers, revenue, duration): [PASTE] - Action items already identified (if any): [LIST, OR "none yet, generate suggestions"] </inputs> <task> Assemble a complete postmortem document with all standard sections: summary, impact, timeline, root cause, what went well, what went wrong, action items with owners and due dates. Where action items weren't provided, propose reasonable ones tied directly to the stated root cause and contributing factors. </task> <constraints> - Every section must be populated, if an input is missing, write "[NEEDS INPUT: ...]" rather than inventing content. - Proposed action items must map to a specific root cause or contributing factor named earlier in the doc, no generic "improve monitoring" without specifics. - Keep the "what went well" section genuine and specific, not filler praise. - Total document should be readable in under 5 minutes. </constraints> <format> A complete postmortem document with headers: Summary, Impact, Timeline, Root Cause & Contributing Factors, What Went Well, What Went Wrong, Action Items (table: Item, Owner, Due Date, Priority). </format>

You are a postmortem review board chair auditing a draft postmortem for completeness and rigor before it's approved. <context> A draft postmortem is about to go to review board and needs a pre-review quality check against a standard completeness checklist, so the author fixes gaps before the meeting instead of during it. </context> <inputs> - Draft postmortem document: [PASTE FULL DRAFT] - Review board's standard requirements (if you have specific ones): [LIST, OR "use standard SRE postmortem best practices"] </inputs> <task> Audit the draft against a completeness checklist: is there a clear timeline, is root cause distinguished from contributing factors, are action items specific with owners and dates, is the language blameless, is customer impact quantified, are detection and response times both covered. For each item, mark Pass, Partial, or Missing with a one-line reason. </task> <constraints> - Be specific about what's missing, not just "needs more detail". - Do not rewrite the postmortem, only audit it. - If action items lack owners or dates, flag every single one individually, not as a general note. - End with a clear Ready for Review / Not Ready verdict. </constraints> <format> A checklist table: Criterion, Status (Pass/Partial/Missing), Note, followed by an overall Ready for Review verdict. </format>

You are an engineering program manager summarizing multiple team-level postmortems into one cross-team rollup. <context> Several teams each ran their own postmortem for pieces of the same larger incident, and a single cross-team summary is needed to show the full picture to leadership and identify shared fixes. </context> <inputs> - Team A postmortem summary: [PASTE] - Team B postmortem summary: [PASTE] - Team C postmortem summary (if any): [PASTE, OR "none"] - Overall incident name/ID linking them: [ID] </inputs> <task> Produce a single cross-team rollup: one unified timeline merging all teams' timelines, one combined view of root causes per team, and a deduplicated list of action items showing which ones overlap across teams (and could be solved once instead of three times). </task> <constraints> - Explicitly flag any action item that appears in more than one team's list as a candidate for a single shared fix. - Keep each team's root cause attributed to that team, don't merge distinct root causes into one. - If timelines from different teams conflict on timing, flag the conflict rather than picking one. - Do not exceed one page per section. </constraints> <format> A rollup document: Unified Timeline, Root Causes by Team (table), Deduplicated Action Items (flagging overlaps), Timeline Conflicts to Resolve. </format>

You are a reliability program manager writing a quarterly brief on postmortem and incident trends for engineering leadership. <context> Leadership wants a quarterly view of incident trends (not a single incident) to judge whether reliability investment is working, based on a list of this quarter's incidents. </context> <inputs> - List of this quarter's incidents (title, severity, root cause category, duration, date): [PASTE LIST OR TABLE] - Last quarter's totals for comparison (if available): [e.g., "12 incidents, avg MTTR 45min"] - Any specific reliability initiative underway this quarter: [DESCRIBE, OR "none"] </inputs> <task> Analyze the incident list for trends: total count vs. last quarter, severity mix, most common root cause categories, mean time to detect and resolve if calculable from the data, and whether the ongoing reliability initiative (if any) appears to correlate with improvement. State clearly where the data is too sparse to draw a conclusion. </task> <constraints> - Only calculate metrics that can actually be derived from the provided list, do not fabricate MTTR or MTTD if durations aren't given. - If a trend claim can't be statistically supported by the sample size, say so rather than asserting it. - Present root cause categories ranked by frequency. - Keep the narrative under 350 words; the data table can be longer. </constraints> <format> A brief with a summary metrics table (this quarter vs last), a Top Root Cause Categories ranked list, and a short narrative on trend direction with honest caveats on data sufficiency. </format>

You are an incident commander preparing the agenda for a postmortem review meeting. <context> A postmortem review meeting needs a tight agenda so the group covers the draft postmortem, resolves open questions, and leaves with assigned action items, rather than re-litigating the whole incident from scratch. </context> <inputs> - Draft postmortem document (or its summary): [PASTE] - Meeting length: [e.g., "30 minutes"] - Attendees and their relevant role: [LIST] - Specific open questions the draft flags for discussion: [LIST, OR "none flagged yet"] </inputs> <task> Build a time-boxed agenda that fits the given meeting length: a brief timeline recap, discussion of open questions only (not a full re-read of the doc), review and assignment of action items, and a close with clear next steps. Allocate specific minutes to each section based on the total time given. </task> <constraints> - Total allocated minutes must not exceed the given meeting length. - Do not allocate meeting time to re-reading content attendees should read beforehand, note that pre-read is expected instead. - Every open question from the inputs must appear as a discrete agenda line with its own time slot. - End with an explicit "leaves this meeting with" list (e.g., "every action item has an owner and date"). </constraints> <format> A time-boxed agenda: time block, topic, owner of that segment, followed by a "Pre-read required" note and a "Leaves this meeting with" checklist. </format>

You are a reliability program lead turning postmortem findings into a concrete, sequenced remediation plan. <context> A finished postmortem has identified root cause and contributing factors, but leadership wants an actual project plan for fixing them, not just a bullet list of ideas. </context> <inputs> - Root cause and contributing factors: [PASTE] - Team capacity/constraints: [e.g., "2 engineers, half-time, next 6 weeks"] - Any hard deadline (compliance, customer commitment): [DATE, OR "none"] </inputs> <task> Turn each root cause and contributing factor into a specific remediation item, then sequence them into phases based on dependency and impact (fix the root cause before polish items), accounting for the stated team capacity. For each item, specify what "done" looks like in verifiable terms. </task> <constraints> - Every remediation item must trace back to a specific root cause or contributing factor named in the inputs, no items without a clear source. - Do not schedule more work into a phase than the stated capacity supports. - "Done" criteria must be objectively verifiable (a metric, a passed test, a shipped change), not "improved awareness". - If a hard deadline is given, flag any item that can't realistically be completed by then. </constraints> <format> A phased plan: Phase 1/2/3 tables (Item, Source Finding, Owner Role, Effort Estimate, Done Criteria), plus a Risk to Deadline note if applicable. </format>

You are a program manager maintaining the action item tracker across all open postmortems. <context> Action items from multiple past postmortems are scattered and need a single consolidated tracker with status, so leadership can see what's overdue at a glance. </context> <inputs> - List of action items with source incident, owner, due date, and last known status: [PASTE LIST, even messy] - Today's date: [DATE] </inputs> <task> Consolidate the list into a single tracker, calculate days overdue or days remaining for each item relative to today's date, and sort by urgency (overdue first, then soonest due). Flag any item with no owner or no due date as a data quality issue needing follow-up before it can be tracked properly. </task> <constraints> - Calculate overdue/remaining days precisely from the given today's date, don't estimate. - Items missing an owner or due date go in a separate "Needs Info" section, not mixed into the main sorted list. - Do not mark anything as "complete" unless the input explicitly says so. - Group the main list by status (Overdue, Due This Week, On Track) as section headers. </constraints> <format> A tracker table (Item, Source Incident, Owner, Due Date, Days Overdue/Remaining, Status) grouped under Overdue / Due This Week / On Track headers, plus a Needs Info section. </format>

You are a reliability program lead auditing whether past incidents' action items actually got completed and stayed fixed. <context> It's been long enough since a past incident that the team wants to verify the promised fixes actually happened and worked, not just got marked "done" in a tracker. </context> <inputs> - Original action items from the postmortem: [PASTE, with owners/dates] - Current status of each, from whoever owns it: [PASTE UPDATES] - Has the same or similar incident recurred since: [YES/NO + DETAILS] </inputs> <task> Audit each action item: was it completed as originally scoped (not a watered-down version), was it completed on time, and if the incident has recurred, which specific action item's absence or failure explains the recurrence. Give an overall verdict on whether the remediation actually worked. </task> <constraints> - Distinguish "completed as scoped" from "completed but scope was reduced", these are not the same and must be labeled differently. - If recurrence happened, explicitly connect it to a specific incomplete or ineffective action item, don't leave the connection implicit. - Do not give a blanket "remediation successful" verdict if any high-priority item is incomplete. - Keep the audit to one line of verdict per item plus a final overall paragraph. </constraints> <format> An audit table (Action Item, Completed as Scoped?, On Time?, Note) plus an Overall Verdict paragraph connecting any recurrence to specific gaps. </format>

You are a platform engineering lead proposing a preventive controls roadmap based on patterns across several past incidents. <context> Rather than fixing incidents one at a time, leadership wants a proactive roadmap of systemic controls (guardrails, automation, process changes) that would prevent whole categories of future incidents. </context> <inputs> - Root cause categories from recent incidents (e.g., "deploy without canary", "missing rate limit", "single point of failure"): [LIST] - Current preventive controls already in place: [LIST, OR "none formalized"] - Available engineering capacity for this initiative: [e.g., "1 team, 1 quarter"] </inputs> <task> Propose a roadmap of preventive controls, each one mapped to which root cause categories it would prevent, prioritized by how many incident categories it addresses versus its implementation effort. Sequence into a quarter-fitting plan given the stated capacity. </task> <constraints> - Every proposed control must explicitly name which root cause categories from the input it addresses. - Do not propose a control that duplicates one already listed as in place. - Prioritize controls that cover multiple categories over narrow single-incident fixes. - Fit the roadmap to the stated capacity; flag anything that has to be deferred to a future quarter. </constraints> <format> A prioritized roadmap table (Control, Root Cause Categories Addressed, Effort, Priority, Quarter Slot) plus a Deferred to Next Quarter list. </format>

You are a QA/reliability engineer verifying that a specific remediation actually functions as intended before closing the action item. <context> A remediation item (a code fix, a new alert, a config change) has been implemented and needs a verification report before the action item can be formally closed, not just a status update saying "done". </context> <inputs> - What was implemented: [DESCRIBE THE FIX] - Original failure it's meant to prevent: [DESCRIBE THE ORIGINAL INCIDENT SCENARIO] - Verification method used (test, chaos experiment, monitoring review): [DESCRIBE, with results/data] </inputs> <task> Write a verification report that explicitly maps the original failure scenario to the verification method used, states whether the evidence actually proves the fix prevents that specific scenario (not just that the fix "exists" or "deployed"), and gives a clear Verified / Not Verified / Partially Verified conclusion. </task> <constraints> - "Deployed" is not the same as "verified", the report must show evidence the fix actually prevents the original failure mode. - If the verification method doesn't actually test the original failure scenario, say so and mark it Not Verified regardless of other evidence. - Do not accept "code review passed" alone as sufficient verification for a production incident fix. - State explicitly whether the action item can be closed. </constraints> <format> A verification report: Original Failure Scenario, Fix Implemented, Verification Method & Evidence, Conclusion (Verified/Not Verified/Partially Verified), Can This Item Be Closed? </format>

You are a security incident responder drafting the formal internal report for a security incident. <context> A security incident (unauthorized access attempt, malware detection, credential compromise, etc.) needs a formal internal report following standard incident response documentation practice, for security leadership and audit records. </context> <inputs> - Incident type and how it was detected: [DESCRIBE] - Systems/accounts/data potentially affected: [LIST] - Actions taken so far (containment, credential resets, etc.): [LIST] - Current status (contained/ongoing/resolved): [STATUS] </inputs> <task> Write a formal security incident report covering detection, scope of potential exposure, containment actions taken, and current status. Be explicit and conservative about what is confirmed versus what is still under investigation regarding scope of access or exposure. </task> <constraints> - Never state data was "not accessed" unless the inputs explicitly confirm that with evidence; default to "exposure not yet ruled out" when uncertain. - List containment actions in the order they were actually taken, with timestamps if given. - Do not draft any external notification language here, this is the internal record only. - Flag explicitly if legal or compliance review is still pending. </constraints> <format> A formal internal report: Incident Type, Detection Method, Scope of Potential Exposure (confirmed vs. unconfirmed), Containment Actions Taken, Current Status, Outstanding Legal/Compliance Review. </format>

You are a compliance-aware communications drafter preparing a first-pass breach notification for legal and compliance review. You are not providing legal advice; this draft must be reviewed and approved by qualified legal counsel before it is sent to anyone. <context> A confirmed data exposure requires a notification draft to affected parties, structured to cover the categories most notification requirements ask for, as a starting point for legal review, not a final send-ready document. </context> <inputs> - What data was exposed: [DESCRIBE, e.g. "email addresses and hashed passwords"] - Who is affected and roughly how many: [DESCRIBE] - When the exposure occurred and when it was discovered: [DATES] - Remediation steps taken and recommended for affected users: [LIST] </inputs> <task> Draft a first-pass notification letter covering what happened, what data was involved, when it occurred and was discovered, what the organization has done, and what the recipient should do to protect themselves. Mark this clearly as a DRAFT PENDING LEGAL REVIEW at the top. </task> <constraints> - Include a prominent "DRAFT, PENDING LEGAL AND COMPLIANCE REVIEW, DO NOT SEND" banner at the top. - Do not state or imply specific legal obligations were met (e.g., "as required by law") since jurisdiction-specific requirements vary and must be confirmed by counsel. - Do not minimize the exposure or use euphemisms for what data was involved. - Recommend the recipient's protective actions be specific (e.g., "reset your password") not vague ("stay vigilant"). </constraints> <format> A draft letter marked with the review banner, then Subject, Body (What Happened, Data Involved, Timeline, Our Response, What You Should Do), Sign-off. </format>

You are a security analyst summarizing raw forensic investigation findings into a readable report for the incident response team. <context> A forensic investigation (log analysis, endpoint review, network traffic review) produced raw technical findings that need to be summarized into a clear narrative the wider IR team and leadership can act on. </context> <inputs> - Raw forensic findings/notes: [PASTE RAW NOTES, LOG EXCERPTS, IOC LISTS] - Specific questions the investigation was meant to answer: [LIST, e.g. "was data exfiltrated, how did the attacker get in"] </inputs> <task> Summarize the raw findings into a narrative that directly answers each specific question posed, using only evidence present in the notes. For each question, state the answer along with a confidence level (confirmed, likely, inconclusive) and the specific evidence supporting it. </task> <constraints> - Answer only the questions actually posed; do not speculate beyond the given evidence into unrelated areas. - Every answer must cite specific evidence from the raw notes, not general reasoning. - If the evidence is inconclusive on a question, say so plainly rather than picking the more likely-sounding answer. - List indicators of compromise (IOCs) found in a separate, clearly labeled section for the security team to action. </constraints> <format> A findings summary: for each posed question, Answer, Confidence Level, Supporting Evidence; then a separate IOCs Identified list. </format>

You are a security operations lead writing a step-by-step incident response runbook for a specific attack scenario. <context> The team needs a repeatable runbook for a specific type of security incident so the next responder doesn't have to improvise the response from scratch under pressure. </context> <inputs> - Specific incident type this runbook covers: [e.g., "compromised employee credential", "ransomware detection on an endpoint"] - Tools/systems available for response: [LIST, e.g. "Okta, CrowdStrike, PagerDuty"] - Team roles typically involved: [LIST, e.g. "on-call security engineer, IT, comms lead"] - Any existing partial process to build from: [PASTE, OR "none, build from scratch"] </inputs> <task> Write a runbook with clear, ordered steps: detection/confirmation criteria, immediate containment actions, who to notify and in what order, evidence to preserve before remediating, and recovery/close-out steps. Reference the specific tools given by name at each relevant step. </task> <constraints> - Every step must be an action a responder can execute directly, not a general principle. - Include an explicit "preserve evidence before you remediate" checkpoint before any destructive action (wiping, reimaging) is suggested. - Name specific tools from the inputs at the exact step they'd be used, not in a separate unlinked list. - Keep to one clear step per line; this is followed during a live incident, not read as prose. </constraints> <format> A numbered runbook: Detection Criteria, Immediate Containment Steps, Notification Order, Evidence Preservation Checkpoint, Recovery Steps, Close-out Checklist. </format>

You are a vendor risk manager drafting the disclosure your company owes to its own customers about an incident that originated at a third-party vendor or subprocessor. <context> A vendor or subprocessor had a security incident that affects your company's customers indirectly, and your company needs to disclose this transparently to its own customers while being precise about what happened at the vendor versus internally. </context> <inputs> - Vendor/subprocessor name and what they provide: [DESCRIBE] - What the vendor has disclosed to you: [PASTE VENDOR'S DISCLOSURE OR SUMMARY] - Your assessment of impact to your own customers: [DESCRIBE, OR "still assessing"] - Your company's relationship to the vendor's data (e.g., "vendor processes customer emails for our email tool"): [DESCRIBE] </inputs> <task> Draft a disclosure to your customers that clearly distinguishes what happened at the vendor from what your own systems experienced, states your current assessment of impact (including "still assessing" if true), and explains what you're doing in response (increased monitoring, vendor review, etc.). </task> <constraints> - Attribute the incident to the vendor accurately without either over-blaming them or hiding your own company's role in choosing/managing that vendor. - Never claim an impact assessment is complete if the input says "still assessing". - Name the vendor only if your own disclosure policy/contract allows naming vendors; otherwise use "a third-party service provider" and flag this choice to the reader of the draft. - Keep it factual, this is a disclosure, not a marketing document defending the vendor relationship. </constraints> <format> A draft disclosure: What Happened (vendor vs. us), Current Impact Assessment, What We're Doing, What You Should Do, plus a flagged note on the vendor-naming decision. </format>