The IT & Cybersecurity Library Documented. Defensible. Verified.

Builds a step-by-step runbook for a recurring operational task so any qualified team member can execute it without asking questions. Use it for any procedure that runs more than once and matters if it goes wrong.

## Context
You are a technical writer helping an IT or cybersecurity professional document a recurring operational procedure. The audience is a qualified team member who knows the environment but is running this task for the first time without the original author in the room.

System or environment: [SYSTEM OR ENVIRONMENT NAME]
Task being documented: [TASK NAME AND BRIEF DESCRIPTION]
Pre-conditions (what must be true before starting): [PRE-CONDITIONS]
Step-by-step notes from the author: [RAW PROCEDURE NOTES]
Known failure modes and what to do: [FAILURE MODES]
Escalation path: [ESCALATION CONTACT OR PROCESS]
Tools and access required: [TOOLS AND ACCESS]

## Task
Produce a runbook with these sections: Overview, Pre-conditions, Tools and Access Required, Procedure (numbered steps), Verification (how to confirm success), Failure Modes and Recovery, Escalation, and Revision History (one placeholder row).

## Standards
- Number every step. Sub-steps use 1a, 1b format.
- Each step is one action. Start with a verb: open, run, click, verify, copy.
- Include exact commands, paths, and field values only when the author supplied them. Use [PLACEHOLDER] for any value you cannot fill from the notes.
- Verification section must describe a specific observable outcome that confirms success, not a vague "check that it worked."
- Do not invent commands, hostnames, IP addresses, file paths, tool names, or system behaviors the notes do not contain.
- Failure Modes comes from the author's notes only. If none were supplied, write this section as empty and flag it for the author to complete.
- Tone is neutral and imperative. No conversational filler.
- Do not fabricate CVEs, vulnerability details, error codes, or log entries. If a step should reference an error code, write [ERROR CODE] as a placeholder.
- If any named system, tool, or command is missing or ambiguous, ask before drafting.

Sample output. Generated by AI from sample inputs:

# Runbook: Rotate Application Service Account Password
System: Northwind Corp Active Directory / IIS Web Farm
Version: 1.0 | Owner: J. Mercer | Last reviewed: 2026-06-13

## Overview
This runbook covers the quarterly rotation of the svc_webapp service account password used by the Northwind e-commerce application on IIS. Incorrect rotation causes application authentication failures.

## Pre-conditions
- Maintenance window is active (Saturday 02:00-04:00 local)
- You have Domain Admin rights in CORP domain
- You have RDP access to WEB-APP-03 and WEB-APP-04
- Backup of IIS application pool credentials is current (verify with the config backup runbook)

## Tools and Access Required
- Active Directory Users and Computers (ADUC) or PowerShell with RSAT
- RDP client
- IIS Manager on WEB-APP-03 and WEB-APP-04
- Password manager access for svc_webapp entry

## Procedure

1. Generate a new password meeting the CORP complexity policy.
   1a. Use the approved password manager to generate a 20-character random password.
   1b. Save the new password to the svc_webapp entry before continuing.

2. Update the password in Active Directory.
   2a. Open ADUC or run: `Set-ADAccountPassword -Identity svc_webapp -Reset`
   2b. Enter the new password when prompted.
   2c. Confirm the command completes without error.

3. Update the IIS application pool on WEB-APP-03.
   3a. RDP to WEB-APP-03.
   3b. Open IIS Manager. Navigate to Application Pools.
   3c. Right-click NorthwindAppPool. Select Advanced Settings.
   3d. Under Process Model, update Identity password to the new value.
   3e. Click OK. Recycle the application pool.

4. Repeat step 3 on WEB-APP-04.

5. Restart the Northwind Windows Service on WEB-APP-03 and WEB-APP-04.
   5a. Run: `Restart-Service -Name NorthwindSvc`

## Verification
Navigate to https://[APP URL]/healthcheck from an internal workstation. The page must return HTTP 200 and display "Status: OK" within 60 seconds of the service restart. If it does not, go to Failure Modes.

## Failure Modes and Recovery
- Health check returns HTTP 500 or login error: the new password likely did not save to one IIS pool. Re-open IIS Manager on both servers, verify the password under Advanced Settings, and recycle both pools.
- AD password change fails with Access Denied: confirm your account is in the Domain Admins group and retry.

## Escalation
If the application does not recover within 15 minutes: contact [ESCALATION CONTACT] at [PHONE/SLACK] and open a P1 incident ticket.

## Revision History
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | 2026-06-13 | [AUTHOR] | Initial draft |

Writes a structured knowledge base (KB) article from notes about a resolved issue or technical question. Use it right after closing a ticket so the fix is captured before context fades.

## Context
You are a technical writer helping an IT or cybersecurity professional capture a resolved issue or technical question as a reusable knowledge base (KB) article. The audience is a team member or end user who hits the same problem later and needs to solve it without escalating.

System or application: [SYSTEM OR APPLICATION]
Issue summary: [ISSUE SUMMARY]
Symptoms as the user experienced them: [SYMPTOMS]
Root cause: [ROOT CAUSE]
Resolution steps taken: [RESOLUTION STEPS]
Verification that the issue is resolved: [VERIFICATION STEPS]
Any workarounds if the full fix is not available: [WORKAROUNDS]
Related ticket number or reference: [TICKET OR REFERENCE NUMBER]
Audience (end user, tier-1 technician, or engineer): [AUDIENCE]

## Task
Produce a KB article with these sections: Title, Summary (two sentences), Applies To, Symptoms, Root Cause, Resolution, Verification, Workaround (if applicable), Related Resources.

## Standards
- Title format: [Action or Resolution] for [Issue] on [System]. Example: Fix for Login Failure After Password Reset on Okta.
- Write for the stated audience. End-user articles avoid command-line steps. Engineer articles can include commands verbatim.
- Include exact steps, commands, and paths only when the author supplied them. Mark any value you cannot fill as [PLACEHOLDER].
- Root Cause states only what the author supplied. Do not theorize beyond the supplied facts.
- Do not invent error codes, log lines, CVE identifiers, hostnames, or system behaviors not in the inputs.
- Related Resources lists only references the author provides. Write [ADD REFERENCES] if none were supplied.
- If symptoms or resolution steps are missing, ask before drafting.

Sample output. Generated by AI from sample inputs:

# Fix for VPN Client Disconnect After Windows Update on GlobalProtect

## Summary
Users on Windows 11 workstations running GlobalProtect 6.2 may experience automatic VPN disconnection after installing the June 2026 cumulative update (KB5039302). Reverting the network adapter driver resolves the issue.

## Applies To
- Operating system: Windows 11 22H2 and 23H2
- VPN client: Palo Alto GlobalProtect 6.2.x
- Affected systems: Domain-joined workstations at Northwind Corp

## Symptoms
- VPN connects but drops within 30-90 seconds
- Event Viewer shows: "Network connection lost" under Application logs
- Issue began after Windows Update on or after June 10, 2026

## Root Cause
The June 2026 cumulative update (KB5039302) replaced the Intel Ethernet adapter driver with a version incompatible with the GlobalProtect virtual adapter on affected hardware. The driver version introduced was 12.19.1.36.

## Resolution
1. Open Device Manager on the affected workstation.
2. Expand Network Adapters.
3. Right-click the Intel Ethernet adapter. Select Properties.
4. Go to the Driver tab. Click Roll Back Driver.
5. Select the rollback reason and confirm.
6. Restart the workstation.
7. Connect to GlobalProtect and confirm stability over 5 minutes.

## Verification
VPN connection holds for at least 5 minutes without dropping. Event Viewer shows no network disconnect events during that window.

## Workaround
If rollback is not available (hardware has no prior driver stored), pause Windows Update and contact the IT Help Desk. A driver package is available on the internal software share at [PATH].

## Related Resources
- Ticket: HD-20481
- Vendor advisory: [ADD REFERENCES]

Drafts a clear, professional response to an open support ticket. Use it when you need a well-structured reply that addresses the user's issue without over-explaining or leaving gaps.

## Context
You are an IT support technician or help desk analyst drafting a response to a support ticket. The ticket was submitted by [USER NAME] in [DEPARTMENT]. The ticket system is [TICKETING SYSTEM, e.g., ServiceNow, Jira Service Management, Zendesk]. Ticket summary: [TICKET SUMMARY]. Current status: [CURRENT STATUS, e.g., in progress, awaiting parts, resolved]. Any actions already taken: [ACTIONS TAKEN].

## Task
Write a professional ticket response that:
- Acknowledges the issue in one sentence, using the user's own words where possible.
- States what has been done so far, if anything.
- Describes the next step and who owns it.
- Gives a realistic timeline for resolution or next contact: [EXPECTED TIMELINE].
- Closes with a direct offer to follow up.

## Standards
- Under 150 words. Plain language a non-technical user can follow.
- No jargon without a brief explanation.
- Confident and specific. Avoid "we will try" or "hopefully." State what will happen and when.
- Do not promise resolution if you cannot guarantee it. State the next concrete step instead.
- Do not invent ticket details, system names, error codes, or resolution steps that were not provided.
- If the ticket summary or actions taken are missing or ambiguous, ask before drafting rather than filling in plausible details.

Sample output. Generated by AI from sample inputs:

Hi Sergeant Martinez,

Thanks for submitting a ticket about your VPN connection dropping after the Windows update on June 10.

I've reviewed your device logs and confirmed the issue is a known conflict between the updated network adapter driver and our VPN client. I've pushed a corrected driver to your machine (WEB-APP-03). The push is scheduled to run tonight during the maintenance window.

You should be able to connect normally by 0800 tomorrow. Please test it then and reply here if the issue continues. If it is still dropping, I will remote in directly to resolve it the same morning.

Ticket: INC-4821
Next contact: 0800 June 14

Writes a structured root cause analysis for a resolved incident, based on the facts you supply. Use it after a service disruption or security incident to document what happened, why, and what prevents recurrence.

## Context
You are an IT engineer or security analyst writing a post-incident root cause analysis (RCA) for [INCIDENT ID]. The incident affected [AFFECTED SYSTEMS OR SERVICES] and impacted [USER OR BUSINESS IMPACT]. Incident timeline from your records: [TIMELINE, list of date-time and event pairs]. Root cause as determined by your team: [ROOT CAUSE]. Contributing factors: [CONTRIBUTING FACTORS]. Corrective actions taken: [CORRECTIVE ACTIONS TAKEN]. Preventive actions planned: [PREVENTIVE ACTIONS PLANNED]. RCA audience: [AUDIENCE, e.g., internal IT, management, customer].

## Task
Write an RCA document with these sections:
1. Executive Summary: two to three sentences covering what happened, when, and the business impact.
2. Timeline: the events from my records, formatted as a clear chronological list.
3. Root Cause: what the team determined, with a plain explanation of the causal chain.
4. Contributing Factors: any conditions that made the incident worse or harder to detect.
5. Corrective Actions: what was done to resolve it.
6. Preventive Actions: what will stop this from recurring, with owners and target dates from my inputs.

## Standards
- Factual and neutral. This is a learning document, not a blame document.
- Use only the timeline, root cause, and actions I provided. Do not invent events, error messages, CVEs, log entries, hostnames, or findings.
- Preventive actions must come from my input. Do not add recommendations I did not supply.
- Adjust depth and technical detail to match the stated audience.
- If timeline or root cause is missing, ask before drafting.

Sample output. Generated by AI from sample inputs:

RCA: INC-7741 | Email Service Outage | Northwind Fabrication

Executive Summary
On June 10, Northwind Fabrication's internal email service was unavailable for 2 hours and 17 minutes, from 0913 to 1130. All 240 employees were unable to send or receive email. The outage was caused by a misconfigured certificate renewal that allowed the mail server's TLS certificate to expire without alert.

Timeline
- 0913: Monitoring alert fires for SMTP (Simple Mail Transfer Protocol) connection failures on NW-MAIL-01.
- 0921: Tier 2 engineer confirms TLS certificate expired at 0900.
- 0934: Replacement certificate requested from internal PKI (Public Key Infrastructure).
- 1045: Certificate issued and installed on NW-MAIL-01.
- 1118: Service restored; delivery queue clearing.
- 1130: All pending messages delivered. Incident declared resolved.

Root Cause
The TLS certificate for NW-MAIL-01 was not enrolled in the certificate lifecycle monitoring system during a mail server migration in March. No automated renewal or expiration alert was configured for this certificate.

Contributing Factors
- Migration checklist did not include a step to register new assets in the certificate monitoring system.
- Manual certificate inventory was last audited in January.

Corrective Actions
- Expired certificate replaced and email service restored by 1130.

Preventive Actions
- Owner: Network Team | Target: June 28 | Register all certificates on NW-MAIL-01 and NW-MAIL-02 in the certificate monitoring platform.
- Owner: Change Management | Target: July 15 | Add certificate registration as a mandatory checklist item in the server migration runbook.

Drafts a calm, professional reply to a frustrated or hostile user ticket. Use it when a ticket comes in angry or escalating and you need to de-escalate without losing your footing.

## Context
You are a help desk analyst or IT support technician replying to a ticket from [USER NAME] at [ORGANIZATION NAME]. The user is frustrated. The situation: [TICKET SUMMARY]. What has already been done or communicated: [PRIOR ACTIONS]. Your role is to respond professionally, acknowledge the user's frustration, explain the current status clearly, and give them a concrete next step.

## Task
Draft one reply to this ticket. The reply should: acknowledge the frustration without being defensive, summarize what is known about the issue and what has been done, state the next action with a name or team responsible and an expected timeframe if one exists, and give the user one thing they can do or know right now.

## Standards
- Plain, direct language. Short paragraphs.
- Acknowledge the impact on the user. Do not minimize it.
- Do not promise a resolution time you do not actually have.
- Do not blame the user, other teams, or the system.
- Do not use jargon the user would not know.
- Tone is calm and professional. Not apologetic to the point of weakness. Not cold.
- Under 200 words.
- Do not invent ticket history, prior communications, hostnames, error codes, or system details the user did not supply.
- If [PRIOR ACTIONS] is empty or unclear, ask before drafting so the reply does not misstate what has already happened.

Sample output. Generated by AI from sample inputs:

Inputs used: User: Dana Kowalski at Northwind Logistics. Ticket: VPN has been down for two days, user cannot access file server, missed a client deadline. Prior actions: ticket assigned to network team, no update given to user.

---

Hi Dana,

Thank you for following up. I understand this has kept you from your work for two days, and I know missing a client deadline is a real impact. That is not acceptable service and I am sorry for the delay in communication.

Here is where things stand: your ticket is with our network team. They are working the VPN connectivity issue now. I have flagged it as a business-impact case so it moves to the front of their queue.

Next step: a network technician will contact you directly before 3:00 PM today with an update or a fix. If you do not hear from them by 3:00 PM, reply to this ticket and I will escalate immediately.

In the meantime, if you need to access a specific file urgently, reply here and I will check whether we can get it to you another way.

Thank you for your patience.

IT Support

Takes a raw security information and event management (SIEM) or endpoint detection and response (EDR) alert and produces a structured triage decision: priority, likely cause, immediate actions, and escalation recommendation. Use it when an alert lands and you need to move fast without missing a step.

## Context
You are a security operations analyst helping triage an alert from a SIEM or EDR platform. The analyst will supply the alert details. Your job is to produce a structured triage note they can act on and record. You do not have visibility into this environment beyond what is pasted below. Do not invent log lines, process names, hostnames, IP addresses, or threat context that the analyst did not supply.

Alert source: [ALERT SOURCE]
Alert name and rule ID: [ALERT NAME AND RULE ID]
Affected host or user: [AFFECTED ASSET]
Timestamp: [TIMESTAMP]
Raw alert detail or log excerpt: [RAW ALERT DETAIL]
Additional context from the analyst (recent changes, known activity): [ANALYST CONTEXT]

## Task
Produce a triage note with these sections:
1. Priority assessment: critical, high, medium, or low. One sentence explaining why.
2. Most likely explanation: the two or three most plausible causes, ranked, based only on the alert detail supplied.
3. Immediate analyst actions: a numbered checklist of the next three to five steps to confirm or rule out each explanation. Be specific to the data supplied.
4. Escalation recommendation: escalate now, monitor and reassess, or close with documentation. One sentence of rationale.
5. Questions for the analyst: what additional data would change the assessment.

## Standards
- Base every statement on the alert detail and context the analyst supplied. Do not reference external threat intelligence, CVE numbers, or attacker techniques unless the analyst provided that information.
- Do not state that a system is compromised or that an attack is confirmed unless the supplied evidence supports that conclusion.
- Do not invent log lines, command lines, hostnames, IP addresses, or file hashes that the analyst did not paste.
- Keep the triage note under 400 words.
- Use plain language. Spell out technical acronyms the first time.
- If a key input field is missing or blank, ask the analyst to supply it before producing the triage note.

Sample output. Generated by AI from sample inputs:

Triage Note -- Northwind Logistics, WEB-APP-03
Alert: Suspicious PowerShell execution (Rule PS-1042) | 2026-06-10 14:32 UTC

1. Priority assessment: High. PowerShell with encoded arguments on a web-facing server is a recognized post-exploitation pattern. No benign explanation is confirmed.

2. Most likely explanations:
a. Automated patch or monitoring agent running a scheduled task (most likely if a maintenance window was active).
b. Adversary lateral movement or command-and-control (C2) activity following a web application compromise.
c. Developer or admin running an ad-hoc script without change control documentation.

3. Immediate analyst actions:
1) Pull the full process tree for WEB-APP-03 from 14:00-15:00 UTC and identify the parent process of the PowerShell instance.
2) Decode the base64 argument string and review the decoded command before taking any other action.
3) Check WEB-APP-03 for outbound connections on non-standard ports in the same window.
4) Review the change management log for authorized maintenance on WEB-APP-03 today.
5) Isolate WEB-APP-03 from the network if the decoded command shows download or execution of remote content.

4. Escalation recommendation: Escalate to senior analyst now if isolation is warranted or if the decoded command is not immediately explainable. Otherwise monitor and reassess within 30 minutes.

5. Questions for analyst: Was a maintenance window active at 14:32? Who has admin credentials on WEB-APP-03? Has this rule fired on this host before?

Drafts a security incident report from your incident notes, timeline, and findings. Use it after containment, when you need a clear record for leadership, compliance, or after-action review.

## Context
You are a security analyst drafting an incident report for [ORG NAME]. The report will be reviewed by [AUDIENCE: e.g., IT leadership, compliance team, executive team]. It documents a security incident from detection through containment. You are working from the analyst notes and timeline supplied below. Do not invent log data, IP addresses, hostnames, system names, vulnerability details, or findings that are not in the supplied notes.

Incident ID or name: [INCIDENT ID]
Date and time range: [DATE TIME RANGE]
Systems affected: [AFFECTED SYSTEMS]
Brief description of what happened: [INCIDENT DESCRIPTION]
Timeline of key events (chronological notes): [TIMELINE NOTES]
Containment and remediation actions taken: [ACTIONS TAKEN]
Data or services impacted: [IMPACT]
Current status: [CURRENT STATUS]

## Task
Draft an incident report with these sections:
1. Executive Summary: three to five sentences. What happened, when, impact, and current status. Non-technical.
2. Incident Timeline: dated and timed events in chronological order, drawn from the notes supplied.
3. Affected Systems and Data: what was affected and how, based on the supplied impact information.
4. Containment and Remediation Actions: numbered list of actions taken, with dates where available.
5. Root Cause Assessment: state the root cause if the notes support a conclusion. If the cause is not yet confirmed, say so plainly.
6. Recommendations: three to five specific actions to prevent recurrence, based on what the incident revealed.
7. Open Items: unresolved questions or follow-on tasks, flagged clearly.

## Standards
- Every fact in the report comes from the supplied notes. Do not add context, threat intelligence, or findings the analyst did not supply.
- Do not claim that data was exfiltrated, that an attacker achieved a specific objective, or that a system is clean unless the supplied notes support that conclusion.
- Do not fabricate CVE numbers, IOC (indicator of compromise) values, attacker techniques, or tool names.
- Use precise, plain language. Spell out all technical acronyms the first time.
- Root Cause Assessment must say "root cause not yet determined" if the notes do not support a conclusion.
- If any key section input is missing, note it as [PENDING] in that section and ask the analyst to supply it.

If named inputs are missing or ambiguous, ask before drafting.

Sample output. Generated by AI from sample inputs:

INCIDENT REPORT
Org: Northwind Logistics | Incident ID: INC-2026-0041 | Prepared: June 11, 2026

1. Executive Summary
On June 9, 2026, a contractor account at Northwind Logistics was used to access the file server FS-SHARE-01 outside of normal business hours. The account was disabled within two hours of detection. No confirmed data exfiltration occurred. The incident is contained; a full access review is in progress.

2. Incident Timeline
- 2026-06-09 22:14 UTC: SIEM alert fires on after-hours login for contractor account SVC-CONTRAC-07.
- 2026-06-09 22:31 UTC: On-call analyst reviews alert and confirms login from IP not matching VPN range.
- 2026-06-09 23:02 UTC: Account SVC-CONTRAC-07 disabled by identity team.
- 2026-06-10 08:15 UTC: Forensic review of FS-SHARE-01 access logs begins.
- 2026-06-10 11:40 UTC: No evidence of file download or lateral movement found in the log window reviewed.

3. Affected Systems and Data
FS-SHARE-01 was accessed. No confirmed data exfiltration. Scope of files browsed is under review.

4. Containment and Remediation Actions
1. SVC-CONTRAC-07 disabled 2026-06-09 23:02 UTC.
2. Password reset forced for all active contractor accounts 2026-06-10 09:00 UTC.
3. Access log review ongoing as of report date.

5. Root Cause Assessment
Root cause not yet determined. The account may have been compromised via credential exposure outside the Northwind environment. Investigation ongoing.

6. Recommendations
1. Implement time-of-day access controls for all contractor accounts.
2. Require multi-factor authentication (MFA) for all contractor VPN sessions.
3. Complete access log review of FS-SHARE-01 for the 30 days prior to the incident.
4. Conduct a full contractor account access review and remove inactive accounts.

7. Open Items
- Forensic log review not complete as of report date. [PENDING: ETA June 13]
- Root cause not confirmed. [PENDING: external credential exposure check]

Writes a security operations center (SOC) shift handover report from the outgoing analyst's notes. Use it at the end of every shift so the incoming analyst has full situational awareness without a verbal download.

## Context
You are a SOC (Security Operations Center) analyst assistant helping the outgoing shift analyst produce a clear, complete handover report. The incoming analyst may not share any context from the current shift. The report must let them pick up every open thread without asking.

Shift details:
- Analyst name: [ANALYST NAME]
- Shift date and hours: [SHIFT DATE AND HOURS]
- Open alerts and their current status: [OPEN ALERTS]
- Incidents investigated or escalated: [INCIDENTS]
- Actions taken (containment, tickets, escalations): [ACTIONS TAKEN]
- Watchlist items and IOCs (indicators of compromise) observed: [WATCHLIST AND IOCS]
- Tool or feed anomalies (SIEM, EDR, ticketing): [TOOL ANOMALIES]
- Anything needing immediate attention at shift start: [PRIORITY HANDOFF ITEMS]

## Task
Draft a shift handover report with these sections: Shift Summary, Open Alerts, Active Incidents, Actions Taken This Shift, Watchlist and IOC Notes, Tool and Feed Status, Priority Handoff Items.

## Standards
- Lead each section with the most time-sensitive item.
- Alert and incident entries include: ID or ticket number, asset or host involved, current status, and last action taken with a timestamp.
- Do not invent alert IDs, hostnames, IP addresses, CVEs, IOCs, or log lines that the analyst did not supply. If a field is blank, write "None reported this shift."
- Priority Handoff Items is a numbered list. Each item is one sentence with an owner or a recommended first action.
- Neutral operational tone. No jargon the incoming analyst would not recognize.
- Under 500 words.
- If any critical field (Open Alerts, Active Incidents) is blank and the shift had activity, ask the analyst to supply it before drafting.

Sample output. Generated by AI from sample inputs:

SOC SHIFT HANDOVER REPORT
Analyst: M. Okafor | Shift: 2026-06-13, 23:00 - 07:00

Shift Summary. Moderate volume. One active incident escalated. Three alerts closed. SIEM feed from EDR (Endpoint Detection and Response) connector degraded for approximately 40 minutes starting at 02:15; restored at 02:57. No confirmed compromises this shift.

Open Alerts.
- ALT-4421 | Host: WEB-APP-03 | Repeated failed SSH logins from external IP | Status: Monitoring. Last action: IP added to watchlist at 03:14.
- ALT-4438 | Host: FILESERVER-02 | Unusual outbound data transfer at 04:50 | Status: Under review. Last action: Packet capture initiated at 05:03.

Active Incidents.
- INC-0891 | WEB-APP-03 brute-force attempt | Escalated to Tier 2 at 04:30. Awaiting senior analyst review. Tickets linked: ALT-4421.

Actions Taken This Shift.
- ALT-4399 closed (false positive, confirmed dev build process). 00:45.
- ALT-4412 and ALT-4418 closed (scheduled maintenance traffic, verified with IT ops). 01:30.
- External IP blocked at perimeter per playbook for INC-0891. 04:35.

Watchlist and IOC Notes.
- IP 198.51.100.44 added to watchlist (source: brute-force cluster on WEB-APP-03). Verify against threat intel before escalating.

Tool and Feed Status.
- EDR connector to SIEM: degraded 02:15-02:57. No events dropped; backfill confirmed at 03:05. Monitor for recurrence.

Priority Handoff Items.
1. INC-0891: Tier 2 review pending on WEB-APP-03. Check for callback traffic from that host.
2. ALT-4438 on FILESERVER-02: packet capture running, needs analyst review by 08:00.
3. EDR connector: if it degrades again, open a ticket with the platform team.

Drafts a security policy from the key decisions and requirements you supply. Use it when standing up a new policy or replacing an outdated one, before it goes to legal or leadership review.

## Context
You are a security policy writer helping [ORGANIZATION NAME], a [ORG TYPE] with approximately [EMPLOYEE COUNT] employees. The person directing this work is a [AUTHOR ROLE] responsible for information security governance. The policy will govern how the organization handles [POLICY SUBJECT]. Applicable regulatory or compliance drivers: [REGULATORY DRIVERS]. Any existing related policies or standards to stay consistent with: [RELATED POLICIES].

## Task
Draft a security policy with these sections: Purpose, Scope, Definitions, Policy Statements, Roles and Responsibilities, Compliance and Enforcement, Exceptions Process, and Review Cycle. Include a document header with: title, version number, effective date placeholder, owner, and approval authority.

## Standards
- Policy statements use "must" for mandatory requirements and "should" for recommendations. Avoid "shall" unless required by the regulatory driver.
- Scope states explicitly who and what systems are covered, and who and what are out of scope.
- Definitions cover every term a new employee would not know; no undefined acronyms.
- Roles and Responsibilities name job functions, not individuals.
- Compliance section states the consequence of non-compliance at a category level (disciplinary action, contract termination, regulatory referral); it does not invent penalty amounts.
- Exceptions Process names the approver, the required documentation, and the review interval.
- Do not fabricate regulatory citations, control numbers, or penalty figures. If a regulatory driver implies a specific control, reference the driver by name and instruct the reader to consult the authoritative source.
- If any input is missing or ambiguous, ask before drafting rather than filling the gap with invented requirements.

## Standards (continued)
- Plain language throughout. No legal jargon a non-lawyer cannot parse.
- Target length: 600 to 1,000 words for the policy body, excluding the header and definitions table.

Sample output. Generated by AI from sample inputs:

INFORMATION SECURITY POLICY: ACCEPTABLE USE OF CLOUD SERVICES
Version: 1.0 | Effective Date: [PENDING APPROVAL] | Owner: Information Security Manager | Approval Authority: VP of Technology
Organization: Northwind Industrial Supply | Classification: Internal

Purpose
This policy establishes requirements for the use of cloud-based services to protect Northwind Industrial Supply's data, systems, and reputation. It ensures cloud adoption is secure, compliant, and consistent with contractual obligations.

Scope
This policy applies to all Northwind employees, contractors, and third-party vendors who access or store Northwind data in cloud services. It covers all cloud platforms including software-as-a-service (SaaS), infrastructure-as-a-service (IaaS), and platform-as-a-service (PaaS) solutions. It does not apply to on-premises systems or tools that do not transmit or store Northwind data.

Definitions
Cloud service: Any computing resource delivered over the internet by a third-party provider, including storage, applications, and computing platforms.
SaaS (Software as a Service): Software hosted and delivered by a vendor, accessed via a web browser or API.
Data classification: Northwind's four-tier system (Public, Internal, Confidential, Restricted) governing handling requirements.

Policy Statements
1. Employees must obtain approval from the Information Security team before subscribing to or piloting any new cloud service that will store or process Internal, Confidential, or Restricted data.
2. Cloud vendors storing Confidential or Restricted data must execute a data processing agreement (DPA) with Northwind before data is transferred.
3. Employees must use Northwind-approved identity and access management credentials (single sign-on where available) for all cloud services. Personal accounts must not be used for business data.
4. Multi-factor authentication (MFA) must be enabled for all cloud services that support it, for all Northwind accounts.
5. Employees should review access permissions for cloud-shared files quarterly and remove access that is no longer needed.

Roles and Responsibilities
Information Security Manager: Maintains the approved cloud vendor list, reviews new service requests, and updates this policy annually.
IT Operations: Configures and enforces MFA for cloud services and maintains identity federation.
All Employees: Follow this policy, complete annual security awareness training that covers cloud use, and report suspected violations to the IT Help Desk.
Vendor Management: Ensures DPAs are executed before cloud vendor onboarding.

Compliance and Enforcement
Violations of this policy may result in disciplinary action up to and including termination, in accordance with Northwind's Employee Code of Conduct. Vendors in violation may have their access revoked and contracts reviewed. Suspected violations should be reported to the Information Security Manager.

Exceptions Process
Requests to deviate from this policy must be submitted in writing to the Information Security Manager. Requests must include: the business justification, the specific policy statement to be excepted, the compensating controls in place, and the proposed exception duration (maximum 12 months). Approved exceptions are logged and reviewed at renewal.

Review Cycle
This policy will be reviewed annually or following any material change to Northwind's cloud environment or applicable regulatory requirements.

Note: This is a draft for review. Regulatory references and penalty language must be confirmed against Northwind's specific compliance obligations before approval.

Drafts a formal written response to a single audit finding, including the root cause, corrective action plan, and target completion date. Use it when an internal or external auditor issues a finding and your organization must respond in writing.

## Context
You are a governance, risk, and compliance (GRC) professional responding to an audit finding on behalf of your organization. The auditor has documented a gap, control weakness, or noncompliance. Your written response becomes part of the audit record and may be reviewed by regulators, leadership, or the board.

Organization name: [ORGANIZATION NAME]
Audit type (internal, external, regulatory): [AUDIT TYPE]
Auditor or audit body: [AUDITOR NAME]
Finding title and reference number: [FINDING TITLE AND REFERENCE NUMBER]
Finding text as written by the auditor: [AUDITOR FINDING TEXT]
Root cause identified by your team: [ROOT CAUSE]
Corrective actions planned: [CORRECTIVE ACTIONS]
Target completion date: [TARGET COMPLETION DATE]
Person or team responsible: [RESPONSIBLE PARTY]

## Task
Draft a formal audit finding response with these sections:
1. Acknowledgment: one sentence accepting or respectfully disputing the finding, stated plainly.
2. Root cause: the technical or process reason this gap exists, in two to three sentences.
3. Corrective action plan: a numbered list of specific steps, each with the responsible party and target date.
4. Compensating controls (if any): interim measures in place while the full remediation is underway.
5. Management signature block: name, title, date, and a line for signature.

## Standards
- Work only from the inputs provided. Do not invent additional findings, root causes, or corrective steps the user did not supply.
- Do not fabricate CVEs, system names, log data, hostnames, or vulnerability details. Use only what is in the inputs.
- Formal, professional tone. First-person plural (we, our organization). Past tense for what happened, future tense for what will be done.
- Under 400 words.
- If the finding text, root cause, or corrective actions are missing or ambiguous, ask before drafting. A response built on assumptions can worsen the audit record.

Sample output. Generated by AI from sample inputs:

Audit Finding Response
Organization: Northwind Defense Contractors LLC
Audit: External compliance review, FY 2026
Finding Reference: NCF-2026-07
Finding Title: Privileged Account Review Not Performed Quarterly

1. Acknowledgment
Northwind Defense Contractors LLC acknowledges the finding that quarterly privileged account reviews were not completed for the period January through September 2026.

2. Root cause
The quarterly review cadence was documented in our Access Control Policy but was not entered into our IT task management system as a recurring obligation. As a result, two review cycles were missed without a notification or escalation. The process gap was process-tracking, not policy intent.

3. Corrective action plan
1. Enter quarterly privileged account reviews into the IT ticketing system as recurring tasks with assigned owners. Responsible: IT Security Manager. Target: November 15, 2026.
2. Conduct the overdue Q1-Q3 2026 reviews and document results. Responsible: IT Security Manager. Target: November 30, 2026.
3. Add privileged account review completion to the monthly GRC dashboard reported to leadership. Responsible: GRC Analyst. Target: December 1, 2026.

4. Compensating controls
Privileged account access is logged by our identity management platform and reviewed on an ad-hoc basis during incident investigations. No unauthorized access was identified in the logs for the missed review periods.

5. Management sign-off
Name: ______________________
Title: ______________________
Date: ______________________
Signature: __________________

Drafts an architecture decision record (ADR) that documents why a technical choice was made, what alternatives were considered, and what consequences to expect. Use it whenever you make a significant design or infrastructure decision so the reasoning survives beyond the meeting.

## Context
You are a technical writing assistant helping an engineer or architect document a significant design decision. The audience is the engineering team and future maintainers who need to understand not just what was decided but why, and what the team gave up by not choosing the alternatives.

System or service name: [SYSTEM OR SERVICE NAME]
Decision title: [DECISION TITLE]
Context and problem being solved: [CONTEXT AND PROBLEM]
Decision made: [DECISION]
Alternatives considered: [ALTERNATIVES CONSIDERED]
Consequences and trade-offs: [CONSEQUENCES AND TRADE-OFFS]
Status (proposed, accepted, deprecated, superseded): [STATUS]
Date and decision owner: [DATE AND OWNER]

## Task
Draft an ADR with these sections: Title, Status, Context, Decision, Alternatives Considered, Consequences, and Notes.

## Standards
- Plain technical language. Write for an engineer who was not in the room.
- Context states the problem as it existed before the decision, not the solution.
- Decision is one or two sentences naming exactly what was chosen and why it beat the alternatives.
- Alternatives Considered lists each option with its key trade-off. Minimum two alternatives.
- Consequences states what the team gains and what it gives up. Include operational, security, and maintenance implications where applicable.
- Do not invent technology names, version numbers, performance figures, or integration details the user did not supply.
- Notes section is optional. Use it only for links, follow-on decisions, or review dates the user provides.
- Do not fabricate CVEs, known vulnerabilities, or security claims for any technology named.
- If any named input is missing or ambiguous, ask before drafting.

## Verification checklist (embedded reminder)
Before using this ADR: confirm every technology name and version, confirm every trade-off claim against your team's actual testing or documented knowledge, and confirm status with the decision owner.

Sample output. Generated by AI from sample inputs:

# ADR-014: Use PostgreSQL for the Northwind Inventory Service

**Status:** Accepted
**Date:** 2026-06-10
**Owner:** Platform Engineering, J. Calloway

## Context

The Northwind Inventory Service needs a persistent store for SKU records, stock levels, and transaction history. The team evaluated storage options during the Q2 architecture review. The service handles roughly 40,000 writes per day with moderate read traffic. Strong consistency on stock-level updates is a hard requirement; a double-decrement on the same SKU causes fulfillment errors.

## Decision

Use PostgreSQL 16 as the primary data store. It provides the ACID (atomicity, consistency, isolation, durability) guarantees the stock-level update pattern requires, and the team already operates a managed PostgreSQL cluster on the company's cloud platform.

## Alternatives Considered

**DynamoDB:** Offers near-unlimited scale and low operational overhead, but eventual consistency on stock counters without careful application-side locking would require significant extra work to avoid double-decrements. Rejected because the consistency model adds complexity that offsets the operational savings.

**MongoDB:** Document model fits the SKU catalog well, but multi-document transactions carry a performance cost and the team lacks MongoDB operational experience. Rejected on operational risk.

## Consequences

Gains: Strong consistency on stock writes, familiar operational tooling, straightforward migration path from the existing prototype. Gives up: horizontal write scaling beyond a single primary node; if write volume grows beyond current projections, a sharding strategy will be needed. Follow-on decision required: connection pool sizing for the inventory service container fleet.

## Notes

Revisit if daily write volume exceeds 500,000. See ADR-011 for the managed database platform choice.

Drafts a blameless outage postmortem from your incident timeline and notes. Use it within 48 to 72 hours of an incident, while the details are fresh, to capture what happened and what the team is doing about it.

## Context
You are a technical writing assistant helping an engineering team produce a blameless postmortem after a production incident. The audience is the engineering team, engineering management, and in some organizations, affected customers or stakeholders. The goal is to understand what happened and prevent recurrence, not to assign blame.

Incident title and ID: [INCIDENT TITLE AND ID]
Date and duration: [DATE AND DURATION]
Severity: [SEVERITY]
Services affected: [SERVICES AFFECTED]
Impact summary: [IMPACT SUMMARY]
Incident timeline (chronological, with timestamps): [INCIDENT TIMELINE]
Root cause analysis: [ROOT CAUSE ANALYSIS]
Contributing factors: [CONTRIBUTING FACTORS]
What went well: [WHAT WENT WELL]
Action items with owners and due dates: [ACTION ITEMS]

## Task
Draft a postmortem with these sections: Incident Summary, Timeline, Root Cause, Contributing Factors, Impact, What Went Well, Action Items, and Lessons Learned.

## Standards
- Blameless throughout. No individual names tied to mistakes. Engineers as a team made decisions with the information available at the time.
- Timeline is chronological with timestamps from the user's notes. Do not infer or fill in events the user did not supply.
- Root Cause is what the team identified from their own investigation. Do not speculate beyond what the user provides.
- Impact uses the user's numbers. Do not estimate user counts, revenue impact, or error rates the user did not give.
- Action items are specific and assigned: what, who, by when. Mark any field the user left blank as [OWNER?] or [DUE DATE?].
- Do not fabricate log lines, error messages, hostnames, metric values, or alert names.
- Do not invent CVEs, vulnerabilities, or security findings.
- If the timeline has gaps or the root cause is still under investigation, say so clearly rather than filling the gap.
- If any input is missing or ambiguous, ask before drafting.

Sample output. Generated by AI from sample inputs:

# Postmortem: Database Connection Pool Exhaustion (INC-2026-0412)

**Date:** 2026-06-09
**Duration:** 47 minutes (14:22-15:09 UTC)
**Severity:** SEV-2
**Services affected:** Northwind Order API, Northwind Customer Portal
**Written by:** Platform Engineering team

## Incident Summary

On 2026-06-09, the Northwind Order API became unavailable for 47 minutes due to database connection pool exhaustion on DB-PRIMARY-01. Customer-facing order placement was unavailable. Browsing and authentication were unaffected. The incident was resolved by restarting the API service, which released stale connections, and by deploying a configuration change to reduce the per-instance connection limit.

## Timeline

| Time (UTC) | Event |
|---|---|
| 14:22 | PagerDuty alert: Order API health check failing |
| 14:24 | On-call engineer acknowledged alert |
| 14:31 | Database connection count confirmed at 500/500 (pool exhausted) |
| 14:38 | Decision made to restart API pods to release stale connections |
| 14:44 | First API pod restarted; partial recovery observed |
| 14:55 | All API pods restarted; service recovered |
| 15:09 | Incident declared resolved after 10-minute monitoring window |

## Root Cause

A deployment at 13:55 UTC increased the number of Order API instances from 4 to 8 as part of a planned scale-up for the summer traffic period. The per-instance connection pool limit was not adjusted. The 8 instances collectively opened 500 connections, exhausting the database's configured maximum.

## Contributing Factors

- The deployment runbook did not include a step to recalculate the per-instance pool limit when instance count changes.
- The database connection limit was not included in the pre-deployment checklist.
- No alert existed for database connection count approaching the ceiling.

## Impact

Order placement was unavailable for approximately 47 minutes. Per support data, 312 order attempts failed during the window. No data loss occurred.

## What Went Well

- On-call was paged within 2 minutes of the first failing health check.
- The team correctly identified the root cause within 9 minutes of acknowledging the alert.
- The database connection metric was available in the existing dashboard; detection was fast once the engineer looked.

## Action Items

| Action | Owner | Due |
|---|---|---|
| Add per-instance connection pool recalculation step to scale-up runbook | T. Reyes | 2026-06-16 |
| Create alert for database connections above 80% of configured maximum | D. Park | 2026-06-16 |
| Add database connection ceiling to pre-deployment checklist | Platform Engineering | 2026-06-20 |

## Lessons Learned

Scale-up events need a connection budget review as a required step, not an afterthought. A single alert on database connection headroom would have surfaced this before customers were affected.

Builds a week-by-week Security+ study plan tailored to your schedule, current knowledge level, and exam date. Use it at the start of your prep so you work every domain in order and do not run out of time before the test.

## Context
You are helping [YOUR NAME] build a personalized CompTIA Security+ (SY0-701) study plan. Available study hours per week: [WEEKLY HOURS]. Target exam date: [EXAM DATE]. Today's date: [TODAY'S DATE]. Current knowledge level: [KNOWLEDGE LEVEL, e.g., brand new to IT security, 2 years of help desk experience, holds CompTIA A+ and Network+]. Known weak areas or domains to prioritize: [WEAK AREAS, e.g., cryptography, cloud security, or not yet assessed]. Study resources available: [RESOURCES, e.g., Darril Gibson book, Professor Messer videos, Jason Dion practice exams, or list what you have].

## Task
Produce a week-by-week study plan covering all Security+ exam domains for the time period between [TODAY'S DATE] and [EXAM DATE]. Include:
1. A domain schedule: assign each Security+ SY0-701 domain to specific weeks in proportion to its exam weight and [WEAK AREAS].
2. Weekly study blocks: for each week, list what domain or sub-topic to cover, suggested resource chapters or video sections, and a practice milestone (quiz, flashcard set, or lab).
3. A review phase: the final two weeks before [EXAM DATE] dedicated to full practice exams and weak-area remediation.
4. A daily time guide: how to split [WEEKLY HOURS] across weekdays and weekends realistically.

## Standards
- Base domain weights on the official CompTIA SY0-701 exam objectives. Do not invent domain percentages.
- Do not recommend specific exam dumps by name or any resource that violates CompTIA's candidate agreement.
- Do not guarantee a passing score. A study plan is a guide, not a promise.
- If [EXAM DATE] leaves fewer than four weeks, flag it and suggest a realistic revised date rather than compressing the plan into something unusable.
- Tailor the pacing to [KNOWLEDGE LEVEL]. A beginner needs more time in fundamentals; someone with Network+ can move faster through networking concepts.
- Do not invent question content, practice questions, or specific exam scenarios.
- If [TODAY'S DATE] or [EXAM DATE] is missing, ask before building the timeline.

Sample output. Generated by AI from sample inputs:

Student: Alex Rivera. Weekly hours: 10. Exam date: August 25, 2026. Today: June 16, 2026. Knowledge level: 2 years help desk, holds CompTIA A+. Weak areas: cryptography and cloud security. Resources: Professor Messer SY0-701 videos, Jason Dion practice exams.

Study window: 10 weeks (June 16 through August 25).

Domain schedule (SY0-701 official weights, approximate):
- Weeks 1 to 2: General Security Concepts (12%) and Threats, Vulnerabilities, Mitigations (22%). You have help desk exposure here; move at a steady pace.
- Weeks 3 to 4: Security Architecture (18%). New territory for most help desk folks. Slow down on cloud models.
- Weeks 5 to 6: Security Operations (28%). Largest domain. Split across two full weeks.
- Week 7: Security Program Management and Oversight (20%).
- Weeks 8 to 9: Cryptography deep dive and cloud security remediation (your flagged weak areas). Use Messer's cryptography section and Dion's cloud-focused practice sets.
- Weeks 9 to 10: Full practice exams. Two timed full-length exams under test conditions. Review every wrong answer.

Weekly structure (10 hours):
- Weekdays: 1.5 hours Monday through Thursday (6 hours total).
- Weekend: 2 hours Saturday, 2 hours Sunday (4 hours total).
- Each session: 60 percent new content, 40 percent review of the prior session.

Weekly milestones:
- End of week 2: Complete Messer videos for domains 1 and 2. Score a 20-question Dion domain quiz per domain.
- End of week 4: Complete architecture module. Draw a diagram of a segmented network from memory.
- End of week 6: First full 90-question practice exam. Score target: 70 percent or higher.
- End of week 8: Cryptography and cloud sub-domain quizzes. Score target: 80 percent on targeted questions.
- Week 10: Two full timed practice exams. If either score is below 80 percent, assess whether to postpone the exam date.

Note: This plan assumes ten hours per week is achievable every week. Adjust week assignments if you miss a session rather than compressing them.

Builds a structured study plan for the Certified Information Systems Security Professional (CISSP) exam based on your available time, current knowledge, and target exam date. Use it when you are committing to the CISSP and need a realistic schedule that covers all eight domains.

## Context
You are a study plan advisor helping [YOUR NAME] prepare for the CISSP exam. The CISSP covers eight domains of information security knowledge. A realistic plan accounts for prior experience, available study hours, and the depth each domain demands.

Background:
- Current role and years of experience: [CURRENT ROLE AND EXPERIENCE]
- Domains where you feel strongest: [STRONG DOMAINS]
- Domains where you feel weakest: [WEAK DOMAINS]
- Hours available per week for study: [WEEKLY STUDY HOURS]
- Target exam date or timeframe: [TARGET DATE]
- Study materials you have or plan to use: [STUDY MATERIALS]

## Task
Produce a week-by-week study plan from today through two weeks before the exam date. Include:
1. A domain coverage schedule showing which domain each week covers and approximate hours.
2. A note on weighting: domains with higher exam weight or your noted weaknesses should get more time.
3. A review and practice-test phase in the final two weeks.
4. A weekly routine template showing how to split the hours across the week.
5. A short list of study techniques suited to the CISSP's conceptual, managerial framing.

## Standards
- Base the schedule on [WEEKLY STUDY HOURS] and [TARGET DATE]. Show the arithmetic: total available hours and how they are allocated.
- Do not invent exam pass rates, domain weights, or question counts. Reference only that the CISSP has eight domains and that domain weights shift with each exam version; the candidate should verify current weights at isc2.org.
- Flag any plan where available hours appear insufficient for a candidate at [CURRENT ROLE AND EXPERIENCE] level without additional commitment.
- Keep language direct. No claims that following this plan guarantees a pass.
- If [TARGET DATE] or [WEEKLY STUDY HOURS] is missing or unrealistic, ask before building the schedule.

Sample output. Generated by AI from sample inputs:

Candidate: Jordan Ellis. Role: Network Administrator, 4 years. Target date: 16 weeks out. Study hours: 10 per week. Materials: Official Study Guide (9th ed.), Boson practice exams. Strong: Network and Communications Security, Security Operations. Weak: Security and Risk Management, Security Architecture.

Total available hours: 16 weeks x 10 hours = 160 hours.

Domain coverage schedule (weeks 1-14):
- Weeks 1-2: Security and Risk Management (20 hours). Highest exam weight historically. Weakest area. Heaviest investment.
- Week 3: Asset Security (8 hours).
- Weeks 4-5: Security Architecture and Engineering (18 hours). Second weakest area.
- Week 6: Communication and Network Security (9 hours). Strongest area; review and note gaps only.
- Week 7: Identity and Access Management (10 hours).
- Week 8: Security Assessment and Testing (8 hours).
- Weeks 9-10: Security Operations (14 hours). Strong area but high exam weight; do not compress.
- Week 11: Software Development Security (8 hours).
- Weeks 12-13: Cross-domain integration and weak-area review (20 hours). Revisit Security and Risk Management and Architecture.
- Weeks 14-15: Practice exams only (25 hours). Two full timed simulations minimum. Review every wrong answer.
- Week 16: Light review, rest, logistics.

Weekly routine template (10 hours):
- Monday: 1.5 hours reading.
- Tuesday: 1.5 hours reading.
- Wednesday: 1 hour flashcards or concept review.
- Thursday: 1.5 hours reading.
- Saturday: 2.5 hours (reading + chapter questions).
- Sunday: 2 hours (week review + note consolidation).

Study technique notes for the CISSP:
The CISSP tests how a manager thinks, not how a technician executes. When a question offers a technical fix and a policy fix, the policy fix is usually correct. Practice choosing the most risk-aware answer, not the most technically complete one. Use wrong-answer analysis as your primary study loop: for every missed question, write one sentence on why the correct answer is better.

Note: Verify current domain weights at isc2.org before finalizing this plan. Weights change between exam versions.

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.

## 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.

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.

Turns your incident timeline and technical notes into a one-page executive brief for leadership after a security incident. Use it within 24 hours of containment, when executives need the facts without the noise.

## Context
You are a security communications assistant helping an IT or cybersecurity team lead draft a post-incident executive brief. The audience is senior leaders: they need to understand what happened, what the organization did, what the current status is, and what comes next. They do not need raw log data or packet-level detail.

Incident summary provided by the responder:
- Incident title: [INCIDENT TITLE]
- Date and time detected: [DETECTION DATE AND TIME]
- Date and time contained: [CONTAINMENT DATE AND TIME]
- Systems affected: [AFFECTED SYSTEMS]
- What happened (responder summary): [INCIDENT NARRATIVE]
- How it was detected: [DETECTION METHOD]
- Actions taken: [RESPONSE ACTIONS]
- Current status: [CURRENT STATUS]
- Known business impact: [BUSINESS IMPACT]
- Immediate next steps: [NEXT STEPS]

## Task
Draft a post-incident executive brief with these sections: What Happened, How We Detected It, What We Did, Current Status, Business Impact, What Comes Next. Add a brief header line with the incident title, date, and classification (for example, Confidential).

## Standards
- One page. Under 450 words.
- Plain language. No unexplained technical acronyms.
- State only facts the responder supplied. Do not infer impact, escalation, root cause, or remediation that is not in the inputs.
- Do not state or imply that systems are now secure or that data was not exfiltrated unless the responder explicitly confirmed those conclusions from evidence.
- Do not fabricate CVE (Common Vulnerabilities and Exposures) identifiers, attacker attribution, IOC (Indicator of Compromise) values, or technical findings not present in the inputs.
- If data exfiltration status is unknown, say so plainly.
- Current Status must end with the name and title of who the executive can contact for updates.
- What Comes Next lists actions with owners and target dates if the responder supplied them; otherwise, leave owner and date as blanks for the reader to fill.
- Tone: direct, calm, factual. No panic language. No minimizing.

If any input is missing or ambiguous, especially business impact or current status, ask before drafting.

Sample output. Generated by AI from sample inputs:

POST-INCIDENT EXECUTIVE BRIEF
Incident: Unauthorized Access to Finance File Share | June 11, 2026 | Confidential

What Happened
On June 10 at 11:42 PM, an attacker used a compromised employee account to access the Finance shared drive on file server FIN-FS-02 at Northwind Industrial. The account belonged to an employee who had clicked a credential-harvesting link in a phishing email earlier that day. The attacker browsed and downloaded files for approximately 47 minutes before the session was terminated.

How We Detected It
Northwind's security monitoring platform flagged an after-hours login from an unfamiliar geographic location. The alert was escalated to the on-call security analyst at 12:14 AM on June 11.

What We Did
The analyst disabled the compromised account at 12:19 AM and terminated the active session. The incident response team was assembled at 12:45 AM. The Finance file share was taken offline at 1:03 AM for forensic preservation. A password reset was forced for all accounts in the Finance organizational unit.

Current Status
Contained as of June 11, 1:03 AM. Forensic review of file access logs is in progress to determine what data the attacker downloaded. Systems are operational. Contact for updates: Maria Chen, CISO, [email protected].

Business Impact
Finance shared drive was offline for approximately 3 hours. No customer-facing systems were affected. The scope of any data exposure is not yet confirmed and is under active investigation.

What Comes Next
- Complete forensic review of file access logs. Owner: Incident Response Team. Target: June 13.
- Notify legal and compliance regarding potential data exposure. Owner: CISO. Target: June 12.
- Mandatory phishing awareness training for all Finance staff. Owner: HR and IT Security. Target: June 20.
- Present full post-incident report to leadership. Owner: CISO. Target: June 18.