How To Build a WISP (Written Information Security Program) for the FTC Safeguards Rule

A WISP (Written Information Security Program) is the written, living “source of truth” for how your business protects customer information under the FTC Safeguards Rule. It’s not just a policy binder—it should connect your risk assessment to the safeguards you actually operate (access controls, encryption, training, vendor oversight, monitoring/testing, and incident response). The most maintainable approach is to build the WISP in the same order the Rule describes program elements, and to document simple routines for updates and evidence. For the official FTC overview, see the FTC’s guidance on the Safeguards Rule here.

TL;DR

• Start by naming your program owner (“Qualified Individual”) and scoping what’s in bounds.
• Write your risk assessment early—your WISP should trace safeguards back to risks.
• Document what you actually do, who owns it, and what proof you keep.
• Build a maintenance cadence (training, vendor reviews, monitoring/testing, leadership reporting).
• Include an incident response approach and a clear update rhythm so the WISP stays “living.”

---

Who This Is For

This is for:

• Small businesses that handle customer financial information and need a WISP that aligns to the FTC Safeguards Rule
• CPA and accounting firms building an FTC-aligned program that’s realistic to maintain
• Owners/partners who want clear documentation they can use for client security questionnaires and insurance renewals

This is not for:

• Enterprises seeking a deeply technical, framework-by-framework implementation playbook
• Teams that want a one-size-fits-all template without tailoring (a WISP that doesn’t match reality is hard to defend)

What This Is

A Written Information Security Program (WISP) is the written documentation of your information security program—your scope, roles, risk assessment, safeguards, oversight routines, and how you keep everything current.

Plain-English definition: your WISP answers:

• What customer information do you have, and where does it live
• What risks could realistically affect it
• What safeguards do you use to reduce those risks
• How you monitor, test, train, and manage vendors
• How you respond to security events and report status to leadership

If you’re unsure whether the Rule applies to your organization or how exceptions apply, confirm with counsel—coverage and obligations can be fact-specific.

Why This Matters

The FTC Safeguards Rule is designed to push covered organizations toward a reasonable, risk-based security program, not a “checkbox binder.” Reviewers (clients, insurers, auditors, regulators) usually want to see clear ownership, a written risk assessment, safeguards tied to risks, and evidence that the program is maintained over time.

A short scenario (anonymized):
A small CPA firm has solid tools and a capable IT partner, but no single document that ties risks to safeguards. A client vendor assessment asks for proof of vendor oversight, incident response, and testing routines. The firm scrambles to assemble “something that looks like a WISP.” A maintainable WISP won’t eliminate work, but it replaces last-minute scrambling with a simple update rhythm and a clear evidence trail.

The “Step-by-Step” WISP Build Sequence

Use this sequence to produce a WISP that maps cleanly to the Rule’s program elements:

1. Name the owner (Qualified Individual) + backup, and define authority and reporting.
2. Define scope: what “customer information” you handle, systems, users, vendors, and locations.
3. Inventory: where customer information is collected, stored, transmitted, and disposed of.
4. Write the risk assessment: foreseeable risks, current safeguards, gaps, remediation plan, and risk acceptance decisions.
5. Document safeguards (administrative/technical/physical) and map them to risks.
6. Define monitoring/testing routines and what evidence you keep.
7. Vendor oversight: selection criteria, contracts, and periodic review routine.
8. Incident response + reporting: what you do during a security event, and how leadership gets regular written updates.
9. Maintenance cadence: annual review, change triggers, and version/change log.

Recommended WISP Table of Contents

This outline is intentionally “small-business sized.” Add detail only where your risk assessment requires it.

1. Purpose, scope, and definitions (including what you treat as “customer information”)
2. Roles & responsibilities (Qualified Individual, leadership, control owners)
3. System/data inventory (where data lives + who can access it)
4. Risk assessment (method, results summary, remediation plan, risk acceptance log)
5. Safeguards (by topic: access, encryption, devices, disposal, change management, logging/monitoring, app/security evaluation)
6. Monitoring & testing plan (cadence + evidence)
7. Training plan (baseline + refreshers + specialized training where needed)
8. Service provider oversight (selection, contract expectations, periodic review)
9. Incident response plan (and breach notification decision path)
10. Leadership reporting (annual written report + what it includes)
11. Program maintenance (review triggers, version control, exception process)

Key Exception / Applicability Callout (Read This Early)

The Safeguards Rule includes a limited exception for certain requirements if you maintain customer information concerning fewer than 5,000 consumers. If you believe an exception may apply to your organization, document your reasoning and confirm with your attorney if you’re unsure. Even when an exception applies to certain provisions, many organizations still document a lightweight version of those elements because it improves operational readiness and supports common client/insurer expectations.

Detailed Plain-English Breakdown (Mapped to FTC Safeguards Rule Elements)

1. Designate a Qualified Individual (QI)

Meaning:
Name the person responsible for overseeing and implementing the information security program. The QI can be internal, an affiliate, or a service provider—but your business remains responsible for compliance.

Common failure:
“No one owns it.” Security happens, but decisions, exceptions, and updates aren’t governed.

What good looks like:

• Named QI + backup
• Short responsibilities list (risk assessment ownership, policy updates, vendor oversight, monitoring/testing, incident coordination)
• Simple exception log (what/why/who approved/expiration)

---

2. Conduct a Written Risk Assessment

Meaning:
Your risk assessment identifies reasonably foreseeable internal/external risks and evaluates whether your safeguards sufficiently control them. Your WISP should clearly show how risks are evaluated, prioritized, mitigated, or formally accepted.

Common failure:
A generic risk assessment that doesn’t reflect actual systems, vendors, and workflows—and doesn’t drive decisions.

What good looks like:

• Inventory-first: systems, devices, users, vendors, and data locations
• Clear mapping: Risk → Existing safeguards → Gaps → Plan → Owner → Target date
• A short “risk acceptance” approach (who can accept risk, how it’s documented)

CPA firm note: include seasonal staffing changes, client portals/document exchange, remote work devices, and the tax software ecosystem in scope and risk considerations.

---

3. Design and Implement Safeguards to Control Identified Risks

Meaning:
Based on your risk assessment, you must design and implement safeguards that address the risks you identified.

Common failure:
The WISP lists best practices but doesn’t say what you actually do, who does it, or how you prove it.

What good looks like:
For each safeguard topic, document:

• Meaning: why it exists
• Owner: who maintains it
• Cadence: how often it’s reviewed
• Evidence: what you save (reports, tickets, logs, sign-offs)

Safeguard topics to cover (plain-English):

1. Access controls: who has access, why, and periodic reviews
2. Data inventory: where customer info is collected/stored/transmitted
3. Encryption: at rest and in transit (or documented equivalent controls if not feasible)
4. Apps/tools evaluation: how you evaluate software used to store/access/transmit customer info
5. Multi-factor authentication (MFA): for access to systems with customer info (with written QI-approved equivalent controls if used)
6. Secure disposal: how you dispose of customer information when no longer needed (and how you handle legal retention needs)
7. Change management: how you evaluate security impact before meaningful system changes
8. Logging/monitoring: how you track authorized user activity and detect unauthorized access

---

4. Regularly Monitor and Test Safeguard Effectiveness

Meaning:
You must monitor and test safeguards on a cadence appropriate to your environment, and increase testing after material changes.

Common failure:
“Set it and forget it.” Tools exist, but no cadence, no accountability, no proof.

What good looks like:

• A simple schedule: what’s monitored/tested, by whom, how often
• An evidence plan: monthly/quarterly summaries, tickets, reports
• “Material change” triggers: new system, new vendor, new office, major staffing shift, incident/near-miss

---

5. Train Staff

Meaning:
Provide security awareness training and refreshers; add specialized training for people responsible for implementing safeguards, where needed.

Common failure:
Training is informal with no tracking or onboarding process.

What good looks like:

• New-hire training promptly
• Annual baseline + periodic refreshers
• Tracking: completion records + policy acknowledgments
• Clear “how we report suspicious activity” guidance

---

6. Oversee Service Providers (Vendor Management)

Meaning:
Select capable service providers, require appropriate safeguards via contract, and periodically assess them.

Common failure:
Vendors are chosen for convenience; security expectations aren’t documented or reviewed.

What good looks like:

• Vendor list of “in-scope” providers (IT, cloud, payroll, portals, e-sign, hosting, etc.)
• Minimum contract expectations (confidentiality, access control, incident notification, data handling)
• Annual review routine (questionnaire, attestations when available, or documented review notes)

---

7. Keep the Program Current

Meaning:
Update your program based on the results of testing/monitoring, material changes, or emerging threats.

Common failure:
The WISP is written once and never updated.

What good looks like:

• Annual review + interim updates after meaningful changes
• Versioning and a change log (what changed, why, who approved)
• A short “exception” process so temporary deviations don’t become permanent

---

8. Create a Written Incident Response Plan

Meaning:
A written plan that covers roles, communications, remediation, documentation, and post-incident improvement.

Common failure:
The plan is a generic template that doesn’t match how decisions are actually made (or it doesn’t exist).

What good looks like:

• A one-page “who does what” during an event
• Vendor contact list + escalation path
• Decision points: containment, recovery, customer/client comms (as applicable), legal/insurance engagement
• Post-incident review routine (“what we learned” and what changes)

Exception note: if you believe a small-entity exception applies to some requirements, document your analysis and confirm with your attorney if needed; many firms still keep a lightweight plan because it improves operational readiness.

---

9. Provide Regular Written Reporting to Leadership

Meaning:
Leadership should receive a written program status update on a defined cadence (often at least annually), covering program status, key risks, testing/monitoring results, vendor oversight, security events (if any), and recommended changes.

Common failure:
Leadership never gets a clear picture of risk, progress, and open items—so funding and decisions are reactive.

What good looks like:

• A short annual memo (1–3 pages) with: program overview, major changes, key findings, vendor risks, testing results, incidents (if any), and next priorities
• A standing monthly/quarterly cadence (even a brief status update) for growing firms

---

10. Breach Notification Decision Path

Meaning:
Your incident response plan should include a “notification decision path,” so the team knows who decides, what facts to gather, and when to involve counsel/insurer if a security event occurs.

Common failure:
Confusing internal incident response with notification obligations—or assuming notification is never required.

What good looks like:

• A documented decision path (roles, timing, evidence capture, approvals)
• A timeline record of actions and decisions

---

Common Mistakes & Misconceptions

• Tools ≠ compliance. Tools can support safeguards, but the WISP must show governance, consistency, and evidence.
• Outsourcing ≠ outsourcing accountability. A provider can help implement and supervise, but the business remains responsible.
• A template WISP is enough. A WISP that doesn’t match your real environment becomes a liability during reviews.
• Risk assessment is a one-time project. Expect to revisit risks as systems, vendors, and workflows change.
• “We’ll document it later.” Documentation created only under a deadline is usually incomplete and inconsistent.

High-Level Implementation Overview (People / Process / Technology)

People

• Name the QI and backup; define decision rights for exceptions and risk acceptance
• Assign “control owners” (training, vendor management, monitoring/testing, incident response coordination)
• Make leadership reporting routine, not event-driven

Process

• Keep a WISP change log and a simple evidence routine
• Tie every major safeguard back to a risk
• Use a “review trigger” list (new system, new vendor, new office, staffing changes, security event)

Technology (No Configuration, Just Outcomes)

• Use technology to enforce what your WISP says you do (identity controls, device protections, monitoring/testing, backups, secure data handling)
• Focus documentation on who/what/how often/how you prove it, not brand names

Leader Self-Check (5-Minute Checklist)

•  We have a named Qualified Individual (and backup) with clear responsibilities
•  We can list where customer information lives and who can access it
•  Our risk assessment is written, current, and drives remediation priorities
•  We can show access review evidence and offboarding consistency
•  We have a monitoring/testing schedule and can produce proof of execution
•  We track training completion and policy acknowledgments
•  We maintain a vendor list with a periodic reassessment routine
•  We have a written incident response plan (or a documented exception analysis)
•  Leadership receives a written security program status report on a cadence
•  We update the WISP after meaningful operational changes

---

How Office Heroes Supports This

Most small businesses and CPA firms don’t struggle with wanting a WISP—they struggle with turning “we do security stuff” into a defensible, maintainable program that ties together (1) what data you handle, (2) what risks matter, (3) what safeguards you actually run, and (4) what proof you can produce on demand.

Office Heroes helps by taking the work that usually becomes a last-minute scramble—documentation, evidence routines, and program consistency—and making it a repeatable operating rhythm. Specifically, we can help you:

• Translate your environment into a WISP that matches reality (scope, systems/data inventory, roles, and plain-English policies that align to your actual workflows).
• Turn the risk assessment into an action plan (risk-to-safeguard mapping, prioritized remediation, and a simple risk acceptance/exception process that leadership can approve).
• Set up “audit-ready” evidence habits (what to collect, how often, and where it lives—so client/insurer questionnaires don’t become emergencies).
• Strengthen verification where your risks justify it, including independent testing like network penetration testing when it makes sense for your scope.
• Run ongoing compliance operations (risk tracking, vendor oversight routines, monitoring/testing cadence, and leadership-ready reporting) through Compliance Risk Management.

Office Heroes can support compliance efforts, but responsibility remains with the business.

Related Resources & Internal Links

If you’re building a broader Safeguards program, start at the FTC Safeguards Rule Compliance Guide hub, and use the WISP as the document that ties everything together.

Links Needed (so we don’t invent URLs):

• WISP Breakdown page URL
• FTC Assessment page URL (requested internal deep link)
• Overwatch package overview page URL (if separate from the service page)

When to Get Help

Consider outside help (IT, compliance, and/or counsel) if:

• You can’t confidently scope where customer information lives or who can access it
• Your vendor ecosystem is large or fast-changing (and oversight is informal)
• You’re struggling to produce consistent evidence of monitoring/testing routines
• You’ve had a security event and need to validate response + notification decision paths
• You’re preparing for a client security review, insurer renewal, or regulatory inquiry

If you want a practical starting point, book an IT consultation to scope your environment and build a WISP plan you can maintain.