DEV Community: Runbook Foundry

How to Write an AI Acceptable Use Policy for Employees (With a Sample Outline)

Runbook Foundry — Wed, 21 Oct 2026 00:07:31 +0000

Your staff are already using AI tools. Someone is pasting meeting notes into a chatbot to get a summary. Someone else installed a browser extension that "writes better emails". A manager is asking an assistant to rank job applicants. None of this is necessarily bad, but without rules you have no idea which company data has gone where, and nobody knows what they're allowed to do.

An AI acceptable use policy (AUP) fixes that. It doesn't need to be long. The best ones fit on a page or two, use plain language, and answer the three questions employees actually have: Which tools can I use? What can I put into them? What am I still responsible for?

This guide walks through how to write one for a small or mid-sized organization, with examples and a short sample outline you can adapt.

Why a short policy beats a perfect one

Small businesses tend to stall on AI policy because it feels like it needs a lawyer, a committee and a risk framework. Those things help later. Right now, the biggest risks are simple and common:

Data leakage: confidential or personal data pasted into a consumer tool whose terms allow the provider to keep or train on it
Unchecked output: AI-drafted content sent to customers with wrong facts, made-up references or someone else's copyrighted text
Automated decisions about people: screening, scoring or disciplining staff or applicants with no human review
Shadow tools: extensions, plugins and "AI features" quietly switched on inside apps you already pay for

A clear one-page policy published this month addresses all four. You can build the fuller program (tool intake reviews, an AI inventory, vendor contract terms) over the following quarter.

Step 1: Decide who owns it

Pick one accountable owner. In a small business that's usually the IT lead, operations manager or whoever owns security. Name a second approver from HR or leadership. Write both into the policy header along with an effective date and a review date (at least annually; AI tools change fast, so six months is better).

Step 2: Inventory what people already use

Before writing rules, find out what's happening. A 10-minute anonymous survey works well:

Which AI tools have you used for work in the last month?
Are you signed in with a work account, a personal account or no account?
What do you use them for (drafting, summarizing, coding, research, images, meetings)?
Have you ever pasted customer, employee or financial information into one?
What would you like to use AI for but haven't, because you weren't sure it was allowed?

Pair it with a quick technical check: browser extensions on managed devices, OAuth apps connected to your email and file storage, and AI features enabled in your existing SaaS admin consoles. The answers will tell you which tools to approve, which to block and where the real data risk is.

Step 3: Define approved tools in tiers

A tiered model is easier for staff than a long allow/deny list:

Tier	What it means	Example
Approved for internal data	Company-licensed, signed in with a work account, with contract terms that say your data isn't used to train models	The assistant built into your company's office suite, if your plan's terms cover this
Approved for public data only	Fine for brainstorming or rewriting public information. No company or personal data.	A free chatbot used to draft a generic job ad
Not approved	Blocked or forbidden for company work	Unvetted browser extensions, apps that want access to your whole mailbox

Keep the actual list on a separate page (an intranet page or shared doc) and link it from the policy, so you can update tools without re-approving the policy.

Step 4: Write data rules people can apply in five seconds

This is the most important section. Tie it to the data categories you already use, or define simple ones:

Data type	Approved for internal data	Public-only tools
Public information (website copy, published docs)	Yes	Yes
Internal (non-sensitive notes, process docs)	Yes	No
Confidential (financials, contracts, strategy, source code)	Only if the tool is explicitly approved for it	No
Personal data (customer or employee details)	Only if the tool is explicitly approved for it	No
Credentials (passwords, API keys, tokens)	Never	Never

Add a tie-breaker: "When unsure, treat it as confidential and ask."

Worked examples help more than definitions. Include three or four:

✅ "Summarize these anonymized meeting notes" in the company assistant
✅ "Suggest five subject lines for this public product announcement" in any approved tool
❌ "Here's our customer export, find the churn risks" in a personal chatbot account
❌ "Debug this script" when the script contains a live API key

Step 5: Make humans accountable for output

AI output is a draft, not a source. The policy should say plainly:

You are responsible for anything you send, publish or act on, however it was produced.
Check facts, numbers, names and references before use. AI tools can confidently invent all four.
Check for bias, security problems (especially in generated code) and copied material.
AI must not make final decisions about people: hiring, performance, pay, discipline, credit or access. A person reviews and documents the decision.

Step 6: Be clear on transparency

Decide when people must disclose AI use. A practical rule: disclose when content is substantially AI-generated and it's customer-facing, published, legal, or the customer or contract requires it. Internal drafts usually don't need a label. Never present AI output as independently verified fact without checking it.

Step 7: List what's prohibited

Keep this short and concrete:

Creating deceptive, harassing, discriminatory or illegal content
Impersonating real people (voice, image or writing) without consent
Generating malware or trying to get around security controls
Recording or transcribing colleagues or customers without the notice and consent the law and your policies require
Using personal AI accounts for company work
Connecting AI tools or extensions to company email, files or systems without IT approval

Step 8: Say how to report problems

Mistakes will happen. Make it safe to report them quickly: "If you think you've put the wrong data into an AI tool, or you see unapproved AI use, tell [contact] right away. Reporting in good faith will not be held against you." That sentence does more for security than any monitoring tool.

Step 9: Exceptions, enforcement and acknowledgment

Exceptions: written approval from a named role, recorded with an expiry date.
Enforcement: point to your existing disciplinary process rather than inventing a new one.
Acknowledgment: a signature line or an e-sign step at the bottom. You'll want a record that people read it.

Sample AI acceptable use policy outline

Here is a short outline you can turn into a one- or two-page policy. Replace the bracketed fields.

Purpose and scope. Covers generative AI tools (chatbots, writing, coding, image and meeting assistants, and AI features inside existing apps). Applies to all employees, contractors and temporary staff on any device when company work or data is involved.
Approved tools. Use only tools on the Approved AI Tools list at [link], signed in with your company account. Request new tools, extensions or AI features from [contact] before use.
Data rules. The data table above, plus "never enter credentials" and "when unsure, treat as confidential."
Human review and accountability. You own the output. Verify before use. No final decisions about people without documented human review.
Transparency. Disclose substantial AI use in customer-facing, published or legal material, or where required.
Prohibited uses. The list from Step 7.
Security and incident reporting. Report data mistakes and unapproved use to [contact]. Good-faith reports are protected.
Exceptions and enforcement. Written exceptions from [role]. Violations handled under existing policies.
Ownership and review. Owner [name/role], approver [name/role], effective [date], next review [date].
Acknowledgment. Name, signature, date.

Rolling it out in two weeks

Week 1

[ ] Run the usage survey and the technical check
[ ] Draft the policy using the outline above
[ ] Publish the Approved AI Tools list (start with two or three tools)
[ ] Have HR and, ideally, legal counsel review it

Week 2

[ ] Leadership approves and announces it, ideally in a short all-hands slot rather than only by email
[ ] Collect acknowledgments
[ ] Turn off or restrict AI features and extensions that aren't on the approved list, using your admin consoles
[ ] Put a review date in the calendar

Afterwards: add a simple intake form for new tool requests, keep a list of the AI tools and features in use, and check that the contracts for your approved tools cover data use, retention and training the way you expect.

Common mistakes to avoid

Banning everything. People will use personal accounts anyway, and you lose visibility. Approve something useful.
Writing for lawyers. If staff can't apply it in five seconds, they won't.
Forgetting built-in AI. The biggest exposure is often an AI feature switched on by default in a tool you already use.
Publishing and walking away. Tools, terms and features change quarterly. Review the list at least that often.

This is general guidance, not legal advice. Have qualified counsel review your final policy, especially if you handle regulated data or operate in several jurisdictions.

Resources: Free 1-page AI acceptable use policy template · Full kit with a tool intake questionnaire, vendor AI clause checklist and NIST AI RMF workbook: AI Acceptable Use Policy Template + AI Governance Kit ($39; code LAUNCH30 takes 30% off paid kits through Oct 31, 2026). I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.

Google Workspace Security Audit: 25 Settings to Check Today (With Admin Console Paths)

Runbook Foundry — Tue, 20 Oct 2026 00:09:10 +0000

Most Google Workspace tenants at small businesses were set up in an afternoon, years ago, by whoever was handy. The defaults are reasonable, but "reasonable" leaves gaps: one super admin with SMS codes, mail forwarding open to anyone, Drive links shared with "anyone on the internet", and OAuth apps nobody remembers approving.

This is a read-first audit. Work through the 25 settings below, write down what you find, and only then decide what to change. Every path starts from the Google Admin console (admin.google.com) and was checked against Google's current admin help pages in October 2026. Google moves menus around, so if a path doesn't match, search the setting name in the console's search bar.

Before you start

Use a super admin account, but not your daily one if you can avoid it. Some settings below are visible only to super admins.
Record, don't fix. Make a simple sheet with four columns: Setting, Current value, Recommended, Action. Changes go through a pilot organizational unit (OU) first.
Know your OUs. Most settings can be applied per OU or per group. A setting can look right at the top level and be overridden for one department. Check the left-hand OU panel on each page.
Check your edition. A few items depend on edition. Where that matters, it's noted.

Admin accounts and sign-in (1 to 8)

1. How many super admins you have
Path: Account > Admin roles > Super Admin, then view the assigned admins.
Target: two to four named people. One is a single point of failure; ten means ten accounts that can take over the tenant. Use narrower prebuilt or custom roles for help desk work.

2. Super admins have separate admin-only accounts
Path: Directory > Users, open each super admin, then Admin roles and privileges.
Target: the super admin identity is not the same account used for daily email, browsing and chat. Daily accounts are the most phished.

3. Super admin self-recovery
Path: Security > Authentication > Account recovery > Super admin account recovery.
Target: a deliberate decision. Google recommends turning self-recovery off if you have several super admins who can help each other. If you leave it on, make sure each super admin's recovery phone and email belong to them and are current.

4. 2-Step Verification is allowed and enforced
Path: Security > Authentication > 2-step verification.
Target: "Allow users to turn on 2-Step Verification" checked, and Enforcement set to On (or "Turn on enforcement from date") for every OU. Set a short new-user enrollment period, such as one to two weeks. Google is also enforcing 2SV for administrator accounts.

5. Phishing-resistant 2SV for admins
Path: same page, select the OU or group that holds your admins, then Methods.
Target: "Only security key". Google's help notes that this option now accepts passkeys as well as hardware keys. Check who has keys enrolled first (Reporting > User Reports > Security) so you don't lock anyone out, and generate backup codes for emergencies.

6. Passkeys allowed
Path: Security > Authentication > Passwordless > Skip passwords.
Target: "Allow users to skip their password and authenticate with a passkey" checked, at least for a pilot OU. Passkeys are phishing-resistant and usually easier for staff than codes.

7. Password policy
Path: Security > Authentication > Password management.
Target: enforce strong passwords, a minimum length of at least 12 characters, "Enforce password policy at next sign-in" checked, and password reuse not allowed. Avoid forced periodic expiry, which tends to produce weaker passwords.

8. Web session length
Path: Security > Access and data control > Google session control.
Target: a defined session duration rather than "never expires", for example 12 to 24 hours for most users and shorter for admins. Shorter sessions limit the value of a stolen session cookie.

Email (9 to 16)

9. SPF, DKIM and DMARC
Path for DKIM: Apps > Google Workspace > Gmail > Authenticate email. SPF and DMARC live at your DNS host.
Target: DKIM generated and authenticating for every sending domain (2048-bit where your DNS host allows it). One valid SPF record per domain. A DMARC record that moves from p=none with reporting to p=quarantine or p=reject once legitimate senders are aligned.

10. Enhanced pre-delivery message scanning
Path: Apps > Google Workspace > Gmail > Spam, Phishing and Malware.
Target: enhanced pre-delivery scanning turned on. It lets Gmail take a little longer to catch phishing before it reaches the inbox.

11. Attachment protections
Path: Apps > Google Workspace > Gmail > Safety, then Attachments.
Target: protection against encrypted attachments, attachments with scripts and anomalous attachment types turned on, with an action stronger than the default warning (spam or quarantine). Check "Apply future recommended settings automatically".

12. Link and external image protections
Path: Apps > Google Workspace > Gmail > Safety, then Links and external images.
Target: identify links behind shortened URLs, scan linked images, warn on clicks to untrusted domains, and apply future recommended settings automatically.

13. Spoofing and authentication protections
Path: Apps > Google Workspace > Gmail > Safety, then Spoofing and authentication.
Target: all five protections on (similar domain names, employee name spoofing, inbound mail spoofing your domain, unauthenticated mail, and Groups protection). These directly reduce invoice and CEO-fraud email.

14. Automatic forwarding
Path: Apps > Google Workspace > Gmail > End User Access, then Automatic forwarding.
Target: "Allow users to automatically forward incoming email to another address" unchecked for most OUs. Attackers set up forwarding to quietly copy a mailbox after a takeover. Allow it only for OUs with a documented need.

15. POP and IMAP access
Path: Apps > Google Workspace > Gmail > End User Access, then POP and IMAP access.
Target: off, unless an OU has a documented client that needs it. Older mail clients are a common way around modern sign-in protections.

16. External recipient warning
Path: Apps > Google Workspace > Gmail > End User Access, then the external recipient warning setting.
Target: on. It catches misaddressed email and replies to look-alike domains.

Sharing and collaboration (17 to 19)

17. Drive external sharing
Path: Apps > Google Workspace > Drive and Docs > Sharing settings > Sharing options.
Target: external sharing either off or limited to allowlisted domains for sensitive OUs. Where it stays on, warn users when sharing outside the organization and don't let files be published to the web without review. Then review what's already shared publicly. Settings stop new exposure but don't fix the old.

18. Calendar external sharing
Path: Apps > Google Workspace > Calendar > Sharing settings.
Target: external sharing of primary calendars set to "Only free/busy information". Full details leak meeting titles, dial-ins and who reports to whom.

19. Groups for Business sharing
Path: Apps > Google Workspace > Groups for Business > Sharing settings.
Target: external access to groups restricted by default, and group owners not able to let people outside the organization join. Then check that no group lets "anyone on the web" view or post.

Apps, API access and AI (20 to 23)

20. Third-party app access (OAuth)
Path: Security > Access and data control > API controls, then Manage App Access and Settings.
Target: review every app with access to Gmail, Drive or admin data, and mark each one Trusted, Limited or Blocked on purpose. Under Settings, decide what users can do with unconfigured third-party apps. Restricting access to high-risk Google data such as Gmail and Drive is a strong default.

21. Domain-wide delegation
Path: Security > Access and data control > API controls > Manage Domain Wide Delegation.
Target: every client ID has a known owner, a current purpose and the minimum scopes. Delete anything nobody can explain. Domain-wide delegation lets a service act as any user, so treat it as a crown-jewel credential.

22. Marketplace app installs
Path: Apps > Google Workspace Marketplace apps > Apps list > User Install Settings.
Target: "Allow users to install and run only selected apps" (allowlisted apps), with a simple request process for new ones.

23. Gemini and AI access
Path: Generative AI > Gemini app.
Target: access turned on only for the OUs or groups your AI acceptable use policy covers. Make sure staff know which AI tools are approved and what data they may use with them. Tidy your Drive sharing (item 17) first, because AI assistants can surface whatever a user already has access to.

Devices, data and monitoring (24 and 25)

24. Mobile device management
Path: Devices > Mobile & endpoints > Settings > Universal > General > Mobile management.
Target: at least Basic management, with a screen lock required, so you can sign a lost phone out of company data. Use Advanced where your edition supports it and you need device approval or full wipe.

25. Takeout and alerting
Paths: Data > Data import & export > Google Takeout and Security > Alert center.
Target: Google Takeout turned off for departing-user and sensitive OUs, so a leaver can't bulk-download their mailbox and Drive. In the Alert center, make sure alerts such as suspicious login, leaked password, government-backed attack and super admin changes reach a mailbox someone actually reads. An alert nobody sees isn't an alert.

Scoring your audit

Give each item a status: OK, Gap, or Accepted risk (with a reason and an owner). Then sort the gaps:

This week: 1, 4, 5, 9, 13, 14, 20. These close the most common account takeover and business email compromise paths.
This month: 2, 3, 7, 11, 12, 15, 17, 21, 25.
This quarter: everything else, plus a review of existing public Drive shares.

Making changes safely

Pilot first. Create a "Pilot-Security" OU with IT and one or two willing staff. Apply the change there and wait a few days.
Communicate before enforcing. Tell people what's changing, when, and what they need to do (for example, enroll a passkey before the 2SV date).
Have a way back in. Keep at least one tested super admin with a hardware key stored securely before you tighten admin 2SV.
Write it down. Log the date, the setting, the old value and the new value. When something breaks next month, the change log is the first place you'll look.
Re-audit quarterly. Google adds new settings, staff change and exceptions creep back in.

Resources: Free M365 + Google Workspace hardening checklist · Full 82-control version with a scored workbook and read-only GAM scripts: Google Workspace Security Audit Checklist ($39; code LAUNCH30 takes 30% off paid kits through Oct 31, 2026). I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.

What % of top domains are spoofable in October 2026?

Runbook Foundry — Mon, 19 Oct 2026 23:56:46 +0000

Anyone can put your domain in the From: line of an email. Whether receiving servers believe it comes down to a few DNS records, and DMARC is the one that tells them what to do when a message fails authentication.

So I wanted to know: among the most-linked domains on the web, how many still leave that door open?

Short answer: 27.9%. Of 974 domains we could audit from the Majestic Million top 1,000, 272 publish no DMARC record, publish one with p=none, or publish an invalid record. A policy of none asks receivers to do nothing.

Method

Source list: the Majestic Million top 1,000 by GlobalRank, downloaded on October 19, 2026. This is a one-day snapshot.
Attribution (CC BY 3.0): "Majestic Million" by Majestic (https://majestic.com/reports/majestic-million), licensed under the Creative Commons Attribution 3.0 Unported License. Domains were normalized; no other changes were made to the list.
Checks: passive DNS lookups (DMARC, SPF, MX, a set of common DKIM selectors, MTA-STS, TLS-RPT, BIMI) and one HTTPS request per domain. Nothing was sent to any mailbox and nothing was probed.
Coverage: 20 of the 1,000 entries are public suffixes rather than registrable domains, so they were skipped. Of the remaining 980, 974 resolved cleanly. One returned NXDOMAIN and five returned DNS errors. All percentages below are of those 974.
"Spoofable" means the effective DMARC policy isn't enforced: the record is missing, says p=none, or is invalid. Subdomains are judged by the policy they inherit from their organizational domain (sp= or p=).

Every figure was recomputed from the per-domain CSV with a short Python script. This post only reports aggregates, and no individual domains are named.

Findings

DMARC policy distribution

Effective policy	Domains	Share
reject	517	53.1%
quarantine	185	19.0%
none	165	16.9%
missing	107	11.0%

The good news first: 72.1% enforce DMARC, and most of them have gone all the way to reject. Among the biggest sites on the web, enforcement is now the norm.

The other 27.9% matters, though. These domains are heavily linked, widely recognized, and exactly what a phisher wants to put in a From: header.

Spoofable share by mail provider

We classified each domain by its MX records.

Provider (from MX)	Domains	Spoofable
Google Workspace	270	18.1%
Microsoft 365	161	20.5%
Proofpoint	93	17.2%
Mimecast	26	19.2%
Other / self-hosted	253	40.7%
None (no MX or null MX)	165	38.2%

(Zoho had only 6 domains, too few to chart.)

The pattern: domains on a major hosted platform or a secure email gateway are spoofable about 17-21% of the time. Domains on other or self-hosted mail are about twice as likely (40.7%). The provider doesn't set your DMARC policy for you, but the big platforms' admin consoles, setup wizards, and bulk-sender documentation all push toward it.

The "no MX" group is easy to overlook. A domain that never receives mail can still be impersonated in outbound mail. Parked and non-mail domains should publish v=spf1 -all and p=reject. It takes two TXT records and costs nothing.

The rest of the stack

No SPF record: 151 domains (15.5%). Another 10 (1.0%) go over SPF's 10-DNS-lookup limit, which makes evaluation return a permanent error.
SPF ending: -all 45.5%, ~all 35.4%, ?all 3.2%.
MTA-STS in enforce mode: just 15 domains (1.5%). TLS-RPT: 51 (5.2%). Encrypting mail in transit with downgrade protection is still rare.
BIMI with a logo: 150 (15.4%), 108 of which reference a mark certificate.
Average posture score: 62.3 / 100 on the audit's composite scale. Grade distribution: A 82, B 332, C 304, D 139, F 117.

Why p=none isn't protection

p=none is monitoring mode. It tells receivers: "If a message claiming to be from me fails SPF and DKIM alignment, deliver it anyway, and send me a report." That's a useful first step, because the reports show you every service that sends mail as your domain. But it's a step, not a destination.

To a phisher, a domain at p=none is effectively the same as a domain with no record. Receivers may still apply their own heuristics, but you've explicitly opted out of telling them to reject forgeries. 165 domains in this list (16.9%) are in that state.

The bulk-sender rules changed the baseline

The big mailbox providers now set a minimum for high-volume senders:

Gmail (Email sender guidelines): since February 1, 2024, anyone sending more than 5,000 messages a day to personal Gmail accounts needs SPF and DKIM, a DMARC record ("your DMARC enforcement policy can be set to none"), and a From: domain aligned with SPF or DKIM. Marketing and subscribed mail must support one-click unsubscribe and show a visible unsubscribe link. Spam rates in Postmaster Tools must stay below 0.30%, and Google recommends staying under 0.10%.
Yahoo (Sender Hub requirements): enforcement began in February 2024 and rolled out gradually. Bulk senders need SPF and DKIM, a valid DMARC policy of "at least p=none" that passes with an aligned From: domain, one-click unsubscribe (RFC 8058 POST recommended) honored within 2 days, and a spam rate below 0.3%. Yahoo doesn't publish a fixed volume threshold.
Microsoft (Outlook.com high-volume sender announcement, April 2025): domains sending more than 5,000 emails a day to Outlook.com, Hotmail.com and Live.com addresses must pass SPF and DKIM and publish DMARC of at least p=none, aligned with SPF or DKIM, from May 5, 2025; non-compliant mail goes to Junk at first, with later rejection (550 5.7.515). Unsubscribe links and list hygiene are listed as recommended practices rather than hard requirements, and no specific spam-rate limit is set.

Note the bar: p=none is enough to comply at all three. These rules got almost everyone to publish DMARC, which may be why only 11.0% of this list has no record at all. They didn't make anyone enforce it. Compliance and protection are two separate milestones.

A step-by-step DMARC rollout

Moving to enforcement is mostly an inventory exercise. Here's a sequence that rarely breaks legitimate mail:

Inventory senders. List everything that sends as your domain: your mail platform, marketing tools, CRM, ticketing, billing, HR systems, and any servers that send alerts.
Fix SPF. One record that includes only the services you actually use, under 10 lookups, ending in ~all for now (-all once you're confident).
Turn on DKIM everywhere. Use 2048-bit keys where you can, signing with your domain (aligned) rather than the vendor's.
Publish p=none with reporting: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.example; fo=1 Send aggregate reports to a mailbox or a DMARC report analyzer.
Watch for 2-4 weeks. Every legitimate source should pass aligned SPF or DKIM. Fix the ones that don't.
Move to p=quarantine, optionally ramping with pct=25, then 50, then 100. Keep reading reports.
Move to p=reject, and set sp=reject unless subdomains need their own policies.
Keep reporting on. New SaaS tools show up all the time, and the reports are how you catch them before they break.
Extras: v=spf1 -all plus p=reject on every non-mail domain, then MTA-STS and TLS-RPT for transport security.

Limitations

DKIM can't be fully enumerated. DNS doesn't let you list selectors. The audit checks a set of common ones, so "DKIM not found" doesn't prove DKIM is missing, and we deliberately left DKIM out of the headline.
A snapshot is not a verdict. This is public DNS as of October 19, 2026. Records change daily, and a domain at p=none may be partway through a planned rollout.
Spoofable ≠ spoofed. We measured policy, not abuse. Receivers also apply their own reputation filtering.
Provider detection is MX-based. A domain can receive mail through one service and send through several others.
The top 1,000 by links isn't the whole internet. Long-tail domains may look different.

Resources

DMARC specification: RFC 7489
Majestic Million: majestic.com/reports/majestic-million (CC BY 3.0)

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft, Google or Yahoo.

How to Run a Ransomware Tabletop Exercise for a Small Business in 90 Minutes

Runbook Foundry — Mon, 19 Oct 2026 02:52:45 +0000

Most small businesses have some kind of incident response plan. Far fewer have ever said it out loud with the people who would actually use it. A tabletop exercise fixes that. You get the owner, the office manager, whoever handles IT (in-house or MSP) and the person who talks to customers into one room, read them a realistic ransomware story one piece at a time, and write down every place where they hesitate.

You don't need a consultant, a lab or a full afternoon. This guide shows you how to run one in 90 minutes, and it includes a complete sample scenario you can use as-is.

What a tabletop is (and what it isn't)

A tabletop exercise is a facilitated discussion. Nobody touches production systems. The facilitator presents an "inject", a new development in the story, and the group talks through what they would do, who decides, and how they would know.

It is:

A safe, no-blame way to test plans, decision rights and contact lists
Cheap evidence that you practice, which insurers, auditors and larger customers increasingly ask about
A source of a short, prioritized list of fixes

It isn't:

A test of individuals or a performance review
A penetration test or a live restore
Finished when the meeting ends. The fixes are the point.

Before the session: 30 minutes of prep

1. Pick a sponsor. The owner or a senior manager opens the session and receives the findings. Without a sponsor, people skip it or treat it as an IT meeting.

2. Pick 5 to 8 participants. For a small business that usually means:

Owner or general manager (business decisions, payments, legal contact)
IT lead or MSP contact (technical response)
Finance or bookkeeping (payroll, invoicing, bank contacts)
Office or operations manager (staff communication, phones, facilities)
Whoever handles customers or marketing (external messages)

3. Assign three roles that aren't players:

Facilitator: reads injects, asks questions, keeps time. Ideally someone who won't be answering.
Scribe: records decisions, owners, open questions and gaps.
Timekeeper: can be the facilitator, but a visible timer helps.

4. Gather what people would really reach for: the incident response plan (even if it's two pages), the cyber insurance policy and its claims hotline, the list of critical systems, backup details, and the staff and vendor contact list. Print them. If something doesn't exist, that's your first finding.

5. Tailor the scenario. Replace the bracketed names below with your real systems. A scenario that says "the file server" lands better when it says "the Q: drive on SRV-01".

The 90-minute agenda

Time	Segment
0:00 to 0:05	Sponsor welcome, purpose, ground rules
0:05 to 0:10	Scenario setup and starting assumptions
0:10 to 1:10	Four injects, about 15 minutes each
1:10 to 1:25	Hot wash: what worked, what didn't, top fixes
1:25 to 1:30	Owners, dates and close

Read these ground rules aloud at the start:

No fault, no blame. We are testing the plan, not people.
Answer with the tools, people and authority you have today, not what you wish you had.
Decisions don't have to be perfect. Make a call and say why.
Don't fight the scenario. If a detail doesn't fit, we'll adjust it and move on.
Findings are reported without names attached.

Free sample scenario: "The Friday Invoice"

This scenario is written for a 10 to 50 person business using a cloud email suite, a shared file server or NAS, and an accounting system. Adjust the details to fit.

Starting assumptions (read aloud): It's an ordinary Friday. The office closes at 5 p.m. Backups run nightly. The IT person or MSP is reachable by phone. Nobody has reported anything unusual this week.

Inject 1: Friday, 4:40 p.m.

The bookkeeper mentions that an "invoice" email from a regular supplier had a link that opened a page asking her to sign in again. She did, then the page went blank. She shrugged and went back to work. Ten minutes later, two staff report that files on the shared drive have strange extensions and won't open.

Discussion questions:

Who is the first person told, and how? Who is told second?
What is the very first technical action? Who is allowed to take it?
Do we disconnect anything right now? What exactly, and who decides?
The bookkeeper's account may be compromised. What do we do with it in the next 15 minutes?

What good looks like: someone clearly owns the call to isolate affected machines. The suspected account gets its password reset and its sessions revoked. Somebody starts a written timeline. The IT contact is reached by phone, not email.

Inject 2: Friday, 6:15 p.m.

A ransom note appears on the file server and on three desktops. It claims the attackers copied "all finance and HR data" and will publish it in 72 hours unless paid. The office is closed and most staff have gone home.

Discussion questions:

Who do we call now: the insurer's hotline, a breach coach, an incident response firm, the police? In what order? Where are those numbers written down?
Does anyone have the authority to engage outside help that costs money tonight?
Who decides whether paying is even on the table, and who must be consulted first?
What do we tell staff who will arrive on Monday?

What good looks like: the insurer is contacted early, because many policies require notice and sometimes require using approved vendors. Nobody contacts the attackers without legal and insurer guidance. Evidence is preserved rather than wiped in a rush to rebuild.

Inject 3: Saturday, 10:00 a.m.

The IT lead reports that last night's backup job ran at 11 p.m., after the encryption started, and the backup target was a network share that is now encrypted too. The cloud backup has a copy from Thursday night, but nobody has ever restored more than a single file from it.

Discussion questions:

How long would a full restore from the Thursday copy take? Has anyone ever measured it?
What do we restore first? Who decided that order, and is it written down?
Which systems can the business live without for a week? Which ones for a day?
How do we make sure we aren't restoring onto machines the attacker still controls?

What good looks like: the group agrees on a recovery order based on business impact, such as accounting, email and then file shares. Someone notes that restore time is unknown and adds a test restore to the action list. Rebuilding is held until the entry point is understood.

Inject 4: Monday, 8:30 a.m.

A customer calls the front desk. They received an email from your bookkeeper's address asking them to update the bank details for your invoices. A local reporter has also emailed asking for comment about "a data leak".

Discussion questions:

Who speaks for the company, and what do they say? Is a holding statement ready?
How do we warn customers about the fraudulent bank-details request without causing panic?
Who checks whether any payments were already redirected?
Do we have notification obligations to customers, employees or regulators? Who would know?

What good looks like: one spokesperson. A short holding statement that says only what is known and avoids claims you can't support yet, such as "no data was accessed". A call to the bank. A plan to contact legal counsel about notification duties.

Sample holding statement (adapt it and have counsel approve before use):

"[Company] is responding to a cybersecurity incident affecting some of our systems. We acted quickly to contain it and are working with specialists to restore services safely. If you receive any request to change our payment details, please call us on a number you already have before acting. We will contact anyone directly affected."

Facilitation tips that make the difference

Read, then wait. Silence is uncomfortable. Let it work. Don't answer your own questions.
Push for specifics. "Who exactly? How would you reach them at 9 p.m. on a Friday? Where is that number written?"
Add friction if it's too easy. "The IT person is on a flight." "The owner's phone is the compromised device."
Bring quiet people in. Ask finance and the front desk directly. The best findings often come from them.
Park rabbit holes. Write deep technical debates on a parking-lot list and move on.

The hot wash (15 minutes)

Ask these five questions and have the scribe capture the answers:

What worked well that we should keep?
Where did we hesitate, and why?
What information did we need but couldn't find?
Which decisions had no clear owner?
If this happened tomorrow, what one thing would we want fixed first?

Turning findings into action

The exercise is only worth the fixes it produces. Within a week, write a one-page after-action summary:

Date, scenario and participants (roles, not names, if you prefer)
Top 3 to 5 findings, each written as a gap: "No one knew the insurer's claims hotline number."
One action per finding, with an owner and a due date
When you'll check progress, for example at 30 and 90 days

Typical first-exercise actions for small businesses:

[ ] Print an emergency contact sheet (IT, MSP, insurer hotline, bank, counsel) and store it offline
[ ] Do a full test restore of one critical system and time it
[ ] Keep at least one backup copy that is offline or immutable, not just a network share
[ ] Write down who can approve emergency spending and engage outside responders
[ ] Prepare a holding statement and name one spokesperson
[ ] Add a "call to confirm" rule for any change to payment details
[ ] Turn on multi-factor authentication for every email account, starting with finance and admins

Run another exercise in six months with a different scenario, such as a compromised cloud account or a supplier outage. Compare your scores. Getting better is the evidence.

Resources: Free M365 + Google Workspace hardening checklist · Full kit with 3 scenarios, a slide deck and an after-action template: Ransomware Tabletop Exercise Template ($49; code LAUNCH30 takes 30% off paid kits through Oct 31, 2026). I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.