Free policy generator

Incident response policy generator

Answer a few questions about your team, reporting channels, and escalation paths. The document builds live beside the form as you type, already mapped to SOC 2, ISO 27001, or GDPR. When you're done, export to Word, Markdown, or PDF. Everything runs right in your browser, with no signup, no email capture, and nothing sent to our servers.

Your organization
Map to frameworks
People and contacts
Response targets

Answers are saved in this browser only, so you can come back and keep editing.

A starting template, not legal advice. Read it against how your company actually works, change anything that isn't true, and have counsel review obligations specific to your industry and jurisdiction. Nothing you enter leaves this page.

What auditors actually check in this policy

Auditors do not fail you for having a modest plan. They fail you for writing promises you cannot keep. Most generic templates copy enterprise procedures, pledging round-the-clock on-call coverage, a 15-minute response SLA, and immediate forensics teams that a ten-person company does not have. An auditor will ask to see your on-call schedule or your last post-incident review to see if you obeyed your own rules. They also check whether you separate minor security events from actual breaches, and whether your reporting deadlines match the laws you operate under, like GDPR's 72-hour window.

Once you export your document, make it operational with two quick tasks. First, create the dedicated incident channel and public security email address you specified in the form. Store your cyber insurer's claim number and outside counsel's details in your team password manager. Second, put an annual tabletop exercise on the engineering calendar. Running a simple one-hour hypothetical incident and keeping the written notes gives auditors the operational evidence they look for every year.

Questions

What must an incident response policy include?

A thorough policy needs clear definitions separating routine events from actual security incidents. It should outline explicit roles like an incident commander and communications lead, a severity rating table from SEV1 to SEV4, and a structured response workflow covering triage, containment, eradication, and recovery. It also needs regulatory notification deadlines, insurer contact obligations, and requirements for post-incident reviews and annual tabletop testing.

What do SOC 2 and ISO 27001 auditors look for?

Auditors want to see that your plan is tested and actively maintained. For SOC 2, they check whether staff have an established path to report issues and whether you run periodic tabletop drills. For ISO 27001, they look at control A.5.24 through A.5.28, ensuring you assess events, learn from past disruptions, and retain incident records. Above all, they verify that your stated response times reflect real operational practices.

How fast do we need to notify customers and regulators after a breach?

Deadlines depend on the regulations and contracts that govern your business. GDPR requires notifying supervisory authorities within 72 hours of becoming aware of personal data compromises. HIPAA allows up to 60 calendar days for individual breach notices, and PCI DSS expects your plan to cover prompt notice to the payment brands and your acquirer. Many enterprise customer contracts also mandate notice within 24 to 48 hours, so align your policy with your strictest signed agreements.

How often should we review and test our incident response policy?

Review your policy at least once every twelve months or right after any major architectural change. In addition to document reviews, conduct a tabletop exercise annually. Gather your primary responders for a 60-minute walk-through of a realistic scenario, like a compromised credential or ransomware attack. Record who attended, note what processes succeeded or stalled, and update your policy based on what you discovered during the exercise.

Is a generated incident response policy enough for an audit?

A generated policy gives you the formal structure auditors look for, but documentation is only half of compliance. You also need evidence that the policy reflects your day-to-day operations. If your document specifies an escalation Slack channel, an emergency email inbox, and annual tabletop training, you must establish those communication channels and retain dated notes from your drills. An unedited template without operational backing will not satisfy an audit.

More templates: Access control policy generator · Password policy generator · Vulnerability management policy generator · Data retention policy generator

Checked once. Now have it watched.

Your incident response policy defines how you contain security events once they occur. Attack Surface Scan supports detection by continuously monitoring your verified domains for exposed ports, expired TLS certificates, dangling CNAMEs, and unexpected DNS changes. Its change feed and PDF reports provide concrete external evidence when investigating incidents or demonstrating perimeter monitoring to auditors.

7-day trial of the full product, no card required. Scanning needs domain ownership verified by DNS: Attack Surface Scan never scans anything you haven't proved you control.