Writing a WISP for a Tax Practice: What Goes In It

What is a WISP?

A WISP is a written information security plan: the document that says how your practice protects client data, who is in charge of it, and what happens when something goes wrong. The FTC’s Safeguards Rule calls it a “comprehensive information security program that is written in one or more readily accessible parts” (16 CFR 314.3). The IRS calls it a WISP. Same thing.

It has to fit your “size and complexity, the nature and scope of your activities, and the sensitivity of any customer information at issue.” A two-person seasonal office and a ten-partner CPA firm should not have the same document. IRS Publication 5708 says it plainly: “There is no one-size-fits-all WISP.”

Do tax preparers have to have one?

Yes. The Safeguards Rule names “an accountant or other tax preparation service that is in the business of completing income tax returns” as a financial institution (16 CFR 314.2). IRS Publication 4557 says the same thing: “tax return preparers must create and enact security plans to protect client data,” and that failing to do so “may result in an FTC investigation.” Pub 5708 adds that tax and accounting professionals are financial institutions “regardless of size.” That covers accounting firms doing bookkeeping and payroll next to returns, too.

The IRS also puts it in front of you every year. Line 11 of Form W-12, the PTIN application and renewal, reads: “I am aware that paid tax return preparers are required by law to create and maintain a written information security plan that provides data and system security protections for all taxpayer information.” It’s a yes-or-no box, and you must check one.

Read that closely. You’re acknowledging the law. The form doesn’t ask you to send in the plan. So the first person to actually read your WISP may be someone looking at it after a breach. Write it for that reader.

What goes in it?

Start with IRS Publication 5708, Creating a Written Information Security Plan for your Tax & Accounting Practice (Rev. 8-2024). The Security Summit (the IRS, state tax agencies, and private-sector tax groups) wrote it to help smaller practices, and it includes a fill-in-the-blanks sample. Use that one. I’m not going to hand you a different template. The official one is free, and anyone reviewing your plan will recognize it.

Its outline:

1. Objectives, purpose, and scope. What data you hold and why the plan exists.
2. A qualified individual. Pub 5708’s sample calls this person the Data Security Coordinator. List your authorized users and what each can access.
3. Risk assessment. What information you handle, where it could be lost, and how you test for new risks.
4. Hardware inventory. Every device, where it sits, and what client data it stores or processes.
5. Safety measures. Policies for data collection and retention, disclosure, network protection, user access, electronic data exchange, Wi-Fi, remote access, connected devices, and reportable incidents, plus an employee code of conduct.
6. An implementation clause. Signed and dated.
7. Attachments. Retention policy, rules of behavior, breach procedures, staff acknowledgments, the hardware inventory, and the list of who can access client data.

Then check it against the rule, because the rule is what you’re held to. 16 CFR 314.4 requires, among other things: a written risk assessment; access limited to what each person needs; encryption of customer information at rest and in transit over external networks; multi-factor authentication “for any individual accessing any information system”; secure disposal within two years of last use unless you have a legitimate reason to keep it; logging of user activity; security awareness training; service providers bound by contract to keep safeguards; a written incident response plan; and a written report from your qualified individual at least once a year. If a breach involves at least 500 consumers, you notify the FTC no later than 30 days after you discover it.

Small practices get one break. If you hold information on fewer than 5,000 consumers, 16 CFR 314.6 drops four items: the written risk-assessment requirements, the penetration testing and vulnerability scans, the written incident response plan, and the annual report. You still assess risk. You still need the plan, MFA, and encryption.

Where does IT come in?

Most of the WISP is IT. Pub 5708’s sample says your firewall “will be secured and maintained by the Firm’s IT Service Provider,” that event logs get reviewed “at random intervals not to exceed 90 days,” and that remote access “will only be allowed using multi-factor Authentication (MFA).” Each of those is a factual claim about your office. Sign the template as written when none of it is true, and you have a document proving you knew what you were supposed to do.

The sections IT has to be able to back up:

• Hardware inventory. Every laptop, desktop, server, and NAS that touches client data, with location and contents. That’s Attachment E in Pub 5708. We’ve pulled a 312-asset inventory in 47 minutes for an insurance audit, with encryption status included.
• Encryption. Full-disk encryption on every machine with client data, with recovery keys escrowed. See BitLocker at scale.
• MFA. Email, remote access, tax software, cloud storage. The rule says any information system. An exception needs your qualified individual’s written approval.
• Access and offboarding. Unique logins, no shared accounts (Pub 5708’s sample says so directly), and access cut the day someone leaves.
• Where client data lives. Pub 5708 tells the coordinator to list every location, including “Database applications, such as Bookkeeping and Tax Software Programs.” That list should include the spreadsheet of passwords on someone’s desktop. We find those in audits.
• Patching and logging. OS patches installed, firewall firmware current, event logging on.

Keeping it true after you write it

Pub 5708 calls the WISP “an evergreen document,” and the sample says to review it at least annually. Annual is the floor. A plan drifts the week something breaks.

Here’s a real one. A client’s QuickBooks Desktop hung on the Intuit ID login and he couldn’t email invoices. The same-day workaround was exporting PDFs and sending them from Gmail. For invoices, fine. Now picture the same kind of hang in tax software in March, and a preparer doing the same thing with a client’s return. Pub 5708’s sample policy says client data doesn’t go out by plain email unless it’s encrypted or password-protected, with the password sent some other way. Under deadline pressure, nobody opens the WISP first.

So the real job isn’t writing the plan. It’s catching the moment the office stops matching it: a new hire on a shared login, a new printer on the Wi-Fi with its factory password, a workaround that quietly became the process. The rule expects this. 314.4(g) says you adjust the program after testing, after material changes to how you operate, and after anything else that affects it.

What this looks like when we do it

For accounting firms and tax practices, we start from Pub 5708 and the 314.4 elements, and we fill the IT sections with what’s actually on your network instead of what the template assumes. Then:

• We inventory every device and tie it to the plan’s hardware attachment.
• We enforce MFA, encrypt every machine with escrowed keys, and write up any exception for your qualified individual to approve.
• We map each control to the 314.4 paragraph it answers, so the annual review is a check, not a rewrite.
• We keep it current as part of managed IT, so the document matches the office in April, not just the day it was signed.

The Safeguards controls are part of our month-to-month managed IT. The first written program build is scoped separately, on a call.

If your WISP is a template nobody has opened since the last PTIN renewal, get in touch and we’ll walk through it with you.

Key takeaways