A WISP for small tax and bookkeeping firms that use automations: what the Safeguards Rule asks of your tools

Many small firms wrote their written information security plan (WISP) once, from the IRS template, and filed it. Then they added a reminder tool, an automation server, a shared spreadsheet and an email service. Each of those now handles client names, email addresses and sometimes account details. If they aren't in the plan, the plan no longer describes how your firm actually works.

This article covers who needs a WISP, what the FTC Safeguards Rule asks for in plain terms, and how to write automations into the plan without turning it into a 60-page document nobody reads.

Not legal advice. We build and test automations; we're not lawyers or security auditors. This is a plain-English summary of primary sources, checked on October 28, 2026. State data-security and breach laws, your professional body's rules and your own risk assessment add to it. Have a qualified adviser review your plan; nothing here is a compliance guarantee.

Is a WISP mandatory for tax preparers?

For paid tax return preparers, the IRS says yes, in several places:

• The Safeguards Rule names tax preparation. The FTC's rule, 16 CFR part 314, applies to "financial institutions" under its jurisdiction. Its definitions include someone who "becomes your client for the purpose of obtaining tax preparation ... services from you".
• IRS Publication 5708, the IRS's WISP guide and template, says that under the Gramm-Leach-Bliley Act and the Safeguards Rule, "tax and accounting professionals are considered financial institutions, regardless of size", and that "a requirement of the Safeguards Rule is implementing and maintaining a WISP" (Pub 5708, Rev. 8-2024).
• Your PTIN application asks. Line 11 of Form W-12 (Rev. October 2026) asks you to confirm you're aware that "paid tax return preparers are required by law to create and maintain a written information security plan".
• The IRS Office of Professional Responsibility ties it to Circular 230. Its July 22, 2026 newsletter (OPR Issue 2026-22) is headlined "Practitioners Should Have a Written Information Security Plan" and concludes that federal law "requires tax return preparers to create and maintain" one. It points to section 10.35 (competence, which it reads as including technological competence) and section 10.36. Section 10.36 requires firm leaders to have "adequate procedures" so that employees and contractors comply.

Bookkeeping-only firms are less clear-cut. The rule's "customer relationship" covers financial products or services "used primarily for personal, family, or household purposes" (16 CFR 314.2). A firm that only keeps books for businesses and never prepares individual returns may fall partly or wholly outside it. Many such firms write a WISP anyway, because clients and insurers ask for one, and because owners' personal details end up in business books. Ask your adviser where your firm stands.

What the rule asks for, mapped to your tools

The core requirements are in 16 CFR 314.4. Here's each one next to what it means once automations are involved:

Safeguards Rule requirement	What it means for automations
A Qualified Individual runs the program (a). It can be you, or an outside provider you oversee.	Someone owns the automations: who can change them, who reviews them, and who gets the alerts.
A risk assessment (b), written unless you're under the small-firm exemption below.	List what each tool can see. A reminder tool that sees names and missing-document lists is lower risk than one that reads bank feeds.
Access controls (c)(1): only authorized users, each limited to what they need.	Separate logins on the automation server; no shared admin account; read-only API keys where the vendor offers them.
Know your data and systems (c)(2).	An inventory row for each tool (see the template below).
Encryption of customer information "both in transit over external networks and at rest" (c)(3), or compensating controls your Qualified Individual approves.	HTTPS on the automation server and its webhooks; disk or database encryption where it stores data.
Multi-factor authentication "for any individual accessing any information system" (c)(5).	MFA on the automation server, email service, spreadsheet account, practice management and accounting logins. n8n supports authenticator-app two-factor login (n8n docs).
Disposal of customer information no later than two years after it was last used, unless you need it or the law requires keeping it (c)(6).	Automation logs and spreadsheets need a retention period, not "forever".
Logging and monitoring of authorized users' activity (c)(8).	Keep the tools' audit or access logs where they exist.
Oversee service providers (f): choose capable ones, require safeguards by contract, reassess them periodically.	Your email service, automation host, spreadsheet provider and practice software are service providers. Keep their security terms on file.
Notify the FTC within 30 days of discovering a "notification event" (unencrypted customer information acquired without authorization) that involves at least 500 consumers (j).	Know where client data sits in each tool so you can tell what was exposed.

Small-firm exemption. If your firm holds customer information on fewer than 5,000 consumers, four parts don't apply (16 CFR 314.6): the written risk assessment (b)(1), annual penetration testing and vulnerability scans (d)(2), the written incident response plan (h), and the Qualified Individual's annual written report (i). Encryption, MFA, access controls, disposal and service-provider oversight still apply. Most small firms benefit from a short incident plan anyway; Pub 5708's template includes one.

The automation-specific gaps we see

These are the places where a WISP written before automations tends to have holes:

1. Execution logs. Automation tools keep a copy of what passed through them. Self-hosted n8n, for example, saves execution data for both successful and failed runs by default and deletes it after 336 hours (14 days) or once 10,000 executions pile up (n8n environment variables). That means every client email the workflow built is sitting in its database for two weeks. Decide on purpose: shorten the retention, stop saving successful runs, or document the 14 days in your plan.
2. Spreadsheets as databases. A Google Sheet that tracks missing documents is fine; one that also holds SSNs or full account numbers is a liability. Write a rule into the plan: no SSNs, EINs or full account numbers in any automation sheet.
3. Email bodies. IRS Publication 4557 recommends that you "encrypt all sensitive files/emails, especially those with the taxpayer's personally identifiable information" and "implement multi-factor authentication for anyone accessing customer information on your system" (Pub 4557, Rev. 6-2024). The simplest approach for automated email is to put no sensitive data in it: send a link to your client portal and never ask clients to reply with attachments.
4. API keys and tokens. Prefer the tool's encrypted credential store over workflow text or a shared document, and rotate keys when someone leaves. Where a key has to live in a server environment variable instead (our Karbon recipes read KARBON_APP_ID and KARBON_ACCESS_KEY that way, because the calls run in n8n Code nodes, which can't use stored credentials), note it in the plan: any workflow on that n8n instance can read it, so limit who can edit workflows.
5. Internal digests. A Monday email listing which clients are behind contains client names. Send it only to firm accounts with MFA turned on, not to personal addresses.
6. Messages that are also marketing. Circular 230 section 10.30 bars "false, fraudulent, or coercive" and "misleading or deceptive" statements in public communications and solicitations, and enrolled agents may not describe themselves as "certified" (31 CFR 10.30). Plain reminders are unlikely to raise this, but check any template that promotes your services.

One more question to take to your adviser: whether using last year's return information to drive this year's reminders needs client consent under the tax-return-information rules in IRC section 7216. OPR's newsletter notes that the civil (section 6713) and criminal (section 7216) penalties for unauthorized disclosure sit alongside Circular 230. The answer depends on what the reminder does and who sees it, so we don't try to settle it here.

A WISP entry for one automation

You don't need a new document per tool. One table row or short paragraph each is usually enough. A sample entry, to adapt:

Tool: n8n (self-hosted), document chase workflow
Owner: [Qualified Individual]
Data it sees: client first name, email, list of missing document types, portal link
Data it must never see: SSN, EIN, full account numbers, documents themselves
Access: two named admin logins, MFA on both; API keys in n8n credentials where the node supports them, otherwise in server environment variables (noted here); read-only where offered
Encryption: HTTPS (TLS) for the editor and webhooks; host disk encrypted
Retention: execution data kept [N] days; sheet rows deleted [N] months after the season
Service providers: hosting provider, email sender, Google Workspace (terms on file, reviewed yearly)
If something goes wrong: disable the workflow, rotate keys, follow incident plan section [X]

How our accounting recipes fit

We publish five n8n recipes for small tax and bookkeeping firms. They were designed with this plan in mind:

• Document chase ladder emails one list of missing items per client at day 0, 3, 7 and 14, with portal links only and never a request for attachments.
• Uncategorized transactions questions reads QuickBooks Online through n8n's own OAuth2 credential and sends each client one weekly list of transactions to explain.
• Tax organizer checklist from last year builds each client's checklist from last year's documents. It's the one to raise with your adviser on the section 7216 question above.
• Invoice reminders sends a short series of payment reminders with your QuickBooks pay link, and skips invoices you've paused.
• Waiting-on-client digest sends staff a weekly internal summary. It contains client names, so send it only to MFA-protected firm addresses.

Before client-supplied text goes into an email, a Karbon note or the digest, four of them (all but the invoice reminders, which send only the QuickBooks invoice number, amount, due date and pay link) apply the same rule: numbers written like an SSN or ITIN (123-45-6789 or 123 45 6789) or an EIN (12-3456789) become [removed], and any other unbroken run of 5 or more digits is cut to its last 4 (99887766 becomes *7766). Runs of 4 digits or fewer, such as years and form numbers, are left alone. That's a safety net, not a guarantee: n8n's execution log (point 1 above) still holds the unmasked rows the workflow read, so keep those numbers out of the source data too. TaxDome is only read, never written to. Karbon is written to: the chase ladder and the uncategorized-transactions recipe add notes, and the organizer recipe creates work items, so the Karbon key needs write access. QuickBooks is only read. No AI model is involved; every decision is a written rule. All five were tested on October 28, 2026 against mocks built from each vendor's API documentation, with invented clients, never with a live firm's data. Each recipe page lists exactly what was tested.

For the document-chase side in more depth, see Client document reminder emails. For the full list of rules we design around, see the accounting and bookkeeping hub.

Sources

All checked on October 28, 2026.

• FTC Safeguards Rule on eCFR: 16 CFR 314.2, 314.4, 314.6 (regulation text)
• IRS: Publication 4557, Safeguarding Taxpayer Data (Rev. 6-2024); Publication 5708, Creating a WISP (Rev. 8-2024); Form W-12 (Rev. October 2026); OPR newsletter Issue 2026-22 (regulator)
• Circular 230: 31 CFR 10.30 (regulation text)
• n8n: execution data environment variables and two-factor authentication (vendor documentation)