Written client data security plan: 4 factors to check

Key takeaways

• Check which federal rules cover your services.
• Inventory client data, storage locations and access.
• Describe safeguards you actually use.
• Write incident response steps before you need them.

A written information security plan, often called a WISP, is a document that describes how a business protects client data, who handles which parts of that job, and what happens when something goes wrong. For some businesses a WISP is required by law. For others it is a practical habit that is much cheaper to write before a problem than after one.

Whether a plan applies to you, and how long it needs to be, depends on four factors. The first is which federal rules cover your work. The second is how much client data you hold and how sensitive it is. The third is which safeguards and controls the plan has to describe. The fourth is what you would have to do if client data were exposed. Each factor is covered below, with links to the official pages behind the claims.

This post is general information for bookkeepers and small-business owners. It is not legal advice, the rules it describes can change, and the official pages it links to are the authority. Before you rely on any of them for your own business, read the source and talk to a qualified professional who knows your situation.

Does a federal law require my business to have a written plan?

For tax and accounting professionals, yes: federal law requires them to create and maintain a written plan, so the first factor is whether your work falls within that group.

In a news release from the IRS and its Security Summit partners, the agency reminded tax professionals to protect client data with a Written Information Security Plan ( IRS, "IRS, Security Summit remind tax pros they need a Written Information Security Plan to protect client data"). Read the exact wording there before you draw conclusions about your own work.

Whether that requirement describes you depends on the services you provide, not on your job title. A bookkeeper who prepares tax returns is in a different position from one who only records transactions, sends invoices, and reconciles accounts. Do not assume you are in or out of the group. Read how the IRS describes it, and ask a tax adviser how it applies to the services you actually sell. Writing down which services you provide is a useful first step, because the answer depends on those facts.

Clients may also ask to see how you protect their information before they hire you or sign a contract. That request is not a legal rule, but it is a practical reason to have a plan that you can explain without guessing.

A second federal rule, the FTC Safeguards Rule, covers a different group of businesses. The Federal Trade Commission's guidance explains that the Rule took effect in 2003, that the FTC amended it in 2021 to keep pace with current technology, and that it amended the Rule again in 2023 to require covered entities to report certain data breaches and security incidents ( FTC, "FTC Safeguards Rule: What Your Business Needs to Know"). The Rule applies to financial institutions that are subject to the FTC's jurisdiction and are not subject to the enforcement authority of another regulator under section 505 of the Gramm-Leach-Bliley Act, 15 U.S.C. § 6805.

That coverage test has several parts. The 2021 amendments added finders as a new example of a financial institution, which shows that the Rule's reach has changed over time. Because the Rule depends on whether your business is a financial institution, whether the FTC has jurisdiction over it, and whether another regulator already enforces the law against it, test your own business against each condition instead of relying on a general impression. If the answer is still unclear after you read the FTC page, get advice from someone who can review your specific services.

How much client data do I hold, and how sensitive is it?

The size, scope, complexity and sensitivity of the client data you handle should set how detailed your plan is. The IRS puts it this way: a WISP protects client information most effectively when it is tailored to the size, scope, complexity and sensitivity of the customer data it handles ( IRS, "Written Information Security Plans are essential for tax pros").

Size is the simplest of the four. It is the number of clients you serve and the number of records you keep for each. A sole bookkeeper with a small client list has less to manage than a firm with several staff members and years of archived client folders. The plan for each can be sound, but the one for the larger firm has more people, more files, and more places for things to go missing.

Scope is about what you collect. Names and mailing addresses are one category. Bank account numbers, card details, tax identification numbers, and login credentials for a client's accounting software are another. The more kinds of information you collect, the more places you need to protect, and the more a leak could be used for fraud.

Complexity is about how the data moves. Consider every place client information lives or passes through: email attachments, shared drives, a client portal, a payroll or payment provider, a personal phone that syncs your inbox, a laptop you take to client sites, and paper folders in a filing cabinet. Each of these is a step the plan has to address. A business that uses one cloud accounting service on one locked computer has fewer paths to describe than one that exchanges files by email with dozens of clients.

Sensitivity asks how much harm a leak would cause. A list of invoice totals is less sensitive than a list of bank details tied to names. The IRS framing focuses on identity thieves and data breaches, which points to information that could be used to open accounts, redirect payments, or impersonate a client. When you rank your data, put the information that enables fraud at the top of the list, and give it the strongest protections in the plan.

A practical way to start is a short inventory: each kind of client data you hold, where it sits, who can open it, and how it leaves your hands. You do not need a formal document to do this. The inventory becomes the factual basis for the rest of the plan and shows you where the four factors point. A plan written for a one-person practice with one cloud service will look different from one written for a small office that keeps paper files, and both can be appropriate when they describe the real setup.

The four factors also interact. A large volume of low-risk data, such as a mailing list for seasonal reminders, may call for a lighter set of protections than a small volume of bank details. Scope and sensitivity often matter more than raw size, so do not measure your plan only by how many clients you have. Keep the most sensitive records in the fewest places, and be deliberate about who can reach them. That focus keeps a small practice's plan proportionate instead of generic.

Retention belongs in the inventory too. Client records you no longer need still count as client data while they sit on a drive or in a filing cabinet. Decide how long you keep each type of record and what you do with it afterward, whether that means deleting digital copies or shredding paper. Your plan should state that decision, because old files are easy to forget and remain exposed to the same risks as current ones. For a related recordkeeping review, see electronic invoice records.

Which safeguards and controls must the plan cover?

The plan has to describe the safeguards you actually use, and the FTC's Safeguards Rule gives one fixed outline for covered businesses. Section 314.4 of the Rule identifies nine elements that a company's information security program must include ( FTC, "FTC Safeguards Rule: What Your Business Needs to Know"). Read section 314.4 for the full list before you build your outline, so that your plan addresses each element the rule names, rather than relying on a summary.

A second outline comes from the National Institute of Standards and Technology. Its Cybersecurity Framework 1.1 is organized into five functions, and NIST describes those five functions as the five primary pillars for a successful and holistic cybersecurity program ( NIST, "The CSF 1.1 Five Functions"). You will need to scale it down to fit a small practice, but its structure gives you a checklist of areas to think about, and it helps you notice gaps you might otherwise miss.

One control that often appears in these plans is multi-factor authentication. The FTC's Safeguards Rule defines it as authentication through verification of at least two of three types of authentication factors: knowledge factors, such as a password; possession factors; or inherence factors, such as biometric characteristics ( FTC, "FTC Safeguards Rule: What Your Business Needs to Know"). The definition has a practical consequence. Two passwords are both knowledge factors, so they do not add up to multi-factor authentication under that definition. The plan should say which accounts use it, such as accounting software, email, banking, and any client portal, and which do not.

Keep the list of controls honest. A plan that claims a safeguard you do not actually use is worse than a shorter plan that describes what you really do. When you update the document, check each claim against the setting in the tool itself, not against what you remember turning on. Write down the date of each change so the record matches the practice, and so that you can show what was in place at a given time if a question ever comes up.

Access is the part of the plan clients are most likely to ask about, so describe it in plain terms. List the roles in your practice, such as owner, bookkeeper, and assistant, and say which of them can see billing details, change bank information, or export files. Shared logins make that hard to track, so note where you use them and whether you can replace them with individual accounts. Remove access when someone stops working on a client's file or leaves the practice. Use the invoice login security guide for a related account review.

Backups deserve a line of their own. Your plan should say where copies of client files are kept, who can restore them, and whether a copy is stored apart from the original. A backup that shares the same login as the original can be lost along with it.

What must I do if client data is exposed?

Under the FTC's Safeguards Rule, covered financial institutions must notify the FTC as soon as possible, and no later than 30 days after discovery, of what the Rule calls a notification event ( FTC, "FTC Safeguards Rule: What Your Business Needs to Know"). That deadline is set out in section 314.4(j), and the clock runs from discovery.

A notification event is a security breach involving the unauthorized acquisition of at least 500 consumers' unencrypted information. Both parts of that test matter. The breach must involve unauthorized acquisition, meaning someone who was not entitled to the information obtained it. The count covers consumers' unencrypted information, so encryption changes whether an event counts for this purpose. Knowing whether your client files are encrypted, and roughly how many consumers' information you hold, is therefore part of the plan, not a detail for later.

Do not treat the 500-consumer figure as the whole answer on its own; check how the Rule and the FTC page use each term.

Because the clock starts at discovery, a plan should say how you would find out about an incident and who would decide whether it must be reported. A plan that waits for an incident before deciding on the process will spend the critical hours working out the process, not responding. Write the steps down in advance: who you call, what you preserve, which clients you tell, and where you would find the official reporting instructions. A short written checklist is enough, as long as it is ready before you need it.

Keep a simple incident log as well. Record when you learned of a problem, what you saw, what you did, and when you did it. The log supports any report you have to make and gives you a record of events if a client or regulator asks later. After each incident, review the log and update the plan wherever it fell short.

Illustrative example: inventory before writing

Suppose a practice holds 10 client folders in a cloud service and 10 paper folders. Its inventory covers 20 folders across those storage locations. It records the data types, who can open each location and how files leave the practice. If bank details appear in both places, the plan must describe protection in both places rather than treating the folder count as the whole risk assessment.

Today, inventory the client data in your accounting software: record what it contains, who can open it and how it leaves your hands. Use that record to begin your plan.

Where should I start?

Start by finding out whether either federal rule covers your work, then write an inventory of the client data you hold. Those two steps settle the first factor and most of the second, and they tell you how much of the rest applies to you.

Do clients need the whole plan?

Clients do not need the whole document. A short note that explains what data you keep, how it is protected, and whom they can contact with questions answers the question most clients have, and it gives you a chance to learn which information they consider most sensitive.

When should I review the plan?

Review the plan when you change tools, add staff, start collecting a new kind of client data, or find that a control is not working as described. Keep the document short and accurate.