If you are building or updating a Written Information Security Program, the hardest part is often not the security itself — it is knowing what the document needs to contain and how to structure it so it actually holds up under regulatory review. A WISP that looks like it was downloaded from the internet and never customized will not satisfy regulators, auditors, or enterprise clients reviewing your security posture. This WISP template breaks down the seven sections every security program needs, explains what belongs in each one, and gives you a framework you can adapt to your organization's size, industry, and risk profile.

Before You Start: What a WISP Template Must Actually Do

A WISP is not a generic IT policy document. It is a living, organization-specific program that documents how your company identifies, manages, and responds to information security risks in a way that is tailored to the actual data you handle, the systems you use, and the threats you face. Under the FTC Safeguards Rule, it must be tailored to the size and complexity of your organization and the sensitivity of the customer information you handle. Treat this template as a structure — the starting point that your organization's specific details, controls, and context need to fill in before it becomes a real compliance asset.

Section 1: Program Overview and Governance

The first section establishes the foundation that every other part of the WISP rests on. It defines the purpose of the program, the scope (which systems, data types, locations, and business units are covered), and — most importantly — it formally designates your Qualified Individual: the named person responsible for overseeing and coordinating your information security program. Regulators start here. If there is no named individual with clear accountability, the rest of the program has no owner and no enforceability.

What to include: a program purpose statement explaining why the WISP exists and what it is designed to protect; an organizational scope statement defining the boundaries of the program; the Qualified Individual's name, title, and specific responsibilities; their reporting structure and to whom they present annually; and the schedule for program review and update.

Section 2: Risk Assessment

Every other section of your WISP should trace back to a risk identified here. The risk assessment documents what sensitive information your organization handles, where it lives, how it moves, and what could realistically threaten its security, confidentiality, or integrity. This section should include a complete data inventory identifying what types of customer information you collect, store, process, and transmit; a device inventory covering every system that touches that data; a threat and vulnerability register identifying the realistic risks your organization faces; an evaluation of how effective your current controls are against those risks; and documentation of residual risk that remains after controls are applied.

If a risk exists in your assessment but has no corresponding control, you have a documented gap. If a control exists but has no corresponding risk, the control is undocumented. Both situations create problems in an audit or regulatory review. Revisit your risk assessment at least annually and whenever your business, systems, or threat environment changes materially.

Section 3: Safeguards Program

This is the operational core of your WISP — the specific controls your organization has implemented to address the risks identified in Section 2. Administrative safeguards include your access management policies, employee training requirements, background check procedures for personnel handling sensitive data, password standards, and acceptable use policies. Technical safeguards include multi-factor authentication, encryption for data at rest and in transit, endpoint protection and monitoring, patch management processes, network segmentation, and access logging. Physical safeguards cover access controls to spaces containing sensitive systems, device security policies, visitor management, and secure disposal procedures for physical media and decommissioned hardware.

Write this section in plain language that your team can actually follow and that a regulator without deep technical expertise can evaluate. A safeguards section that reads like a vendor data sheet or a technical specification provides no practical protection and no meaningful audit defense.

Section 4: Employee Training Program

This section documents your organization's approach to security awareness training — who receives it, what it covers, how frequently it occurs, and how completion is recorded. The FTC Safeguards Rule explicitly requires ongoing employee training, and "ongoing" means more than a one-time onboarding module. Training must evolve to address new threats, be tailored to the specific risks relevant to each role, and be documented with records that prove compliance.

What to include: training frequency and delivery format; curriculum outline covering the topics addressed in each training cycle; completion tracking process including how records are maintained and for how long; and a process for updating training content in response to new threats or changes in the organization's risk profile.

Section 5: Vendor and Third-Party Risk Management

Your security program is only as strong as the vendors and service providers who have access to your customer data. This section documents your process for selecting service providers, the contractual requirements you impose on them, and how you monitor their ongoing compliance. Every vendor with access to customer information — cloud providers, payroll platforms, accounting software vendors, IT support providers — should be represented here with evidence of your vetting process and the data protection obligations in your contract with them.

What to include: your vendor inventory; the criteria you use to evaluate vendors before onboarding; required contract provisions covering data protection obligations, breach notification requirements, and your right to audit; and your process for periodic vendor reviews including what you review and how often.

Section 6: Incident Response Plan

This section documents your organization's procedures for detecting, responding to, and recovering from security incidents — including data breaches, ransomware events, and unauthorized access to customer information. The FTC Safeguards Rule requires a written incident response plan, and the plan must be more than a theoretical document — it must be tested, communicated to the people who would need to execute it, and connected to actual response capabilities.

What to include: incident classification criteria; defined roles and responsibilities for the response team; internal escalation procedures; external notification procedures including FTC breach notification requirements for incidents affecting 500 or more individuals and applicable state notification timelines; evidence preservation guidance; communication templates for internal and external stakeholders; and a post-incident review process for capturing lessons learned and incorporating them into the plan.

Section 7: Program Review and Update Procedures

A WISP with no revision history is a WISP that has never been maintained — and regulators and auditors know what that looks like. This section establishes how and when your program will be reviewed and updated, who is responsible for initiating reviews, what events trigger an out-of-cycle update, and how updates are documented and communicated.

What to include: your annual review schedule and the process for conducting it; event-triggered review criteria such as new systems, significant personnel changes, security incidents, regulatory changes, or material changes in the business; a document version control procedure; and your board reporting schedule confirming when and how the Qualified Individual reports to senior leadership.

Need Help Building Your WISP Beyond the Template?

A template gives you the structure. A well-built WISP requires an honest assessment of your actual environment, controls that reflect your real risk profile, and documentation that will stand up under regulatory and audit scrutiny. OCD Tech helps organizations across Boston build WISPs that go beyond template compliance — programs that are accurate, actively maintained, and defensible when it matters. Talk to our team today and let's build a security program that actually works.