What should a Google Workspace incident response plan include?

Named roles with out-of-hours numbers, a declaration trigger list, the first five admin console actions in order, one playbook per likely scenario, the evidence to capture before remediation, and the recovery windows that expire.

Is this incident response plan template free to use?

Yes. Copy it, adapt it and adopt it internally or for clients with no attribution required. A link back is welcome but not a condition of use.

How often should the plan be reviewed?

Every six months, and after any real incident. The fields that go stale fastest are the phone numbers and the list of who currently holds super admin.

Template

Incident response plan template

Name: Workspace Migration Services
Address: 5th Floor, 5 Conduit Street, London, W1S 2XD, GB
Telephone: +44 20 7183 3436

An incident response plan for Google Workspace names four scenarios, an owner for each, and the first five console actions to take within 30 minutes: suspend the account, reset sign-in cookies, revoke OAuth tokens, export the login audit log, and place a Vault hold before anything is deleted.

Last checked 2026-08-07 · template reviewed against the current admin console · See what changed

What the template contains
Scenarios covered	Account compromise, data exfiltration, BEC, ransomware on synced files
First-response window	30 minutes, five console actions
Roles defined	Incident lead, Workspace admin, comms owner, legal contact
Evidence captured	Login audit, admin audit, Drive audit, Gmail log search
Format	Plain text, copy and adapt, no attribution required
Recovery windows quoted	Deleted user 20 days, trashed Drive file 25 days

Copy the template

Free to use and adapt, including commercially. Every bracketed placeholder is meant to be replaced before the document is adopted.

Incident response plan — plain text

GOOGLE WORKSPACE INCIDENT RESPONSE PLAN
Organisation: [ORGANISATION]
Owner: [INCIDENT LEAD NAME AND MOBILE]
Version: [1.0]  Last reviewed: [DATE]

1. ROLES
Incident lead: [NAME] - declares the incident, owns decisions.
Workspace admin: [NAME] - holds super admin, executes console actions.
Communications: [NAME] - staff, customers, regulators.
Legal / DPO: [NAME] - breach notification decision.
Out of hours: [PHONE], escalation after 15 minutes to [PHONE].

2. DECLARING AN INCIDENT
Anyone may declare. Trigger examples: unexpected mail forwarding rule,
mass external sharing, login from an unrecognised country, ransom note
in a synced folder, supplier reporting a fraudulent invoice from us.

3. FIRST 30 MINUTES - GOOGLE WORKSPACE
a. Admin console > Directory > Users > [user] > Suspend user.
b. Same user > Security > Sign-in cookies > Reset.
c. Same user > Security > Connected applications > revoke all tokens.
d. Reporting > Audit and investigation > Login audit log > export CSV
   for the last 30 days for the affected user.
e. Vault > Matters > create matter [INCIDENT ID] > place hold on the
   user's Gmail and Drive BEFORE any deletion or account removal.

4. SCENARIO PLAYBOOKS
4.1 Account compromise
 - Steps 3a-3e, then Gmail settings > check filters and forwarding.
 - Reporting > Email log search for messages sent during the window.
 - Reset password, re-enrol 2-step verification, issue new backup codes.
4.2 Data exfiltration via Drive sharing
 - Drive audit log: filter by the user, event "share" and "download".
 - Remove external shares; where the file left the tenant, record it.
 - Decide notification with [LEGAL / DPO].
4.3 Business email compromise / invoice fraud
 - Preserve full headers of the fraudulent message.
 - Contact bank within [X] hours; report to [Action Fraud / FBI IC3].
 - Check for lookalike domains registered against our brand.
4.4 Ransomware on locally synced Drive files
 - Disconnect the endpoint from the network before anything else.
 - Do not delete the cloud copies; version history is the recovery path.
 - Restore from Drive version history or from [BACKUP PROVIDER].

5. EVIDENCE TO CAPTURE (before remediation)
Login audit log, admin audit log, Drive audit log, email log search
export, screenshot of any ransom note, list of affected accounts.

6. RECOVERY WINDOWS - DO NOT MISS THESE
Deleted user restorable for 20 days from the admin console.
Trashed Drive file restorable for 25 days from the admin console.
Beyond those windows only a Vault retention rule set before the
incident preserves the data.

7. COMMUNICATIONS
Internal holding statement: [TEXT].
Customer notification approved by: [NAME].
Regulator: [ICO / STATE AG], deadline [72 HOURS FROM AWARENESS].

8. AFTER THE INCIDENT
Post-incident review within 10 working days, chaired by [NAME].
Findings tracked in [SYSTEM] with an owner and a date each.
This plan reviewed and re-tested every [6] months.

Why generic incident response templates fail on Workspace

Most incident response templates were written for a network with a firewall, a domain controller and endpoints you can physically unplug. None of that describes a tenant where the data lives in Google's datacentres, the identity is a Google account and the attacker's access arrives through an OAuth token rather than a stolen laptop. The result is a document that tells you to isolate the affected host when the affected host is a browser session in another country.

The template on this page replaces those instructions with the actual console paths. Suspending a user, resetting sign-in cookies and revoking connected applications are three separate actions in three separate places, and skipping the second one leaves an attacker with a live session for up to an hour after the password change.

The order of the first five actions, and why it matters

Suspension comes first because it stops new activity without destroying anything. Cookie reset comes second because a password change alone does not terminate existing browser sessions. Token revocation comes third because an OAuth grant issued to a rogue application survives both of the previous steps and is the mechanism most often used to retain access.

Only then do you export logs, and only then do you place a Vault hold. Placing the hold before deleting or removing anything is the difference between an investigation you can complete and one where the evidence expired while a committee discussed it. Vault holds preserve data that would otherwise age out of the standard retention windows.

Suspend the user in Directory rather than deleting them
Reset sign-in cookies to terminate live browser sessions
Revoke every connected application holding Gmail or Drive scopes
Export the login, admin and Drive audit logs before remediation
Open a Vault matter and hold Gmail and Drive for the affected accounts

Adapting the template for your organisation

Three fields decide whether the document is useful at 2am: the incident lead's mobile number, the out-of-hours escalation path, and the name of whoever is authorised to notify a regulator. Fill those in first. Every other bracketed placeholder can be completed at leisure.

Regulatory deadlines vary. UK organisations report qualifying personal data breaches to the Information Commissioner's Office within 72 hours of becoming aware; US obligations depend on state law and sector. Put the deadline that applies to you into section 7 rather than leaving a generic value nobody will check under pressure.

Test the plan before you need it. A tabletop exercise where somebody reads out a scenario and the admin walks through the console live takes under an hour and reliably finds two problems: nobody knows who currently holds super admin, and the audit log export takes longer than anyone expected.

What we see that others don't say

The single control that decides whether a Workspace incident is recoverable is whether a Vault retention rule existed before the incident, because admin console restore only reaches back 25 days for Drive files and 20 days for a deleted user, and neither window survives an attacker who empties trash deliberately.

What this doesn't cover

This is a template, not legal advice. Breach notification decisions belong to your data protection officer or counsel.
It covers the Google Workspace layer only. Endpoints, network devices and non-Google SaaS need their own playbooks.
Cyber insurance policies often mandate a specific notification order; check your policy before adopting section 7 unchanged.
The console paths reflect the Admin console as checked on the date shown; Google relocates menu items without notice.

Want this done for you?

Three fields. We come back with whether this is a 20-minute fix or a project, and what it costs.

Prefer to talk? Call +44 20 7183 3436 (Mon–Fri 08:00–18:00 GMT), or message WhatsApp +44 7403 423563.

Questions we get asked

What should a Google Workspace incident response plan include?: Named roles with out-of-hours numbers, a declaration trigger list, the first five admin console actions in order, one playbook per likely scenario, the evidence to capture before remediation, and the recovery windows that expire.
Is this incident response plan template free to use?: Yes. Copy it, adapt it and adopt it internally or for clients with no attribution required. A link back is welcome but not a condition of use.
How often should the plan be reviewed?: Every six months, and after any real incident. The fields that go stale fastest are the phone numbers and the list of who currently holds super admin.

How this page is verified

Reviewed by Workspace Migration Services security desk, Workspace security and compliance reviewers. Last checked 2026-08-07.

Console paths verified against the Google Admin console on 2026-08-07.
Restore windows of 20 days for a deleted user and 25 days for a trashed Drive file are Google's published admin console values as of 2026-08-07.
Scenario list reflects the incidents Workspace Migration Services has been called into across Workspace tenants to 2026-08-07.

Sources you can check

Cite this page

Free to reuse with attribution. Copy whichever form your publication needs.

Plain citation

Workspace Migration Services, "Incident response plan template", https://workspacemigration.services/templates/incident-response-plan-template (last checked 2026-08-07).

HTML with source link

<p>Google Workspace admin console restore covers deleted users for 20 days and trashed Drive files for 25 days, so an incident response plan has to place a Vault hold before those windows expire. Source: <a href="https://workspacemigration.services/templates/incident-response-plan-template">Incident response plan template</a> — Workspace Migration Services.</p>

Embed this table

<table>
  <caption>Incident response plan template — Workspace Migration Services, 2026-08-07</caption>
  <tr><th>Scenarios covered</th><td>Account compromise, data exfiltration, BEC, ransomware on synced files</td></tr>
  <tr><th>First-response window</th><td>30 minutes, five console actions</td></tr>
  <tr><th>Roles defined</th><td>Incident lead, Workspace admin, comms owner, legal contact</td></tr>
  <tr><th>Evidence captured</th><td>Login audit, admin audit, Drive audit, Gmail log search</td></tr>
  <tr><th>Format</th><td>Plain text, copy and adapt, no attribution required</td></tr>
  <tr><th>Recovery windows quoted</th><td>Deleted user 20 days, trashed Drive file 25 days</td></tr>
</table>
<p><a href="https://workspacemigration.services/templates/incident-response-plan-template">Incident response plan template</a> — data maintained by Workspace Migration Services.</p>

Want the plan rehearsed rather than filed?

We run a tabletop exercise against your live tenant, time each console action, and hand back the plan with the gaps that only appear when someone actually tries to execute it.

Book an audit See pricing