---
title: "Security Incident Response Template"
url: "https://www.openstatus.dev/guides/security-incident-response"
date: "2026-01-19"
author: "openstatus"
description: "Formal template for communicating security issues with professional, reassuring language that maintains user trust."
category: "template"
---

Use this template when investigating or responding to security-related incidents. Maintains professional tone while reassuring users about security measures.

## When to Use This Template

- Potential security vulnerabilities discovered
- Unauthorized access attempts detected
- Data exposure concerns
- Security patch deployments
- Compliance-related issues

## Template Messages

### Investigating

We are investigating a potential security issue. We take security very seriously and are working with our security team to assess the situation.

We will provide updates as we learn more. For security questions, please contact security@yourcompany.com.

### Identified

We have identified the nature of the security issue and are implementing remediation measures.

### Monitoring

Security measures have been implemented. We are monitoring systems to ensure the issue is fully resolved.

### Resolved

The security issue has been resolved. We have taken steps to prevent similar issues in the future.

## Key Principles for Security Communication

### 1. **Be Transparent, But Not Reckless**

Share what you know, but don't provide details that could help attackers:

✅ Good: "We identified unauthorized access attempts to our admin panel"
❌ Avoid: "Attackers tried SQL injection on /admin/login using parameter X"

### 2. **Reassure Without Minimizing**

✅ Good: "No user data was accessed. We take security seriously and have implemented additional safeguards."
❌ Avoid: "It's not a big deal, don't worry about it."

### 3. **Provide Clear Next Steps**

Tell users what (if anything) they should do:
- Change passwords?
- Review account activity?
- Update client software?
- No action needed?

### 4. **Show Competence**

Demonstrate you're handling it professionally:
- "Working with our security team"
- "Engaged external security experts"
- "Following our incident response procedures"

## Real-World Security Communication Examples

### Example 1: Data Access Concern

**Investigating**:
```
We are investigating reports of unusual account activity. As a precaution,
we've temporarily disabled affected accounts and are conducting a thorough
security audit.

If your account was affected, we will contact you directly via email.
```

**Resolved**:
```
Our investigation is complete. No user data was compromised. The unusual
activity was caused by automated testing scripts that were misconfigured.

We've implemented additional monitoring to prevent similar false positives
and improved our alerting to distinguish between legitimate and suspicious
activity.
```

### Example 2: Vulnerability Patch

**Investigating**:
```
We've been notified of a potential security vulnerability in a third-party
library we use. We are investigating the impact and preparing a security
patch.

This appears to be a low-severity issue with no evidence of exploitation,
but we're treating it with high priority.
```

**Resolved**:
```
We've deployed a security patch addressing the vulnerability. No user data
was at risk, and we saw no signs of exploitation. All systems have been
updated and are operating normally.
```

## Tone Guidelines

### Professional & Calm
Security incidents can be stressful. Your communication should be:
- **Measured**: Not panicked or overly casual
- **Clear**: No jargon or ambiguity
- **Authoritative**: Demonstrates control and competence
- **Empathetic**: Acknowledges user concerns

### Example Tone Comparisons

❌ **Too casual**: "Oops, we had a little security hiccup, but it's all good now!"

❌ **Too alarming**: "URGENT: Your data may be compromised! Immediate action required!"

✅ **Just right**: "We've identified and resolved a security issue. No user data was compromised. We've implemented additional safeguards to prevent similar issues."

## Legal & Compliance Considerations

### Include if Required

- **GDPR**: Data breach notifications within 72 hours if personal data affected
- **CCPA**: Notification if California residents' data compromised
- **SOC 2**: Incident must be logged and reported per agreements
- **Industry-specific**: HIPAA (healthcare), PCI DSS (payments), etc.

### Standard Disclaimers

Consider adding:
```
This incident has been reported to relevant authorities as required by
[regulation name]. Affected users will be notified directly via email
as required by law.
```

## Security Incident Checklist

Before publishing updates:

- [ ] Verified facts with security team
- [ ] Removed any tactical details that could help attackers
- [ ] Confirmed legal/compliance requirements met
- [ ] Prepared answers to likely follow-up questions
- [ ] Coordinated with PR/communications team if needed
- [ ] Set up dedicated security@company.com contact
- [ ] Drafted FAQ for support team

## Follow-Up Communication

### Within 24 Hours
Initial resolution and immediate actions taken

### Within 7 Days
Preliminary findings and preventative measures

### Within 30 Days (Optional)
Full post-mortem with technical details (if appropriate)

## Example: Complete Incident Progression

**00:00 - Detection**
```
We're investigating reports of unusual login activity. As a precaution,
we've temporarily increased authentication requirements and are reviewing
account access logs.
```

**00:45 - Identification**
```
We've identified the cause as compromised API keys from a third-party
integration. We've revoked the affected keys and are auditing all
access during the exposure window. No evidence of data access.
```

**02:00 - Monitoring**
```
All compromised keys have been revoked and replaced. We're monitoring
for any related activity. Additional security measures have been
deployed to prevent similar issues.
```

**04:00 - Resolution**
```
Incident resolved. Our investigation confirms no user data was accessed.
We've strengthened our API key rotation procedures and added real-time
monitoring for unusual API activity.

Users with affected integrations will receive direct communication
about key rotation requirements.
```

## When NOT to Use This Template

- System outages unrelated to security → Use appropriate infrastructure template
- Planned security patches with no active threat → Use maintenance template
- Minor configuration issues → Use general service disruption template

Only use security incident language when there's an actual security concern to avoid alarm fatigue.

## Related

This template is one of several in the [incident communication guide](/guides/incident-communication), which covers update cadence by severity, what to avoid saying, and the other scenario templates.

## Frequently asked questions

<details>
  <summary>Do I need to notify users immediately for every security concern?</summary>
  No. Only communicate publicly when there's a confirmed incident with user impact or when you're taking visible security measures (like requiring password resets). Internal security reviews and patched vulnerabilities without exploitation typically don't require public disclosure.
</details>

<details>
  <summary>What legal obligations do I have for security incident disclosure?</summary>
  This varies by jurisdiction and industry. GDPR requires notification within 72 hours for personal data breaches. CCPA has requirements for California residents. Healthcare (HIPAA) and payment systems (PCI DSS) have specific rules. Always consult with legal counsel before publishing security incident communications.
</details>

<details>
  <summary>How much technical detail should I share about a security vulnerability?</summary>
  Share enough to demonstrate competence and transparency, but avoid tactical details that could help attackers. Good: 'unauthorized access attempts to our admin panel.' Bad: 'SQL injection on /admin/login using parameter X.' Wait until the vulnerability is fully patched and no longer exploitable before sharing technical details.
</details>

<details>
  <summary>Should I tell users to change their passwords?</summary>
  Only if there's evidence of credential compromise or unauthorized access to authentication systems. Don't create alarm fatigue by requesting password changes for unrelated security work. Be specific about why you're asking and which accounts are affected.
</details>