DEV Community: Runbook Foundry

Get a weekly CISA KEV digest with n8n (free workflow)

Runbook Foundry — Tue, 27 Oct 2026 03:38:12 +0000

CISA's Known Exploited Vulnerabilities (KEV) catalog is the shortest useful patch list there is: every entry is a CVE that CISA has evidence of being exploited in the wild. CISA publishes it as a public JSON feed with no API key, which makes it a good fit for a small n8n workflow.

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:

Field	Example use
`cveID`	the row key
`vendorProject`, `product`	watchlist matching and display
`dateAdded`	the "new last week" filter
`dueDate`	the remediation deadline for US federal civilian agencies under BOD 22-01. Other organizations can use it as a target date.
`knownRansomwareCampaignUse`	`Known` or `Unknown`
`requiredAction`	CISA's one-line instruction

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

The workflow

Nine nodes, all core (plus sticky notes):

Every Monday 08:00 (Schedule Trigger) → Flag: live run (Code: return [{json:{_dryRun:false}}])
Test workflow (manual) (Manual Trigger) → Flag: dry run (Code: return [{json:{_dryRun:true}}])
Both flags → Download CISA KEV feed (HTTP Request, GET, 30 s timeout)
Filter & build digest (Code)
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

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.
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 }}.
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.

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.

IT Offboarding Checklist Template for Microsoft 365 and Google Workspace (Same-Day Steps)

Runbook Foundry — Tue, 27 Oct 2026 01:34:30 +0000

Free download: IT offboarding checklist (free template). It's ordered for urgent exits; for a planned exit, do the transfer steps first. Copy it, then use the steps below to fill it in. I make these templates.

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:

Inventory what they can reach (identity, SaaS, devices, shared secrets).
Transfer data and ownership you need to keep.
Cut access at a set time, with sessions revoked.
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

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).
Block sign-in on the same user page.
Revoke refresh tokens if you script it: Revoke-EntraUserAllRefreshToken and Set-EntraUser -AccountEnabled $false (Microsoft Learn).
Remove MFA methods and registered devices so a cached authenticator can't be reused.
Convert the mailbox to shared or set forwarding to the manager, and add an auto-reply if customers email this person.
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.
Remove the user from groups, Teams ownership and admin roles.
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):

Change the password and reset sign-in cookies (Admin console > Directory > Users > select user > Security).
Revoke app passwords, security keys and OAuth tokens on the same Security panel.
Remove recovery email and phone so password recovery can't be used.
Suspend the user while you transfer data.
Transfer Drive and Calendar ownership (Admin console > Account > Data transfer), then delete the account or keep it as an archived user.
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. Copy the checklist into your ticketing system or a shared doc and give each step a named owner, so HR can start it and IT can finish it the same way every time.

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.

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.

AI Governance Policy Template for Small Companies: What to Include

Runbook Foundry — Thu, 22 Oct 2026 18:37:30 +0000

An acceptable use policy tells employees what they can do with AI. A governance policy tells the company how it decides. Who approves a new AI tool? Who owns the risk when a model drafts customer emails or screens invoices? What happens when an AI agent with access to your systems does something nobody expected?

Free download: a free AI acceptable use policy template to pair with your governance policy

Large enterprises answer these questions with committees and frameworks. A small company needs the same answers on a few pages. This guide covers what to include, what to leave out and a sample outline you can adapt.

Governance policy vs. acceptable use policy

They work together, but they do different jobs:

	Acceptable use policy	Governance policy
Audience	Every employee	Owners, managers, IT, whoever buys software
Answers	"What can I put into this tool?"	"How do we approve, monitor and retire AI?"
Length	1–2 pages	3–6 pages
Changes	When the approved tool list changes	When your risk appetite or regulations change

If you only have time for one, write the acceptable use policy first. Staff are using AI today. Then add the governance policy so the decisions behind that list stop living in one person's head.

1. Purpose and scope

Start with two or three sentences. Say why the policy exists (to use AI productively while protecting customers, staff and company data) and what it covers. Be explicit that scope includes:

Standalone AI tools (chat assistants, image and code generators)
AI features built into software you already pay for
AI agents or automations that take actions, not just produce text
Models or AI services your company builds into its own products

The built-in features are the ones most often missed. A note-taker that switches itself on in meetings is in scope, even if nobody "bought an AI tool".

2. Roles and accountability

Small companies don't need a committee. They need names next to decisions. Define at least:

AI owner: one person accountable for the policy and the AI inventory. Often the operations lead or the person who already owns IT.
System owners: for each approved AI use, the person who answers for how it's used and what it outputs.
Approvers: who can say yes to a new tool or use case, and the threshold at which the owner or leadership must sign off.
Everyone: report incidents and unexpected AI behaviour, and follow the acceptable use policy.

Write roles, not job titles that will change. "The person responsible for IT" survives a reorganization better than a name.

3. AI inventory

You can't govern what you can't see. Require a simple register with one row per AI use:

Tool or feature name and vendor
Business purpose and system owner
Data it can access (public, internal, confidential, personal, regulated)
Whether it can take actions (send, delete, purchase, change settings)
Risk tier (see below)
Date approved and next review date

A spreadsheet is fine. Update it whenever a tool is approved or retired, and at each quarterly review.

4. Risk tiers

Not every AI use deserves the same scrutiny. Three tiers are usually enough:

Low: public or non-sensitive data, a human reviews every output, no actions taken. Example: drafting a blog outline. Approval by the system owner.
Medium: internal or confidential data, or outputs that reach customers. Example: summarizing support tickets. Requires AI owner approval and a vendor check.
High: personal or regulated data, decisions about people (hiring, credit, pricing for individuals), or AI that takes actions in your systems. Requires leadership approval, a documented risk assessment, and named human oversight.

The tier drives everything else: how much vendor review, how often to check outputs, and who signs off.

5. Approval process for new tools and use cases

Describe the path from "I'd like to use this" to "approved":

Requester fills in a short intake form: tool, purpose, data involved, who will use it.
AI owner assigns a risk tier.
Vendor review proportional to the tier (see next section).
Decision recorded in the inventory, with any conditions ("internal data only", "outputs reviewed before sending").

Set a target turnaround, such as five working days for low-risk requests. If approval is slow, people route around it.

6. Vendor and contract requirements

For medium and high tiers, check the vendor terms before approval. Key questions:

Does the vendor train models on your inputs or outputs? Can you opt out, and is it off by default on your plan?
How long are prompts and outputs retained, and where?
Is there a data processing agreement covering personal data?
Can you get admin controls: single sign-on, audit logs, the ability to disable features?
Who owns the outputs, and what indemnity, if any, does the vendor offer?

Record the answers. Terms change, so re-check at each review.

7. Human oversight and output quality

AI makes confident mistakes. The policy should state plainly that a person remains accountable for anything AI produces or does on the company's behalf. For each tier, define:

Whether every output is reviewed before use, or a sample is checked
Who reviews it and what they check (accuracy, tone, bias, confidential content)
For AI that takes actions: what it may do unattended, what needs confirmation, and spending or permission limits

For agents in particular, give them the least access they need, use separate accounts so their actions are logged, and keep a documented way to switch them off quickly.

8. Fairness, transparency and people decisions

If AI touches decisions about people (job applicants, employees, customers), add specific rules:

AI may assist, but a person makes the final decision.
Check outputs for patterns that disadvantage particular groups.
Tell people when they are interacting with AI or when AI materially contributed to a decision about them, where the law requires or it's simply the decent thing to do.

Several jurisdictions now regulate automated decisions in hiring and lending. Flag this section for legal review.

9. Incidents

Define what counts as an AI incident: confidential data entered into an unapproved tool, a harmful or wrong output that reached a customer, an agent taking an unexpected action. Then route it into your existing incident process: who to tell, how fast, and how to record lessons learned. You don't need a separate AI incident plan.

10. Training and awareness

A short annual session plus onboarding is enough for most small companies. Cover the acceptable use rules, how to request a new tool, and how to report a problem. Keep a record of who completed it.

11. Review cycle

AI tools and terms change fast. Commit to:

A quarterly review of the inventory and approved tool list
An annual review of the policy itself
An ad hoc review when a major vendor changes terms or a new regulation applies to you

Sample outline

Copy this structure and fill it in:

Purpose and scope
Definitions (AI tool, AI feature, AI agent, personal data, confidential data)
Roles and responsibilities
AI inventory requirements
Risk tiers and criteria
Approval process
Vendor and contract requirements
Human oversight and output review
People decisions, fairness and transparency
Incident reporting
Training
Review and exceptions
Related policies (acceptable use, data classification, information security, privacy)

Common mistakes to avoid

Copying an enterprise framework wholesale. Forty pages nobody reads protects nobody. Start small and add detail where your real risks are.
No owner. A policy without a named accountable person decays within a quarter.
Ignoring agents. Tools that can act on your behalf need tighter limits than tools that only write text.
Treating approval as one-off. Re-check vendors and uses at every review.

This is general guidance, not legal advice. Have qualified counsel review your final policy, especially if you handle regulated data or make automated decisions about people.

Resources: Free AI acceptable use policy template. I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with, endorsed by, or sponsored by NIST, ISO, IEC or the European Union.

A Conditional Access Baseline for Small Microsoft Entra Tenants (Report-Only First)

Runbook Foundry — Thu, 22 Oct 2026 00:07:30 +0000

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.

Free download: a Conditional Access report-only log template

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.

Exclude at least two emergency-access accounts from every policy, and write down how they're stored, who can use them, and how their sign-ins are monitored.

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:

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.
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
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:

CA01 (block legacy auth), once the sign-in logs show no legitimate legacy use
CA04, then CA03 (admins first; it's a small group you can help in person)
CA02 (all users), after a user communication with the date and how to register
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 · Free Conditional Access report-only log. I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.

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.

Free download: a free AI acceptable use policy template

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. For each approved tool, note who approved it, when, and why, so the decision is easy to revisit later.

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

Free download: the Microsoft 365 & Google Workspace hardening checklist

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.

Settings only stay secure if the right people hold admin rights, so repeat this check every quarter: list every admin, confirm each one still needs the role, and note the date you checked.

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

Test first. Create a "Test-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. 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.

Free download: the Microsoft 365 & Google Workspace hardening checklist

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

Free Microsoft 365 & Google Workspace hardening checklist. I make this template.
DMARC specification: RFC 9989 (May 2026), which replaces 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.

Free download: a free one-page tabletop exercise scenario (account takeover)

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
[ ] Confirm you can still sign in if your admin accounts are locked or compromised, and write down the emergency-access (break-glass) steps so that scenario is quick to test
[ ] 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 · Free one-page tabletop exercise scenario. I make these templates.

Drafted with AI assistance and reviewed for accuracy.

Not affiliated with Microsoft or Google.