A partner at a mid-size CPA firm pulls up a Written Information Security Program during a client due-diligence review, or worse, during an FTC inquiry after a breach. The document looks fine on its surface. It has section headers for risk assessment, access controls, and incident response. Then someone asks who the firm's Qualified Individual is, and the name on the page left the firm two years ago. Nobody can say which vendor hosts the tax software described in section four, because the firm switched providers last year and never updated the plan. The WISP exists. It just doesn't describe anything the firm actually does.
This happens constantly, and it's worth understanding why a document downloaded from a template library or bundled free with a compliance webinar tends to fall apart the moment anyone looks closely at it.
The FTC Safeguards Rule applies to CPA firms because tax preparation and accounting services fall under the definition of "financial institution" set out in the Gramm-Leach-Bliley Act. That classification surprises a lot of practitioners who think of GLBA as a banking statute, but the FTC's own guidance lists tax preparation firms directly among the covered entities, alongside mortgage brokers, check cashers, and collection agencies.
The rule specifically asks for a program built around the firm's own risk profile.
The FTC's guidance describes reasonable security as a function of three things:
A firm running desktop tax software on an in-office server has a different risk surface than a firm running everything through a cloud platform with remote staff logging in from personal devices. A template written to satisfy neither situation in particular satisfies neither situation well.
This is the structural problem with boilerplate. The document was written to be defensible in the abstract, not to describe a specific firm's systems, vendors, and people. When a regulator, insurer, or client asks the WISP to account for what the firm actually runs, it can't.
Section 314.4 lays out the required elements of the program, and several of them are hard to fake with a fill-in-the-blank document. A firm has to name a Qualified Individual responsible for the program, not just claim to have one. It has to complete a written risk assessment that identifies real threats to the systems it uses, not a hypothetical list of generic risks. It has to design and implement safeguards, monitor them, oversee service providers under contract, and maintain a written incident response plan that names actual people and actual steps.
A 2023 amendment to the rule added something else that a stale template almost never accounts for: firms experiencing a breach affecting 500 or more consumers' unencrypted information now have to report it to the FTC within 30 days, a requirement the agency confirmed took effect in May 2024. A WISP written years before that amendment, and never revisited, simply doesn't build in a process for meeting that deadline. Firms find this out during an actual incident, which is the worst possible time to discover a gap in the plan.
None of this is theoretical for accounting firms specifically. The IRS has leaned on the same rule for years in its guidance to tax professionals, and it publishes its own resources on the subject because so many preparers handle exactly the kind of nonpublic personal information the rule is meant to protect. IRS Publication 4557, Safeguarding Taxpayer Data, walks through the same core requirements and ties them directly back to the FTC rule, and the IRS has also released Publication 5708, a template specifically built to help smaller tax and accounting practices construct a plan from scratch. Even the IRS's own Security Summit initiative has had to keep reminding practitioners that a plan on paper isn't the same as a plan that reflects reality, issuing repeated reminders that a Written Information Security Plan is a legal requirement, not a nice-to-have.
The failures tend to cluster around a few recurring patterns.
The risk assessment section usually reads like it was written for no firm in particular. It lists categories of risk without connecting them to the software the firm runs, the way client documents move between staff and clients, or the vendors who touch the data along the way. A risk assessment that doesn't name the firm's actual practice management system, client portal, or cloud host isn't really an assessment. It's a placeholder.
The vendor oversight section is often missing entirely or reduced to a single sentence promising to monitor service providers, with no contract language, no vendor list, and no process for confirming that vendors are actually doing what they're supposed to. Under the rule, a firm remains responsible for how its service providers handle customer information, which means the WISP needs to show how that oversight actually happens.
The incident response section frequently reads as generic crisis language rather than a workable plan, without a named point of contact, a communication chain, or a path to meeting the 30-day reporting window if the breach crosses the reporting threshold.
And perhaps most commonly, the plan simply stops getting updated. Staff change. Software changes. The firm adds a remote work policy or switches document storage providers, and the WISP still describes the environment from three years earlier. A plan that doesn't match the environment it's supposed to protect creates its own kind of exposure, because it demonstrates in writing that the firm isn't actually following its own documented safeguards.
A compliant plan starts from an actual accounting of what the firm has: its software stack, its data flows, its staff roles, and its vendors. From there, the risk assessment can identify real gaps instead of generic ones, and the safeguards section can describe controls the firm has genuinely implemented rather than controls that sound appropriate.
The Qualified Individual named in the document needs to be a current employee or contracted party who actually understands the firm's systems, since that person carries responsibility for overseeing the program and reporting on it. The incident response plan needs specific names, specific vendors, and a specific process for the 30-day notification clock if a qualifying breach occurs. And the whole document needs a review cycle built into it, because the rule expects an information security program to be an ongoing process, not a one-time filing.
Penalties for getting this wrong aren't hypothetical either. Violations can expose a firm to FTC enforcement action, with fines that can reach into six figures per violation and personal liability for responsible officers, on top of the reputational and client-trust damage that follows any data incident at a firm holding Social Security numbers, bank account details, and full tax histories.
A WISP built from a template someone else wrote for a different kind of business was never going to hold up under that kind of scrutiny. It was built to look complete, not to be complete. For a CPA firm handling the amount of sensitive financial data that comes through a typical tax season, that distinction determines whether the plan holds up under review.
As a managed IT service provider, PK Tech brings 15 years of experience focused on accounting firms. PK Tech holds AICPA SOC 2 Type II attestation, verified through an independent third-party audit of its security and privacy controls. Schedule a WISP compliance review with our team.