Annual WISP Review: What Actually Changes Each Year

Consider a firm that installed a new firewall three years ago, documented it in its Written Information Security Program, and has since moved to cloud-hosted tax software. The firewall still hums in the closet, dutifully logged. The WISP still lists it as a critical control. No one has updated the section on data storage because, technically, nothing failed—the clients’ returns are secure, the PTIN renewal went through, the FTC Safeguards Rule box was checked. This is the usual state of affairs: a document that ages in place while the business around it quietly reconfigures.

The annual review required by the Safeguards Rule is not, for most small practices, a reckoning with catastrophe. It is an exercise in noticing that the assumptions baked into last year’s WISP have become, at best, incomplete. The employee who was designated the “Qualified Individual” has retired. The bank that held the escrow account was acquired. The remote access policy was written when three people worked from home; now twelve do, on machines the firm does not own. Each shift is incremental, defensible, easy to postpone documenting. Accumulated, they constitute a program that describes a firm that no longer exists.

What changes each year is rarely the formal structure of a WISP—its table of contents, its invocation of risk assessment, its appointment of duties. What changes is the fit between that structure and the actual machinery of the practice. The review exists to force a confrontation with the gap, before an examiner or a breach notification does it for you.

Why the annual review exists beyond checkbox compliance

The FTC Safeguards Rule does not ask for a WISP. It asks for a living WISP—one that is reassessed periodically and adjusted to address fresh risks. The regulation’s language is deliberate: “evaluate and adjust,” not “file and forget.” A firm that dusts off its document once a year, changes the date, and resubmits has complied with nothing. It has merely created evidence that it treated security as theater.

The IRS sharpens this point during PTIN renewal, when preparers must attest that they maintain a data security plan. The attestation is not a perfunctory click. It is a declaration under penalty of perjury that the plan exists and is current. A preparer who has not reviewed the WISP since the previous renewal is, at minimum, vulnerable to a finding of negligence; at worst, to something more consequential. The IRS does not specify the format—its Publication 5708 offers a template, as do the NATP and AICPA—but it does specify the obligation to keep the plan accurate. A static document suggests the opposite.

Regulators treat ossification as a signal because the threats do not stand still, and neither does a practice. Consider a firm that migrated client files to cloud storage, added remote staff, or began using AI-assisted transcription for client notes. Each change alters the risk profile. Each renders portions of the prior WISP inoperative or misleading. The annual review is the mechanism for catching these drifts before they become breaches.

The same logic applies to the threat environment itself. A WISP written before the widespread availability of voice-cloning deepfakes or before a major vendor’s API was compromised may address yesterday’s adversary while leaving today’s unguarded. Even firms that rely on an MSP-written policy or templates from Tech 4 Accountants or Rush Tech Support must verify that those documents still describe their actual controls.

The review, then, is not a rewrite. It is a documented evaluation: what has changed in our operations, what has changed around us, and whether our assumptions still hold. The discipline is modest. The alternative—discovering the gaps during an examination—is not.

What actually changes year to year in a small practice

The annual review rarely reveals a smoking gun. More often, it surfaces a series of small displacements that, taken together, leave the WISP describing a practice that no longer exists.

Staff and access. Turnover is the most common delta. A preparer leaves in March; their Active Directory account lingers until June. A new bookkeeper arrives and inherits permissions modeled on their predecessor rather than their actual duties. The WISP may specify quarterly access reviews, but the document itself seldom records when the last one occurred, or what it found.

Software and infrastructure. A firm migrates from desktop QuickBooks to a cloud version, or adds a client portal, or experiments with AI-assisted scheduling. Each shift alters the data map: where information lives, who controls encryption keys, which vendors now hold contractual liability. The IRS Publication 4557 template prompts for a software inventory; it does not, by itself, force the recognition that last year’s inventory is now fiction.

Client data scope. Consider a firm that begins offering monthly bookkeeping to tax-only clients. The WISP written for annual return data—social security numbers, W-2s, the occasional K-1—now must account for continuous bank feeds, stored credentials, and real-time financial access. The risk profile changes in kind, not merely degree.

Vendor postures. A cloud provider revises its terms. A payroll service suffers a breach that does not directly affect the firm but alters the due-diligence record. The MSP-written policy many firms adopt often treats vendors as static; they are not.

Physical and procedural drift. A move to shared office space, the pandemic-era home workstation that became permanent, the fireproof filing cabinet that migrated to storage without updating the asset inventory.

Incident history and guidance. Near-misses—phishing tests failed, suspicious login attempts—accumulate. So do regulatory refinements: the FTC’s amendments, IRS Security Summit bulletins, state-level notification laws. The NATP and AICPA templates incorporate some updates; whether a firm notices depends on whether someone is assigned to look.

The honest limit here is that many years bring incremental adjustments, not overhaul. The danger is treating incremental as negligible. A WISP that drifts by five percent annually, unchecked, becomes unreliable in half a decade without ever announcing its obsolescence. The review’s purpose is to record these quiet erosions before they compound into something that requires explanation to an examiner.

How EEZY WISP structures the annual review

EEZY WISP treats the annual review as a maintenance cycle rather than a ceremonial rereading of last year’s document. The product is built around the premise that a Written Information Security Program must remain current as a firm’s operations, technology, and risk exposure shift in ordinary ways—new software adopted, an employee departed, a vendor replaced, a remote-work arrangement made permanent.

The document is organized to surface these changes through structured sections that correspond to the FTC Safeguards Rule’s requirements. A firm works through its risk assessment, safeguards, and incident response procedures, noting what has materially changed since the prior review. The interface prompts updates where assumptions have aged out: a backup procedure that no longer matches the cloud service actually in use, access controls that fail to reflect current staff, or a vendor list that omits a critical dependency added mid-year. The goal is not to generate drama but to record, with precision, the quiet drift between what the policy says and what the firm actually does.

This living-document approach distinguishes EEZY WISP from static alternatives. The IRS Publication 4557 and 5708 templates, the NATP and AICPA frameworks, and the offerings from Tech 4 Accountants and Rush Tech Support provide foundational language; some firms use an MSP-written policy. These can serve as starting points. Where EEZY WISP differs is in the mechanism of ongoing maintenance—the product is designed to be revised, not filed and forgotten. Each annual cycle produces an updated WISP with versioned changes, supported by the published support hours at eezycloud.com/support: Monday through Friday 9 AM to 8 PM, Saturday and Sunday 9 AM to 12 PM Eastern, should a question arise during review.

The output is a current policy document that satisfies both the FTC Safeguards Rule and the IRS PTIN renewal requirement, with a record of deliberate annual attention that a regulator or examiner can follow.

Pricing and what the renewal cycle involves

Pricing is on the site at eezywisp.com. What follows is what that price covers, and what happens when the year turns over.

EEZY WISP is sold as an ongoing service, not a document you download once and shelf. The annual fee includes maintenance of the policy language itself—updates to address new IRS guidance, revised FTC interpretations, or the occasional statutory change that renders last year’s phrasing quietly obsolete. You are not asked, twelve months later, to evaluate whether updates are worth a separate purchase. They arrive as part of the cycle.

The renewal, then, is less a transaction than a checkpoint. The firm receives the current version of the WISP template, adjusted for whatever has shifted in the regulatory environment since the last review. The user reviews their own implementation—who has access, what systems have changed, whether the incident-response contacts are still the right people—and documents those findings. The policy template and the firm’s self-assessment move forward together, or they do not move forward at all.

This is not the only model. The IRS Publication 4557 and 5708 templates carry no fee, though they place the burden of revision entirely on the firm. Templates from NATP or AICPA, or those offered by Tech 4 Accountants and Rush Tech Support, may bundle updates or may treat them as discrete offerings; the structure varies. An MSP-written policy typically requires a fresh engagement to revise. The distinction worth noting is whether the annual cycle is built into the relationship or must be renegotiated each time the calendar flips.

For EEZY WISP users, the renewal is managed through the same account portal that handles other EEZYVERSE products—central billing at eezycloud.com/account/—with support available during published hours if questions arise about what the year’s update contains or how to record the review. The assumption is that compliance is continuous, and that pricing should reflect that continuity rather than a recurring series of opt-in moments.

The first week of an annual review

Consider a firm that has used EEZY WISP for twelve months. The renewal notice arrives not as a demand but as a prompt: the annual review is due, and the system has flagged sections that typically require attention after a year of operation. The first task is to pull the prior year’s risk assessment and read it with the skepticism it deserves. What seemed probable then—say, that all client data remained on local servers, or that the firm had three employees with remote access—may now read as quaintly optimistic.

The practical sequence unfolds in roughly this order. The firm reviews its current operations against the documented controls. Have new software tools been adopted without updating the vendor list? Has staff turnover altered who holds administrative privileges? The IRS Publication 4557 template, like the NATP or AICPA alternatives, would require the same manual cross-referencing; EEZY WISP structures this as a series of update prompts tied to the original policy language. A bookkeeper who departed in March, a cloud storage migration completed in June—these changes must be logged not because they represent crises but because they erode the assumptions on which the prior WISP rested.

Documentation for PTIN renewal follows from this updated record. The attestation is not a separate creative exercise; it is the byproduct of having traced changes and confirmed that controls still apply. If a firm encounters ambiguity—whether a new e-signature platform qualifies as a vendor requiring due diligence, for instance—support is available during published hours: Monday through Friday 9 AM to 8 PM, Saturday and Sunday 9 AM to 12 PM Eastern.

Some firms, working from an MSP-written policy or a Tech 4 Accountants template, will perform equivalent steps through spreadsheets and email threads. The distinction lies in whether the process generates its own trail or relies on the practitioner’s memory to reconstruct one. After a year, memory is rarely a reliable witness.

The honest alternatives for annual maintenance

Every approach to maintaining a WISP demands something of the firm. None eliminates the obligation to think.

Consider a firm working from a template sourced through Tech 4 Accountants or Rush Tech Support. The document arrives complete, often well-structured, but the burden of annual review sits squarely with the practice. Regulatory guidance shifts—sometimes in small ways, sometimes substantially—and the template does not knock on your door to announce this. Someone inside the firm must monitor IRS publications, FTC amendments, and state-level requirements, then determine which paragraphs no longer reflect current obligations. The same holds for templates drawn from IRS Publication 4557 or 5708, or those offered through NATP and AICPA resources. These are sound starting points, frequently prepared by people who understand the profession. They are not, however, self-maintaining instruments. A practitioner who treats them as install-and-forget documents has, in effect, adopted a snapshot of regulatory understanding that grows more misleading with each passing quarter.

An MSP-written policy presents a different arrangement. The managed services provider who drafts the document often bundles periodic review into broader IT service agreements—patch management, endpoint monitoring, the customary stack. This can work well when the MSP tracks security regulation as a core competency and when the firm’s point of contact actually reads the revised pages rather than filing them unread. The risk here is delegation without verification: the policy becomes something the firm possesses but does not govern, and the annual review becomes a line item on an invoice rather than a genuine exercise in risk assessment.

What unites these alternatives is the absence of automatic updating. No template refreshes itself. No MSP contract, however comprehensive, replaces the firm’s own judgment about whether its controls still match its operations. The annual review, under any of these models, remains a discipline to be cultivated internally—an appointment the firm must keep with itself.

Where the WISP sits in the broader security stack

A Written Information Security Program is not a firewall, a backup system, or an incident-response drill. It is the documented policy layer that sits above these controls and asks whether they still match the risks the firm actually faces. The annual review, then, is less a technical audit than a governance exercise: a check on whether the assumptions baked into last year’s policy have drifted out of alignment with the firm’s operations, its vendors, or the threats in circulation.

Consider a firm that migrated its client files to a new cloud storage provider six months ago. The technical migration succeeded; permissions were set, data transferred, staff trained. But if the WISP still names the previous vendor as the firm’s primary document repository, the policy has become a fiction. The gap is not dramatic—no breach occurred, no system failed—but the erosion is real, and a regulator noticing the discrepancy would reasonably ask what else the firm has failed to update.

This is where the WISP earns its keep. It forces a structured conversation about what has changed, who decided it, and whether the written record reflects that decision. The alternatives for producing this document are varied and defensible. A firm might adapt the IRS Publication 4557 or 5708 templates, purchase a template from Tech 4 Accountants or Rush Tech Support, work from NATP or AICPA frameworks, or task an MSP with drafting something bespoke. Each approach has its partisans. The common hazard is treating the WISP as a one-time compliance artifact rather than a living policy that requires annual reconciliation against the technical reality below it.

For firms already using other EEZY products, EEZY WISP sits within the same EEZYVERSE family: one login across the EEZY products a company uses, with one central bill at eezycloud.com/account/, each product also sold on its own site. Sites are hosted on Microsoft Azure. The integration matters for administrative coherence; it does not oblige adoption of products a firm does not need. The point is simply that the policy layer and the operational layer need not exist in separate administrative universes.