Writing Your WISP: What to Include, What to Skip, and How Long It Should Actually Be

Every year at PTIN renewal, you check the box confirming that your firm has a Written Information Security Plan. If you actually have one, this article will help you make it better. If you checked the box but don't have one yet, this article will help you build it without the paralysis that keeps most people from starting.

The WISP is the foundational document of your security program. The IRS requires it for every tax professional. The FTC Safeguards Rule mandates it for all financial institutions, including CPA firms. But the problem most firm owners run into isn't knowing they need one. It's knowing what to put in it.

The internet is full of WISP templates. Some are 80 pages long, written for enterprise organizations with dedicated security departments. Others are three-page checklists that don't come close to meeting regulatory requirements. Neither extreme serves a 10 to 30 person CPA firm. Your WISP needs to be thorough enough to satisfy the FTC and specific enough to describe your actual firm. It doesn't need to be a novel.

How Long Should It Actually Be?

There's no regulatory requirement specifying page count. The IRS and FTC both say that the plan should be "appropriate to your size and complexity, the nature and scope of your activities, and the sensitivity of customer information at issue."

For a sole practitioner, a focused 8 to 12 page document can cover everything. For a firm with 10 to 30 employees, multiple office locations, or a mix of on-premise and cloud systems, expect 15 to 25 pages. If your WISP is over 40 pages, it probably contains boilerplate language that doesn't apply to your firm, and that's actually a problem. A regulator or auditor who reads your WISP and finds sections that clearly don't match your operations will question whether you actually wrote it or just downloaded it.

The sweet spot is a document that someone new to your firm could read in under an hour and understand how your firm protects client data. If it takes longer than that, it's too long. If it takes less than 20 minutes, it's probably too thin.

The Template Problem

Most firms that have a WISP started with a template. There's nothing wrong with that. Templates provide structure. The problem comes when the template stays unchanged.

Generic WISP templates often miss FTC Safeguards Rule requirements or include language designed for industries and firm sizes that don't match yours. They reference systems you don't use, roles you don't have, and procedures you've never followed. When a regulator reviews your WISP after an incident, they compare what the document says to what your firm actually does. If the WISP describes a security operations center and you're a five-person firm with a single IT provider, that disconnect works against you.

The IRS has started cross-referencing PTIN certifications against reported security incidents, and firms that certified compliance but couldn't produce documentation during subsequent audits or investigations have faced credential challenges. A template WISP you never customized is barely better than no WISP at all, because it creates a documented expectation you haven't actually met.

The goal isn't to start from scratch. It's to take whatever template or starting point you have and make it yours. Every section should describe what your firm does today, not what a generic firm might theoretically do.

What Each Section Should Cover

Here's a walkthrough of the core sections your WISP needs, what belongs in each one, and where to draw the line.

Section 1: Purpose and Scope

Keep this short. Two to three paragraphs. State that the plan describes your firm's information security program as required by the FTC Safeguards Rule and IRS Publication 4557. Define what data is covered (client personal and financial information, taxpayer data, Social Security numbers, bank account details). Identify who the plan applies to (all employees, contractors, temporary staff, and service providers with access to client data).

Section 2: Qualified Individual

Name the person responsible for implementing and overseeing the security program. Under Section 314.4(a) of the Safeguards Rule, this is a required designation. Include their name, title, and contact information. Briefly describe their responsibilities: managing the program, conducting risk assessments, coordinating with the IT provider, delivering training, and reporting annually to firm leadership.

If you're a sole practitioner, you are the qualified individual. Name yourself. For a larger firm, this is often a managing partner or office manager. The person doesn't need to be a security expert. They need to be accountable for making sure the program runs.

Section 3: Risk Assessment

Describe the process your firm uses to identify and assess risks to client data. The FTC requires a written risk assessment that covers internal and external risks to the security, confidentiality, and integrity of customer information.

For a small firm, this doesn't need to be a formal risk matrix with probability scores. It needs to identify the realistic threats your firm faces: phishing attacks, credential compromise, unauthorized physical access, lost or stolen devices, vendor breaches, and employee errors. For each risk, document what safeguards you have in place to address it.

Include the date of the most recent risk assessment. The FTC requires periodic reassessment, particularly when your operations change.

Section 4: Access Controls

Document who has access to client data and how that access is managed. This includes:

Which staff members have access to tax software, document management systems, email, and client portals. How access is granted when someone joins the firm and how it's revoked when they leave. Whether access is role-based (staff only see their own clients) or firm-wide. How admin and privileged access is restricted.

Be specific. Name the systems. Describe the permission levels. If you use Active Directory or a similar tool to manage access, mention it. If access decisions are made informally by a partner, document that too, because knowing your current process is the first step to improving it.

Section 5: Authentication and MFA

Describe your authentication requirements. Under the current Safeguards Rule, multi-factor authentication is required for any individual accessing customer information. Document where MFA is enforced: email, tax software, VPN, remote desktop, cloud platforms, admin consoles.

If MFA is not yet fully deployed, document your plan and timeline for getting there. Honest documentation of a known gap with a remediation plan is better than a false claim of full deployment that falls apart during a claim or investigation.

Section 6: Encryption

Document how client data is encrypted at rest (on your servers, in cloud storage, on laptops) and in transit (email, file transfers, client portal uploads). If you use a cloud-based tax platform, reference the vendor's encryption practices and note that your firm has verified them.

If encryption isn't fully implemented, the Safeguards Rule allows alternative compensating controls if approved in writing by your qualified individual. Document whatever is in place and the rationale for it.

Section 7: Employee Training

Describe your training program. What topics are covered (phishing recognition, password hygiene, data handling, reporting suspicious activity). How often training is delivered (at minimum, annually). How it's documented (attendance records, signed acknowledgments).

Include information about new hire orientation. The FTC expects that employees are trained before they access client data, not six months later.

Section 8: Physical Security

For a small CPA firm, this doesn't need to be elaborate. Document how your office is physically secured: locked doors, visitor policies, how paper records containing client data are stored (locked filing cabinets), and how documents are disposed of (cross-cut shredding).

If employees work remotely, document the expectations for their home workspace: locked rooms, no screen sharing in public places, secure Wi-Fi, no printing of client documents on home printers (or rules for doing so safely).

Section 9: Vendor and Service Provider Oversight

List your key vendors that handle client data: IT provider, tax software, document management, cloud storage, payroll, client portals. For each, document:

What data they have access to. Whether you have a written agreement specifying their security obligations. When you last assessed their security practices.

You don't need to include the full vendor assessment for each one in the WISP. Reference where those assessments are stored.

Section 10: Incident Response Plan

Describe what your firm does when a security incident occurs. This should include:

How incidents are reported internally (who to call, when). Initial containment steps (isolating affected systems, disabling compromised accounts). When and how to engage your IT provider. When to contact legal counsel. Client notification procedures and timelines. FTC notification requirements (within 30 days for incidents affecting 500+ individuals). State breach notification obligations. Documentation requirements during and after the incident.

This section is one of the most important in the entire WISP, because it's the section you'll actually use under pressure.

Section 11: Monitoring and Testing

Document whether your firm uses continuous monitoring or the alternative approach of annual penetration testing plus vulnerability assessments every six months. For most small firms, the monitoring is handled by the IT provider. Document what they do, how often, and where the reports are stored.

Note: firms maintaining information on fewer than 5,000 consumers are exempt from the monitoring and testing requirement, but implementing some level of monitoring is still good practice.

Section 12: Program Review and Reporting

State how often the WISP is reviewed (the IRS recommends quarterly at minimum, and the FTC requires at least annual reporting to firm leadership). Document who reviews it, how changes are tracked, and when the last review occurred.

Include a simple version history at the end of the document: date, reviewer, summary of changes.

What You Can Skip

You don't need sections on topics that don't apply to your firm. If you don't have a bring-your-own-device policy because no personal devices access firm systems, don't include a BYOD section. If you don't process credit card payments, skip the PCI-DSS section. If you don't have a mobile device fleet, don't write a mobile device management section.

Every section in your WISP should describe something your firm actually does. Sections that describe controls you don't have create a false sense of compliance and an actual liability if you're ever investigated.

What You Can Do Today

1. If you don't have a WISP: Start with a template from the IRS (Publication 5708) and customize every section to match your firm. Block 4 hours this week to get through the first draft. It won't be perfect. It will be a starting point.

2. If you have a WISP but haven't updated it: Print it and read it with a red pen. Mark every section that's outdated, inaccurate, or generic. Schedule time to update those sections over the next two weeks.

3. If you used a template and never customized it: Treat it as a starting framework. Go section by section and replace generic language with specifics about your firm: your systems, your staff, your vendors, your procedures.

4. Regardless of where you are: Make sure the qualified individual named in the WISP is actually performing the role. If they're not, either change the name or change the expectation.

The Bottom Line

Your WISP isn't a compliance checkbox. It's the operating manual for how your firm protects client data. The better it reflects your actual practices, the more useful it is. The more useful it is, the more likely your team will follow it. And the more your team follows it, the better positioned you are if a regulator, an insurer, or a client asks to see it.

If the WISP writing process feels overwhelming, or if you want help turning a template into a document that actually describes your firm, Kompflow provides guided workflows that walk you through each section, pulling in the details specific to your systems, your staff, and your operations. The result is a WISP that reads like it was written for your firm, because it was.

Start with what you have. Make it yours. Update it regularly. That's the whole formula.