Learn

Playbook

Incident Response Plan Template for Small Businesses on Google Workspace: Roles, First-Hour Steps and What to Log

Incident Response Plan Template for Small Businesses on Google Workspace: Roles, First-Hour Steps and What to Log

Incident Response Plan Template for Small Businesses on Google Workspace: Roles, First-Hour Steps and What to Log

A one-page incident response plan for small businesses on Google Workspace: who does what, the first-hour Admin console steps and what to log.

A one-page incident response plan for small businesses on Google Workspace: who does what, the first-hour Admin console steps and what to log.

Julien Monguillot

Julien Monguillot

Julien Monguillot

Co-Founder

Co-Founder

Co-Founder

Created:

Created:

Created:

Learn

A usable incident response plan for a small business on Google Workspace fits on one page: it names who declares an incident, who leads the response, who talks to customers and regulators and exactly which buttons to press in the Admin console in the first hour. Most templates sold online are written for security teams that don’t exist at a 15-person company. This one is written for the founder, COO or ops lead who will actually be holding the plan when something goes wrong.

TL;DR

  • We recommend a small business incident response plan with four named roles (Declarer, Lead, Communicator, External Liaison), not a 40-page policy document.

  • In the first hour on Google Workspace, suspend the account, capture evidence, revoke sessions and OAuth tokens, then review the audit logs.

  • Log every action with a timestamp, even informally, because insurers, auditors and regulators all expect an evidentiary trail of who did what and when.

  • Line up outside incident responders before you need them. Negotiating a contract during an active breach costs you hours you don’t have.

  • Test the plan twice a year with a short tabletop exercise rather than a live-fire drill, so the roles and steps are muscle memory when it counts. CISA and the UK NCSC both publish free scenario packs.

About the Author: This article is written by the ShiftControl team. ShiftControl was built by ex-ExpressVPN operators and is purpose-built for Google Workspace, for companies that run IT without a dedicated IT team.

Who Should Be On a Small Business Incident Response Team?

We recommend four roles filled by named people, not job titles that rotate. Larger organizations spread incident response across dedicated security, legal and communications teams, but a company of 10 to 100 people doesn’t have that bench, so the same person often holds two of these roles.

  • Declarer - the person authorized to say “this is an incident,” usually the founder, COO or ops lead. Without a named declarer, suspicious activity gets debated in Slack for hours before anyone acts.

  • Lead - owns the response end to end: coordinates the timeline, makes containment decisions and decides when the incident is closed.

  • Communicator - handles internal updates to staff and, if needed, external notices to customers or partners. Keeping this separate from the Lead means the person fighting the fire isn’t also drafting the customer email.

  • External Liaison - the point of contact for outside responders, legal counsel, cyber insurance and regulators. This role matters most in the first 72 hours, because breach-notification clocks start early: GDPR gives 72 hours from becoming aware of a breach, and Singapore’s PDPA sets its own deadlines (see below).

Write these four names, plus a backup for each, at the top of a single page. A plan nobody can locate or read during an actual incident has little practical value, so simplicity beats comprehensiveness.

What Should the First Hour of a Google Workspace Incident Look Like?

Do a quick check of the login and audit logs to confirm the compromise. If you see active misuse, suspend the account immediately and investigate after. Every minute an attacker keeps account access is a minute they can do more damage.

Here is the sequence for a suspected compromised account on Google Workspace:

  1. Suspend the account if you see active misuse or can’t rule it out. In the Admin console, go to Users, select the affected account and suspend it. This blocks sign-in immediately without deleting data, which matters because you may need that account’s content as evidence later. One known gap: a suspended user can keep participating in a Google Chat session until that session ends, so check for it separately.

  2. Capture evidence. Before you revoke anything, export the relevant audit log entries and take screenshots of the account’s forwarding rules, filters and OAuth grants. Once you remove a malicious OAuth grant, you may lose the detail of what scopes it had.

  3. Reset sign-in cookies, then revoke tokens. In the user’s Security panel, reset sign-in cookies (suspension also does this automatically), which ends active browser and mobile sessions. This doesn’t sign the user out of some apps, such as Gmail and Drive for desktop. Then review the connected apps and revoke any third-party OAuth tokens and app passwords. Then end sessions in any third-party apps that use their Google sign-in. A stolen password is useless if the session and tokens tied to it are already dead.

  4. Review the admin and login audit logs. Google Workspace logs login successes and failures, admin role changes, file creation and deletion, mail forwarding rule changes and Drive sharing permission changes. Each change you make is also logged, so note your own actions to keep the timeline clear.

  5. Check for mail forwarding and delegation rules. Attackers who get into an inbox commonly set up silent forwarding rules to exfiltrate future email. Check Gmail settings, filters and delegated access for that account specifically.

This order matters. Suspend first, because that stops the bleeding. Capture evidence before you revoke anything. Then review the logs, because that tells you how bad the cut was.

What Should You Log During an Incident, and Why Does It Matter?

A security incident log template needs five fields per entry: timestamp, action taken, person responsible, system affected and evidence reference. This sounds basic, but it’s one of the most often skipped steps in small business incident response, because everyone is focused on fixing the problem rather than documenting it.

Field

Example Entry

Timestamp

2026-03-14 09:12 SGT

Action

Suspended user account [email protected]

Owner

COO (Declarer/Lead)

System

Google Workspace Admin console

Evidence

Screenshot of audit log entry #4471, saved to incident folder

Why this matters beyond internal tidiness: SOC 2 and ISO 27001 expect documented incident response procedures, and GDPR requires you to keep records of breaches and, unless a breach is unlikely to result in a risk to individuals, to notify the supervisory authority within 72 hours of becoming aware of it. Insurers also typically ask for a timeline when you file a claim. None of these frameworks mandate a specific “first-hour logging” format, but a contemporaneous log is far easier to defend than one reconstructed from memory afterward.

If you handle personal data of people in Singapore, the PDPA adds its own clock. Assess a suspected breach within 30 calendar days. If it is likely to cause significant harm, or it affects 500 or more individuals, notify the PDPC as soon as practicable and no later than 3 calendar days after you decide it is notifiable, and notify affected individuals as soon as practicable. Your log is the evidence of when you became aware and when you decided.

Google Workspace’s native audit logs are retained for roughly 6 months by default, which is enough for most small business incidents. Retention and lag vary by log type, though: Gmail log search, for example, covers only the last 30 days. It’s worth exporting key entries into your incident log rather than relying on the console alone, since logs can roll off that retention window while a drawn-out investigation or legal process is still ongoing.

When Should You Bring in Outside Incident Responders?

Bring in outside responders the moment an incident involves data exfiltration, ransomware or any system you can’t fully audit internally within the first hour. A small business with no dedicated security team should not spend that first hour deciding whether to call someone; that decision should already be made as part of the plan, with a contract or retainer in place before anything happens.

This is the part most small business plans get backward. Companies wait until they’re mid-incident to look for a forensics firm, which means negotiating scope, price and onboarding while also trying to contain an active breach.

Cyber incident response (IR-1, via Blackpanda) gives you 24/7 incident responders and is included in every ShiftControl subscription, so the question of who to call is settled before an incident occurs, not during one.

When you do engage an outside firm, your Lead and External Liaison should already know:

  • What access the responders need (read-only admin access is usually a sensible starting point)

  • What they’re authorized to decide without asking you first (for example, isolating a compromised device)

  • How quickly they can be reached outside business hours

How Do You Test an Incident Response Plan Without Disrupting the Business?

A tabletop exercise tests the plan by walking through a hypothetical scenario out loud, without touching production systems. This is the cheapest and lowest-risk way to find gaps. You don’t have to write scenarios from scratch: CISA publishes Tabletop Exercise Packages that include ransomware and phishing scenarios, and the UK NCSC offers a free Exercise in a Box aimed at organizations including small and medium-sized businesses.

Run one twice a year, for 45 to 60 minutes:

  1. Pick a realistic scenario (a phishing email that led to a compromised account is the most common starting point for small businesses).

  2. Read the scenario to the whole team, including the Declarer, Lead, Communicator and External Liaison.

  3. Ask each person, in turn, what they do in the first 15 minutes, then the first hour.

  4. Note where people hesitate or disagree, since that’s where the written plan is unclear or missing a step.

  5. Update the one-page plan the same week, while the gaps are fresh.

The exercise works because it forces the plan off the page and into someone’s mouth. A plan that sounds complete on paper often falls apart the moment someone has to say, out loud, who they’d call first.

Frequently Asked Questions

Does a small business really need a formal incident response plan?

Yes. An incident is the worst time to decide who does what, and a one-page plan settles that in advance.

What’s the difference between an incident response plan and a security policy?

A security policy describes ongoing rules (password requirements, access reviews). An incident response plan is the specific, numbered sequence of actions taken once something has already gone wrong.

Do we need a lawyer involved in our incident response plan?

At minimum, identify who your External Liaison calls for legal advice before an incident, particularly for breach notification obligations under GDPR, Singapore’s PDPA or sector-specific rules. Under the PDPA, a notifiable breach must go to the PDPC no later than 3 calendar days after you decide it is notifiable.

How long should we keep Google Workspace audit logs?

Google Workspace retains most audit log types natively for around 6 months, though some log types differ. If your incident response or compliance needs require longer, export logs on a schedule rather than relying on the console’s default window. Export to BigQuery is available only in Enterprise Standard/Plus, Education Standard/Plus, Frontline Standard, Frontline Plus and Enterprise Essentials Plus editions.

What counts as a “critical” incident versus a lower-severity one?

Severity is generally judged by the potential for harm, the nature of the incident (whether data was destroyed, accessed or altered), the type of data affected and whether the incident is still ongoing or contained. Critical incidents, such as an active breach or a service outage, typically demand action within minutes to an hour, while lower-severity issues can be addressed on a longer timeline. Apply the same logic to your own incident log: tag each entry with a severity so your Lead can triage multiple simultaneous alerts.

Can incident response be automated?

Parts of it can. Removing a leaver’s Google Workspace access automatically closes one common gap before it becomes an incident.

Who should write the one-page plan?

Whoever would be the Lead in an actual incident. Writing it yourself, rather than outsourcing it to a template you never read again, is what makes it usable instead of decorative.

About ShiftControl

ShiftControl is purpose-built for Google Workspace, for companies that run IT without a dedicated IT team. Google Workspace access is set up and removed automatically when someone joins, moves or leaves, and everything else runs as a guided task list for the app owner. You can see every app and OAuth scope connected to your Workspace and track SaaS spend and renewals. You can also export app assignments and authorization history as audit evidence. Cyber incident response (IR-1, via Blackpanda) is included in every subscription. ShiftControl is SOC 2 Type 2 compliant, ISO 27001 certified and signed the CISA Secure by Design Pledge in 2024. Setup takes as little as 10 minutes with a Google Workspace admin sign-in.

Start a 14-day free trial, no credit card required.

References

  1. Incident Response Plan Template (cloud.google.com)

  2. How To Create An Incident Response Plan For Small Business (purplesec.us)

  3. Suspend a user temporarily (knowledge.workspace.google.com)

  4. Small Business Incident Response Plan (Template) (anushkadahanayake.com)

  5. What is an Incident Response Plan Template? - Palo Alto Networks (paloaltonetworks.com)

  6. Small Business Incident Response Plan (Template) - tekRESCUE (mytekrescue.com)

  7. Incident Response Plans: What to Include & Why They Matter | Huntress (huntress.com)

  8. Guide on Managing and Notifying Data Breaches under the PDPA (pdpc.gov.sg)

  9. Data retention and lag times (knowledge.workspace.google.com)

  10. Set up service log exports to BigQuery (knowledge.workspace.google.com)

  11. CISA Tabletop Exercise Packages (cisa.gov)

  12. Exercise in a Box (ncsc.gov.uk)

  13. Sign a user out of a managed Google Account (knowledge.workspace.google.com)

Get started

Experience SaaS management as it should be: straightforward management and robust security with ShiftControl.

Get started

Experience SaaS management as it should be: straightforward management and robust security with ShiftControl.

Company

Your privacy choices

© 2026 Shift Control Pte. Ltd. All rights reserved.

Company

Your privacy choices

© 2026 Shift Control Pte. Ltd. All rights reserved.

Company

Your privacy choices

© 2026 Shift Control Pte. Ltd. All rights reserved.