Category: EEZY Ecosystem

Consider a firm that loses a laptop holding four years of client returns. The owner spends the weekend changing passwords and drafting a letter to clients, then discovers the FTC Safeguards Rule already required a Written Information Security Program — a written document, kept current, describing how the firm protects client data. The rule did not ask whether the firm had time. It asked for the document.

The IRS asks for the same thing at PTIN renewal, and Publication 4557 tells tax professionals what a WISP must cover. This is not a standard that applies once a firm reaches a certain size or once an afternoon opens up. A solo preparer with a home office owes the same document as a forty-person firm, because the obligation attaches to the data, not to the headcount.

A data security plan, then, is closer to a filed tax return than to a strategic plan. It exists because an authority expects to see it, and it describes controls the firm actually runs — access limits, encryption, incident response — rather than controls the firm admires. Writing one is an act of compliance first and craftsmanship second, which is why the task so often waits until something goes missing.

The document the IRS and the FTC already expect you to keep

Your office holds Social Security numbers, bank records, and tax returns for every client you serve. That has always been true. What has changed, if you have renewed your preparer tax identification number lately, is the expectation that you can show how you protect those records. A Written Information Security Program is the document that answers that expectation, and the government treats it as a requirement rather than a courtesy.

Two instruments govern this. The FTC Safeguards Rule obligates tax preparers to maintain a WISP. The IRS, for its part, expects a security plan to be in place as part of PTIN renewal. The agency has published its own guidance for practitioners: Publication 4557, Safeguarding Taxpayer Data, and Publication 5708, Creating a Written Information Security Plan for your Tax & Accounting Practice. These are not obscure references. They are the IRS telling you, in plain terms, what it wants to see.

An office with two employees and a filing cabinet is held to the same standard as a national firm. The rule does not scale down for size, and the IRS does not grade on effort. Consider a firm that has operated for years on trust and a locked door: the obligation arrives all the same, and the absence of a written plan is the deficiency, not the absence of good intentions.

You have options for producing the document. The IRS publications themselves contain templates. Tech 4 Accountants and Rush Tech Support sell WISP templates aimed at practitioners. NATP and the AICPA offer templates to members, and a managed service provider can draft a policy for you. Each route can satisfy the requirement. The question is which one leaves you with a program you understand and can follow, rather than a binder that sits untouched.

What a WISP is, and what it is not

A Written Information Security Program is a document. It identifies the risks to client data your office holds, assigns responsibility for protecting that data, and sets out the procedures your staff follow. Under the FTC Safeguards Rule, tax preparers must have one, and the IRS asks for it at PTIN renewal. That is the whole category: a written policy, kept current, that describes how your office handles information security.

It is not software. It does not scan your network, encrypt your drives, or block phishing emails. It is not insurance; it will not pay a claim after an incident. It is not a guarantee against a breach, and no document can be. A WISP that promises otherwise is overselling its own merchandise.

The document must describe your office as it operates: your people, your systems, your vendors, your actual practices. A firm of two bookkeepers working from laptops has different risks from a ten-person CPA office with a server room and three cloud applications. A template that describes an imaginary operation—one with an IT department, a formal risk committee, and a budget neither exists—protects no one because no one can follow it. The IRS Publication 4557 and 5708 templates, the NATP and AICPA materials, and the WISP templates from Tech 4 Accountants and Rush Tech Support all supply a starting structure. None of them can assess your risks for you. That work belongs to the person who knows where the files sit and who opens them.

A policy nobody reads protects no one. The Safeguards Rule expects your WISP to reflect your real operations, and an examiner can tell the difference between a document your office lives by and one purchased to satisfy a checkbox. The honest test is simple: hand the document to a new hire. If they can follow it, it works. If it describes a firm that does not exist, it does not.

What EEZY WISP provides

EEZY WISP is a Written Information Security Program: the security policy document a business is required to keep, written and maintained. That is the product. It exists because the obligation predates the purchase.

Tax preparers must have a WISP under the FTC Safeguards Rule, and the IRS requires one at PTIN renewal. A firm without this document is not merely behind on paperwork; it is operating without something the government already expects to see. The document must exist, and it must reflect the office as it actually runs.

The maintained part matters. An office’s systems, staff, and obligations change, and a policy left static stops describing the firm it covers. EEZY WISP keeps the document current rather than treating it as a one-time exercise in compliance theater.

Firms that prefer other routes have them. Tech 4 Accountants and Rush Tech Support sell WISP templates. The IRS publishes 4557 and 5708 as guidance. NATP and AICPA offer templates to members. An MSP can write a policy. Each approach asks something different of the firm: time, judgment, or both.

Pricing is on the site. EEZY WISP is part of the EEZYVERSE family, with one login across the EEZY products a company uses and one central bill at eezycloud.com/account/.

The document is not a substitute for the firm’s own judgment. It records the program; it does not run the office. A firm that wants to treat security as a living practice will find the document useful. A firm that wants a talisman will find it insufficient.

What it costs

EEZY WISP publishes its price at eezywisp.com. That is the whole answer, and it is the point. A firm can open the site, read the number, and decide. No sales call, no demo scheduled to learn the price, no form that trades an email address for a quote.

This matters because the alternatives do not all work this way. A template from Tech 4 Accountants or Rush Tech Support may list a price on its own site, or it may route a firm through a checkout flow that asks for contact details first. The IRS Publication 4557 and Publication 5708 templates cost nothing to download, which is a genuine price, though the cost of assembling them into a working program is measured in hours rather than dollars. Templates from NATP or AICPA follow each organization’s own purchasing rules. An MSP will quote a WISP as part of a broader engagement, which means the price arrives attached to a conversation about managed services. None of these approaches is wrong. They differ in how much friction stands between a firm and a number it can act on.

The friction is not trivial for a small office. A sole practitioner reviewing compliance obligations between client appointments does not benefit from a pricing process that requires a phone call during business hours. The question “what does this cost” has a single correct answer at any given moment, and a firm ought to reach that answer in one step.

Pricing for EEZY WISP products, including this one, sits on the site. A firm that wants the current figure can find it there and weigh it against the alternatives on its own schedule.

Getting started and the first week

Consider a firm that has just obtained a WISP document. The first week is not glamorous, but it is manageable.

Day one: the owner reads the document cover to cover. Not to memorize it, but to understand what it expects. A WISP from a provider such as EEZY WISP, Tech 4 Accountants, or Rush Tech Support will outline procedures for access control, password management, and offboarding. The IRS Publication 4557 and 5708 templates cover similar ground in plainer language. The owner’s task is to compare each procedure to what actually happens in the office.

Day two: the audit begins. Who has access to client files? More people than expected, probably. How are passwords handled? If the answer involves a sticky note or a shared spreadsheet, that is a gap. What happens when an employee leaves? Here is where the hypothetical firm discovers something uncomfortable: a former employee’s credentials still work on the shared drive. Nobody revoked them. Nobody thought to do so. The WISP gives the firm a procedure to follow—deactivate accounts, revoke remote access, retrieve company devices—and the owner follows it that afternoon.

Day three and four: assign responsibility. The WISP names a qualified individual to oversee the program. In a small firm, that is often the owner. The document also specifies who handles what when something goes wrong. Staff need to know their roles, not in theory, but in writing.

Day five: put the finished plan where staff can find it. A shared drive, a printed binder, somewhere accessible. The WISP is not a trophy; it is a working document. Staff should be able to consult it when a question arises, and the owner should review it annually or whenever circumstances change.

By Friday, the firm has a document it can show the IRS at PTIN renewal, and more importantly, it has closed a hole it did not know existed. That is the point.

The honest alternatives

A small office has several defensible routes to a written security plan, and each has its merits.

The IRS publishes its own guidance. Publication 4557, Safeguarding Taxpayer Data, and Publication 5708, Creating a Written Information Security Plan for Your Tax & Accounting Practice, cost nothing and carry the authority of the agency that will accept or reject your renewal. They are thorough. They are also, by design, generic: the office must translate federal prose into its own procedures, name its own systems, and fill its own blanks. That work is not difficult, but it takes hours, and the result must satisfy an examiner who did not write it.

Professional associations offer another path. NATP and AICPA members receive WISP templates with their dues—policies drafted for the tax trade, closer to daily practice than federal boilerplate. The same trade-off applies in milder form: the office must still customize the document to its own hardware, software, and staff, and must trust its edits to hold up under review.

Tech 4 Accountants and Rush Tech Support sell WISP templates built specifically for preparers and CPAs. These arrive with industry language already in place, which saves drafting time. They still require the office to verify that every claim in the document matches every machine in the office.

Finally, the office’s managed service provider can write a policy from scratch. An MSP knows the network, the backup schedule, and which machines run which operating systems. That knowledge is genuine. A policy written by an outside technician, though, may reflect the MSP’s habits more than the firm’s obligations, and the office remains responsible for a document it did not draft.

Each route ends at the same place: someone in the office must read the result, adjust it, and stand behind it. The alternatives differ chiefly in who performs that labor and how much of it remains when the template arrives.

How a WISP fits with the rest of the office’s security practice

A WISP is a record, not a safeguard. The office still needs the safeguards themselves: a password manager, multi-factor authentication on every account that offers it, access controls that limit client files to the staff members working on them, encryption on laptops and portable drives, and a vendor list that someone reviews at least annually. The WISP’s job is to say which of these the office uses, who runs each one, and when the office last checked that they still work. An examiner from the IRS or the FTC does not test the office’s firewall. The examiner asks for the document that describes the firewall, the policy behind it, and the person responsible for it.

This distinction matters because some firms buy a template, file it, and assume the work is done. The document without the practice behind it is a liability, not a compliance shortcut. The reverse is also true: an office with strong habits but no written program has the same exposure, because the Safeguards Rule requires the written program and the IRS asks for it at PTIN renewal.

Firms that want a template rather than a blank page have several honest options. Tech 4 Accountants and Rush Tech Support sell WISP templates built for tax practices. The IRS publishes its own starting points in Publications 4557 and 5708. NATP and the AICPA offer templates to members, and some firms have an MSP draft a policy to order.

EEZY WISP belongs to the EEZYVERSE family of products, which share one login and one central bill at eezycloud.com/account/. Support hours are published at eezycloud.com/support: Monday through Friday 9 AM to 8 PM and Saturday through Sunday 9 AM to 12 PM Eastern. For a firm already using other EEZY products, that is context, not a pitch. The document still has to match the practice. No template writes that part.

Consider a firm that signed its WISP in March, filed the renewal, and has not opened the document since. Two preparers have left, one has joined, the firm has switched portals, and it now feeds client documents into a cloud bookkeeping platform that did not exist in the file a year ago. The WISP, meanwhile, still describes a four-person office, a local server, and a vendor that the firm dropped in June. The document is current in the sense that it exists; it is not current in the sense that it describes anything.

The FTC Safeguards Rule requires tax preparers to maintain a WISP, and the IRS asks for one at PTIN renewal. Neither agency specifies that the program must reflect reality, but a program that describes a firm that no longer exists will not survive a close reading, and the gap between the paper and the practice is precisely what an examiner or a plaintiff’s attorney will find first.

An annual review, done properly, is not a ritual re-reading. It is a working audit of what has actually moved: staff, systems, vendors, and the threats that target them. Each of those changes the program hastily, and each deserves its own line of inquiry.

The problem: a WISP that sits still while the firm does not

The FTC Safeguards Rule does not ask a firm to write a security program once and file it away. It asks the firm to maintain one — to keep it current with the business it actually conducts. That verb, maintain, does the quiet work in the regulation. A program that described the firm accurately in January may misdescribe it by October, and the gap between the two is not a technicality. It is the difference between a document that demonstrates compliance and one that undermines it.

The IRS adds its own prompt. The PTIN renewal asks whether the preparer has a written information security plan in place, which means the question arrives on a schedule whether or not the document has kept pace with the year. A firm can answer yes and still be holding a paper relic.

The drift happens in ordinary ways. Consider a firm that adopts a new client portal in March, hires a seasonal preparer in January, and moves its document storage to a different cloud provider over the summer. Each change is reasonable. None of them is dramatic. But the WISP still names the old portal, the old headcount, and the old storage arrangement, and no one has revised the section on access controls to reflect who can now reach client data and from where. The document describes a firm that no longer exists.

This is the risk that annual review exists to catch. A WISP that describes last year’s practice is evidence against the firm, not for it. An FTC examiner, an IRS inquiry, or a state board asking questions will read the document against the firm’s actual operations, and the discrepancies will read as neglect rather than oversight. The same holds for a template pulled from Tech 4 Accountants, Rush Tech Support, or an IRS Publication 4557 starting point: any of these can serve as a foundation, but none of them updates itself.

The review is the mechanism that keeps the document honest.

What the Safeguards Rule actually asks you to revisit

The Safeguards Rule does not tell you to dust off your Written Information Security Program every January and read it aloud. It asks for something more demanding: a periodic reassessment of risk, an adjustment of safeguards in light of testing results and operational changes, and ongoing oversight of the service providers who touch client data. None of this arrives with a calendar date attached. The rule expects your program to reflect current reality, not the reality of the year you wrote it.

Consider a firm that added three staff members, moved its tax software to a hosted platform, and engaged a new e-signature vendor. Each change alters the risk picture. The rule’s maintenance provisions exist for precisely this reason: safeguards that fit last year’s operations may leave this year’s gaps wide open.

IRS Publication 4557 and Publication 5708 give tax professionals a workable framework for the same exercise. They translate the rule’s abstractions into questions a practitioner can answer: what data do you hold, where does it go, who can reach it, and how would you know if something went wrong.

A WISP template from any source—Tech 4 Accountants, Rush Tech Support, NATP, AICPA—still requires the firm to fill in its own specifics. Those specifics are the parts that go stale. Your vendor list, your access controls, your incident response contacts: all of it drifts the moment operations change. The template cannot track that drift. Only the person who runs the firm can.

What changes each year: the six things to check

Start with personnel. Who joined, who left, and whose access changed mid-year? Consider a firm that added a bookkeeper in March and never updated its access-provisioning section; the document still describes a two-person operation, and the newest hire can read everything the principal can. Offboarding matters as much: a departed employee’s active credentials are a finding waiting to happen.

Next, systems and software. New tax prep platforms, client portals, mobile devices, and migrations from a local server to cloud hosting each alter the security picture. A WISP written for desktop software does not describe a firm that moved its files to the cloud in July. If the document names products the firm no longer runs, revise it.

Third, vendors and service providers. The FTC Safeguards Rule requires oversight of third parties that touch client data. List who receives it now — payroll processors, cloud hosts, document-shredding services — and confirm contracts and due diligence are current. A template from Tech 4 Accountants or Rush Tech Support, or one drawn from IRS Publication 4557, will prompt this review; it will not perform it.

Fourth, the threat picture. New phishing methods, fresh IRS scam alerts, and disclosed vulnerabilities in software the firm already runs all belong in the risk assessment. A WISP that names last year’s scam is a historical document.

Fifth, physical and access controls. An office move, a new remote-work arrangement, or laptops purchased without verified encryption each change what the WISP must say.

Sixth, incident history and near-misses. If the firm weathered a phishing attempt or a misdirected email, the response section should reflect what the firm learned, not what it once assumed it would do.

How EEZY WISP handles the annual review

EEZY WISP is a written information security program — the security policy document a business is required to keep, written and maintained. The document is maintained. That is the point of an annual review, and it is built into the product rather than left to the firm’s memory. EEZY WISP is written for tax preparers subject to the FTC Safeguards Rule and the IRS requirement to have a WISP on the PTIN renewal.

The annual review is the working audit described above: staff, systems, vendors, and threats, each in turn, each checked against what the document says. When something has changed — a new preparer, a new piece of software, a vendor that no longer holds client data — the document is updated to reflect it. The review is not a ritual re-reading. It is the act of keeping the program current, and EEZY WISP is maintained so that the act is possible.

A firm that prefers to do this work itself has other routes. The IRS publishes templates in Publications 4557 and 5708. NATP and AICPA offer their own. Tech 4 Accountants and Rush Tech Support sell WISP templates, and an MSP can write a policy from scratch. Each is a legitimate way to produce the document. The difference is what happens after. A template is a starting point; a policy written by an MSP is a snapshot. EEZY WISP is maintained, which means the annual review is not the moment a firm discovers its program no longer describes its practice. The document is already being kept current. Pricing is on the site.

What the review costs in time and money

Pricing for EEZY WISP is on the site at eezywisp.com. The annual review itself carries no separate fee. The real cost is the hours a principal or office manager spends on the six checks above — typically a few focused hours for a small firm, more if vendors or systems changed substantially. That time is the price of keeping the document honest, and it is not optional under the Safeguards Rule, which expects the program to reflect current circumstances rather than the circumstances of some earlier year.

Compare the alternatives on their own terms. A template from Tech 4 Accountants or Rush Tech Support carries its own price — check the vendor, since none is stated here — and the review burden lands on the same principal regardless of which document the firm bought. An MSP-written policy arrives through a consulting engagement, which may suit a firm that wants someone else to do the thinking, though the engagement does not end the firm’s obligation to review what was written. The IRS 4557 and 5708 templates are free and demand the most self-assembly; a firm using them should budget the largest share of review time, because the document will not have been shaped to the firm’s particular systems and vendors in the first place.

The annual review, then, is not a recurring fee but the discipline that makes whatever document the firm owns worth having. A WISP that has not been read against the current staff roster, the current software stack, and the current vendor list is a historical record, not a program. The hours spent on the review are the difference between the two.

Getting started: the first review, week by week

Three weeks is enough. A firm that spreads the work across three weeks will finish; a firm that schedules a single afternoon will not.

Week one: read the WISP against reality. Take the current document and the firm’s actual practice, side by side. Mark every sentence that no longer matches what happens — a named employee who has left, a software tool no longer in use, a safeguard the firm describes but does not perform. Consider a firm that wrote its WISP three years ago and has since moved its client portal; the document still describes the old portal. That sentence is not a technicality. It is a misstatement about the firm’s own security, and an examiner will notice.

Week two: gather the facts. Work through the six checks from the section above and collect the raw material: the current staff roster, the vendor list, the software inventory, and any notes on incidents or near-incidents from the past year. Do not revise anything yet. The task this week is to know what is true.

Week three: revise, assign, and schedule. Rewrite the passages that no longer hold. Give each safeguard a named owner — one person, not a department. Then set the next review date, twelve months out, and put it on the calendar before the week ends. A review date that lives only in the WISP is a wish.

Firms using EEZY WISP work from the maintained document they already hold, so week one starts from a current text rather than an archaeological dig. Firms working from a template supplied by NATP, the AICPA, or an MSP should confirm that the template carries a review schedule; if it does not, add one. A WISP without a review date is a letter that never gets mailed.

Where the WISP sits in the rest of the stack

A WISP does not live in a drawer. It touches nearly everything else the firm operates. The IRS asks whether the firm maintains a written security program as part of the PTIN renewal; the answer should describe the actual program, not the one from two hires ago. Client engagement letters increasingly carry security representations — how data is stored, who can reach it, what happens when something goes wrong — and those representations should match the WISP’s text. Cyber insurance questionnaires probe the same ground: multifactor authentication, encryption, vendor oversight. If the WISP promises controls the firm has not implemented, the questionnaire becomes a liability rather than a formality. Portal and practice-management software deserve the same scrutiny. The WISP describes the security settings of these systems; when the software updates, or the firm switches providers, the document must follow. A firm that moved from one document portal to another last March but never revised its WISP is describing a firm that no longer exists.

Keeping the document current is easier when the document itself is easy to reach. EEZY WISP is part of the EEZYVERSE family, so a firm that uses other EEZY products signs in once and sees one central bill at eezycloud.com/account/. Support hours run Monday through Friday 9 AM to 8 PM and Saturday through Sunday 9 AM to 12 PM Eastern, published at eezycloud.com/support.

None of this requires a consultant or a weekend. It requires reading the document against the firm as it stands — the staff roster, the software stack, the insurance forms, the engagement letters — and correcting what no longer holds. An annual review, done honestly, is the difference between a document a firm has and a program a firm runs.

Consider a firm that consists of one enrolled agent and one bookkeeper, sharing a rented office and a server that hums in the corner like an appliance that knows too much. The FTC Safeguards Rule requires this firm to designate a qualified individual to oversee its information security program, conduct risk assessments, monitor service providers, and test the effectiveness of its safeguards. The rule does not specify whether the qualified individual may be the same person who answers the phones in March.

The gap between what the rule demands and what a two-person firm can implement is where most compliance anxiety lives. The regulation speaks in the measured cadence of institutions with dedicated IT departments and compliance officers; the typical tax practice speaks in the cadence of a professional who would like to finish the extension season without a ransomware incident. Somewhere between those two registers sits the Written Information Security Program—the document the IRS asks about on the PTIN renewal, and the artifact most likely to be requested when something goes wrong.

The rule is not unreasonable in its expectations. It is unreasonable only in its assumption that every covered firm possesses the infrastructure to meet them unassisted. For the practitioner who has spent the afternoon resetting a client’s forgotten password, the requirement to maintain continuous monitoring of network activity does not read as a best practice. It reads as a reminder that the law was drafted by attorneys who have never met a tax preparer.

What the Safeguards Rule actually requires of you

The regulation, codified at 16 CFR Part 314, asks for nine things. Stripped of its regulatory phrasing, the list reads as follows.

Designate a qualified individual to run your information security program. In a sole proprietorship, this is you. The title is less important than the responsibility: someone must own the program, keep it current, and answer for it.

Conduct a written risk assessment. You must identify where client data lives, how it moves, and where it is vulnerable — then document those findings and revisit them as your practice changes. An assessment that lives only in your head does not satisfy the rule.

Implement access controls and encryption. Limit who can reach client data to those who need it, and encrypt sensitive information both in storage and in transit. For most small firms, this means strong passwords, multi-factor authentication, and full-disk encryption — all of which you likely already have, but which the rule expects you to commit to writing.

Monitor your service providers. Your cloud storage, your practice-management software, your payroll processor — if a vendor touches client data, you are expected to have evaluated their security and to have that evaluation on record.

Train your staff. Anyone with access to client data must understand how to protect it. This includes recognizing phishing, handling data securely, and knowing what to do when something goes wrong.

Maintain the written program itself. The WISP is where all of these commitments live — the designated individual, the risk assessment, the controls, the vendor oversight, the training plan. It is the document a regulator would ask to see, and the IRS asks whether you have one when you renew your PTIN.

The rule does not require perfection. It requires a documented, good-faith program that matches the size and complexity of your firm. A two-person practice is not expected to operate like a bank. It is expected to have thought about the risks and written down what it is doing about them.

The risk assessment you can do without a consultant

The Rule requires a written risk assessment, which sounds like something involving binders. For a small firm, it need not be. Consider a firm that receives client documents through a portal, by email, on thumb drives, and occasionally as paper shoved under the door during tax season. That list, written down, is the beginning of the assessment.

Start with entry points. Where does client data arrive? Note each channel: your portal, email, physical mail, walk-ins, the thumb drive a client hands you with a smile and a shrug. Then identify who touches it. In a two-person firm, this is a short list, but it still includes you, your colleague, and anyone else who might see a file — a contractor, a cleaning crew, a spouse who borrows the laptop.

Next, trace where data rests and how it moves. Does it sit on a local server, in the cloud, on a laptop that travels? Does it pass through email attachments, a client portal, a shared drive? Write down each location and each path. A spreadsheet with three columns — entry, storage, movement — suffices. IRS Publication 4557 offers a framework for this exercise, and templates from Tech 4 Accountants or Rush Tech Support can provide structure if you prefer not to start from a blank page.

The point is not to produce a document that impresses an auditor with its thoroughness. The point is to see your own operation clearly enough to know where the risks are. A firm that has mapped its data flows can make reasonable decisions about protecting them. A firm that has not is guessing.

The Rule asks for reasonableness, not perfection. An afternoon with a spreadsheet, honestly filled out, is a defensible start. The assessment should be revisited when something changes — new software, a new employee, a new way clients send you files — but it does not need to be a recurring ordeal. It needs to exist, and it needs to reflect reality.

What a WISP is, and what it is not

A Written Information Security Program is, at bottom, a document. It records three things: the policies your firm has adopted to protect client information, the risks you have identified in the course of your work, and the controls you have put in place to address those risks. The FTC Safeguards Rule requires it to be written, and it requires you to maintain it. That second verb does more work than the first.

What a WISP is not: software. Purchasing a tool does not produce a program, and the Rule does not ask what you have bought. It asks what you have written down, what you have assessed, and what you are actually doing. Nor is it insurance. A policy document does not transfer risk; it documents how you intend to manage it. And it is not a binder you assemble once, place on a shelf, and produce in the event of an inquiry. A WISP that describes a practice your firm no longer follows is a liability wearing the costume of a safeguard. If your document says you encrypt laptops and you do not, the document itself becomes evidence against you.

The Rule expects the program to track your operations as they are, not as they were when you first drafted it. New software, a new employee, a new way of receiving documents — each of these changes your risk picture, and your WISP should reflect that. An outdated WISP is arguably worse than none at all, because it demonstrates you knew the right questions and stopped asking them.

Firms obtain this document in several ways. Some adapt the templates the IRS publishes in Publications 4557 and 5708, or use materials from professional associations such as NATP or AICPA. Some hire an MSP to draft one. Others purchase a maintained program from a specialist provider — Tech 4 Accountants and Rush Tech Support, among others, offer templates in this space. The format matters less than the fit: the document has to describe your firm, not a generic one.

The honest limits of a template

A template — ours, Tech 4 Accountants’, the IRS 4557 materials, one drafted by your MSP — solves a specific problem: producing a written program that satisfies the documentation requirement. What it does not do is anything else.

The rule asks you to identify reasonably foreseeable internal and external threats, assess the likelihood and potential damage of each, and evaluate the sufficiency of your existing safeguards. That is a judgment call about your systems, your clients, and your tolerance for inconvenience. No template can make it for you. It can list the categories of risk; it cannot tell you whether your office manager’s personal laptop, which accesses the firm portal on weekends, is a vulnerability you have accepted or one you have simply failed to consider.

Consider a firm that has adopted a practice-management platform, a document portal, and three separate bank-feed integrations, none of which the partners could explain under mild questioning. A template will give them a sensible password policy and a place to record their multifactor authentication decision. It will not tell them which MFA method suits their workflow, whether their vendors’ security practices meet the rule’s due-diligence standard, or why the bookkeeper’s credentials appear in a shared spreadsheet labeled “IMPORTANT.”

This is the honest arithmetic: the document is necessary and not sufficient. If you handle modest volume, understand your systems, and can follow written instructions, a well-constructed template is likely enough. If your practice is large, your stack is opaque, or your data practices have accreted over years without examination, you may need a security professional to perform the assessment the rule contemplates. That costs money. So does a data breach, rather more of it.

The rule does not demand perfection. It demands a program, implemented and maintained. A template gets you the program. The implementation remains, as it has always been, your department.

What EEZY WISP provides

EEZY WISP is a written information security program — the document itself, written and maintained, that the FTC Safeguards Rule requires a tax preparer to keep and that the IRS asks about at PTIN renewal. It is not software that scans your network, not a monitoring service, and not a consultant who visits your office. It is the policy document, drafted to satisfy the rule’s requirements, kept current as those requirements evolve, and available when you need to demonstrate that the document exists.

The distinction matters because much of the market addresses a different problem. Tech 4 Accountants and Rush Tech Support sell WISP templates, which provide the raw material but leave the drafting, updating, and tailoring to you. IRS Publications 4557 and 5708 offer government-issued frameworks, as do the NATP and AICPA templates — all legitimate starting points, all requiring you to turn a general outline into a working program. An MSP will sometimes write a policy as part of a broader engagement, though the quality and ongoing maintenance vary considerably. EEZY WISP occupies the narrower ground of delivering the finished, maintained document itself.

The service is hosted on Microsoft Azure. Pricing is on the site.

Whether a maintained document is what your firm needs depends on what you already have. If you have nothing, the requirement is not satisfied by good intentions. If you have a template you have not looked at since you downloaded it, you may have a document in name only. EEZY WISP addresses the specific, unglamorous task of keeping a compliant written program in place — a task that is easy to defer and difficult to reconstruct after the fact.

Getting the program into your practice

A Written Information Security Program arrives as a document, but it only becomes a program when it collides with the way your firm actually operates. That collision is best staged deliberately, over the course of a week, rather than left to happen on its own.

Start by reading the document against your data flows, not the ones the template assumes. Consider a firm that receives client documents through a secure portal, stores working papers in the cloud, and exchanges the occasional spreadsheet by email. Each of those channels needs to be accounted for in the program, and any that do not apply to your practice should be noted as such. The FTC expects the document to reflect your reality, not a generic ideal.

Next, adjust the named roles and procedures. If the program designates a Chief Information Security Officer and you are a two-person operation, the responsible party is whoever actually makes decisions about software, passwords, and vendor access. Name that person. If your firm has no IT department, the procedure for responding to a suspected breach needs to say who calls whom, not refer to an internal security team that does not exist.

Then distribute the finished document to everyone who touches client data, including seasonal staff and any bookkeeper or contractor with system access. Acknowledgment of receipt, even by email, creates a record that the FTC would find persuasive.

Finally, set a calendar reminder to revisit the program when your tools or staff change. A new practice management platform, a new employee, a new e-signature vendor — each of these triggers a review. The program is a living document, not a one-time purchase.

If questions arise during implementation, support is available Monday through Friday, 9 AM to 8 PM, and weekends 9 AM to noon Eastern, at eezycloud.com/support.

Alternatives and how EEZY WISP fits your stack

You have options, and it is worth surveying them before committing. The IRS offers Publications 4557 and 5708, free frameworks that outline what a security program should address. They are useful starting points, though they leave you to do the drafting. NATP and AICPA provide templates to their members, which are more tailored to tax practice but still require you to fill in the particulars of your own operation. Tech 4 Accountants and Rush Tech Support sell commercial WISP products, as do many MSPs who will draft a policy as part of their engagement. Each approach has its adherents, and none of them is wrong.

The question is not whether these alternatives exist but how much of your own time you are willing to spend assembling something the FTC will find adequate. A template from a professional association is a reasonable foundation if you have the patience to adapt it. An MSP-drafted policy may serve if your provider understands the Safeguards Rule specifically, not just IT generally. The free IRS publications will not write your program for you, but they will tell you what the agency expects to see.

EEZY WISP occupies a different position. It is a maintained, written program designed for the compliance requirement itself, not a byproduct of another service. If you use other EEZY products, they share a single login and a central bill at eezycloud.com/account/, though each is also sold independently. Support runs Monday through Friday, 9 AM to 8 PM, and weekends 9 AM to noon, Eastern time. Pricing is on the site.

Consider a firm that has done everything right on paper. It adopted a written information security program, encrypted its laptops, turned on multifactor authentication, and can produce the document on request. That same firm, however, has not run a security training session in two years, and the newest hire learned the firm’s procedures by watching the person at the next desk. Under the FTC Safeguards Rule, that gap is not a technicality. The rule requires qualified individuals to verify that all personnel receive security awareness training, updated as risks change, and that everyone with access to client data is trained on the program’s policies and procedures. A binder on a shelf does not satisfy that obligation. People do.

This is the one requirement that cannot be delegated to a document, and it is where most small firms quietly fall short. The training duty appears in the rule itself, not as a suggestion, and the IRS has folded it into its own expectations for tax professionals. A Written Information Security Program that names training but never delivers it is a program that exists on paper and nowhere else.

The training obligation hiding inside the Safeguards Rule

Every requirement in the Safeguards Rule can, in some fashion, be satisfied by a document. You can write your risk assessment into a file, your incident response plan into a binder, your access controls into a policy. The one thing you cannot write your way out of is § 314.4(c), which obligates you to provide your employees with security awareness training that addresses the risks you have identified and to keep that training current as those risks change. The Rule assumes a living practice, not a shelf.

The structure of the obligation matters. The Rule first requires a qualified individual to oversee your information security program—someone with the authority and competence to run it, whether that person is an employee, a contractor, or a fractional hire. That individual is responsible for the written program and, critically, for training the staff. The WISP document and the training program are separate deliverables. Possessing one does not discharge the other.

Here is where most small firms quietly fall short. They have a WISP—often a template from Tech 4 Accountants, Rush Tech Support, NATP, AICPA, or the IRS’s own Publication 4557 and 5708 frameworks—and they believe the work is done. But a template, however well drafted, contains no record that anyone has ever been taught to recognize a phishing email, to verify a wire request by phone, or to handle a client file with appropriate care. The IRS PTIN renewal asks whether your firm maintains a WISP. Answering yes when your only evidence is a PDF is technically accurate and practically thin. An examiner who asks for your training log will not be impressed by your table of contents.

Documented, recurring training is the difference between a program that exists and a program that functions. It need not be elaborate. It must be real, repeated, and provable.

What ‘good enough’ training looks like for a small firm

The Safeguards Rule does not prescribe a format, a vendor, or a curriculum. That flexibility is a gift to small firms, and also the reason so many do nothing: without a specification, the task feels undefined. It need not be. A defensible program for a ten-person firm is modest, repeatable, and documented.

The core components are few. A session once or twice a year, in person or by video, covering the threats your staff actually faces: phishing and business email compromise, password hygiene, secure handling of client documents, and what to do when something looks wrong. Onboarding training for every new hire, before they touch client data. Periodic phishing simulation, so the lesson is tested rather than merely heard. A written acknowledgment, signed and dated, confirming each employee completed the training. And a log recording who completed what, and when.

That log is the part firms most often skip, and it is the part an examiner will ask for first. Training that happened but was not recorded is, from a compliance standpoint, training that may as well not have. A shared spreadsheet with names, dates, and topics is sufficient. The record does not need to be elegant; it needs to exist.

Firms that want outside help have reasonable options. The IRS publishes free security-awareness material in Publication 4557, and NATP and AICPA member resources include training content. Managed service providers frequently bundle security training for their clients. A firm can also run the entire program in-house with a checklist, a log, and an hour of preparation. The Rule permits any of these.

Honesty requires a caveat: training does not prevent every breach. Determined attackers deceive trained people, and honest employees make mistakes. What training does is reduce the frequency of those mistakes and, just as importantly, demonstrate to regulators and to clients that the firm took its obligations seriously. Good faith, documented, is not a consolation prize. In a compliance review, it is often the whole game.

How EEZY WISP addresses training

EEZY WISP is the written security program document your firm is required to keep: a WISP written and maintained to satisfy the FTC Safeguards Rule and the IRS PTIN renewal question. That document is the foundation. It defines the policies your training must reinforce — acceptable use, access controls, incident response, vendor management — and gives your employees a single, coherent reference rather than a scatter of memos and good intentions.

What the document cannot do is stand at the front of the room. The Safeguards Rule treats employee training as an ongoing obligation, not a one-time event, and that cadence belongs to the firm. EEZY WISP does not include a training module, a learning management system, or a quiz feature. If you encounter a WISP product that claims to check the training box for you entirely, be skeptical; the rule expects your people to be trained, and someone at your firm has to own that calendar and keep the records.

In practice, that means pairing your EEZY WISP document with a recurring schedule — onboarding for new hires, annual refreshers for everyone, and targeted sessions when something changes, such as a new practice-management system or a revised IRS publication. IRS Publication 4557 remains a useful, free companion for structuring those sessions, and templates from Tech 4 Accountants, Rush Tech Support, NATP, or the AICPA face the same constraint: they supply the policy, not the classroom.

The EEZY WISP document gives your training a spine. It is where your policies live, where updates are reflected, and where an inspector can see that your program is written down rather than improvised. The teaching itself, and the records that prove it happened, remain your firm’s responsibility — as the rule intends.

What it costs

Pricing for EEZY WISP is published at eezywisp.com, and there is little point in repeating it here. The more useful question is what the alternative costs, because there is always an alternative.

A firm can assemble its own program from IRS Publication 4557 and the 5708 templates, or from the template libraries offered by NATP and AICPA. Tech 4 Accountants and Rush Tech Support sell WISP templates as well. None of these options carries a product price, but none of them is free. The cost is staff time: someone must read the source material, adapt it to the firm’s actual systems, write the policy, and then keep it current as the FTC’s expectations, the firm’s software, and its staff change. The Safeguards Rule requires the program to be maintained, not merely written once and filed away. A template that sits untouched for two years is a document, not a program, and an examiner will notice the difference.

Training adds another layer. A written policy does not train anyone. Someone has to build the training content, deliver it to new hires and returning staff, document that it happened, and repeat it on a schedule. In a three-person firm, that someone is usually the principal, and the hours come out of billable time.

EEZY WISP is priced on the site, and the EEZYVERSE arrangement means one login and one central bill at eezycloud.com/account if the firm uses other EEZY products. Support runs Monday through Friday, 9 AM to 8 PM, and weekends 9 AM to noon, Eastern, per eezycloud.com/support. Whether the subscription is cheaper than the hours depends on what the principal’s hours are worth, which is a calculation each firm can do without assistance.

Getting started and the first week

Consider a firm that has just purchased EEZY WISP: two partners, one administrative staff member, and a shared office where client files live on a single server. The document arrives, and the first task is reading it. Not skimming. Reading. The Safeguards Rule requires the firm to designate a qualified individual to oversee the program, and in a two-person firm, that person is likely one of the partners, already carrying a full client load.

The second task is the first training session. This is where the document meets the staff. The qualified individual walks through the WISP section by section: how client data is handled, what the acceptable-use policy requires, how to recognize a phishing attempt, what to do when something looks wrong. Attendance is logged, because the FTC expects firms to demonstrate that training occurred, not merely assert that it did. A sign-in sheet or a dated email confirmation suffices. The point is evidence.

The third task is scheduling. The Safeguards Rule does not specify a frequency, but semiannual refreshers are a defensible rhythm, and the calendar reminder should be set before the first session ends. Firms that intend to revisit training “when things slow down” are firms that never revisit it.

None of this requires an IT department. It requires a document, a designated owner, an hour with the staff, and a calendar entry. Firms that prefer to build their own program from IRS Publication 4557 or a template from NATP or AICPA face the same obligations; the document is only the beginning. If questions arise during setup, support is available Monday through Friday, 9 AM to 8 PM, and Saturday and Sunday, 9 AM to 12 PM Eastern, at eezycloud.com/support.

The first week is not the hard part. The hard part is the second session, and the third.

The honest alternatives

The IRS publishes Publication 4557, a readable overview of safeguarding taxpayer data, and its companion Publication 5708, which contains a WISP template a firm can adapt. Both are free, and both are competent. They explain what the Safeguards Rule expects and give a workable starting document. What they do not do is run a training session. A firm that builds its program from 4557 and 5708 still has to design the curriculum, deliver it, document attendance, and repeat it annually. The template is free; the hours are not.

The NATP and AICPA offer their own templates and guidance to members. These tend to be more tailored to tax practice than the IRS versions, and they come with the credibility of a professional association. The same caveat applies: the template does not train anyone. Someone in the firm owns that task, and if that person leaves, the program usually leaves with them.

Tech 4 Accountants and Rush Tech Support sell WISP templates aimed squarely at the tax and accounting market. These are closer to a finished document than the IRS versions, and they reflect the vocabulary of a working practice. They still require the firm to maintain the policy, update it as the rule evolves, and conduct the training itself.

An MSP-written policy is a different arrangement. A managed service provider will often draft the WISP as part of a broader engagement and may bundle employee training into the same contract. That is a genuine convenience. It also ties the firm’s compliance to a single vendor. If the relationship ends, the policy and the training infrastructure often end with it, and the firm discovers it owns less than it assumed.

None of these options is wrong. Each asks the firm to carry something it may not have the time or staff to carry.

Where training fits in the rest of the stack

A Written Information Security Program is the spine of your compliance obligations, but it is only one component. The Safeguards Rule expects a functioning security apparatus: multifactor authentication on every system that touches client data, encrypted storage for files at rest and in transit, access controls that limit staff to what their role requires, and a written incident-response plan that tells you what to do when something goes wrong. Training is the connective tissue among these elements. MFA fails when an employee approves an authentication request they did not initiate. Encryption fails when someone downloads client files to an unencrypted laptop to work from home. Access controls fail when a departing staff member retains credentials because nobody thought to revoke them.

The other components are largely set-and-verify. You implement MFA, you confirm it works, you revisit it periodically. Training is the one requirement that decays. A written policy does not forget itself; a person does. This is why the Rule treats training as ongoing rather than a single onboarding event.

For firms assembling their compliance stack, the pieces can come from several places. The WISP itself might be drawn from IRS Publication 4557, an AICPA or NATP template, a policy written by an MSP, or a purpose-built document from a provider. EEZY WISP supplies the written program; it belongs to the EEZYVERSE family, where one login covers the EEZY products a firm uses and one central bill sits at eezycloud.com/account, though each product is also sold on its own site. Whatever the source of the document, the training obligation remains yours. No template can sit with your receptionist and explain why the email she just received is a credential-harvesting attempt.

The Safeguards Rule asks for a program, not a binder. A program is only as good as the last time someone actually ran the training.

Consider a firm that has just received a letter from the IRS. Not an audit of a return — a request to see the firm’s Written Information Security Program. The owner knows such a document exists, or at least existed at some point, because someone drafted one years ago. What she cannot say, with any confidence, is where it is. It may be in a folder on a server that was replaced in 2023. It may be in the email account of a bookkeeper who left in 2024. It may simply be gone.

This is more common than anyone in the profession likes to admit. The FTC Safeguards Rule requires tax preparers, enrolled agents, CPA firms, and bookkeepers who handle client financial data to maintain a WISP — a written, current, accessible document that describes how the firm protects nonpublic personal information. The IRS, for its part, asks about it on the PTIN renewal. Both regulators expect the same thing: a document that exists on paper, in a known location, that can be produced on request. Not a policy that was described in a staff meeting. Not a set of security practices that everyone more or less follows. A document.

The distinction matters because the absence of one is difficult to explain after the fact. A firm that has been encrypting its files, using multi-factor authentication, and training its staff on phishing has done the substantive work — but without the written program, it has no way to demonstrate that work to anyone who asks. Regulators do not grade intentions. They ask to see the policy, and the conversation goes considerably better when the answer is a drawer that opens.

The document the PTIN renewal keeps asking about

Every year, somewhere between the continuing-education credits and the fee payment, the PTIN renewal presents a checkbox that gives people pause: Written Information Security Program. The wording is unhurried. It does not explain what a WISP is, where one might obtain such a thing, or what happens to the preparer who checks the box on faith. It simply expects the document to exist, and expects you to know that.

The expectation is not baseless. The IRS requires tax professionals to maintain a written information security plan as a condition of holding a PTIN, and the Federal Trade Commission’s Safeguards Rule obliges tax preparers — along with CPAs, enrolled agents, and bookkeepers who handle client financial data — to keep a written security program of their own. Two agencies, one document. The WISP is that document: a written record of how your firm protects client information, who is responsible for it, and what you do when something goes wrong. It is a policy, not a product. Not software, not insurance, not a certificate to frame. The paper itself, kept current, available on request.

The consequences of not having one are real, though the renewal screen is too polite to say so. The IRS can suspend or revoke a PTIN over a deficient security plan, and the FTC can pursue enforcement against firms that fail to maintain adequate safeguards. Neither agency needs to find a breach to find a problem; the missing document is the problem.

None of this requires panic, but it does require a document you can locate. Some firms write their own from IRS Publication 4557 and the accompanying templates, or adapt materials from professional associations such as NATP or the AICPA. Others purchase a prepared template from a specialist vendor. The distinction matters less than the drawer: whatever you choose, you should be able to open it and put your hands on the thing — because the renewal assumes you already have.

What a WISP is, and what it is not

A Written Information Security Program is a document. That sounds almost too plain to state, but the plainness matters, because much of the confusion around the requirement comes from treating it as something other than what it is.

The document does three things. It identifies the customer financial information your firm holds — tax returns, bank details, Social Security numbers, the quiet accumulation of a filing season. It describes the risks that information faces: a stolen laptop, a phished password, a former employee whose access was never revoked. And it sets out what you do about those risks — who is responsible, which safeguards you have in place, how you will respond when something goes wrong. The FTC’s Safeguards Rule expects this program to be written, and it expects the writing to be maintained as your practice changes. A policy written for a two-person firm in 2019 says little about the firm that firm became.

What a WISP is not: it is not software. Nothing runs in the background because a document exists. It is not a contract with a client, though clients may ask to see it. It is not a certificate, and no one hands you one for having written it.

It is also worth being honest about what the document accomplishes on its own. A WISP organizes your obligations and demonstrates that you considered them seriously. It does not, by itself, encrypt a single file or block a single login. The thinking and the doing are related but distinct, and a drawer full of unimplemented policy is its own kind of exposure.

The Safeguards Rule’s insistence on a written, maintained program is why the dusty PDF ages poorly. A trade-association template — the IRS offers Publication 4557 and Publication 5708, and NATP and AICPA members receive their own versions — provides a starting structure. But a template filled in once and forgotten does not reflect the firm you actually run, and the gap between the two is where examiners tend to look.

Who is actually required to have one

The FTC Safeguards Rule was written for “financial institutions,” a phrase that conjures banks and brokerages. The FTC reads it more generously. If your firm handles client financial data — tax returns, bank statements, payroll records, Social Security numbers — you are likely inside the definition, regardless of what your business card says. The rule does not care whether you work from a suite of offices or a spare bedroom.

Consider a firm that is, in every practical sense, three people and a filing cabinet. The Safeguards Rule applies to that firm with the same force it applies to a national accounting network. There is no small-business carve-out, no headcount threshold below which the obligation dissolves. “We are only three people” is a reasonable thing to say at a dinner party. It is not an exemption the rule recognizes.

The IRS adds its own layer. When you renew your PTIN, the IRS asks whether you have a written information security plan in place. This is not a rhetorical question. Publication 4557 lays out the Security Six and the broader expectations, and the PTIN renewal process puts the WISP question directly in front of you, each year, with a checkbox.

So the population of firms that need one is broad: tax preparers, enrolled agents, CPA firms, bookkeepers, and any small business that touches client financial information as part of its work. If you collect a client’s W-2, you are in.

The document itself can come from several places. Some firms adopt the templates in IRS Publications 4557 and 5708. Others use WISP templates from Tech 4 Accountants or Rush Tech Support, or templates offered through NATP or AICPA membership. Some ask their IT provider to draft one. The source matters less than the result: a written program, kept current, that you can produce when asked. The IRS and the FTC are not grading your prose. They want to see that the document exists, that it reflects your actual practice, and that you can find it.

Where firms usually get one, and the trade-offs

A firm that needs a WISP has four realistic routes, and each carries a different set of obligations.

The first is the do-it-yourself path. IRS Publications 4557 and 5708 contain template material a firm can adapt, and both are free. The catch is that a template is a starting point, not a finished program. Someone inside the firm has to read it, fill in the firm’s actual practices, and keep it current as those practices change. That someone is usually the person who already has the most to do.

The second route runs through professional associations. NATP and the AICPA offer WISP templates to their members. These tend to be better tailored to tax and accounting work than the IRS versions, and the price of admission is membership rather than a separate purchase. The same caveat applies: the template still needs to reflect what your firm actually does, and nobody from the association will check whether it does.

The third route is a vendor template. Tech 4 Accountants and Rush Tech Support both sell WISP templates aimed squarely at the same reader as this article. These are built for the requirement rather than adapted from general guidance, which saves time. Pricing is on their respective sites. What a purchased template generally does not do is maintain itself; the annual review and update remain the firm’s job.

The fourth route is an MSP. Some managed service providers will draft a WISP as part of a broader engagement — the security policy arrives bundled with the monitoring, the backup, and the monthly invoice. This can work well, though the document sometimes reflects what the MSP’s tools do rather than what the firm does, and a policy written to justify a contract is not quite the same thing as a program written for the rule.

EEZY WISP occupies the fourth chair at this table: a maintained document, written and kept current for the requirement itself. The distinction matters less on day one than it does in year three, when the review comes due and the drawer has to open.

What EEZY WISP is, stated plainly

EEZY WISP is a Written Information Security Program. That is the document itself — the security policy a business is required to keep, written and maintained. It is not software that scans your network, and it is not a service that manages your firewalls. It is the policy document, the one the FTC Safeguards Rule expects you to have written down and the IRS asks about when you renew your PTIN.

This puts it in a recognizable category. The same category includes the WISP templates sold by Tech 4 Accountants and Rush Tech Support, the templates the IRS publishes in Publications 4557 and 5708, and the templates that NATP and AICPA make available to their members. A firm with a capable MSP may also have had that MSP write a policy. These are all real ways to arrive at a written program, and a reasonable person could choose any of them.

EEZY WISP exists for the tax preparer, enrolled agent, CPA firm, or bookkeeper who wants the document itself handled — written and maintained — without having to assemble it from a template or delegate it to a vendor whose main business is something else. Pricing is on the site at eezywisp.com.

EEZY WISP is also part of the EEZYVERSE family, so if your firm uses other EEZY products, you carry one login and one central bill. That is context, not a reason to buy. The reason to buy, if there is one, is simpler: you need a WISP, and this is a WISP.

The first week with a written program

Consider a firm that has just signed up for EEZY WISP, or downloaded the IRS Publication 4557 template, or taken delivery of a policy from its MSP. The document arrives. It is longer than expected. The sensible first move is to print it, read it once without editing anything, and then read it a second time with a pencil, marking every sentence that does not match the office as it actually runs.

The gaps announce themselves quickly. The policy says passwords are changed every ninety days; the office has not changed a password since the software vendor forced one. The policy assigns security oversight to a named employee who left in March. The policy requires encryption on laptops; one laptop predates the policy and nobody has checked. None of this is unusual. It is, in fact, the normal condition of a small firm that has had a WISP for years without opening it.

The first week is for closing the obvious ones. Name a current employee as the responsible party. Turn on the password manager. Confirm the backups run and, more important, that a restore has been tested. Write down where client data lives — every laptop, every portal, every shared drive — because the policy will assume a tidy map and the office will have a messy one.

What the first week is not: finished. The document is the beginning of the work, not the end of it. A WISP describes a program, and a program has to be operated — reviewed on a schedule, updated when staff or software changes, revisited after anything goes wrong. This is where most programs quietly fail, not in the writing but in the maintaining, when the binder goes back in the drawer and the drawer stays shut.

A firm that spends its first week honestly reconciling policy to practice will have a weaker document and a stronger program than one that files the WISP unread. The IRS, on a PTIN renewal or in an examination, will ask to see the program. The better question is whether the person who answers the door can describe what it actually does.

How a WISP sits among the rest of your obligations

A WISP is not a freestanding chore. It sits inside a practice that already has obligations, and it reads better when you treat it as one document in a drawer that also holds your engagement letters, your software agreements, and whatever password policy you have actually been following. The FTC Safeguards Rule asks for a written program that fits your size and the data you hold. The IRS asks for the same document at PTIN renewal. Neither agency expects a treatise. Both expect the document to exist, to be current, and to bear some resemblance to how the firm actually operates.

Consider a firm that already sends engagement letters, runs practice management software, and stores client files in the cloud. The WISP does not replace any of that. It names it. The letter that tells a client how their data is handled, the software vendor’s security page, the firm’s own rules for remote access: the WISP gathers these into one place and states who is responsible for keeping them true. If your firm uses a template from Tech 4 Accountants, Rush Tech Support, the IRS 4557 or 5708 materials, a NATP or AICPA model, or a policy your MSP drafted, the WISP is that document, maintained. The source matters less than the upkeep.

Where a firm buys its WISP matters less than whether the document survives contact with January. A WISP that names software the firm no longer uses, or an employee who left, is a liability dressed as a policy. This is the quiet argument for keeping the document close to the rest of the practice’s operations. EEZY WISP is part of the EEZYVERSE family, which means one login across the EEZY products a company uses and one central bill at eezycloud.com/account/, with each product also sold on its own site; the sites are hosted on Microsoft Azure. The point is not the family name. The point is that a document kept near the tools it describes is more likely to be updated when those tools change.

The requirement is real, and the document is obtainable. The distance between having a WISP and not having one is smaller than the distance between having one and maintaining it. The first is a purchase or an afternoon. The second is a habit, and it is the habit the examiners are grading.

Consider a firm that lists “encrypt sensitive data” in its Written Information Security Program, files the document with its PTIN renewal, and considers the matter settled. Then an FTC examiner asks which algorithm the firm uses, whether encryption is applied at rest or in transit, and who verified the configuration last quarter. The firm has no answer. The WISP, technically present, is functionally useless.

This is the gap between policy and practice that regulators have learned to exploit. The Safeguards Rule does not ask for intentions. It requires specific administrative, technical, and physical safeguards, each one documented with enough precision that an outsider could verify its implementation. Encryption, multi-factor authentication, and backup procedures are among the most commonly cited controls in WISPs—and among the most frequently hollow when tested.

The question is not whether your WISP mentions these controls. The question is whether it describes how they operate, who maintains them, and how the firm confirms they still work. A regulator reading your program should find answers, not aspirations.

The gap between listing controls and describing them

A tax preparer searching for WISP help will encounter no shortage of documents promising to solve the problem in an afternoon. The IRS Publication 4557 template, the NATP and AICPA frameworks, the offerings from Tech 4 Accountants and Rush Tech Support—each provides a foundation. Yet most arrive at the same impasse: a page that announces the firm will encrypt data, enable multi-factor authentication, and maintain backups, then moves briskly to the next topic. The document exists. Whether it functions is another matter.

The FTC Safeguards Rule requires a written program, a distinction that separates a policy from a prayer. The IRS PTIN renewal asks whether you have a WISP, which creates the impression that possession alone satisfies the obligation. It does not. The genuine exposure lies in an FTC examination following a complaint, or in the frantic hours after a ransomware incident when a forensic auditor asks precisely how your encryption was configured and who verified it last quarter.

Consider a firm that discovers its template WISP states “we use encryption” without specifying whether this means full-disk encryption on office workstations, file-level encryption for client tax returns stored in cloud software, or TLS for data in transit between applications. The distinction matters when a laptop is stolen from a car, or when a browser-based tax program transmits data across jurisdictions. Key management—who holds the recovery keys, how they are stored, what happens when an employee departs—typically goes unmentioned. MFA fares no better: “enabled where available” avoids the harder question of which systems require it, which authentication methods are permitted, and whether hardware tokens are treated differently than SMS codes. Backups, meanwhile, are declared “regular” without addressing retention periods, encryption of backup media, or the tested interval between backup completion and verification of restore capability.

An MSP can draft these controls with technical specificity, though the quality varies with the engagement. The preparer who treats the WISP as a compliance checkbox, however, retains the liability when the checklist fails under pressure.

What a defensible control description actually requires

A regulator reading your WISP does not want poetry. They want coordinates: what, where, by what means, and who verifies. The difference between a passing audit and a follow-up letter often comes down to whether your controls could actually be executed by someone other than the person who wrote them.

Consider encryption. A defensible entry specifies which data categories are covered (client tax returns, bank account numbers, EFIN credentials), where that data resides (local workstations, cloud storage, email in transit), and where it travels (portal uploads, e-file transmissions, backup replication). The standard matters: AES-256 at rest, TLS 1.2 or higher in transit. Most critically, who holds the encryption keys—your firm, your cloud provider, or a third party—and how key access is governed when employees depart. A WISP that states merely “data is encrypted” documents a wish, not a control.

Multi-factor authentication demands similar precision. The method matters: TOTP applications, hardware security keys, or SMS with documented acknowledgment of SIM-swapping risks. Which systems require it—email, tax software, remote access, cloud storage—and which, if any, carry exemptions with written justification. A principal who disables MFA on the server “just for now” and forgets to re-enable it has created a gap that a vague policy cannot explain away.

Backups, too, collapse under generality. Frequency (continuous, daily, weekly), retention periods, testing schedules, offline or air-gapped copies, and recovery time objectives—each element must be stated and assigned. A backup that has never been restored is a hypothesis.

No control prevents all breaches. Documentation quality determines whether your cyber insurer pays, whether the FTC accepts your corrective plan, and whether you can demonstrate due diligence. Templates from IRS Publications 4557 and 5708 provide frameworks but leave implementation specifics to the firm. MSP-written policies vary widely in specificity. Tech 4 Accountants and Rush Tech Support templates approach this with different levels of prescriptive detail. The question is not which template you purchased, but whether your finished document could guide a stranger through your actual environment.

How EEZY WISP structures these three controls

EEZY WISP is a Written Information Security Program—the security policy document a business is required to keep, written and maintained. On the three controls that regulators scrutinize most closely, it takes a particular approach: pre-drafted language that compels specificity without fabricating answers.

For encryption, the document does not declare that data is “encrypted” and move on. It provides control language requiring the firm to name its encryption software, identify who holds the keys, and state where encryption applies in transit versus at rest. The same structure governs multi-factor authentication: the firm must specify which systems require MFA, which factors it accepts, and who enforces exceptions. Backups follow suit—interval, retention period, offsite location, and test frequency are all fields the firm completes with its own operational specifics. Blank spaces would invite procrastination; false specifics would invite worse. The product demands the middle ground.

This distinguishes EEZY WISP from template approaches that leave firms to improvise. The IRS Publication 4557 and 5708 templates, NATP and AICPA offerings, and the policy your MSP might draft all vary in prescriptiveness; some stop at principle, others at checklist. EEZY WISP’s control language is designed to produce a document that answers the follow-up question before it is asked.

The document is maintained as regulations and firm practices change. Sites are hosted on Microsoft Azure. For firms that need to update these controls—say, after switching backup providers or rekeying encryption—the EEZYVERSE family centralizes access: one login across products, with billing at eezycloud.com/account/. Support hours are Monday through Friday 9 AM to 8 PM and Saturday through Sunday 9 AM to 12 PM Eastern, which covers most business-day scenarios where a policy revision cannot wait.

Pricing and what the commitment involves

Pricing is on the site. What merits scrutiny is not the figure itself but what the commitment actually purchases. A WISP that treats encryption, MFA, and backups as check-box items is a document that ages poorly, and aging poorly in this context means becoming evidence against the firm that adopted it.

The obligation is ongoing. Encryption standards advance; what satisfied NIST guidance three years ago may not now. MFA methods deprecate—SMS-based verification, once commonplace, now carries documented vulnerabilities that regulators have noticed. Backups without periodic tested restoration are merely hopeful gestures, and the testing must itself be documented. The WISP must describe not merely that these controls exist but how they are validated, by whom, and on what schedule. A regulator’s follow-up question is never “Do you encrypt?” It is: “Show me the last review of your encryption standard, and who signed off.”

Consider the alternatives. Drafting from IRS Publications 4557 or 5708 templates demands substantial labor to operationalize—the templates provide a skeleton, not the muscle of specific procedures and review cycles. An MSP-written policy may suffice initially, though experience suggests uneven quality and no guarantee of annual revision; the MSP’s incentive is technical service, not regulatory maintenance. Products from Tech 4 Accountants and Rush Tech Support offer structured approaches, as do templates from NATP and AICPA. Each requires the same evaluation: does the commitment include update cadence, or does it terminate at purchase?

EEZY WISP is maintained as a living document, which is to say it is revised to reflect current standards rather than left to fossilize. For firms already using other EEZYVERSE products, the arrangement is consolidated: one login, one central bill at eezycloud.com/account/. Support runs Monday through Friday 9 AM to 8 PM and Saturday through Sunday 9 AM to 12 PM Eastern, hours published at eezycloud.com/support. These are conveniences, not substitutes for the substantive question: whether the WISP you buy today will still defend you when the examiner arrives tomorrow.

The first week: from account to auditable descriptions

Consider a firm that has listed “encryption, MFA, backups” on a prior compliance questionnaire but lacks written specifics. The regulator’s next question—how, specifically, and who checks—would meet silence or improvisation. This is not an uncommon position. Many practices have satisfied initial inquiries with bullet points, only to discover that the FTC Safeguards Rule and IRS scrutiny require documentation that could survive follow-through.

The first week with EEZY WISP involves logging into the EEZYVERSE system and accessing the pre-structured WISP template. The encryption, MFA, and backup sections are not blank pages awaiting aspirational language. They are structured fields that prompt for software names, responsible parties, frequencies, and verification methods. A firm might enter that BitLocker encrypts local drives, that Microsoft Authenticator handles MFA with enforcement through Azure AD conditional access policies, that Veeam runs nightly backups to an offsite repository with monthly restoration tests assigned to a named technician. The template insists on specificity; it will not accept “industry standard” as an answer.

This discipline transforms the document from a one-time exercise into a maintainable record. When the software changes, the responsible employee departs, or the backup frequency shifts, the WISP is amended. The alternative—starting from an IRS Publication 4557 template or a generic policy from an MSP—often produces a document that sits untouched until the next compliance event, at which point its contents may no longer describe actual practice.

Support is available during published hours if questions arise on how to describe a particular control. For firms using multiple EEZY products, central billing is handled through eezycloud.com/account/. The point, however, is not administrative convenience. It is that a WISP worth keeping is one that accurately reflects what the firm does, who does it, and how anyone would know.

The honest alternatives and their tradeoffs

The IRS offers Publication 4557 and its companion 5708 templates at no cost. They are, by design, frameworks—useful for orienting a firm to the Safeguards Rule’s categories, but they leave the operative specifics of encryption protocols, MFA implementation, and backup verification procedures as exercises for the reader. A practitioner with both the time and the security fluency to draft these sections competently will find them adequate starting points. Most tax preparers, one suspects, do not.

NATP and AICPA templates serve their respective memberships with industry-appropriate scaffolding. They address the vertical’s particular risks more directly than the IRS publications, though they may bundle with membership dues or continuing education offerings. The specificity of their technical controls varies; some editions handle encryption and MFA with reasonable granularity, others with a discretion that leaves the same implementation gaps.

Tech 4 Accountants and Rush Tech Support each market WISP templates as commercial products, and their approaches to the encryption-MFA-backup triad differ in instructive ways. Tech 4 Accountants tends toward prescriptive detail—specific tool categories, configuration standards, verification cadences—while Rush Tech Support’s template structure emphasizes assignable responsibility and procedural workflow. Neither approach is inherently superior; the fit depends on whether a firm lacks technical guidance or operational discipline.

The MSP-written policy occupies its own category, and it is the most uneven. A capable managed services provider may produce a document that accurately reflects the firm’s actual controls, with encryption standards, MFA scope, and backup testing procedures specific to the environment they manage. The hazard is conflation: too many MSP policies read as service descriptions with security language grafted on, documenting what the vendor does rather than what the firm must govern. When the regulator asks who checks, the answer becomes circular—the MSP checks themselves, and the WISP records their assurance.

The honest tradeoff, then, is between labor and precision. Free templates demand more of the former; paid alternatives offer varying degrees of the latter; MSP policies risk substituting vendor convenience for institutional accountability.

Where a WISP lives in the firm’s operational stack

A Written Information Security Program is not a piece of software you install. It is a document that sits between your firm’s operational reality and the regulator’s expectation that you can explain it. This distinction matters because a WISP that merely names encryption, multi-factor authentication, and backups without connecting them to actual tools and actual people is a promise without plumbing.

Consider a firm that prepares returns in Drake Tax, stores client documents in a practice management system with optional MFA, and runs backups to a cloud service with its own encryption claims. The WISP must specify which of these systems handles data at rest versus in transit, whether MFA is required for all users or only some, how often backups are tested, and who verifies that the configurations have not drifted. The document does not replace the tax software’s encryption or the backup provider’s infrastructure; it describes how the firm ensures those controls remain active and appropriate.

This is where many template-based approaches falter. The IRS Publication 4557 template, the NATP or AICPA frameworks, and policies drafted by an MSP may list the right controls in the abstract but leave the firm to map them to its specific stack. A firm using Tech 4 Accountants or Rush Tech Support templates faces the same translation problem: the WISP must be reconciled with whatever combination of Drake, Lacerte, QuickBooks Online, SharePoint, or local servers the firm actually operates. If the stack changes and the WISP does not, the document becomes a historical curiosity rather than evidence of a living program.

For firms using multiple EEZY products, the EEZYVERSE single login and central billing at eezycloud.com/account/ reduce the administrative friction of managing several tools, though each product including EEZY WISP is also sold on its own site. The practical requirement remains: the WISP must accurately describe controls the firm actually operates, updated when the stack changes, with support available during the hours a small firm might need to make those updates—Monday through Friday 9 AM to 8 PM and Saturday through Sunday 9 AM to 12 PM Eastern, as published at eezycloud.com/support.

Consider a firm that has just reached the IRS PTIN renewal screen after updating its preparer information and paying the fee. The cursor hovers over a checkbox asking whether the business maintains a data security plan. The language is sparse—”security policy” or “plan,” perhaps a reference to protecting client information—without specifying length, format, or whether the document has been reviewed since it was first drafted. An honest preparer who keeps client files encrypted, uses strong passwords, and has never suffered a breach might still pause, uncertain whether an informal understanding among staff qualifies or whether the IRS expects something that would satisfy an examiner.

The hesitation is warranted. The PTIN renewal does not ask whether your defenses are effective, whether you have documented them, or whether they meet the FTC Safeguards Rule’s standards for a Written Information Security Program. It asks, in effect, whether you have a policy—a question that conflates intention with evidence. A preparer who answers “yes” based on a verbal agreement with a part-time bookkeeper has, by the screen’s logic, satisfied the prompt. One who answers “no” because the firm lacks a formal WISP risks denial of the PTIN, even if the underlying security practices are sound.

The vagueness serves no one well. The IRS requires a WISP on the PTIN renewal, and the FTC mandates one under the Safeguards Rule, yet the renewal interface offers no guidance on what either agency considers sufficient. The result is a compliance gap where the most scrupulous preparers agonize and the least attentive click through—a design that tests temperament more than it tests security.

What the IRS Actually Asks During PTIN Renewal

The PTIN renewal screen presents its security questions with a studied brevity that borders on the oracular. You are asked whether your firm has a data security plan, whether you have reviewed it, and whether you have communicated it to your staff. Each question demands a binary yes-or-no response. There is no upload function, no field for elaboration, no opportunity to explain that your plan is seventeen pages or seventeen sentences, that you drafted it yourself or inherited it from an MSP, that it sits in a binder or lives in cloud storage. The IRS simply wants the box checked.

This minimalist approach is not an oversight. The questions derive from IRC §7216 and its attendant regulations, supplemented by IRS Publication 4557, not from the FTC Safeguards Rule. The distinction matters in theory more than in practice. The FTC rule mandates a Written Information Security Program with specific elements: risk assessment, access controls, encryption standards, incident response. The IRS, operating under different statutory authority, merely asks whether you have a plan and whether you have bothered to look at it lately. The two regimes cover substantially the same ground—client financial data must be protected—but the IRS frames its inquiry as a matter of tax-preparer professionalism rather than consumer-protection compliance.

What the questions do not ask is equally telling. They do not ask whether your plan meets any particular standard, whether it has been tested, whether you have suffered a breach, or whether you could produce it within twenty-four hours of an examiner’s request. They do not distinguish between a comprehensive WISP from a service like EEZY WISP, a template from NATP or AICPA, the IRS’s own Publication 4557 or 5708 boilerplate, or a document your cousin who “does computers” wrote between playoff games. The ambiguity is deliberate: the IRS lacks the resources to evaluate thousands of individual security programs, so it settles for a modest behavioral nudge. Check the box, and the liability shifts, at least partially, to you.

The overlap with the FTC Safeguards Rule, however, means that a box-checked plan may not suffice if the FTC comes calling. An honest preparer hesitates because the right answer to the IRS question—yes, I have a plan—says nothing about whether that plan would withstand scrutiny elsewhere.

Why These Questions Exist and What They Expect

The PTIN renewal does not ask for your WISP’s table of contents. It asks, in essence, whether you have one—whether you have considered how client data moves through your practice, who can touch it, and what happens when something goes wrong. The IRS inherited this concern from the FTC Safeguards Rule, which obliges financial institutions (a category that includes tax preparers) to maintain a Written Information Security Program. The renewal questions are a lightweight compliance check, a pulse taken annually rather than a physical exam.

The vagueness is partly the point. Regulators are less interested in whether you own a document with the right title than in whether you have exercised judgment about your own risks. A preparer who has walked through the IRS Publication 4557 checklist, or worked with a template from NATP or AICPA, and actually adapted it to their practice has done what the question intends to capture. One who downloads a generic WISP from a template site, renames it, and forgets it has satisfied the letter and missed the spirit. The renewal screen cannot distinguish between the two. It is an honor system with consequences deferred.

Consider a firm that checks every box, files the renewal, and keeps no incident-response log, no access review, no training record. The IRS does not audit these answers in real time. The FTC might, eventually, and a state board certainly could following a client complaint or a data breach. The gap between checking a box and maintaining a living program becomes material at precisely the wrong moment—when a preparer must demonstrate that their security posture was reasonable, documented, and ongoing. The renewal questions test awareness; they do not verify implementation. That verification happens elsewhere, and usually under duress.

The honest preparer hesitates because the questions are doing two jobs at once: they ask for a simple yes, but they imply a standard of care that is neither simple nor static. The correct response is not merely to possess a WISP, but to treat it as a practice obligation rather than a filing artifact. EEZY WISP is built around that distinction, as are the template approaches from Tech 4 Accountants or Rush Tech Support, or a policy drafted by an MSP. The difference lies not in the document’s existence but in whether it reflects actual practice—and whether you can show that it does.

What EEZY WISP Provides for These Questions

EEZY WISP is a Written Information Security Program—the security policy document a business is required to keep, written and maintained. Tax preparers must have a WISP under the FTC Safeguards Rule, and the IRS requires one on the PTIN renewal. What EEZY WISP offers is the document itself: a complete program that addresses the policy questions the renewal screen raises, from data-retention schedules to incident-response procedures, without leaving the preparer to guess what wording might satisfy either regulator.

The program is built for the specific obligations of tax and accounting practices. It is not a generic template dressed up with a logo swap. The distinction matters because the PTIN renewal questions assume a level of operational detail—how you handle client data, who has access, what happens when someone leaves—that a downloaded PDF from IRS Publication 4557 or 5708, however useful as guidance, does not by itself constitute. Industry templates from NATP or AICPA, or the WISP offerings from Tech 4 Accountants and Rush Tech Support, provide their own approaches to this gap; an MSP-written policy is another path, though quality varies with the provider’s familiarity with tax practice. EEZY WISP occupies this same category of finished document, not checklist or tutorial.

For firms already using other EEZY products, the account sits within the EEZYVERSE family: one login across the EEZY products a company uses, with one central bill at eezycloud.com/account/. Support hours are published at eezycloud.com/support: Monday through Friday 9 AM to 8 PM, Saturday and Sunday 9 AM to 12 PM Eastern. The site and document hosting run on Microsoft Azure. Pricing is on the site.

What the renewal screen asks for, in the end, is evidence of a living policy. EEZY WISP provides the document. Whether it answers the questions to your satisfaction is something you can determine before purchase.

What It Costs

Pricing is on the site. That is the only figure EEZY WISP publishes, and the only one needed here.

The question, of course, is what that figure buys you beyond the document itself. The PTIN renewal asks whether you maintain a data-security plan; it does not ask whether you wrote it yourself, adapted an IRS template, or purchased one from a vendor. An honest preparer might reasonably conclude that any of these routes satisfies the checkbox. The IRS Publication 4557 and 5708 templates cost nothing. NATP and AICPA offer templates to members. Tech 4 Accountants and Rush Tech Support sell WISP products of their own. Some firms simply have their MSP draft something serviceable and call it done.

Against these alternatives, EEZY WISP is positioned as a maintained product rather than a one-time document. The distinction matters if you consider what the FTC Safeguards Rule actually requires: not merely possession of a policy but ongoing review and adjustment as risks change. A template downloaded in haste and filed away may technically answer “yes” to the PTIN question this year. Whether it would withstand scrutiny after a data incident is another matter entirely.

EEZY WISP is sold on its own site and as part of the EEZYVERSE family, with central billing at eezycloud.com/account/. Support hours are published at eezycloud.com/support: Monday through Friday 9 AM to 8 PM, Saturday and Sunday 9 AM to 12 PM Eastern. These arrangements are worth noting only if you anticipate needing revisions or clarification—scenarios that tend to arise at inconvenient moments, such as when a client asks what safeguards you actually have in place.

The cost of getting this wrong is not priced on any vendor’s site. The FTC may impose civil penalties for Safeguards Rule violations; state regulators and professional liability carriers have their own appetites for documentation. The PTIN renewal question, with its deliberate vagueness, offers no guidance on whether your answer would survive such examination. It merely asks. What you pay for, in the end, is not the policy itself but the reduced probability of discovering its inadequacy at the wrong time.

Getting Started and the First Week

Consider a firm that purchases EEZY WISP on a Monday morning. By afternoon, they have the document framework: a structured Written Information Security Program organized around the FTC Safeguards Rule’s core requirements, with sections for risk assessment, access controls, data retention, incident response, and the rest. What they do not have—what no template, however well constructed, can provide—is a description of their systems, their vendors, and their actual procedures. That work remains.

The first week, then, is less about writing than about inventory. Someone at the firm must determine which computers hold client tax data, whether those machines are encrypted, who has administrative privileges, and whether the backup system actually functions as assumed. The EEZY WISP template asks these questions explicitly; answering them honestly often reveals gaps. Perhaps the firm discovers that a contractor retains remote access after engagement’s end, or that the “cloud” storage arrangement lacks a proper business associate agreement. The template does not solve these problems. It surfaces them.

Responsibility assignment follows. The Safeguards Rule requires a qualified individual to oversee the program; the WISP identifies this role, but the firm must name an actual person, document their authority, and ensure they receive the access necessary to perform the function. Annual review dates must be scheduled—noted in calendars, not merely acknowledged as a good intention. The IRS PTIN renewal asks whether you have a security policy and whether you review it annually. These are binary prompts; the renewal screen does not inquire whether your policy accurately describes your practice, whether your staff have read it, or whether the review you scheduled actually occurred. The questions are a prompt, not an endpoint.

Real alternatives function similarly. A template from Tech 4 Accountants or Rush Tech Support, an IRS Publication 4557 framework, or a policy drafted by an MSP all require this same population step. The NATP and AICPA templates likewise provide structure demanding firm-specific content. The difference lies in the scaffolding’s clarity and the guidance for identifying what, precisely, needs customizing. EEZY WISP is hosted on Microsoft Azure and, like other EEZYVERSE products, shares a single login and central billing at eezycloud.com/account/. Support hours are Monday through Friday 9 AM to 8 PM and Saturday through Sunday 9 AM to 12 PM Eastern, published at eezycloud.com/support. These details matter when a preparer, mid-inventory, encounters a question the template raises but cannot itself answer.

By Friday, the firm possesses a populated first draft, a calendar entry for annual review, and a list of gaps requiring remediation. The PTIN renewal can now be completed with accuracy. Whether the firm’s security posture merits that accuracy is a separate question—the document is a starting point, not a finished one.

The Honest Alternatives

Several paths lead to a document you can present at PTIN renewal. Each carries its own burden of adaptation.

The IRS offers Publications 4557 and 5708, free and self-directed. These are not fill-in-the-blank templates so much as explanatory guides with sample language. A preparer must extract, interpret, and assemble the relevant provisions, then determine which controls apply to their particular setup. The price is right; the hours required are not trivial, and the risk of misinterpretation falls entirely on the firm.

Tech 4 Accountants and Rush Tech Support both sell WISP templates marketed to tax practices. These arrive closer to completion than IRS publications, though the purchaser still bears responsibility for customizing procedures to actual operations, documenting risk assessments, and establishing a review cadence. Quality varies with how diligently the preparer adapts the template rather than signing and filing it away.

NATP and AICPA templates come as member benefits, shaped by industry familiarity. Access requires ongoing membership dues, and the documents reflect association assumptions about typical firm structures. A solo practitioner with cloud-based workflows or a multi-partner firm with on-premise servers may find the fit approximate.

Some firms commission an MSP-written policy. Here the variable is the MSP itself. The resulting document often reflects the provider’s preferred stack—this firewall, that backup solution—rather than the firm’s actual risk profile. A policy tethered to specific vendor tools ages poorly when those tools change, and an MSP’s security expertise does not automatically translate into regulatory documentation that satisfies the FTC’s risk-based standard.

None of these alternatives, however obtained, automatically constitute a program that meets the Safeguards Rule. The Rule requires ongoing risk assessment, employee training, and regular updates. A document, however professionally formatted, is merely evidence of intent. The IRS PTIN screen asks whether you have a security policy. The FTC asks whether you maintain a living program. The gap between those two questions is where firms discover, often inconveniently, that possession and compliance are not the same thing.

How a WISP Fits With Everything Else

A Written Information Security Program is not a firewall, not a backup drive, and not the two-factor authentication prompt your client portal insists upon. It is the document that explains why you have those things, how they connect, and who is responsible when they fail. For a small tax practice, the WISP sits at the policy layer—above the technical implementation but below the firm’s strategic decisions about risk tolerance and client trust.

Consider a firm that has adopted practice management software with built-in encryption, a client portal for document exchange, and automated cloud backups. Each of these tools generates its own settings, its own vendor agreements, its own update cadence. The WISP is where these disparate elements are gathered into coherence: the portal’s encryption satisfies which data-protection requirement, the backup system’s retention period aligns with which recordkeeping obligation, the incident response procedure triggers at what threshold of suspected breach. Without this layer, a firm possesses security measures but lacks security architecture.

The interface is bidirectional. The WISP shapes technical choices—mandating, for instance, that remote access tools meet specified authentication standards before procurement. Conversely, technical changes necessitate policy revision. A switch from one backup provider to another is not merely an IT task; it is a WISP amendment, documented and dated.

For firms already using other EEZY tools, EEZY WISP belongs to the same product family, with one login and central billing at eezycloud.com/account/. This integration is useful in the way that coherent bookkeeping is useful: it reduces the administrative surface area where obligations are forgotten.

Alternatives exist. A firm might adapt the IRS Publication 4557 or 5708 templates, purchase from Tech 4 Accountants or Rush Tech Support, or commission an MSP to draft something bespoke. The AICPA and NATP offer their own frameworks. Each approach produces a document; the question is whether that document accurately reflects what the firm actually does.

The PTIN renewal questions, however briefly phrased, sit at the intersection of IRS expectations, FTC mandates, and professional liability. That is a crowded intersection, and the preparer who treats the security policy as operational infrastructure rather than annual paperwork is the one least likely to be caught without an answer when it matters.

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.

Consider a firm that has spent the morning renewing its principal’s PTIN for the upcoming filing season. The practitioner reaches the final screens and encounters a question about whether the business maintains a Written Information Security Program—a WISP, in the jargon—and realizes, with the slow certainty that accompanies last-minute compliance, that no such document exists in any drawer, drive, or shared folder. The renewal can proceed, but the absence has been noted, and the question will return.

The WISP is, in the most literal sense, a document: the security policy that the Federal Trade Commission’s Safeguards Rule requires businesses to keep if they handle customer financial information. For tax preparers, enrolled agents, CPA firms, and bookkeepers, this is not an abstract requirement. The FTC mandates it. The IRS, through the PTIN renewal process, asks about it directly. Yet the acronym tends to arrive without explanation, buried in checklists between EFIN verification and software updates, as though its meaning were already common knowledge.

What the WISP actually contains—risk assessment, access controls, incident response, employee training, vendor oversight—is a separate matter from what it is: a maintained, written program, not a one-time purchase or a checkbox exercise. The confusion is understandable. Most practitioners encounter the term as an item to clear rather than a standard to meet, and by the time its significance becomes apparent, the renewal deadline or a preparatory compliance review has already tightened the schedule.

What a WISP actually is

A Written Information Security Program is, at bottom, a document. It identifies what could go wrong with your clients’ financial information—laptop theft, phishing, unauthorized access to cloud storage, a rogue employee, a vendor breach—and states, in writing, what your firm does to prevent, detect, and respond to each risk. The FTC Safeguards Rule calls it a WISP. Everyone else in the tax profession calls it that too, though the acronym tends to arrive without explanation, like a form you are expected to have signed without being shown the text.

It is worth clarifying what a WISP is not. It is not a piece of software. It is not a cyber insurance policy. It is not a task you complete once and file away. A WISP is a living document, which means it must be reviewed and adjusted as your firm’s technology, personnel, and risks change. The FTC expects you to have written it, to mean it, and to follow it.

The Safeguards Rule requires a WISP of all “financial institutions”—a term the FTC defines broadly enough to sweep in tax preparers, enrolled agents, CPAs, and bookkeepers who handle consumer financial data. The IRS, for its part, asks on the PTIN renewal whether the practitioner has a data security plan, which is functionally the same question. A “no” is not a prudent answer.

The document itself can be produced in several ways. Some firms adopt templates from the IRS—Publications 4557 and 5708 provide starting points—or from professional associations such as NATP or AICPA. Others hire an MSP to draft something bespoke. Still others purchase templates from specialized providers such as Tech 4 Accountants or Rush Tech Support. Each approach has its trade-offs in specificity, maintenance burden, and the degree to which the resulting document reflects the actual operations of the firm that adopts it.

The essential point is that a WISP exists on paper, governs practice in reality, and is subject to inspection by regulators who have grown less inclined to accept vague assurances in place of written specifics.

How a WISP tool solves the compliance problem

Most tax practitioners did not enter the profession to write information-security policy. The FTC Safeguards Rule requires a Written Information Security Program that addresses risk assessment, access controls, data encryption, incident response, and several other domains—each of which demands fluency in a vocabulary more commonly found in a CISO’s office than in a tax preparation suite. Drafting such a document from scratch is, for the typical sole practitioner or small firm, a project of uncertain scope and considerable opportunity cost.

A template or specialized service supplies the architecture. Products such as those from Tech 4 Accountants, Rush Tech Support, the IRS Publication 4557 and 5708 templates, or association offerings from NATP and AICPA provide pre-structured frameworks that map the Rule’s requirements to document sections. EEZY WISP operates in this same category: a written program that organizes the required elements into a coherent policy document. The practical benefit is coverage. A practitioner working without guidance might omit the incident-response plan or understate the vendor-management provisions; a purpose-built template prompts for these explicitly. The resulting document can be produced during a regulatory inquiry or shown to a client who asks, appropriately, how their data is protected.

The limitations deserve equal emphasis. A WISP, however well constructed, does not implement the safeguards it describes. It does not encrypt your hard drives, train your staff, or prevent a phishing breach. The Rule’s requirements for employee training, vendor due diligence, and periodic risk assessment remain the practitioner’s operational responsibility. The document is a map, not the territory. Consider a firm that purchases a thorough template, files it with its other compliance records, and proceeds as before: it has a WISP, but it does not have compliance. The practitioner must still execute what the document prescribes—update it after a systems change, follow the incident-response protocol when indicated, and maintain the administrative practices the Rule demands. The tool reduces the friction of documentation; it does not dissolve the obligation of implementation.

What EEZY WISP provides

EEZY WISP is a Written Information Security Program—the security policy document a business is required to keep, written and maintained. It is not a consultation, a network scan, or a binder that sits on a shelf until someone asks to see it. The product is the document itself, produced to satisfy the FTC Safeguards Rule and the IRS question on PTIN renewal that asks whether you have one.

The alternatives are not difficult to locate. Tech 4 Accountants and Rush Tech Support both offer WISP templates. The IRS publishes Publications 4557 and 5708, which include template language a practitioner might adapt. NATP and AICPA make templates available to members. Many firms receive a policy written by their managed service provider, sometimes thorough, sometimes a generic printout with their letterhead swapped in. Each of these approaches has its adherents. The MSP route, in particular, can be adequate if your provider understands tax practice; it can also be a photocopied afterthought billed as “compliance included.”

EEZY WISP occupies a narrower position: a purpose-built document, maintained as a product rather than a favor or a membership perk. Pricing is on the site. The infrastructure is hosted on Microsoft Azure. Support hours are Monday through Friday, 9 AM to 8 PM, and Saturday through Sunday, 9 AM to 12 PM Eastern, as published at eezycloud.com/support.

For firms that use other EEZY products, the account structure follows the EEZYVERSE model: one login across the EEZY products a company uses, with one central bill at eezycloud.com/account/. Each product is also sold on its own site, so a WISP purchased in isolation does not require committing to a broader platform.

The value proposition, such as it is, rests on specificity. A WISP from a generalist template library may require substantial editing to reflect a tax practice’s actual data flows, employee count, and software stack. One from an MSP may reflect what the MSP thinks you do. EEZY WISP is designed for the vertical it serves, which is a different thing from claiming it is the only reasonable choice. For some firms, the IRS template and a quiet afternoon with a red pen will suffice. For others, the cost of getting it wrong—an FTC inquiry, a preparer penalty, or simply the sleeplessness of knowing the document in the drawer would not survive scrutiny—outweighs the cost of having it done competently by someone who does this particular document repeatedly.

What it costs

EEZY WISP publishes its pricing at eezywisp.com. That is the extent of what may be stated here with certainty; the site will disclose whether the product is priced as a one-time purchase, an annual subscription, or some other arrangement. The same principle applies to every alternative worth considering. Tech 4 Accountants and Rush Tech Support both offer WISP templates; their pricing, too, resides on their respective sites. The IRS furnishes Publications 4557 and 5708 without charge, though the word “free” demands qualification: these templates require substantial adaptation, legal review, and ongoing maintenance, the cost of which is measured in hours rather than dollars. NATP and AICPA members may access templates through their associations; non-members face membership fees or separate purchase prices, again discoverable through direct inquiry. An MSP-written policy arrives with whatever that particular provider charges for professional services, a figure that varies by geography, firm size, and the MSP’s own pricing philosophy.

The broader calculation extends beyond the document itself. Consider a firm that selects the IRS template, spends six hours customizing it, another four consulting with counsel, and thereafter dedicates annual hours to revision. The arithmetic becomes personal and particular. Consider another firm that purchases a template from Rush Tech Support or Tech 4 Accountants and discovers the fit is imperfect, requiring supplemental work. Consider a third firm that engages an MSP and receives a thorough policy at professional-services rates, then faces the question of who maintains it when personnel change or regulations shift.

EEZY WISP’s pricing is on the site. Its structure belongs to the EEZYVERSE: one login across EEZY products a company uses, one central bill at eezycloud.com/account/. Support hours are published at eezycloud.com/support: Monday through Friday, 9 AM to 8 PM; Saturday and Sunday, 9 AM to 12 PM Eastern. The sites run on Microsoft Azure. These are fixed points in an otherwise variable marketplace. The prudent practitioner compares total cost of ownership, not merely the price at checkout, and recognizes that the cheapest initial outlay may not be the least expensive path to sustained compliance.

Getting started and the first week

Consider a firm that purchases EEZY WISP. The login arrives through the EEZYVERSE portal—the same credential they would use for other EEZY products, with billing centralized at eezycloud.com/account/. The document opens as a structured template, not a blank page. They see sections for risk assessment, access controls, incident response, and the other components the FTC Safeguards Rule enumerates. The first task is reading it through, which takes less time than one might expect from a regulatory document, though the subject matter rewards attention.

Customization follows. A sole practitioner operating from a home office will have different access protocols and vendor relationships than a four-partner firm with a downtown lease and three remote bookkeepers. The template accommodates both without pretending they face identical risks. The practitioner marks which sections apply, adjusts the inventory of information systems, and names the individual responsible for program oversight—a requirement that sounds ceremonial until one realizes it has real consequences for liability and for answering IRS inquiries during PTIN renewal.

The first week typically surfaces friction between policy and practice. Perhaps the firm discovers its backup schedule exists only in the head of a part-time IT contractor, or that “encryption” has meant the password on a spreadsheet. These gaps are the point of the exercise, not a failure of the template. The WISP from Tech 4 Accountants or Rush Tech Support would surface similar discrepancies; the IRS Publication 4557 template would too, though with more of the drafting burden on the practitioner. An MSP-written policy might arrive with less need for initial customization and a correspondingly higher invoice.

By week’s end, the firm has a dated document, an assigned compliance lead, and a calendar entry for the periodic review the Safeguards Rule mandates. The document is not finished—it is maintained. Support is available Monday through Friday, 9 AM to 8 PM Eastern, and Saturday through Sunday, 9 AM to 12 PM Eastern, should questions of interpretation arise.

The honest alternatives

Practitioners have several legitimate paths to a compliant WISP, and the choice depends largely on how much legwork you are prepared to do yourself.

The federal government offers free templates through IRS Publication 4557 and Form 5708. These documents are authoritative, cost nothing, and will satisfy a regulator who checks the box. What they do not offer is hand-holding. You must still conduct your own risk assessment, adapt the language to your firm’s actual systems and vendors, and maintain the document as those systems change. For a solo practitioner with modest technical infrastructure, this is genuinely workable. For a growing firm with multiple locations, cloud applications, and remote staff, the self-assessment burden grows quickly.

Industry associations provide another route. NATP and AICPA both offer WISP templates to members. These tend to reflect the specific concerns of tax and accounting professionals more precisely than government documents, and they arrive with the implicit endorsement of peers. The same caveat applies: the template is a starting point, not a finished program.

Specialized vendors have entered this space with more tailored offerings. Tech 4 Accountants and Rush Tech Support both provide WISP templates designed for tax preparers. These typically require less adaptation than government or association documents, though the degree of ongoing support and integration with other compliance tools varies. Neither publishes pricing in the materials reviewed for this article; interested firms should consult their respective sites.

Some practitioners engage their managed service provider to draft a policy, or hire a compliance attorney to build one from scratch. An MSP-written policy has the advantage of reflecting your actual network configuration; a compliance attorney’s work may hold more weight in a dispute. Both paths cost more in time or fees, and neither guarantees the document will be maintained without additional engagement.

A minority of practitioners simply draft their own. This is not reckless if you understand the Safeguards Rule’s requirements and your own environment. It is, however, a defensible choice only for those who can honestly assess whether their expertise matches the task.

How it fits with your firm’s stack and the EEZYVERSE

EEZY WISP is one product in the EEZYVERSE family. The arrangement is straightforward: one login across whatever EEZY products a company uses, one central bill at eezycloud.com/account/, and each product also available on its own site. For a small tax or accounting firm already managing a patchwork of practice management software, tax prep platforms, and cloud storage, this is less about technological integration than about administrative sanity.

The WISP itself does not replace your existing security stack. It documents it. Your firewall, your multi-factor authentication, your encrypted backup regimen—whatever measures you have in place—find their formal articulation in the document the FTC requires you to maintain. EEZY WISP sits alongside these tools rather than supplanting them, much as the WISP templates offered by Tech 4 Accountants, Rush Tech Support, or the IRS itself serve the same documentary function without touching your actual infrastructure.

The practical benefit of the EEZYVERSE model, such as it is, accrues to the person in your office who handles vendor relationships. One fewer login to misplace, one bill to reconcile, one set of support hours to remember: Monday through Friday 9 AM to 8 PM, Saturday and Sunday 9 AM to 12 PM Eastern, as published at eezycloud.com/support. Sites run on Microsoft Azure, which is neither distinctive nor disqualifying.

Consider a firm that already uses an EEZY product for another purpose—document management, say, or time tracking. Adding the WISP through the same portal requires no new procurement process, no fresh vendor security review, no additional point of contact when something goes wrong. This is not transformative. It is merely one less friction point in a profession where friction points accumulate faster than billable hours.

The alternatives remain viable. An MSP can draft your policy. NATP and AICPA offer templates. IRS Publications 4557 and 5708 provide free starting points. EEZY WISP’s case rests on the modest proposition that a compliance document need not arrive through a separate vendor relationship, with its attendant invoices and support queues, when it could simply appear in an account you already maintain.