If your firm prepares federal returns, runs payroll, or touches a client's bank feed, the federal government already considers you a "financial institution" — and as of the 2026 filing season, the IRS will not renew your PTIN unless you attest, under penalty of perjury, that you have a written information security program in place. That attestation is not a check-the-box formality. It is a sworn statement that your firm has implemented the nine elements of the FTC Safeguards Rule, has designated a Qualified Individual to run the program, has tested it within the past year, and has a plan for reporting a breach to regulators within thirty days.
Most solo practitioners and small bookkeeping shops find out about the WISP requirement either when a client asks for one as part of a vendor due diligence questionnaire, or when the IRS sends a "tax pro security awareness" letter after a phishing incident. Neither moment is a good time to start from zero. This guide walks through what the WISP actually has to contain, how the FTC Safeguards Rule maps to a small firm's reality, and how to stand up a credible program without hiring a fractional CISO or buying an enterprise GRC tool.
Why a WISP Is No Longer Optional
Two regulators sit on top of every tax preparer and bookkeeper in the United States, and they reinforce each other.
The first is the IRS, which has been requiring a written security plan under Section 7216 and the Gramm-Leach-Bliley Act for years, but only recently put real teeth behind it. Starting with the 2024 PTIN renewal cycle, every preparer must affirm that they have a current WISP. The 2026 renewal window adds an explicit attestation about the FTC Safeguards Rule's nine elements. False or careless attestations are the kind of thing that gets discovered after the fact during a breach investigation, and a misstatement on a PTIN application is a separate exposure from the breach itself.
The second is the Federal Trade Commission, which enforces the Safeguards Rule under 16 CFR Part 314. The FTC has the power to assess civil penalties of up to $100,000 per violation against firms that fail to maintain a compliant program, and a "violation" can be defined narrowly — a single missing control across hundreds of client records is the kind of math that has produced eight-figure consent orders against larger preparers.
The Safeguards Rule has also tightened over the last three years. The October 2023 amendment requires firms to notify the FTC within 30 days of any "notification event" — an unauthorized acquisition of unencrypted customer information affecting 500 or more people. That reporting requirement went live in May 2024, and the FTC has already used it to identify firms that did not have a WISP in place when the breach occurred. A breach without a plan is a much worse posture than a breach with one.
For tax pros, this stacked structure means a single phishing incident can trigger PTIN exposure with the IRS, civil penalties with the FTC, state attorney general inquiries under 50-state breach notification laws, and a wave of identity-theft claims from the affected clients. The WISP is the only document that meaningfully reduces the size of that fan.
The Nine Elements You Must Document
The FTC Safeguards Rule lists nine specific program elements at 16 CFR § 314.4. The IRS template in Publication 5708 organizes its sections around the same nine, and a WISP that does not address each of them in writing is not a compliant WISP. Here is what each element actually means in a small firm.
1. Designate a Qualified Individual
You must name one person — by title and by name — who is accountable for the security program. The FTC is explicit that the Qualified Individual does not need a particular degree or certification. What matters is that the role is documented, that the person has the authority to make decisions, and that they report to senior management at least annually. In a solo practice, the Qualified Individual is usually the owner. In a small firm, it is often the managing partner or office manager, supported by an outside MSP for the technical work. The role can be outsourced, but the responsibility cannot.
2. Conduct a Written Risk Assessment
The risk assessment identifies the foreseeable internal and external risks to client information across paper records, digital files, cloud applications, email, mobile devices, and any third-party services you use. It must be written, it must be periodic, and it must be specific enough that someone reading it can see what threats you considered. A one-page table mapping "asset → threat → likelihood → impact → mitigation" is sufficient for most small firms. A two-line statement that "we use antivirus software" is not.
3. Design and Implement Safeguards
The Safeguards Rule names specific technical controls that your program must address: access controls, asset inventory, encryption of customer information at rest and in transit, secure development practices for any in-house applications, multi-factor authentication for any system that accesses customer data, secure disposal of customer information no later than two years after the last interaction, change management, and monitoring of authorized user activity.
The two controls that most small firms get wrong are encryption and MFA. The Rule requires encryption of customer information on your systems and in transit. If your engagement letters are sitting unencrypted in a Dropbox folder synced to a personal laptop, that is a finding. MFA must use at least two of the three authentication factors — knowledge, possession, inherence — and the only path to skipping it is a written approval from the Qualified Individual for an equivalent control. "It is inconvenient" is not an equivalent control.
4. Regularly Monitor and Test Safeguards
The Rule requires either continuous monitoring or annual penetration testing and biannual vulnerability assessments. For a small firm, the realistic path is the second one: an authenticated vulnerability scan twice a year, and a penetration test annually if you handle a meaningful volume of returns or any high-risk client data. The test results must be documented and reviewed by the Qualified Individual.
5. Train Your Staff
Every employee with access to client information needs role-appropriate security training, and that training must be refreshed periodically. The Qualified Individual needs more than the basic training. Phishing simulations, password hygiene, secure file handling, and incident reporting procedures are the table-stakes topics. Training logs — date, attendee, topic — should live in the WISP folder.
6. Oversee Service Providers
If you use a tax software vendor, a cloud storage platform, a document signing service, a payroll processor, or a bookkeeping app, those are service providers under the Rule. You must select them based on their ability to maintain appropriate safeguards, contractually require them to do so, and periodically assess whether they continue to meet that bar. SOC 2 Type II reports are the standard evidence; a vendor that cannot produce one is a flag.
7. Keep the Program Current
A WISP is a living document. The Rule requires you to evaluate and adjust the program in light of testing results, material changes to operations, and changes in the threat landscape. Annual review at minimum, plus a refresh whenever you change tax software, migrate to a new cloud platform, open a new office, or bring on a new partner.
8. Write a Written Incident Response Plan
The IRP must specify the internal process for responding to a security event: goals, roles and responsibilities, internal communications, external communications, evidence preservation, remediation steps, and post-incident review. The plan must also include the regulatory notification path — to the FTC within 30 days for events affecting 500+ people, to the IRS Stakeholder Liaison for any data theft, and to each state attorney general per the relevant state breach law.
9. Report to the Board (or Owner) Annually
The Qualified Individual must report in writing, at least annually, to the firm's governing body — the board, the managing partner, or the sole proprietor. The report covers the overall status of the program, material risks, testing results, service provider issues, and any security events. For a one-person firm, this means the owner writes a memo to themselves, dates it, and files it. It sounds silly until you are sitting across from an FTC investigator.
The IRS Publication 5708 Template Is the Easiest Starting Point
The Security Summit — a partnership between the IRS, state tax agencies, and the major tax software vendors — publishes a fillable WISP template as IRS Publication 5708. It is a 28-page document, structured around the nine FTC elements, that walks a small firm through every required section. Recent revisions have added language on MFA approval workflows, encryption alternatives, and the 30-day breach notification process.
Two practical notes about Publication 5708:
- Treat it as scaffolding, not a finished plan. The template asks you to fill in your firm's specific safeguards, vendors, training topics, and incident response contacts. A WISP that still has the placeholder text in it is worse than no WISP — it is documentary proof that you did not perform a risk assessment.
- Do not skip the appendix items. The template's data classification appendix, asset inventory, and vendor list are the parts that make the WISP defensible. A breach response that begins with "we don't know exactly which clients were affected" because there was no asset inventory is the worst possible starting point.
The companion publication, IRS Publication 4557 — Safeguarding Taxpayer Data, is a longer educational guide that covers the broader landscape: federal and state breach notification laws, common attack patterns against tax pros, the IRS reporting workflow when a preparer's EFIN is compromised, and a list of free or low-cost technical resources. Read it once, keep it bookmarked, and revisit when you onboard new staff.
The Real-World Build: A 90-Day Roadmap for a Small Firm
Standing up a WISP from scratch is intimidating mostly because the regulations describe an enterprise security program in a language that does not map cleanly onto a six-person CPA firm. Here is a sequencing that actually fits a small practice.
Days 1 to 14 — Inventory and Designate. Designate the Qualified Individual in writing. Build the asset inventory: every device that touches client data, every cloud application, every paper file location, every service provider. The inventory is the single most leveraged document in the WISP — risk assessment, encryption decisions, vendor oversight, and incident response all reference it.
Days 15 to 30 — Risk Assessment. Walk through the inventory and identify foreseeable threats. Phishing against staff. Lost laptop with synced client files. Ransomware encrypting the document repository. Vendor breach exposing client uploads. Score each, note current mitigations, and flag gaps.
Days 31 to 60 — Controls Implementation. Close the gaps. MFA across every system that touches client data, including tax software, email, cloud storage, document signing, and bookkeeping platforms. Full-disk encryption on every workstation and laptop. Secure disposal procedures for paper, hard drives, and former-client folders. Vendor contracts updated to include security obligations. Staff training rolled out with a tracked completion log.
Days 61 to 80 — Write the Plan. Open Publication 5708 and fill in each section against the inventory, risk assessment, and controls you have now implemented. Write the incident response plan with specific named contacts, the FTC reporting workflow, and the IRS Stakeholder Liaison contact for your region. Document the annual review schedule.
Days 81 to 90 — Test, Train, Report. Run a tabletop exercise of the incident response plan. Get a vulnerability scan from a reputable provider. Conduct the formal staff training session and capture the attendance log. Write the Qualified Individual's first annual report, sign it, file it.
At the end of 90 days, you have a defensible WISP. It is not a one-and-done; it is the start of an annual cycle that ratchets the program forward each year.
Where Most Small Firms Still Fall Short
After watching a few hundred small practices go through their first WISP cycle, the same gaps come up repeatedly.
- Treating the WISP as a Word document instead of an operating practice. A plan filed in a drawer is not a program. The proof of compliance lives in training logs, vendor reviews, vulnerability scan reports, and annual board reports — not in the plan document itself.
- Confusing client confidentiality with data security. A confidentiality clause in an engagement letter is a contractual obligation. The FTC Safeguards Rule is a regulatory obligation with technical, administrative, and physical control requirements. They overlap but they are not the same.
- Ignoring personal devices. If a partner checks client email on a personal phone, that phone is in scope for the WISP. The risk assessment must address it, MFA must be enforced on it, and the incident response plan must contemplate it.
- Skipping the service provider review. A vendor that suffers a breach affecting your clients still leaves you on the hook for the FTC notification if you cannot demonstrate appropriate oversight. The annual SOC 2 review takes an hour and may save the firm.
- Filing the breach reporting workflow under "we'll figure it out if it happens." The 30-day clock from the FTC starts on discovery, not on the date you decide it is real. Pre-positioning the reporting form, the state-by-state notification contact list, and the cyber insurance carrier number in the WISP is the difference between a controlled incident and a regulatory pile-on.
What Good Bookkeeping Has to Do With This
The WISP is fundamentally a story about records — what you have, where it lives, who can touch it, and what you do when something goes wrong. The firms that struggle most with the Safeguards Rule are the same ones that struggle with their own books: scattered records across disconnected systems, no version history, no audit trail for who changed what and when.
The connection is not coincidental. A bookkeeping practice built on plain-text, version-controlled accounting gives you the same primitives that a credible security program needs: a single source of truth, a tamper-evident history, the ability to reconstruct exactly what the state of the world was on any given date, and the ability to grant or revoke access without losing the trail. When the FTC asks what client data you held on the date of an incident, "let me query the ledger as of that timestamp" beats "let me check whether that backup is still good."
Keep Your Firm's Financial Records as Defensible as Your WISP
A Written Information Security Plan is only as good as the records it protects. If your own books live in opaque systems with no version history, you have already lost the audit trail that the FTC Safeguards Rule, your professional liability carrier, and your clients all expect you to maintain. Beancount.io provides plain-text, Git-versioned accounting that gives accounting firms complete transparency over their own financial data — every transaction, every reclassification, every reconciliation captured in a tamper-evident history you actually control. Get started for free and run your practice on the same standard of evidence you owe your clients.