IRS WISP Example: Build Your Tax Firm's Security Plan

What Is an IRS WISP and Who Must Have One?

If you prepare federal tax returns for clients, the IRS requires you to maintain a Written Information Security Plan (WISP) — a formal, written document that describes exactly how your firm protects client data. This requirement comes directly from IRS Publication 4557, Safeguarding Taxpayer Data, which applies to every tax professional who handles federal returns, regardless of firm size.

A WISP is not a checkbox exercise. It is an operational document that maps your firm's specific risks, describes the technical and administrative controls you have in place, and defines exactly what happens when a data breach occurs. The IRS — in coordination with the Federal Trade Commission (FTC) Safeguards Rule under the Gramm-Leach-Bliley Act (GLBA) — treats an absent or incomplete WISP as a compliance failure that can result in civil penalties and referral to state licensing boards.

This guide provides a real IRS WISP example: actual policy language, required section breakdowns, and the 2026 compliance standards your plan must meet. Whether you are writing your first WISP or auditing an existing one, the sections below give you a practitioner-level model to follow.

Two IRS publications govern this requirement:

• IRS Publication 4557 — Safeguarding Taxpayer Data: the primary guidance document for tax professionals on data security obligations
• IRS Publication 5709 — A Step-by-Step Guide to Creating a Written Information Security Plan: a template-based guide updated in April 2024 specifically to help smaller practices build compliant WISPs

Together, these publications define the IRS WISP example framework that every compliant tax preparer should follow. See also our deeper analysis of IRS WISP requirements for tax professionals and the full breakdown of what a Written Information Security Plan must contain.

The Nine Required Sections of an IRS WISP

IRS Publication 5709 organizes a compliant WISP into nine core sections. Every IRS WISP example must address all nine — omitting even one section leaves your firm exposed to both regulatory scrutiny and real security gaps.

The nine required sections are:

1. Designation of a Security Coordinator
2. Risk Assessment
3. Safeguards Implementation
4. Employee Training and Education
5. Security Incident Response
6. Third-Party Service Provider Management
7. Records Disposal Program
8. Monitoring and Adjustment Program
9. Documentation

Below is a closer look at the first three sections with the policy language the IRS expects to see.

1. Designation of a Security Coordinator

Your WISP must name a specific individual — not a role or department — as your Information Security Program Coordinator. This person owns the plan, updates it annually, and is the point of contact during a breach. For a sole proprietor, that is you. For a multi-partner firm, designate one named partner or office manager with documented authority to enforce the plan firm-wide.

2. Risk Assessment

Before you can protect client data, you must identify where it lives. Your risk assessment must catalog every location — physical and digital — where Personally Identifiable Information (PII) is stored, processed, or transmitted. This includes desktop workstations, laptops, mobile devices, cloud storage, email servers, physical file cabinets, and every third-party software platform your firm uses.

The risk assessment does not need to be a lengthy technical document. For a small practice, a two-page inventory that lists each data location and its associated risks — unauthorized access, theft, hardware failure, ransomware — satisfies the IRS requirement. Update this inventory every time you adopt a new tool or change your infrastructure. Firms with multiple offices should also review how data moves between locations; our guide on centralized security for multi-location tax offices covers this in depth.

3. Safeguards Implementation

This is the operational core of your WISP. Safeguards fall into three categories the IRS and FTC Safeguards Rule both recognize:

• Technical safeguards: Multi-Factor Authentication (MFA) on all systems, disk encryption on laptops and workstations, encrypted email for client communications, automatic screen lock, firewall and endpoint protection software
• Administrative safeguards: Written access control policies, annual security awareness training for all staff, background checks for employees with data access, incident response procedures
• Physical safeguards: Locked filing cabinets for paper records, restricted access to server rooms, secure shredding (cross-cut or micro-cut) of documents containing PII, visitor sign-in logs

IRS WISP Example: Sample Policy Language for Each Required Section

The sections below provide ready-to-adapt policy language drawn from IRS Publication 5709 requirements and the FTC Safeguards Rule. Replace bracketed placeholders with your firm's specific details. This is not a copy-paste document — you must tailor each section to reflect your actual practices, actual technology, and actual risks. An IRS WISP example that still contains generic placeholder text is a compliance failure, not a compliance solution.

Employee Training Policy (Sample)

"All [Firm Name] employees with access to client data must complete information security awareness training within 30 days of hire and annually thereafter. Training covers: phishing identification, password security, secure document handling, clean desk policy, and breach reporting procedures. Completion is documented with a signed acknowledgment form retained in each employee's personnel file for a minimum of three years."

Phishing remains the leading entry point for attacks on tax practices, so this section carries real operational weight. Reinforce it with practical training — our explainer on how phishing attacks work and the phishing scams resource center give your staff concrete examples to recognize.

Terminated Employee Access Revocation (Sample)

"Upon termination or resignation of any employee, [Firm Name]'s Security Coordinator will revoke all system access — including email, tax software, cloud storage, and VPN — within one business hour of the separation being confirmed, and before the employee completes an exit interview. Physical access credentials (keys, keycards) are collected at the exit interview. A termination checklist documenting completed access revocation is signed by the Security Coordinator and retained for three years."

Third-Party Vendor Management (Sample)

"[Firm Name] will only share client PII with third-party service providers who have executed a written data security agreement confirming they maintain safeguards equivalent to those required under the FTC Safeguards Rule. All vendor agreements are reviewed annually by the Security Coordinator. A current list of approved vendors and their data access scope is maintained as Appendix B of this plan."

The IRS explicitly requires you to vet all software providers, payroll platforms, and cloud storage vendors under this provision. For a full treatment of the FTC Safeguards Rule's application to tax preparers, see our analysis of the FTC Safeguards Rule for tax preparers.

Data Retention and Disposal (Sample)

"Client records containing PII are retained for a minimum of seven years from the date of filing, or longer if required by applicable federal or state law. Upon expiration of the retention period, paper records are destroyed using a cross-cut or micro-cut shredder, or by a certified third-party shredding service that provides a Certificate of Destruction. Electronic records are securely deleted using software that overwrites data in conformance with NIST Special Publication 800-88, Guidelines for Media Sanitization."

The seven-year retention minimum aligns with IRS audit statute of limitations periods and is the most commonly cited standard across state-level WISP requirements. Referencing NIST SP 800-88 for electronic media disposal adds measurable specificity that auditors look for when reviewing a plan for genuine operational grounding.

IRS Publication 5709: The Official WISP Template Explained

In April 2024, the IRS released Revision 4 of Publication 5709, "Written Information Security Plan — A Step-by-Step Guide." This is the closest thing to an official IRS WISP example, and it reflects current FTC Safeguards Rule requirements that took full effect for tax preparers in 2023.

Publication 5709 is structured as a fillable PDF that walks you through each required section. Key updates in the 2024 revision include explicit language around four areas that smaller practices frequently overlook:

• Multi-Factor Authentication: The FTC Safeguards Rule now requires MFA on any system that contains or accesses customer financial data. Publication 5709 includes a dedicated MFA section your WISP must address by name — listing each system and the authentication method deployed.
• Encryption in transit and at rest: The revised template distinguishes between encryption of stored data (at rest) and data transmitted via email or file transfer (in transit). Both are required, and your WISP must specify which tools or protocols you use for each.
• Access control and least privilege: Employees should only access the specific client records necessary for their role. Publication 5709 provides sample language for documenting your access control matrix, including what happens when an employee changes roles internally.
• Security event logging: The updated guidance recommends retaining system access logs for a minimum of two years to support incident investigation. Your WISP should specify which systems generate logs and where those logs are stored.

The IRS also maintains Publication 5708, which provides standards for electronic security plan documentation and auditable sign-off procedures. While Publication 5709 focuses on what your WISP must contain, Publication 5708 addresses the procedural framework — including electronic acknowledgment by staff members, version control of plan revisions, and documentation standards that satisfy audit requirements. Together, these publications form the complete IRS WISP compliance framework.

If you have not reviewed your WISP against the 2024 version of Publication 5709, that review is overdue. Tax software providers including Drake, Lacerte, and ProSeries reference this publication in their own security documentation. Use our WISP template for tax preparers as a starting framework, then customize it against the actual risks your practice faces.

For practices that also serve business clients subject to state privacy laws — particularly those in California (CCPA), Massachusetts (201 CMR 17.00), or New York (SHIELD Act) — your WISP may need to incorporate additional state-specific requirements on top of the federal IRS baseline. These state frameworks generally require the same core elements as the IRS standard but may impose shorter breach notification windows and broader definitions of covered personal information.

Maintaining, Testing, and Updating Your WISP

Writing your WISP is the first step. Keeping it current and operational is where most small practices fall short. The IRS does not accept a static document written once and filed away. A compliant WISP is a living document — it must evolve as your firm grows, your technology changes, and new threats emerge.

Annual Review Requirements

Schedule your WISP review every year, ideally before tax season begins. During the review, confirm that your Security Coordinator designation is still accurate — people change roles and leave firms. Verify that your data inventory reflects every current system, including any new software adopted since the last review. Ensure all vendor agreements are current and cover current data processing activities. Check that employee training records are complete and no staff member is overdue for recertification. Confirm your incident response contact list — including the IRS Identity Theft Unit number — is still accurate.

Triggered Updates

Beyond the annual review, your WISP must be updated any time a material change occurs at your firm. The IRS and FTC Safeguards Rule both treat a plan that no longer reflects your actual operations as effectively non-compliant. Material changes include:

• Hiring or terminating an employee with data access
• Adopting a new tax software platform, cloud storage provider, or communication tool
• Moving offices or changing your physical security setup
• Experiencing a security incident, even one that did not result in a confirmed breach
• A change in federal or state law that affects your data security obligations

The ransomware threat to tax practices is one of the fastest-evolving risks your WISP should address. A ransomware incident response section — including offline backup procedures and recovery time objectives — is now expected by IRS examiners who review WISPs during preparer compliance checks. If you are unsure how these attacks unfold, our explainer on how ransomware works provides the background your plan should account for.

Documenting Breaches and Security Incidents

If your firm experiences a data breach or security incident, your WISP must require you to document it in writing regardless of scale. That documentation should include the date and nature of the incident, the data affected, the corrective actions taken, and the notification steps completed. This breach log becomes part of your WISP and demonstrates that your security program is responsive and operational rather than theoretical.

For additional guidance on building a defensible breach response posture, see our overview of what to do after a data breach and the incident patterns the IRS most commonly investigates during preparer compliance reviews.

Common IRS WISP Mistakes and How to Avoid Them

After reviewing WISPs from small and mid-size tax practices across multiple states, Bellator Cyber Guard's security team consistently identifies the same patterns of non-compliance. These are not obscure technicalities — they are the gaps that auditors flag first and that attackers exploit most often.

Using a Generic Template Without Customization

Downloading an IRS WISP example template and submitting it unchanged is the single most common mistake. Your WISP must reflect your actual practice: your specific software tools, your actual employee count, your real data storage locations. A template that references "cloud storage" without naming the specific platforms you use, or that lists "MFA" without specifying how it is configured, does not meet the IRS standard. Auditors look for specificity. Generic language signals that the plan was never actually implemented.

No Incident Response Contact List

Many WISPs describe what to do during a breach in general terms but omit the specific contacts required for immediate notification. Your incident response section must include:

• IRS Identity Theft Unit: 1-800-908-4490
• Your state tax authority's breach notification contact
• Your cyber insurance carrier and policy number
• Your IT support provider or managed security provider
• The FBI Internet Crime Complaint Center (IC3) at ic3.gov

Skipping the Physical Security Section

Tax preparers who work primarily in digital environments often omit physical safeguards entirely. But physical security is an explicit IRS requirement. Your WISP must address how paper client files are stored and locked, who has physical access to your office after hours, how you handle disposal of printed tax returns, and whether workstations auto-lock when unattended. A breach through an unlocked filing cabinet is still a reportable breach.

Treating MFA as Optional

As of 2023, Multi-Factor Authentication is mandatory under the FTC Safeguards Rule for all systems that contain or access customer financial data — and the IRS has adopted this requirement by reference in Publication 4557. If your WISP describes MFA as a recommended practice rather than a firm requirement, update your language now. Your WISP should name every system where MFA is enabled and specify the authentication method used for each. See our guide on PTIN and WISP requirements for tax preparers for implementation specifics that satisfy both IRS and FTC standards.

Failing to Document Plan Updates

Some firms update their security practices but never revise the WISP itself. If your firm adopted a new cloud platform last year but your WISP still references the old one, the document no longer reflects reality — and an auditor will treat it accordingly. Every material change to your operations should trigger a corresponding WISP revision with a documented change log, the date of the update, and the Security Coordinator's sign-off. Publication 5708 provides standards for maintaining this kind of auditable revision history through electronic acknowledgment and version control.