Free Incident Response Playbook Template for Small Businesses

These playbooks give [Company Name] (the "company") step-by-step instructions for specific kinds of security incidents. They supplement the company's Incident Response Policy and Plan (the "plan") and do not replace it. NIST SP 800-61 Revision 3 notes that many organizations document their incident procedures as playbooks because they give people actionable steps for specific situations.

What is already in the plan. The plan carries its own playbooks for business email compromise and payment fraud, ransomware and extortion, and lost or stolen devices. Those are not repeated here. When an incident covered here turns into one of those, for example money is sent to a fraudster or files are encrypted, responders switch to the plan's playbook for it.

Scope. These playbooks apply to everyone with a role in the plan, including the IT provider and any other service provider that helps respond, and to every company system, account, and device, including cloud services and systems run for the company by vendors.

Authority. These playbooks become effective when approved and signed by the Chief Executive Officer. The people named in the plan may take the containment actions described here, such as disabling an account or isolating a device, without waiting for further approval.

1. Start with the plan. Report the incident, call the Incident Response Lead, and work through the plan's first-hour checklist. The checklist always comes first.
2. Assign a severity level using the plan's four levels: Critical (Level 1), High (Level 2), Medium (Level 3), and Low (Level 4). Each playbook gives guidance, but the Incident Response Lead decides, and when in doubt chooses the higher level.
3. Open the matching playbook from the index below. If more than one fits, for example malware that stole a password used to take over an email account, run both and let the Incident Response Lead set the order.
4. Follow the playbook's steps in order unless the Incident Response Lead says otherwise. Steps can run in parallel when enough people are available.
5. Record every action, decision, and time in the incident log, using the company's Incident Report Form and Incident Log where adopted.
6. Close the incident only when the playbook's "done when" list is complete and the Incident Response Lead agrees.

Same roles, same phases. The playbooks use the roles defined in the plan: the executive decision-maker, the Incident Response Lead and alternate, technical response, legal counsel, finance, human resources, and the communications spokesperson. Their steps follow the plan's phases: Detect and analyze (the first 30 to 60 minutes), Contain, Eradicate, Recover, and then Improve through the post-incident review.

Who does the technical steps. The IT provider performs the technical steps under the direction of the Incident Response Lead. Business decisions, such as shutting down a system that customers rely on, contacting customers, or notifying anyone outside the company, stay with the executive decision-maker and legal counsel.

• Assume the attacker can read company email and chat. Coordinate the response by phone or through the backup channel named in the plan.
• Preserve before you fix. Capture logs, screenshots, and, where the technical team advises, disk or memory images before wiping, reimaging, or restoring anything.
• Do not contact the attacker, and do not tell the person suspected of an insider incident that they are under review.
• Call the cyber insurer's breach hotline before hiring any outside firm, agreeing to pay anything, or admitting fault. Many cyber policies require prompt notice and the insurer's consent before costs are incurred.
• Call legal counsel for any incident that may involve personal, regulated, or customer data, payment fraud, extortion, or an employee's conduct.
• When verifying anything with a vendor, bank, customer, or employee, use a phone number the company already has on file, never one supplied in the suspicious message.
• Note the time of discovery (defined below). Many notification deadlines run from it, and legal counsel needs it to decide which apply.

Discovery

The time an incident is first known, or by exercising reasonable diligence would have been known, to any employee, officer or agent of the company other than the person who caused it. Breach counsel confirms how each law defines discovery.

Notification. None of these playbooks sets a notification deadline. Whether an incident must be reported to affected people, customers, regulators, or law enforcement depends on the data involved, where the affected people live, the company's industry, and its contracts. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section). Notification laws differ by state and industry, and this playbook is a starting point, not legal advice.

Use this playbook when. An attacker has, or may have, signed in to a company Microsoft 365 account, whether through a stolen password, repeated MFA prompts, or a malicious app the user approved. If money has been sent or payment details changed, run the plan's business email compromise playbook at the same time and call the bank first.

Signs

• Sign-in alerts or sign-ins from unfamiliar locations, devices, or times.
• MFA approval prompts the user did not start. Microsoft notes that MFA fatigue attacks, which flood a user with prompts hoping one is approved, are rising. Unexpected prompts can mean someone already has the password.
• Inbox rules that forward mail outside the company or move it to rarely checked folders, or new external forwarding.
• Sent or deleted messages the user did not write, replies to emails the user never sent, or the account blocked from sending.
• A request to approve an app or "verify your identity" that asked for access to mail, files, or contacts. The FBI warns that this kind of OAuth consent phishing can bypass both passwords and multi-factor authentication.

Severity. High (Level 2) by default. Critical (Level 1) if the account has administrator rights, if money moved, or if the attacker reached regulated or large amounts of personal data. Medium (Level 3) only if the logs show the sign-in failed and nothing was accessed.

First 30 to 60 minutes (Detect and analyze)

1. Tell the user, by phone, not to approve any sign-in prompts and not to delete anything, and ask when the problem started.
2. Call the Incident Response Lead and the IT provider, and open the incident log.
3. Confirm the takeover from the sign-in logs before tipping off the attacker, unless the account is actively sending fraud or phishing, in which case contain at once.
4. For a High or Critical incident, call the cyber insurer's breach hotline before hiring any outside firm, agreeing to pay anything, or admitting fault.
5. Check whether the same password is used on any other account, including banking and vendor portals, and add those to the list to reset.

Contain

1. In the Microsoft Entra admin center, disable the account (Microsoft prefers this until the investigation is complete), then select Revoke sessions on the user's Overview page. If the account is synchronized from on-premises Active Directory, disable it there and reset its password twice there, as Microsoft advises for hybrid environments, then select Revoke sessions in the Microsoft Entra admin center. Access already granted through an access token can last until the token expires. If the account cannot be disabled, reset the password instead.
2. Reset the password to a strong, unique value and give it to the user by phone or in person, never by email, because the attacker may still be reading the mailbox. Have the user delete and recreate any app passwords, because a password reset does not revoke them.
3. Review the user's registered MFA methods and devices, and remove any the user does not recognize.
4. Review mailbox forwarding and all inbox rules, including hidden ones, and remove anything that forwards, redirects, deletes, or moves mail to folders such as Notes, Junk Email, or RSS Subscriptions.
5. Review the applications the user has consented to and any administrator roles assigned to the account, and remove what should not be there.

Eradicate

1. Review the Microsoft Entra sign-in logs for the account: IP address, location, time, and whether each sign-in succeeded or failed.
2. Search the audit log in the Microsoft Defender portal using a date range that starts just before the first suspicious activity, without filtering for specific activities at first.
3. Use Message trace to see what the account sent, and review files accessed or shared in OneDrive and SharePoint.
4. If the user approved a malicious app, disable it for the whole organization rather than simply deleting it. Microsoft notes that a deleted app can return if another user consents to it. The FBI notes that this kind of access is not ended by changing the password.
5. Find out how the attacker got in, such as a phishing page, a reused password, or a stolen session, and close that gap for every user.
6. Check other accounts for the same signs, starting with anyone who received phishing from the compromised account.

Recover

1. Re-enable the account only after it is clean, with a new password and strong MFA, such as security keys or authenticator app prompts that require number matching.
2. Walk the user through their mailbox settings, rules, and recovery options together, and confirm nothing unfamiliar remains.
3. If Microsoft blocked the account from sending, remove it from the Restricted entities page in the Microsoft Defender portal once the account is secured.
4. Watch the account's sign-ins closely for at least 30 days.

Evidence to preserve

• Sign-in logs and audit logs covering the whole period of attacker access, exported before they age out.
• Screenshots or exports of every malicious rule, forwarding setting, app consent, and MFA method before removing it.
• Copies of phishing or fraudulent messages sent from or to the account, with full headers.

Notification and communication

Warn people who received phishing or fraudulent messages from the account, by phone or from a clean account, and tell them to delete the message and verify any payment request by calling a known number. Because the attacker may have read the mailbox and files, list what personal, customer, or regulated information the account could reach. Breach counsel determines whether notice is legally required. The executive decision-maker approves sending each notice, its content and its method on that advice, and never overrides a determination that notice is required. Counsel works out to whom and when using the notification table in the incident response plan and the Data Breach Notification Procedure, where adopted. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section). Notification laws differ by state and industry, and this playbook is a starting point, not legal advice.

Speaking for the company. Only the communications spokesperson speaks to customers, the media, or the public, using statements approved by the executive decision-maker and legal counsel. This does not limit the Protected Reports section.

Done when

• The attacker's sessions, rules, forwarding, apps, devices, and MFA methods are removed and the account is secured.
• The logs show what the attacker accessed and sent, and legal counsel has made the notification decision.
• The entry point is closed and every affected recipient has been warned.

Use this playbook when. A vendor, machine builder, software supplier, or IT provider that can reach company systems reports a breach, or there are signs its remote access, its accounts, or its software is being used against the company. NIST SP 800-61 Revision 3 notes that service providers often have privileged access, so the risk of the provider being compromised should be considered and addressed.

Signs

• A breach notice from a vendor, or a public security advisory about remote access or management software, or another product, the company uses.
• Remote sessions, scripts, or software installs that nobody requested or approved.
• Remote access tools on company computers that are not on the approved list. CISA warns that attackers increasingly co-opt legitimate remote access tools, which often do not trigger antivirus or EDR.
• A software update that behaves strangely, or many computers changing at once.

Severity. High (Level 2) at minimum. Critical (Level 1) if the attacker used the provider's access to reach company systems, or if the compromised provider is the IT provider or another provider with administrator access to everything.

First 30 to 60 minutes (Detect and analyze)

1. Confirm the report by calling the vendor at a phone number already on file. Attackers can impersonate a vendor's security team.
2. Call the Incident Response Lead and open the incident log. If the compromised provider is the company's own IT provider, the Incident Response Lead takes direct control of the response and does not rely on that provider alone to investigate itself.
3. For a High or Critical incident, call the cyber insurer's breach hotline before hiring any outside firm, agreeing to pay anything, or admitting fault.
4. If the IT provider itself is compromised, ask the insurer for an independent incident response firm from its approved panel.
5. List every way the vendor connects: remote access tools, VPN accounts, cloud admin roles, shared passwords, and software it installs or updates.

Contain

1. Disable the vendor's accounts and remote access, end open sessions, and block its remote access tool at the firewall and on company computers. Where the company depends on the vendor for daily operations, the executive decision-maker decides how to keep running without it.
2. Pause updates and automatic deployments from the affected software until the vendor and the technical team confirm they are safe.
3. Change every password, key, and token the vendor knew or could reach, starting with administrator, email, backup, and banking accounts.
4. Protect backups and logs: confirm they are intact and that the vendor's tools cannot reach or change them. CISA advises keeping log servers out of reach of remote management tools.

Eradicate

1. Review remote access, RMM, VPN, and cloud audit logs for sessions, scripts, accounts, and changes the company did not approve, starting from before the vendor's reported compromise.
2. Use EDR to search every computer for unapproved remote access tools, new accounts, and the indicators the vendor or public advisories publish.
3. Ask the vendor, in writing, what happened, when, which customers and systems were affected, what the attacker could reach in the company's environment, and what it fixed. Coordinate with the vendor's incident response team, but keep the company's own investigation under its own control.
4. Remove or update the affected software as the vendor and public advisories direct, and rebuild any system that was changed by the attacker.

Recover

1. Restore the vendor's access only after it explains the cause and the fix and the Incident Response Lead approves, through named accounts with MFA under the company's Third-Party and Vendor Remote Access Policy, where adopted.
2. Review the vendor's contract for its incident notice duties and security obligations. CISA advises that contracts detail how and when providers notify customers of an incident.
3. Watch closely for at least 30 days for any return of the vendor's tool or accounts.

Evidence to preserve

• The vendor's breach notice and every written answer it gives.
• Remote access, RMM, VPN, firewall, and cloud audit logs covering the period of exposure.
• A list of every vendor account, tool, and credential, and when each was disabled or changed.

Notification and communication

The company may need to tell its own customers if their data or deliveries were affected through the vendor. The vendor may also notify people on its own, so ask what it plans to send and when, to keep messages consistent. Breach counsel determines whether notice is legally required. The executive decision-maker approves sending each notice, its content and its method on that advice, and never overrides a determination that notice is required. Counsel works out to whom and when using the notification table in the incident response plan and the Data Breach Notification Procedure, where adopted. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section). Notification laws differ by state and industry, and this playbook is a starting point, not legal advice.

Speaking for the company. Only the communications spokesperson speaks to customers, the media, or the public, using statements approved by the executive decision-maker and legal counsel. This does not limit the Protected Reports section.

Done when

• Every vendor path into company systems is closed or rebuilt, and credentials it knew are changed.
• The logs show what the attacker did through the vendor, and legal counsel has made the notification decision.
• Access is restored, or the vendor is replaced, with the decision documented.

Use this playbook when. A current or departing employee, contractor, or other insider may be copying, sending, deleting, or using company or customer information in a way their job does not allow, or misusing their access to damage systems.

Signs

• Large downloads, bulk copying to USB drives or personal cloud storage, or mass printing, especially around a resignation or termination.
• Company files emailed or shared to personal accounts, or forwarding rules to personal email.
• Access to systems or records outside the person's job, or access after hours that has no business reason.
• A tip from a coworker, customer, or competitor, or deleted records and changed settings that nobody can explain.

Severity. Medium (Level 3) for a policy violation with no sign that data left the company. High (Level 2) if personal, customer, regulated, or trade secret information may have been taken. Critical (Level 1) if the person is actively damaging systems or data.

First 30 to 60 minutes (Detect and analyze)

1. Bring in the Human Resources Manager and legal counsel before anyone acts. NIST SP 800-61 Revision 3 recommends notifying human resources when malicious insider activity has occurred. Keep the group to the fewest people possible, and leave out the person's manager or coworkers unless counsel agrees.
2. Do not confront, question, or warn the person, and do not change their access yet unless they are actively causing damage. Evidence can disappear once the person knows.
3. Open a restricted incident log that only the response group can read. Record facts only, and avoid conclusions about the person in writing.
4. For a High or Critical incident, call the cyber insurer's breach hotline before hiring any outside firm, agreeing to pay anything, or admitting fault.
5. Legal counsel decides whether to issue a legal hold and whether privacy rules limit what may be reviewed, especially for personal accounts or personal devices.

Contain

1. Preserve evidence quietly first: export mailbox and file audit logs, sharing and download history, USB and print logs, and remote access logs, and, where counsel advises, image the person's company computer and phone.
2. Plan the removal of access with the Human Resources Manager so it happens at the moment of the HR meeting or departure: disable the account, revoke all sessions, remove remote access and MFA devices, and disable company devices. Microsoft lists employee termination and insider threats among the reasons to revoke all of a user's access.
3. Change shared passwords, door codes, and vendor or bank logins the person knew.
4. Collect company laptops, phones, badges, keys, and storage devices at the meeting, and record what was returned.

Eradicate

1. Remove forwarding rules, external sharing links, connected apps, and personal devices the person set up on company accounts.
2. Determine what information left the company, where it went, and whether it can be recovered. Legal counsel decides whether to send a demand to return or destroy it, and whether to involve law enforcement.
3. Check for any changes the person made to systems, records, payments, or backups, and reverse them.

Recover

1. Restore any damaged or deleted data from backups, and confirm business records are accurate.
2. Reassign the person's mailbox, files, and duties to a manager, under counsel's guidance on what must stay preserved.
3. Review whether access rights, offboarding steps, or data loss controls should change, and track the fixes.

Evidence to preserve

• Audit, sharing, download, USB, print, and remote access logs, exported before they age out, with the time and the name of the person who exported them.
• Images of company devices the person used, where counsel advises.
• Signed agreements, such as confidentiality and acceptable use acknowledgments, and the record of returned equipment.

Notification and communication

Insider incidents often involve employment law and privacy rules as well as breach notice laws. If customer or personal information was taken, the company may owe notice to the people affected or to customers under contract. Breach counsel determines whether notice is legally required. The executive decision-maker approves sending each notice, its content and its method on that advice, and never overrides a determination that notice is required. Counsel works out to whom and when using the notification table in the incident response plan and the Data Breach Notification Procedure, where adopted. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section). Notification laws differ by state and industry, and this playbook is a starting point, not legal advice.

Speaking for the company. Only the communications spokesperson speaks to customers, the media, or the public, using statements approved by the executive decision-maker and legal counsel. This does not limit the Protected Reports section.

Done when

• The person's access is fully removed and company property is recovered.
• What was taken or changed is known as far as possible, and legal counsel has made the notification and legal action decisions.
• Evidence is preserved under any legal hold, and control gaps are assigned for fixing.

Use this playbook when. Security software alerts on a computer or server, or someone ran a file or visited a site that may have installed malicious software, and there is no sign of ransomware. If files are being encrypted or a ransom note appears, switch to the plan's ransomware playbook immediately.

Signs

• An EDR or antivirus alert, especially one the software could not block or clean on its own.
• Unknown programs, browser extensions, or pop-ups, browser searches being redirected, or a computer that suddenly runs very slowly.
• A user who opened an unexpected attachment, ran a download, or entered a password on a suspicious page.
• Unusual network traffic from one device, or passwords saved in the browser being used from elsewhere.

Severity. Medium (Level 3) when malware was blocked on one workstation with no sign it ran. High (Level 2) when it ran, when it is on a server, when it may have stolen passwords, or when more than one device is affected. Critical (Level 1) when it is spreading or shows signs of ransomware.

First 30 to 60 minutes (Detect and analyze)

1. Isolate the device from the network with the EDR console, which keeps it reachable by investigators. Do not power it off or restart it.
2. Call the Incident Response Lead and the IT provider, and open the incident log with the time, the user, and what they were doing.
3. Record the alert details: the file name, its location, the detection name, and the time it first appeared.
4. Ask the user, by phone, whether they entered any passwords, approved any prompts, or plugged in any storage devices around that time.
5. For a High or Critical incident, call the cyber insurer's breach hotline before hiring any outside firm, agreeing to pay anything, or admitting fault.

Contain

1. Use EDR to search every company device for the same file, its fingerprint (hash), and the addresses it contacted, and isolate any other device where it is found.
2. Block the malicious web addresses and file fingerprints at the firewall, email filter, and security software.
3. If the malware could steal passwords, treat every password typed into or saved on the device as stolen: reset them from a clean device and revoke the accounts' active sessions, starting with email, administrator, banking, and remote access accounts. The FBI advises resetting all credentials that may have been exposed, including service accounts and certificates.

Eradicate

1. Rebuild the device from a known-good image rather than trying to clean it, once the technical team has captured the evidence it needs. The FBI advises that, unless instructed to preserve them, compromised systems should be reimaged as soon as possible.
2. Find out how it got in, such as an attachment, a download, an unpatched program, or a USB drive, and close that path.
3. Check for persistence the attacker may have left elsewhere: new accounts, scheduled tasks, remote access tools, and mail forwarding rules.

Recover

1. Restore the user's files from backups taken before the infection, not from the infected device.
2. Return the device to service only after the technical team confirms it is clean and up to date, and the Incident Response Lead approves.
3. Watch the device and any reset accounts closely for at least 30 days.

Evidence to preserve

• The EDR alert, its process tree and timeline, and the malicious file or its fingerprint.
• A memory or disk image before rebuilding, when the technical team or counsel advises, especially for servers and suspected data theft. NIST notes that most malware incidents do not lead to prosecution, so full forensic handling is a judgment call.
• Firewall and proxy logs showing what the device contacted.

Notification and communication

Whether any notice is required is a question for legal counsel. A contained malware incident with no access to personal, customer or regulated information often requires none. If the malware stole passwords, or could reach personal, customer, or regulated information, the question of notice goes to legal counsel. Breach counsel determines whether notice is legally required. The executive decision-maker approves sending each notice, its content and its method on that advice, and never overrides a determination that notice is required. Counsel works out to whom and when using the notification table in the incident response plan and the Data Breach Notification Procedure, where adopted. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section). Notification laws differ by state and industry, and this playbook is a starting point, not legal advice.

Speaking for the company. Only the communications spokesperson speaks to customers, the media, or the public, using statements approved by the executive decision-maker and legal counsel. This does not limit the Protected Reports section.

Done when

• Every affected device is rebuilt or confirmed clean, and the entry point is closed.
• Every exposed password and session is reset or revoked.
• No new detections have appeared during the monitoring period, and legal counsel has decided on notice where data was at risk.

Use this playbook when. Company, customer, or employee information was sent or shown to someone who should not have it by mistake, with no attacker involved: an email to the wrong person, the wrong attachment, a sharing link set to "anyone", a misconfigured cloud folder, or a file posted on the website.

Signs

• An employee realizes they sent the wrong file or picked the wrong address.
• A recipient, customer, or member of the public reports receiving or finding information they should not have.
• A file sharing report shows a link open to anyone, or company data turns up in a search engine.

Severity. High (Level 2) whenever personal, customer, or regulated information may be involved, until legal counsel rules otherwise, consistent with the plan. Medium (Level 3) when only internal business information went to a trusted recipient. Low (Level 4) when nothing sensitive was exposed.

First 30 to 60 minutes (Detect and analyze)

1. The employee reports the mistake immediately to the Incident Response Lead. Reporting quickly matters more than the mistake, and no one is punished for a prompt, good-faith report.
2. Open the incident log and record exactly what was exposed, whose information it was, how many people it concerns, whether it was encrypted, who received or could reach it, and when.
3. Do not forward the exposed data around the company while investigating. Share only the details needed.
4. For a High or Critical incident, call the cyber insurer's breach hotline before hiring any outside firm, agreeing to pay anything, or admitting fault.

Contain

1. Shut off further access: change the sharing link to restricted or delete it, lock down the cloud folder, or take the file off the website. The FTC advises removing personal information improperly posted on a website immediately.
2. Contact the recipient by phone, ask them not to open, forward, or download the information, and ask them to delete it, including from their deleted items, and confirm in writing that they have done so. Legal counsel approves the wording of any written confirmation request for sensitive data.
3. If the data was public, search for copies, and ask search engines and other sites that saved a copy to remove it, as the FTC advises.

Eradicate

1. Review sharing and access logs to learn who opened or downloaded the information while it was exposed.
2. Find the cause, such as address autocomplete, a default sharing setting, or a missing review step, and fix it.

Recover

1. Confirm the exposed data is no longer reachable and record the recipient's deletion confirmation, or the fact that none was received.
2. Update settings or training so the same mistake is less likely, for example a warning when email is addressed to someone outside the company, or limits on "anyone" sharing links.

Evidence to preserve

• A copy of the misdirected message or file and its sharing settings at the time, kept with restricted access.
• Sharing, access, and download logs for the exposure period.
• Every communication with the recipient, including the deletion confirmation.

Notification and communication

An accidental exposure can still be a breach under some state and industry rules, depending on the data, who received it, and whether it was encrypted. A recipient's confirmation that the data was deleted may matter to that decision, so give it to legal counsel. Breach counsel determines whether notice is legally required. The executive decision-maker approves sending each notice, its content and its method on that advice, and never overrides a determination that notice is required. Counsel works out to whom and when using the notification table in the incident response plan and the Data Breach Notification Procedure, where adopted. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section). Notification laws differ by state and industry, and this playbook is a starting point, not legal advice.

Speaking for the company. Only the communications spokesperson speaks to customers, the media, or the public, using statements approved by the executive decision-maker and legal counsel. This does not limit the Protected Reports section.

Done when

• The exposure is closed and the recipient has confirmed deletion, or the attempt is documented.
• What was exposed and about whom is recorded, and legal counsel has made the notification decision.
• The cause is fixed.

Use this playbook when. The company website or another internet-facing service is slowed or knocked offline by a flood of traffic (a distributed denial-of-service, or DDoS, attack), or an attacker has changed its content (defacement) or added malicious code.

Signs

• A sudden surge in traffic, the site timing out or going down, or alerts from the hosting provider.
• Changed pages, images, or messages on the site that nobody at the company posted.
• Customer reports of pop-ups, redirects, or browser warnings on the site, or new administrator accounts on the site.

Severity. Medium (Level 3) when a brochure website is down and nothing was changed. High (Level 2) for defacement, because the attacker had write access, or when the site takes orders or customer logins. Critical (Level 1) when payment or login pages were altered, or customer data may be exposed.

First 30 to 60 minutes (Detect and analyze)

1. Start the incident response plan, call the Incident Response Lead, and open the incident log.
2. Call the CDN, web application firewall, or DDoS protection provider and the hosting provider. They may be able to filter or reroute the traffic, and CISA advises contacting them as part of the response.
3. Record timestamps, source IP addresses, packet captures if available, and any logs or alerts, as CISA advises. Note any error messages the site shows.
4. Stay alert for other attacks at the same time. CISA notes that DDoS attacks can be launched alongside other attacks, such as email spam campaigns.
5. For a High or Critical incident, call the cyber insurer's breach hotline before hiring any outside firm, agreeing to pay anything, or admitting fault.

Contain

1. Turn on the provider's attack or under-attack mode and filtering rules, and ask it to block the attacking addresses.
2. For defacement or malicious code, take the site offline or replace it with a maintenance page so visitors are not harmed or misled.
3. Change the passwords for the website, hosting account, content management system, domain registrar, and DNS, and require MFA on each.

Eradicate

1. Find how the attacker changed the site, such as an outdated plugin, a stolen administrator password, or a hosting account takeover, and close it.
2. Remove attacker accounts, added files, and unknown code. If unsure whether everything was found, rebuild instead of cleaning.

Recover

1. Restore the site from a known-good backup taken before the change, and apply all updates before bringing it back online.
2. Confirm with the provider that traffic is back to normal and the site is clean before ending attack mode.
3. Watch for repeat attacks, and review whether the site needs a protection service or stronger hosting.

Evidence to preserve

• Screenshots and a saved copy of defaced pages, with the time.
• Web server, hosting, CDN, firewall, and content management logs covering the attack.
• Provider ticket numbers and every communication with the provider.

Notification and communication

Keep customers informed through a channel that still works, such as social media or email from a clean account, with statements approved for the purpose. If payment or login pages were altered, customer information may have been captured, which is a question for legal counsel. Report the attack to the FBI at ic3.gov as the plan's law enforcement rule directs. For a DDoS attack, the FBI asks that the report include the word DDoS in its description. Breach counsel determines whether notice is legally required. The executive decision-maker approves sending each notice, its content and its method on that advice, and never overrides a determination that notice is required. Counsel works out to whom and when using the notification table in the incident response plan and the Data Breach Notification Procedure, where adopted. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section). Notification laws differ by state and industry, and this playbook is a starting point, not legal advice.

Speaking for the company. Only the communications spokesperson speaks to customers, the media, or the public, using statements approved by the executive decision-maker and legal counsel. This does not limit the Protected Reports section.

Done when

• The site is restored from a known-good copy, patched, and protected by MFA on every admin login.
• Traffic is normal and the provider confirms the attack has stopped.
• Legal counsel has decided on notice if any customer information was at risk.

Nothing in this document prohibits or restricts anyone from reporting a possible violation of law to, filing a charge or complaint with, communicating with, or taking part in an investigation by any government agency, including law enforcement, the U.S. Department of Health and Human Services, the Securities and Exchange Commission, the National Labor Relations Board, or a state attorney general, or from making any other disclosure protected by law. No approval is needed for these reports, and no one will be disciplined for making one in good faith.

Owner. The Incident Response Lead owns these playbooks and keeps them consistent with the incident response plan. Changes are approved by the Chief Executive Officer.

Exercises. The response team walks through at least one playbook in a tabletop exercise at least once a year, rotating so every playbook is exercised over time, using the company's Tabletop Exercise Plan and After-Action Report where adopted. The IT provider and other key providers take part.

After every use. After a real incident or an exercise, the Incident Response Lead records which steps were unclear, missing, or out of order, and the playbook is updated before the incident is closed or within the post-incident review.

Console and contact check. Admin console menus and setting names at providers such as Microsoft and Google change often. At least every six months, and when changing any provider, the IT provider confirms the steps still match the screens, and the Incident Response Lead confirms phone numbers for vendors, the hosting provider, and the insurer.

Scheduled review. These playbooks are reviewed no later than October 13, 2027, and sooner after a new system, a new provider, new regulated data, or a change to the incident response plan.

Offline copies. Printed copies are kept with the printed incident response plan by the Incident Response Lead, the alternate, and the executive decision-maker, and are replaced after every update.

Related documents. These playbooks work with the [Company Name] Incident Response Policy and Plan, Incident Report Form and Incident Log, Data Breach Notification Procedure, Tabletop Exercise Plan, and Third-Party and Vendor Remote Access Policy, where adopted. If they conflict, the stricter requirement applies, and legal counsel resolves any question about notification.

Approval. Sign below to approve this document for adoption by [Company Name] after it has been reviewed by your legal counsel. Until it is signed, it is a draft and is not in effect.

Revision history. Record every change to these playbooks below. Increase the document version and obtain approval again each time the playbooks are revised.

This document was generated from a starter template provided by Preferred Data Corporation. It is general information only. It is not legal advice and it is not a substitute for advice from a licensed attorney. Using the template does not create an attorney-client, consulting, or other professional relationship.

Preferred Data Corporation is not a law firm or an insurer. It makes no representation that this document is complete, current, or suitable for any particular organization, industry, jurisdiction, or regulatory requirement. To the fullest extent permitted by law, it is not responsible or liable for any loss or damage arising from the use of this template or of any policy created from it. You are solely responsible for how you adapt, adopt, and enforce it.

Laws, regulations, insurance requirements, and contracts that apply to your organization may require different or additional terms. The facts, deadlines, and legal references in this template were checked against their sources on the date shown as "Template content last reviewed" in Document Control, not on the effective date, and may have changed since. Before you adopt, publish, or rely on this document, and in every case where you have a legal, regulatory, or contractual obligation, have it reviewed by qualified legal counsel.

In an actual security incident or data breach, contact your attorney, your cyber insurer, and law enforcement where appropriate. Do not rely on this template alone to decide whether, when, or how to notify anyone.

If Preferred Data Corporation prepared this document for you as part of its services, your service agreement governs those services. The content of this document is still general information and should be reviewed by your own counsel before you adopt it.

This template is provided "as is", without warranties of any kind, including accuracy, completeness, or fitness for a particular purpose. Links to laws, agencies, and other websites are provided for convenience and may change. Use of this template is also subject to the Website and Free Resources Disclaimer and the Terms of Service at preferreddata.com/legal/disclaimer and preferreddata.com/legal/terms-of-service.

To report an error, contact Preferred Data Corporation at preferreddata.com/contact or (336) 886-3282 and include the Document ID shown in Document Control. Corrections are listed in the template changelog on the template's page at preferreddata.com/policy-templates.