Template for Notion — Cybersecurity

Incident Report Template: Notion for Cybersecurity

Cybersecurity product incidents are unique: a failure in your product directly translates to a failure in your customer security posture. When a detection rule fails, customers are exposed to threats they believed were covered. Incident reports must assess customer security impact, not just product functionality.

This Notion template structures incident reports around security impact, detection gap analysis, and customer advisory requirements.

Template sections

5 sections covering the complete incident report workflow.

01

Detection Gap Impact

When a security product incident causes detection failure, quantify the gap: which threats went undetected, for how long, and how many customers were exposed. Map the gap to MITRE ATT&CK techniques. This assessment drives the urgency of the fix and the scope of customer notification.

Incident: Rule engine crash caused all behavioral detections to stop processing for 6 hours. Detection gap: 47 behavioral detection rules inactive, covering 23 ATT&CK techniques including credential access (T1003), lateral movement (T1021), and data exfiltration (T1041). Customers affected: all 342 customers on the behavioral detection tier. Known threat activity during window: 2 customers had active incident response engagements relying on our detections.

Tips

  • Map detection gaps to specific ATT&CK techniques for customer advisory accuracy
  • Identify customers with active security incidents who relied on the failed detections
  • Quantify the detection gap in hours and techniques for severity classification
  • Preserve all logs from the gap window for post-incident threat hunting
02

Customer Security Exposure Assessment

Assess how the incident affected each customer security posture. Some customers have defense-in-depth (other tools compensating) while others rely solely on your product. Prioritize notification and support based on customer exposure level. Include the threat landscape context: were there active campaigns exploiting the gap during the incident window?

Exposure tiers: High exposure (87 customers, our product is sole detection source for affected techniques), Medium (168 customers, partial overlap with EDR coverage), Low (87 customers, full defense-in-depth with alternate detection). Active threats during window: Mandiant reported APT41 campaign targeting techniques T1021 and T1003 during incident period. Priority notification to 87 high-exposure customers with recommended manual threat hunt for the 6-hour window.

Tips

  • Tier customers by exposure level based on their tool stack overlap
  • Check threat intelligence feeds for active campaigns during the gap window
  • Provide threat hunting guidance for the gap period to affected customers
  • Offer incident response support to high-exposure customers proactively
03

Customer Advisory and Communication

Draft the customer advisory including: what happened, when, what was affected, what was the exposure, what customers should do, and when the fix was deployed. Security product advisories must be technically precise because your customers are security professionals. Include threat hunting queries they can run to check for compromise during the gap.

Advisory: "Between 02:00 and 08:00 UTC on August 15, behavioral detection rules were not processing events due to a rule engine crash. Signature-based detections were unaffected. We recommend running the following Splunk/Elastic queries to check for lateral movement activity during this window: [queries provided]. The issue was resolved at 08:12 UTC and all detections have been verified operational. No data was lost; events from the gap window have been retroactively analyzed."

Tips

  • Include specific threat hunting queries for the gap window in the advisory
  • Be technically precise - your customers are security professionals
  • Confirm retroactive analysis of events during the gap period
  • Provide timeline of detection, response, and resolution with UTC timestamps
04

Root Cause and Prevention

Document the technical root cause, why monitoring did not detect the failure faster, and what controls will prevent recurrence. Security product teams must hold themselves to the same operational standards they expect of their customers. Include the detection gap for the incident itself: how long between failure and detection.

Root cause: Rule engine OOM kill due to a single customer generating 10x normal event volume (DDoS attack generating massive log volume). Memory limits not configured per customer. Detection gap: 47 minutes between crash and alert (monitoring checked rule engine health every 5 minutes, but the 5-minute check passed during a brief restart, then crashed again). Prevention: (1) per-customer memory limits with graceful degradation, (2) detection pipeline health check every 60 seconds, (3) canary events that verify end-to-end detection pipeline every 5 minutes.

Tips

  • Calculate the time between failure and detection (your own MTTD for your own product)
  • Implement canary events that verify the detection pipeline end-to-end
  • Add per-customer resource limits to prevent noisy-neighbor incidents
  • Hold your product to the same detection and response SLAs you promise customers
05

Post-Incident Threat Hunt

After resolving the incident, conduct a retroactive analysis of events that occurred during the detection gap. Process the buffered events through the restored detection pipeline to identify any threats that were active but undetected during the window. Notify affected customers of any findings.

Post-incident analysis: 14.2 million events from the 6-hour window retroactively processed through all 47 behavioral detection rules. Findings: 3 true positive alerts identified (1 credential access attempt at Customer A, 2 lateral movement attempts at Customer B). Both customers notified immediately with full alert context and recommended response actions. No evidence of data exfiltration in either case.

Tips

  • Process all events from the gap window through restored detections retroactively
  • Notify customers immediately if retroactive analysis finds threats during the gap
  • Include retroactive analysis results in the final incident report
  • Use the gap window findings to validate detection effectiveness and identify improvements

Copy-paste template

# Incident Report — Cybersecurity Product (Notion)

## Incident Summary
- **Duration:** [Start - End UTC]
- **Detection gap:** [Hours]
- **Detections affected:** [Count, ATT&CK techniques]
- **Customers affected:** [Count by exposure tier]

## Customer Exposure
| Tier | Customers | Exposure | Action |
|---|---|---|---|
| High | [Count] | [Description] | [Immediate notification + hunt] |
| Medium | [Count] | [Description] | [Notification + guidance] |
| Low | [Count] | [Description] | [Standard notification] |

## Advisory
- **Sent:** [Date/Time]
- **Threat hunt queries:** [Provided/Not needed]
- **Retroactive analysis:** [Complete/In progress]

## Prevention
| Control | Description | Status |
|---|---|---|
| [Control] | [Description] | [Implemented/In progress] |

Frequently asked questions

Generate instead of filling in templates

Connect your tools, and Vantage generates the content using real product data. Free to start.

Free to start. No credit card required.

Related reading