What a Real Written Information Security Program Looks Like

Many businesses think a downloaded template satisfies the FTC Safeguards Rule. It doesn't. Swapping in a company name and filing the document away in a shared drive doesn't turn a template into a complete security program.

The FTC has been direct about this distinction. Under the Safeguards Rule, your information security program must be written and appropriate to the size and complexity of your business, the nature and scope of your activities, and the sensitivity of the information you handle. A generic template written for a hypothetical company can't meet that standard, because it was never built around your systems, your vendors, or your actual risks.

This blog will review what a real written information security program (WISP) looks like and the professionals your business needs to achieve it.

The Rule Behind the Requirement

The Safeguards Rule is part of the Gramm-Leach-Bliley Act. It applies to non-bank financial institutions under FTC jurisdiction: tax preparers, mortgage brokers, auto dealers that arrange financing, payday lenders, and similar businesses that handle consumer financial data. The FTC updated the Rule in December 2021, and most of the new requirements took effect on June 9, 2023, according to a summary published by the U.S. Department of Education's Federal Student Aid office, which also enforces the Rule against postsecondary institutions that participate in Title IV programs.

That 2023 update matters because it changed what "written" means in practice. The original 2003 version of the Rule was principles-based and left companies broad discretion in how they designed their programs. The current version is prescriptive. It lists nine specific elements a Written Information Security Program, often shortened to WISP, must contain, and each one is independently enforceable.

The Elements a Template Can't Fake

The Department of Education's guidance clearly lays out the nine elements, and each requires information only your organization can provide.

The program must designate a qualified individual to oversee and enforce it. That person doesn't need a security credential or a particular job title. What the FTC cares about is whether they have the experience to actually run the program, and whether senior management or the board holds ultimate responsibility, even if the role is outsourced to a contractor or a virtual CISO.

The program has to rest on a written risk assessment. This is where most template-based programs fall apart first, because a risk assessment can't be copied from another company. It has to identify the specific internal and external threats to your customer information, assess how likely and damaging each is, and evaluate whether your current safeguards actually address them.

From there, the program must describe the safeguards you've put in place to control the risks identified in the assessment. The Rule lists minimum categories these safeguards need to cover, including access controls, data inventory, encryption of customer information both at rest and in transit, secure application development practices, and multi-factor authentication for anyone accessing customer data. The FTC has singled out encryption and multi-factor authentication specifically, noting that businesses can meaningfully reduce their breach risk by encrypting customer information at rest and in transit.

The remaining elements cover the parts of a program that turn a document into an operating system for security. The company has to test or monitor whether its safeguards are actually working. It has to train personnel to carry out the program, not just acknowledge it. And it has to manage service providers by vetting them, binding them to security obligations in contracts, and reassessing them periodically. The program has to evolve, too. The Rule requires companies to adjust their program based on the results of monitoring, penetration testing, and risk assessments, and to reconsider it whenever the business itself changes in ways that affect its risk profile.

Two final elements apply once a company holds information on 5,000 or more consumers: a written incident response plan, and a requirement that the qualified individual report to the board or senior management at least once a year on the state of the program. Smaller companies are exempt from the last two elements, as well as from the written risk assessment and annual penetration testing. However, they still need a functioning security program built on the first several elements.

Why the Paper Version Fails

None of these nine elements can be satisfied by prose alone. A risk assessment that never references your actual vendors, data flows, or past incidents only describes what a risk assessment should contain. Auditors and regulators can tell the difference immediately, because a real assessment produces findings that show up elsewhere in the program: specific safeguards tied to specific risks, specific training tied to specific roles, specific contract language with specific vendors.

The FTC's own guidance to auto dealers makes this connection explicit. It describes the written program as the record of all the processes and procedures a company follows to protect customer information, covering how that information is collected, stored, shared with other companies, and disposed of once it's no longer needed. A document that never mentions how your company actually collects or disposes of data hasn't described a process. It has described an idea of one.

What a Compliant WISP Actually Looks Like

A functioning WISP reads like an internal reference document, not a marketing brochure. It names the qualified individual by role and explains how they're supervised. It includes a risk assessment with dated findings, not boilerplate risk categories. It maps each required safeguard to the specific risk it addresses so that a reader can trace the logic from threat to control. It documents the testing schedule that's actually been run, not a generic promise to "test regularly." It lists the vendors handling customer data and the contract clauses that hold them accountable. It shows a revision history because a program that hasn't changed in three years wasn't adjusted in response to anything, which itself violates the Rule's requirement to keep the program current.

None of this needs to be elaborate. Small and mid-sized businesses covered by the Rule aren't expected to build enterprise-grade security operations. The Rule itself says the program only needs to be appropriate to the company's size, complexity, and the sensitivity of the data it holds. But appropriate still means specific. A five-page WISP that accurately describes a small tax practice's real processes will hold up better under examination than a fifty-page template stuffed with controls the firm never implemented.

Building a WISP That Holds Up

Start with the risk assessment, because everything else in the program depends on it. Identify where customer information actually lives, who can access it, and which vendors touch it. Then build safeguards that respond to what that assessment found, not to a checklist copied from somewhere else. Assign the qualified individual role to someone who will actually read the incident logs and sign off on the annual report. Put a revision date on the document and commit to revisiting it every time something material changes, whether that's a new vendor, a new system, or a new threat.

A written information security program is meant to function as a working record of how a business actually protects the data in its care. Treated that way, it holds up when a regulator asks to see it. When treated as paperwork, it becomes the first thing to fall apart during an examination, right when the business needs it most.

As a managed IT service provider, PK Tech is proud to offer 15 years of experience with a focus on small to medium-sized businesses. We boast AICPA's SOC 2 Type II attestation, proving via third-party audit that we passed a rigorous and comprehensive assessment of our security and privacy controls.

Schedule a WISP compliance review with our team.