This post walks through a workflow that runs every Monday, keeps the entries added in the previous week (Mon-Sun), stars the vendors you actually run, and emails your team an HTML digest. You can build it from the steps below, or get the finished one free: download page with setup notes or the raw workflow JSON.

The feed

https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

It returns one object with catalogVersion, count and a vulnerabilities array (1,758 entries in catalog 2026.10.26). Each entry has the fields you need for a digest:

The data is CC0 1.0. Credit CISA and don't imply endorsement.

The workflow

Nine nodes, all core (plus sticky notes):

1. Every Monday 08:00 (Schedule Trigger) → Flag: live run (Code: return [{json:{_dryRun:false}}])
2. Test workflow (manual) (Manual Trigger) → Flag: dry run (Code: return [{json:{_dryRun:true}}])
3. Both flags → Download CISA KEV feed (HTTP Request, GET, 30 s timeout)
4. Filter & build digest (Code)
5. Dry run? (IF on _dryRun) → true: Dry run: log only (No Op); false: Email digest (Send Email, SMTP, HTML)

Time zone: the 08:00 trigger uses the workflow's time zone (Settings > Timezone). The workflow JSON doesn't set one, so it falls back to the instance's GENERIC_TIMEZONE, which defaults to America/New_York (self-hosted; on n8n Cloud the default is the owner's detected time zone, or GMT). The week window doesn't use that time zone: the Code node compares CISA's date-only dateAdded with the run's UTC date. If you're more than 8 hours ahead of UTC (for example Tokyo, Sydney or Auckland), Monday 08:00 local is still Sunday in UTC, so each digest covers Sunday to Saturday and says "from to ". To get Mon-Sun there, set the trigger hour to at least your UTC offset, rounded up, using your summer offset if you have daylight saving.

The Code node

This is the core of it, trimmed for the post:

const WATCHLIST = ['microsoft','google','apple','fortinet','citrix','ivanti','atlassian','oracle','adobe','apache'];
const LOOKBACK_DAYS = 7; // keep 7 for the weekly Monday schedule

const feed = $input.first().json;
const vulns = Array.isArray(feed.vulnerabilities) ? feed.vulnerabilities : [];
if (!vulns.length) throw new Error('KEV feed returned no vulnerabilities; check the URL or network.');

// dateAdded is date-only (YYYY-MM-DD), so compare UTC date strings, not timestamps.
const day = d => d.toISOString().slice(0,10);
const end = day(new Date());                                   // exclusive: today's additions go into next week's digest
const start = day(new Date(Date.now() - LOOKBACK_DAYS*864e5)); // inclusive

const recent = vulns
  .filter(v => typeof v.dateAdded === 'string' && v.dateAdded >= start && v.dateAdded < end)
  .map(v => ({ ...v, watch: WATCHLIST.includes(String(v.vendorProject).toLowerCase()) }))
  .sort((a, b) => (b.watch - a.watch) || (a.dueDate > b.dueDate ? 1 : -1));
// ...then build an HTML table from `recent` (escape every field) and return
// { newCount, watchHits, html } for the email node.

Three details matter:

• Compare date strings, not timestamps. dateAdded has no time, so new Date('2026-10-23') is midnight UTC. My first version compared it to Date.now() minus seven days, and anything CISA added on a Monday after the run had aged out by the next Monday, so it was never reported. With string comparison and today excluded, a Monday run covers the previous Monday through Sunday (UTC dates), exactly once.
• Fail loudly on an empty feed. A network hiccup that returns nothing shouldn't produce a cheerful "no new entries" email.
• Escape everything you put into the HTML. The feed is trusted, but escaping is cheap.

The email

Subject: =Weekly KEV patch digest: {{ $json.newCount }} new ({{ $json.watchHits }} on watchlist). Body: ={{ $json.html }}, in HTML format. A week with no additions still sends a short "No new KEV entries added in the previous week (Mon-Sun, to )." email, so silence always means something broke.

Tip: link each CVE in the table to an explainer page so readers don't have to search. KEV Explained has a plain page for every KEV entry at https://kev-explained.pages.dev/cve/<CVE-ID>/, with the required action, due date and links to NVD and the vendor advisory.

Three things that bit me

1. isExecuted is not a reliable dry-run switch. My first version checked $('Test workflow (manual)').isExecuted before sending. That's fine when you click Test in the editor. But n8n execute on the CLI started from the schedule trigger and the email went out. Separate flag nodes per trigger plus an IF node are explicit and easy to see on the canvas.
2. Expressions need the leading =. If you edit the workflow JSON by hand, a subject like Weekly digest: {{ $json.newCount }} is sent literally. It has to be =Weekly digest: {{ $json.newCount }}.
3. Vendor names are CISA's, not yours. Matching is on lowercase vendorProject. Microsoft, Fortinet and Ivanti are what you'd guess, but PHP shows up as both PHP and PHP Group. Run a quick jq -r '.vulnerabilities[].vendorProject' known_exploited_vulnerabilities.json | sort -u on the feed before you fill in the watchlist.

Want it daily? (untested sketch)

Untested sketch: switch the Schedule Trigger to a Days interval; split the Code node so it returns one item per CVE; add a Remove Duplicates node (Operation: Remove Items Processed in Previous Executions → Keep Items Where: Value Is New → Value to Dedupe On: cveID); then build the HTML in a second Code node. I haven't tested this; run it alongside the weekly one first.

Testing it

On self-hosted n8n 2.44.7, against the live feed (catalog 2026.10.26), a test copy with the clock pinned to Monday Oct 26 found 8 entries added Oct 19-25 (6 dated Oct 20, 2 dated Oct 23) and sent its digest to a local test mail server. The same test with the clock pinned to Monday Nov 2, on self-hosted n8n against the same feed, picks up the 2 entries dated Oct 26, which the Oct 26 run correctly left out. I haven't tested it on n8n Cloud or n8n 1.x.

Before you activate it:

• Set the workflow time zone.
• Attach an SMTP credential and replace the placeholder recipient.
• Click Test workflow and check the Code node output.
• Run it once from the schedule trigger to a test mailbox, then activate it.

Ideas to extend it

• Add EPSS scores with a second HTTP Request to FIRST's API, and sort by them within the watchlist.
• Send to Teams or Slack instead of email.
• Open a ticket for each watchlist hit, with the CISA due date as the deadline.

If you'd rather not build the related workflows yourself, this digest is also one of six workflows in the n8n IT-Ops Bundle ($59, paid; I make it). The bundle also has ticket triage, TLS expiry alerts, offboarding, backup-failure alerts and SaaS app review, each with a dry-run mode.

I built this workflow for Runbook Foundry; the full JSON is free at the link above. Drafted with AI assistance; test-run on self-hosted n8n 2.44.7.

Not affiliated with n8n GmbH or CISA. Not tested on n8n Cloud. n8n is a trademark of n8n GmbH. KEV data: CISA Known Exploited Vulnerabilities Catalog, CC0 1.0; use does not imply endorsement by CISA or DHS.

Offboarding gaps are rarely clever. An account stayed active, a phone kept syncing mail, or a shared password never changed. A short checklist that runs in the same order every time closes those gaps, and it leaves a dated record you can show if an auditor, insurer or customer asks.

This guide covers what to do before, on and after the last day in Microsoft 365 and Google Workspace.

Order matters: transfer, then cut, then clean up

If you disable an account first, you can lose access to the files, mailbox and app ownership you still need. If you wait too long, the person keeps access. Use this order:

1. Inventory what they can reach (identity, SaaS, devices, shared secrets).
2. Transfer data and ownership you need to keep.
3. Cut access at a set time, with sessions revoked.
4. Clean up licenses, devices, and shared credentials, and record evidence.

For a hostile or high-risk exit, swap steps 2 and 3. Cut access first and recover data as an admin afterward.

Before the last day (T-5 to T-1)

• Get the exit date and time from HR in writing, and say whether it is planned or immediate.
• List every system the person uses. Start with the identity provider's app assignments, then ask their manager about anything outside SSO: payroll, banking, the domain registrar, social accounts, vendor portals.
• Find what they own: shared drives, Teams or Groups, calendars, scheduled flows or Apps Script, forms, and any OAuth apps they authorized.
• Note shared credentials they knew (Wi-Fi, alarm codes, password-manager shared folders) so you can rotate them.
• Arrange device return and decide whether to keep or wipe each device.

On the last day: Microsoft 365

1. Reset the password and choose Sign out of all sessions (Microsoft 365 admin center > Users > Active users > select user). Microsoft notes that blocking sign-in can take time to take effect, so resetting the password is the fast step (Microsoft Learn).
2. Block sign-in on the same user page.
3. Revoke refresh tokens if you script it: Revoke-EntraUserAllRefreshToken and Set-EntraUser -AccountEnabled $false (Microsoft Learn).
4. Remove MFA methods and registered devices so a cached authenticator can't be reused.
5. Convert the mailbox to shared or set forwarding to the manager, and add an auto-reply if customers email this person.
6. Transfer OneDrive access to the manager before the license is removed. Deleted users' OneDrive has a retention window, so don't leave this for later.
7. Remove the user from groups, Teams ownership and admin roles.
8. Wipe or retire devices in Intune, or collect them.

On the last day: Google Workspace

Google's own checklist covers the core steps (Google Workspace Admin Help):

1. Change the password and reset sign-in cookies (Admin console > Directory > Users > select user > Security).
2. Revoke app passwords, security keys and OAuth tokens on the same Security panel.
3. Remove recovery email and phone so password recovery can't be used.
4. Suspend the user while you transfer data.
5. Transfer Drive and Calendar ownership (Admin console > Account > Data transfer), then delete the account or keep it as an archived user.
6. Wipe or remove the account from managed mobile devices.

Everything outside SSO

This is where most gaps live. For each app on your inventory, record who removed the account, when, and how you checked it. Pay special attention to:

• Finance: bank portals, payment processors, expense tools
• Your domain registrar and DNS host
• Social media and ad accounts
• Shared password-manager folders (rotate any secret they could see)
• API keys, service accounts and automation they created

After the last day (T+1 to T+30)

• Check sign-in logs for the account over the following week.
• Remove licenses once data transfer is confirmed.
• Close out the ticket with evidence: screenshots or log extracts of disabled accounts, device wipe confirmations, and the list of rotated credentials.
• Add anything you missed to the template so the next offboarding is faster.

Make it repeatable

A one-off list helps once. A template that HR starts and IT completes helps every time. If you want this as an editable template, the IT Offboarding Checklist + User Access Review Template ($15) includes a 4-page offboarding checklist in Word, an Excel tracker that records each leaver, step owner and completion date, and a 300-row user access review workbook, written for Microsoft 365 and Google Workspace. I make these templates.

Common mistakes

• Disabling before transferring files, mailbox or automation ownership.
• Forgetting sessions. A password reset without session revocation leaves signed-in apps working.
• No owner for non-SSO apps. Assign each one to a named person with a deadline.
• No record. If you can't show what was done and when, it didn't happen as far as an auditor is concerned.

This is general guidance. Check your own legal, HR and data-retention requirements before deleting accounts or data.

Resources: Free IT offboarding checklist. I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with, endorsed by, or sponsored by Microsoft or Google. Microsoft 365, Entra and Intune are trademarks of Microsoft; Google Workspace is a trademark of Google LLC.

Conditional Access is the most useful security control in a Microsoft 365 tenant and the easiest one to lock yourself out with. One badly scoped "block" policy can stop every admin from signing in, including you.

The answer isn't to avoid it. It's to build a small, boring baseline, test each policy in report-only mode, and only then switch it on. This guide covers which policies to start with in a small tenant (roughly 5 to 300 users), how to read the report-only results, and a rollout order that doesn't wreck anyone's Monday.

Menu paths and recommendations were checked against Microsoft Learn in October 2026. Microsoft renames things often, so treat the docs as the source of truth if a label has moved.

Prerequisites

Licensing. Conditional Access needs Microsoft Entra ID P1, which is included in Microsoft 365 Business Premium and E3/E5. Risk-based policies need P2. If you only have the free tier, use security defaults instead. They give you MFA registration, admin MFA, legacy authentication blocking and device code flow blocking with no configuration.

Security defaults vs Conditional Access. You can't run both. Microsoft's guidance is that organizations replacing security defaults with Conditional Access must turn security defaults off (Entra ID > Overview > Properties > Manage security defaults), and should then turn on Conditional Access policies straight away so there's no gap. Plan that switch for a quiet time and have your policies ready first.

Check for Microsoft-managed policies. Open Entra ID > Conditional Access > Policies and look at the Created by column. Microsoft creates some policies in your tenant in report-only mode, for example MFA for all users, MFA for admins accessing admin portals, blocking legacy authentication and blocking device code flow. According to Microsoft Learn, they're switched on no less than 30 days after they're introduced unless you turn them off, and you'll get email and Message center notice two weeks before. Know what's there so nothing surprises you, and add your emergency access exclusions to them too.

Role. You need at least the Conditional Access Administrator role to create policies.

Step 0: Emergency access accounts

Do this before anything else. Microsoft recommends two or more emergency access ("break-glass") accounts:

• Cloud-only accounts on your *.onmicrosoft.com domain, not synced or federated
• Permanently assigned Global Administrator
• Protected with a passkey (FIDO2) or certificate-based authentication, using a different method from your normal admin accounts
• Credentials stored securely, in separate locations, and not tied to one person's phone
• Sign-in alerts set up, so any use is noticed
• Tested at least every 90 days

Put both accounts in a security group such as CA-Exclude-EmergencyAccess. Exclude that group from every policy that blocks or restricts sign-in. Microsoft notes that report-only policies don't strictly need the exclusion, but add it from day one anyway, so it's already there when you switch the policy on.

Also make a list of service accounts and anything that signs in non-interactively, such as the Entra Connect sync account if you use hybrid identity, or a scanner that sends email. These need deliberate handling, not blanket exclusions.

The starter baseline: six policies

Use a clear naming standard so the list is readable at a glance, for example CA01-AllUsers-Block-LegacyAuth. Every policy below starts with Enable policy = Report-only.

CA01: Block legacy authentication

• Users: All users. Exclude the emergency access group.
• Target resources: All resources.
• Conditions > Client apps: Configure = Yes. Check only Exchange ActiveSync clients and Other clients.
• Grant: Block access.

Legacy protocols can't do MFA, and Microsoft's analysis attributes the large majority of password spray attacks to them. Before enforcing, check who still uses them: Entra ID > Monitoring & health > Sign-in logs, add the Client app column, filter to the legacy protocols, and check the non-interactive sign-ins tab too. The usual culprits are old multifunction printers, line-of-business apps and ancient mail clients.

CA02: Require MFA for all users

• Users: All users. Exclude the emergency access group (and the directory synchronization accounts role if you use Entra Connect).
• Target resources: All resources, with no app exclusions.
• Grant: Grant access > Require authentication strength > the built-in Multifactor authentication strength.

Microsoft's tip is that every organization should have this baseline: all users, all resources, MFA. Resist adding "trusted office IP" exclusions unless you really need them. Attackers don't sit in your office, but stolen sessions and compromised devices can look like they do.

CA03: Require phishing-resistant MFA for admins

• Users: Directory roles. Include at least Global Administrator, Privileged Role Administrator, Security Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Helpdesk Administrator, Authentication Administrator, Privileged Authentication Administrator, Application Administrator, Cloud Application Administrator, Password Administrator and Billing Administrator. Exclude the emergency access group.
• Target resources: All resources.
• Grant: Require authentication strength > Phishing-resistant MFA.

Warning: make sure every admin has registered a passkey (FIDO2), Windows Hello for Business or certificate-based authentication first, using a Temporary Access Pass if needed. Turning this on before they're registered is the classic lockout. Also note that Conditional Access only targets built-in roles. Custom and administrative-unit-scoped roles aren't covered.

CA04: Require MFA for Microsoft admin portals

• Users: The same admin roles as CA03. Exclude the emergency access group.
• Target resources: Select resources > Microsoft Admin Portals.
• Grant: Require authentication strength > Multifactor authentication.

This overlaps with CA02 and CA03 on purpose. If someone later edits or scopes down one policy, this one still protects the admin portals.

CA05: Secure security info registration

• Users: All users. Exclude all guest and external users, and the emergency access group.
• Target resources: User actions > Register security information.
• Conditions > Locations: Include Any location. Exclude All trusted locations.
• Grant: Require authentication strength.

This stops an attacker who has just phished a password from registering their own MFA method. Issue new starters a Temporary Access Pass so they can register from anywhere. One caveat: report-only mode doesn't evaluate policies scoped to User actions, so you won't get report-only data for this one. Test it on a small test group instead. Microsoft also notes that from July 6, 2026, these policies apply during Windows Hello for Business and macOS Platform SSO registration, so test those flows if you use them.

CA06: Block device code flow

• Users: All users. Exclude the emergency access group and any documented exceptions.
• Target resources: All resources.
• Conditions > Authentication flows: Configure = Yes, select Device code flow.
• Grant: Block access.

Device code flow is rarely needed in small businesses but often abused in phishing. If you have Teams Rooms or similar shared devices that rely on it, scope a narrow exception rather than leaving the flow open to everyone.

Next-wave policies (after the baseline is on)

• MFA for guests. Include guest and external users, target all resources, require MFA (if CA02 doesn't already cover them).
• Risk-based policies (P2). Require MFA for medium-or-higher sign-in risk and a secure password change for high user risk.
• Block countries you don't operate in, using a named location. Treat it as noise reduction, not a strong control, because VPNs get around it.
• Device-based access once Intune enrollment is in good shape, plus app protection on mobile.
• Shorter admin sessions: sign-in frequency and no persistent browser for admin roles.

Running report-only properly

Report-only means the policy is evaluated at every sign-in and logged, but nothing is enforced. Users aren't prompted and nobody is blocked. Give each policy at least 7 days, and 14 if your business has weekly or month-end cycles.

Three places to look:

1. Policy impact. Open the policy and select the Policy impact view. It shows what the policy would have done to interactive sign-ins over the past 24 hours, 7 days or month. It needs at least the Security Reader role.
2. Sign-in logs. Entra ID > Monitoring & health > Sign-in logs, open a sign-in and check the Report-only tab. Results are:
   • Report-only: Success: would have been allowed
   • Report-only: Failure: would have been blocked. Investigate every one.
   • Report-only: User action required: the user would have been prompted (for example, for MFA)
   • Report-only: Not applied: conditions didn't match, for example an excluded user
3. Conditional Access insights workbook, if you send sign-in logs to a Log Analytics workspace. It's best for seeing several policies together.

For each Failure, decide: is it an attacker (good, the policy works), a legacy device that needs replacing, or a legitimate scenario that needs a narrow, documented exclusion?

A report-only quirk: policies that require a managed device can still pop a certificate prompt on macOS, iOS and Android during evaluation. Microsoft's advice is to exclude those platforms from report-only device policies.

Switching policies on

Turn on one policy at a time, in this order:

1. CA01 (block legacy auth), once the sign-in logs show no legitimate legacy use
2. CA04, then CA03 (admins first; it's a small group you can help in person)
3. CA02 (all users), after a user communication with the date and how to register
4. CA05 and CA06

For each one:

• Report-only for 7 to 14 days with no unexplained failures
• Exclusions documented with an owner and a review date
• Help desk told what to expect and how to issue a Temporary Access Pass
• Emergency access account sign-in tested
• Switch Enable policy from Report-only to On
• Watch sign-in logs closely for the first 48 hours
• Rollback plan ready: switch the policy back to Report-only, rather than deleting it

Keeping it healthy

• Review exclusions every 90 days. Exclusions are where baselines quietly die.
• Export your policies (JSON via Microsoft Graph) after every change, so you have a backup and a history.
• Test the emergency access accounts quarterly.
• Review any new Microsoft-managed policies when Message center announces them.

A small tenant with these six policies on, real emergency access accounts and documented exclusions is ahead of most organizations its size, and you got there without locking anyone out.

Resources: Free M365 + Google Workspace hardening checklist · Full pack with 16 report-only policy JSONs, a safe PowerShell deployer and a rollout runbook: Conditional Access Policies Baseline ($59). I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.

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:

1. Which AI tools have you used for work in the last month?
2. Are you signed in with a work account, a personal account or no account?
3. What do you use them for (drafting, summarizing, coding, research, images, meetings)?
4. Have you ever pasted customer, employee or financial information into one?
5. 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:

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:

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.

1. 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.
2. 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.
3. Data rules. The data table above, plus "never enter credentials" and "when unsure, treat as confidential."
4. Human review and accountability. You own the output. Verify before use. No final decisions about people without documented human review.
5. Transparency. Disclose substantial AI use in customer-facing, published or legal material, or where required.
6. Prohibited uses. The list from Step 7.
7. Security and incident reporting. Report data mistakes and unapproved use to [contact]. Good-faith reports are protected.
8. Exceptions and enforcement. Written exceptions from [role]. Violations handled under existing policies.
9. Ownership and review. Owner [name/role], approver [name/role], effective [date], next review [date].
10. 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 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). I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.

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 test 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 test 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

1. Test first. Create a "Test-Security" OU with IT and one or two willing staff. Apply the change there and wait a few days.
2. Communicate before enforcing. Tell people what's changing, when, and what they need to do (for example, enroll a passkey before the 2SV date).
3. Have a way back in. Keep at least one tested super admin with a hardware key stored securely before you tighten admin 2SV.
4. 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.
5. 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). I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.

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

Read these ground rules aloud at the start:

1. No fault, no blame. We are testing the plan, not people.
2. Answer with the tools, people and authority you have today, not what you wish you had.
3. Decisions don't have to be perfect. Make a call and say why.
4. Don't fight the scenario. If a detail doesn't fit, we'll adjust it and move on.
5. 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:

1. What worked well that we should keep?
2. Where did we hesitate, and why?
3. What information did we need but couldn't find?
4. Which decisions had no clear owner?
5. 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). I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.