Libraries · it & cyber · secops

Security Operations

Alert triage, incident reports, phishing analysis, and SOC shift reports: the defensive blue-team writing, built so no IOC or CVE reaches a report without you verifying it first.

PROMPTS 24 // OPEN SAMPLES 3 // FREE WITH ACCOUNT 21

Security Alert Triage

OPEN SAMPLE

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.

ALERT SOURCE ·ALERT NAME AND RULE ID ·AFFECTED ASSET ·TIMESTAMP ·RAW ALERT DETAIL ·ANALYST CONTEXT
## 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.
BEFORE YOU RUN IT
  • The exact alert text or log excerpt from your SIEM or EDR, copied from your own platform, not reconstructed from memory
  • The affected hostname, username, or IP address as it appears in your asset inventory
  • Timestamp and time zone of the alert
  • Any recent changes in the environment relevant to this host or user (patches, new software, account changes)
  • Confirm all technical artifacts (log lines, hostnames, IP addresses, process names) come from your own tools, not from the AI
  • Redact passwords, credentials, personal data, and any information classified or restricted by your org policy before pasting
VERIFY BEFORE IT LEAVES YOUR HANDS
  • Every hostname, IP address, and username in the triage note matches your environment, not an AI-invented value
  • The priority assessment reflects the actual alert severity and your org's threat model, not a generic framework
  • No CVE number or named threat actor appears unless you supplied that context
  • The escalation recommendation aligns with your incident response (IR) plan, not a generic recommendation
  • Immediate actions are achievable with your current tools and access before you forward the note
  • Questions for the analyst reviewed: answer any you can answer yourself before escalating
  • No credentials, PII (personally identifiable information), or restricted data appear in the note as written
Sample output
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?
CUSTOMIZATION

Tailor the priority scale to your org's severity definitions if they differ from critical/high/medium/low. For SOC (security operations center) teams with a ticketing system, add a Ticket ID field to the context block so the triage note links back automatically. If your environment uses specific EDR playbooks, paste the relevant playbook step titles into the Analyst Context field and the prompt will align its actions to them. Analysts new to triage can add a step in Standards asking the AI to explain each action in one sentence.

Incident Report

OPEN SAMPLE

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.

ORG NAME ·AUDIENCE ·INCIDENT ID ·DATE TIME RANGE ·AFFECTED SYSTEMS ·INCIDENT DESCRIPTION ·TIMELINE NOTES ·ACTIONS TAKEN ·IMPACT ·CURRENT STATUS
## 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.
BEFORE YOU RUN IT
  • Your incident notes and timeline from the actual incident, not reconstructed from memory alone
  • The list of affected systems as confirmed by your tools, not inferred
  • Containment and remediation actions with dates, pulled from your ticketing or IR log
  • Impact assessment: confirmed data exposure, service downtime, or user impact with scope
  • Confirm all technical artifacts (hostnames, IP addresses, log excerpts) come from your own systems and tools
  • Redact credentials, sensitive personal data, and anything restricted by your org or compliance requirements before pasting
VERIFY BEFORE IT LEAVES YOUR HANDS
  • Every hostname, IP address, and system name in the report matches your confirmed asset inventory
  • No CVE numbers, IOC values, or attacker technique names appear unless you supplied them
  • Root Cause Assessment does not claim a confirmed cause if your investigation is still open
  • Timeline is in the correct chronological order and all timestamps are accurate
  • Data impact section does not overstate or understate scope beyond what evidence supports
  • Recommendations are specific to your environment, not generic boilerplate
  • Open Items section contains any unresolved questions from your notes before the report is finalized
Sample output
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]
CUSTOMIZATION

Adjust the audience field to change the technical depth of the Executive Summary: write for executives and that section stays at business impact, write for a technical team and it can reference system names. For compliance-driven reports (SOC 2, HIPAA, PCI DSS), add a Regulatory Notification section and note the applicable framework. If your org has a standard incident report template, paste its section headers into the Task block so the output maps directly.

Reported Phishing Analysis

Analyzes a user-reported phishing email to identify suspicious indicators, assess risk, and produce a clear analyst finding. Use it when a user reports a suspicious email and you need to triage and document the analysis fast.

FREE WITH ACCOUNT

Log Analysis Explainer

Takes a log excerpt you paste and explains in plain language what it shows, what is normal, and what warrants further investigation. Use it when reviewing unfamiliar log formats or explaining findings to non-technical stakeholders.

FREE WITH ACCOUNT

IOC Summary

Summarizes confirmed indicators of compromise (IOCs) from your investigation data into a structured report for sharing with your team or blocking in your tools. Use it after an investigation to document what you found and make it actionable.

FREE WITH ACCOUNT

User Security Notice

Drafts a clear, plain-language security notice for users affected by or involved in a security event. Use it when you need to notify employees, contractors, or end users without causing panic or confusion.

FREE WITH ACCOUNT

Vulnerability Remediation Plan

Builds a structured remediation plan from your vulnerability scan results, prioritizing by severity and grouping actions by owner. Use it after a scan to turn a raw report into an actionable work plan.

FREE WITH ACCOUNT

Detection Rule Explainer

Takes a detection rule from your SIEM, EDR, or network tool and explains what it detects, how it works, and what would trigger or evade it, in plain language. Use it to onboard new analysts, document rule logic, or review rules for accuracy.

FREE WITH ACCOUNT

Tabletop Exercise Scenario

Builds a tabletop exercise scenario for your security team or leadership group, based on a threat type and your environment details. Use it to prepare realistic, discussion-driven exercises without fabricating vulnerabilities specific to your systems.

FREE WITH ACCOUNT

Incident Containment Checklist

Builds a step-by-step containment checklist tailored to the incident type and affected systems you describe. Use it at the start of containment when you need a clear, documented list of actions so nothing gets missed under pressure.

FREE WITH ACCOUNT

Threat Intelligence Brief

Summarizes a threat advisory or intelligence report into a concise brief for your team or leadership, focused on what it means for your environment. Use it when a new advisory drops and you need to communicate relevance and recommended actions fast.

FREE WITH ACCOUNT

Access Review Summary

Summarizes the findings from an access and privilege review into a structured report with risk ratings, recommended actions, and an audit trail. Use it after a periodic access review to document decisions and communicate findings to management or compliance.

FREE WITH ACCOUNT

All 140 prompts in this library are free with a VetsLearn account: every prompt, every checklist, synced to your account.

Unlock free with an account →

SOC Shift Report

OPEN SAMPLE

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.

ANALYST NAME ·SHIFT DATE AND HOURS ·OPEN ALERTS ·INCIDENTS ·ACTIONS TAKEN ·WATCHLIST AND IOCS ·TOOL ANOMALIES ·PRIORITY HANDOFF ITEMS
## 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.
BEFORE YOU RUN IT
  • All open alert IDs and ticket numbers with their current status, pulled from your SIEM (Security Information and Event Management) or ticketing system, not from memory.
  • Any active incidents, with escalation status and last action taken.
  • IOCs, watchlist additions, or threat intel updates observed or added during the shift, sourced from your own tools and feeds, not generated by the AI.
  • Notes on any tool outages, feed failures, or tuning changes that affect the incoming analyst.
  • Data handling: redact credentials, customer PII (personally identifiable information), and anything classified before pasting, per your org's data-handling policy.
  • Confirm all hostnames, IP addresses, and alert IDs come from your own systems and logs, not from the AI.
VERIFY BEFORE IT LEAVES YOUR HANDS
  • Every alert ID and ticket number verified against your SIEM or ticketing system, not from memory or AI output.
  • No IOCs or hostnames appear in the report that were not supplied by you, pulled from your own systems.
  • Timestamps checked for accuracy and correct time zone, especially near shift boundaries.
  • Priority Handoff Items reviewed for completeness: confirm no open thread was missed.
  • No CVEs, malware families, or threat actor attributions cited unless you supplied them from a verified threat intel source.
  • Incident status matches what is actually in the ticketing system at time of handover.
  • No customer data, credentials, or sensitive internal details visible in the final report.
Sample output
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.
CUSTOMIZATION

Add a section for compliance or regulatory events if your environment is subject to PCI-DSS (Payment Card Industry Data Security Standard), HIPAA (Health Insurance Portability and Accountability Act), or FedRAMP auditing. Teams using automated SOAR (Security Orchestration, Automation, and Response) playbooks can add a Playbook Executions section. Adjust word limits for longer shifts with higher alert volumes. Junior analysts benefit from keeping the Priority Handoff Items section short and action-specific.

Security Incident Postmortem

Writes a blameless postmortem report after a security incident is resolved. Use it within 72 hours of closure to capture what happened, what worked, and what needs to change, while the details are fresh.

FREE WITH ACCOUNT

Security Awareness Email

Writes a staff-facing security awareness email covering a specific threat, behavior, or policy. Use it when a new threat trend, phishing campaign, or policy change needs to reach all employees in plain language.

FREE WITH ACCOUNT

MFA Rollout Communication

Drafts the staff-facing communication for a multi-factor authentication (MFA) rollout: what is changing, when, and what employees need to do. Use it when rolling out MFA to a new group, application, or the whole organization.

FREE WITH ACCOUNT

Vendor Security Questionnaire Response

Helps draft truthful, accurate responses to a vendor or customer security questionnaire based on your organization's actual controls. Use it when a customer or partner sends a security assessment questionnaire and you need to respond without overstating your posture.

FREE WITH ACCOUNT

Data Classification Helper

Classifies a described data asset against your organization's data classification policy and explains the handling requirements that apply. Use it when onboarding a new dataset, building a data inventory, or reviewing whether an existing asset is labeled correctly.

FREE WITH ACCOUNT

Breach Notification Draft

Drafts a breach notification letter to affected individuals or regulatory bodies based on facts your legal team has confirmed. Use it only after legal counsel has reviewed the incident and confirmed notification is required. This draft requires legal review before sending.

FREE WITH ACCOUNT

System Hardening Checklist

Builds a system hardening checklist for a specific operating system and role, organized by control area. Use it when standing up a new system or conducting a hardening review. Verify every control against the authoritative benchmark before applying it.

FREE WITH ACCOUNT

Alert Tuning Rationale

Documents the reasoning behind a SIEM or security tool alert tuning decision: why a threshold was changed, a rule was suppressed, or an exclusion was added. Use it every time you tune an alert so there is a written record for audits and future analysts.

FREE WITH ACCOUNT

Investigation Timeline

Builds a chronological incident investigation timeline from analyst-supplied artifacts: log entries, alert timestamps, and action notes. Use it during or after an investigation to organize the sequence of events before writing a full report.

FREE WITH ACCOUNT

Lessons Learned Summary

Summarizes the lessons from a resolved security incident into a short, action-focused document for the security team and leadership. Use it after the postmortem discussion while conclusions are still fresh.

FREE WITH ACCOUNT

All 140 prompts in this library are free with a VetsLearn account: every prompt, every checklist, synced to your account.

Unlock free with an account →

Risk Acceptance Memo

Drafts a risk acceptance memo documenting why a known security risk is being accepted rather than remediated, who is accepting it, and when it will be reviewed. Use it when a vulnerability or control gap cannot be fixed immediately and a responsible business decision is being made to accept the residual risk.

FREE WITH ACCOUNT

All 140 prompts in this library are free with a VetsLearn account: every prompt, every checklist, synced to your account.

Unlock free with an account →
  • This library is defensive and operational by design. It does not produce exploit code, malware, or attack instructions, and it is not a substitute for your security team or counsel.
  • AI output is a first draft. Never trust a CVE, an indicator of compromise, a log line, or a control mapping it produces. Verify every one against your own tools and the authoritative source.
  • Redact secrets, credentials, customer data, and anything classified before pasting. You remain responsible for what leaves your hands.