MSP WISP Template: Write the Client's Security Program, Then Scope the Work

A written information security program (WISP) is the document that says how a client protects customer data, who is in charge of it, and how anyone would know it is working.

Clients usually ask for one after a trigger. The tax preparer hears about it from the IRS. The financial advisor gets a question from an examiner or an insurer. The accounting firm with Massachusetts clients finds out a state rule has required a written program for years. Then the owner calls the MSP and asks for "the WISP template."

You can hand over a template. The better move is to use the template as a working session: fill in what you already know, mark what the client owns, and list the gaps that need scoped work. That turns a compliance chore into a clear roadmap conversation.

This guide is written for the vCIO, account lead, or technical owner who advises more than one client and needs a repeatable way to do this.

What this template is and is not

This is a drafting aid for a client's program. It is not legal advice, and filling it in does not make a client compliant with anything. The client's counsel, auditor, or examiner decides that.

It also does not move the client's responsibility onto you. Under the FTC Safeguards Rule, a service provider can serve as the Qualified Individual, but the financial institution still keeps responsibility for compliance and has to designate a senior member of its own staff to direct and oversee that person (16 CFR 314.4(a)). Write that into the program in plain words, so nobody reads your name on the cover page as a promise you did not make.

Which clients need a written program

Start with the rule that applies to the client, then write the program to match it. Three common triggers for MSP clients:

Sources: 16 CFR Part 314 (eCFR), 201 CMR 17.00 (Mass.gov), IRS Publication 5708 (Rev. 8-2024). Checked October 23, 2026.

Two details change the scope:

• Small institutions. Under 16 CFR 314.6, a financial institution that maintains customer information on fewer than 5,000 consumers is exempt from the written risk assessment, the continuous monitoring or testing requirement, the written incident response plan, and the annual board report. The rest of the program still applies.
• FTC breach notice. Since May 13, 2024, covered institutions must notify the FTC within 30 days of discovering a notification event involving the information of at least 500 consumers (16 CFR 314.4(j)). Put that clock in the incident section so nobody discovers it during the incident.

Other clients ask for a WISP because an insurer, a bank partner, or a larger customer asked for one. In those cases, ask for the exact question or contract clause before you draft. The wording tells you how much detail they expect.

The WISP template outline

Copy this outline into the client's document. Each section names a decision, an owner, and the evidence that shows it is real. The section list follows the elements in 16 CFR 314.4 and 201 CMR 17.03, so one draft can serve a client covered by both.

WRITTEN INFORMATION SECURITY PROGRAM
Client: ____________________   Version: ____   Approved by: ____________   Date: ________

1. Purpose and scope
   - What information the program protects (customer, employee, financial, tax)
   - Which locations, systems, paper records, and vendors are in scope

2. Program ownership
   - Qualified Individual or designated employee(s): name, role, employer
   - Senior client officer who oversees the program (if the owner is a service provider)
   - Who approves changes to this document

3. Information inventory
   - Where customer information lives (systems, file shares, cloud apps, paper)
   - Who can reach it, and how that access is approved

4. Risk assessment
   - Method, date of last assessment, and criteria used to rate risks
   - Link to the current risk register and the decision on each risk

5. Safeguards
   - Access control and periodic access review
   - Encryption in transit and at rest (or approved compensating control)
   - Multi-factor authentication for anyone accessing customer information
   - Secure disposal and data retention schedule
   - Change management
   - Activity monitoring and logging
   - Physical security for offices and paper records
   - Off-premises rules for laptops, phones, and paper files

6. Testing and monitoring
   - Continuous monitoring, or annual penetration test plus vulnerability
     assessments at least every six months
   - Who reviews results and how findings are tracked

7. People
   - Security awareness training: who, how often, proof of completion
   - Discipline for violations
   - Removal of access when someone leaves

8. Service providers
   - List of providers with access to customer information
   - How each was selected and what the contract requires
   - How often each provider is reviewed

9. Incident response
   - Who declares an incident and who is called first
   - Regulatory and contractual notice clocks
   - Post-incident review and changes made

10. Review and reporting
    - Annual review date, or sooner after a material business change
    - Annual written report to the board or senior officer
    - Change log for this document

The outline is the easy part. The table below is where most of the advisory work happens.

Owner and evidence table

Fill this in with the client during the working session. Leave a cell blank when nobody knows the answer. A blank cell is a finding, and findings are what you scope.

If the "MSP supports" column is longer than your current agreement, that is useful information. Some of it is already in your managed service. The rest is project work, a recurring add-on, or something the client handles with another provider.

For the split between your team and the client in more detail, the shared responsibility matrix template uses the same idea across the whole agreement.

How to run the WISP working session

Plan for one meeting with the owner or office manager and one follow-up for evidence. A sequence that keeps it moving:

1. Confirm the trigger. Which rule, examiner question, insurer form, or contract clause started this? Write it at the top of the document.
2. Name the people. Who is the Qualified Individual or designated employee, and which senior person oversees the program? Do this first, because every later section needs an owner.
3. Walk the inventory. Where does customer information live, including the paper files and the scanner that emails to a personal inbox.
4. Mark each safeguard as in place, partial, or missing. Attach evidence for the first group and move on.
5. Read back the gaps. Turn every partial or missing item into a short finding with a severity and a proposed next step.
6. Agree on the review date. The program needs a review at least annually under 201 CMR 17.03, and the Safeguards Rule expects changes when the business or its risks change.

If the client has never had a risk assessment, run that first. The MSP risk assessment template covers how to rate findings and turn them into decisions. If the incident section is thin, the MSP incident response plan template gives you the call tree and decision owners.

Turn the gaps into scoped work

Most first drafts end with a list of gaps like these:

• MFA is enforced on email but not on the tax software or the line-of-business app.
• Laptops are encrypted, but nobody can produce a report that shows it.
• There is no written vendor list, and two vendors have shared admin accounts.
• Former staff still have access to a cloud file share.
• No one has tested the incident plan, or there is no plan.
• Paper records are kept in an unlocked room.

Sort each gap into one of four outcomes:

The accepted-risk row matters. A WISP with honest, dated risk decisions is more useful to the client than one that claims every control is in place.

If you price this as a recurring service, the MSP compliance pricing guide walks through how to separate the program work from the technical work. If the trigger was an insurance form, compare the gaps against what cyber insurance underwriters check so the same evidence answers both.

Keep the program current without rebuilding it

The first draft takes effort. The second year should not start from a blank page.

Keep the program, the risk register, and the evidence close to the client record, then review them on a schedule:

• Quarterly: access review, MFA coverage, open findings, vendor changes.
• After any material change: new office, new system holding customer data, merger, or a new vendor with access.
• Annually: full program review, updated risk assessment where required, and the written report to the board or senior officer.

That review cycle is the same rhythm as a good business review. The gap analysis workflow for vCIOs shows how to keep findings moving between those meetings.

This is where Scopable's GRC workflow fits: you can attach a framework to a client, track evidence signals and compliance gaps with severity, and turn a finding into a roadmap item, accepted risk, scoped remediation project, or quote. Legal and audit judgment stays with the client's counsel and auditor. Scopable keeps your advisory work and the client's decisions in one record, so next year's WISP review starts from what changed.

To run your next WISP session from a client record instead of a blank document, start Scopable for free.