Resource
A Written Information Security Plan, or WISP, is a documented program that explains how an organization identifies, protects, monitors, and responds to risks involving sensitive information. It applies to businesses of every size, especially organizations that handle customer, employee, financial, health, payment, or confidential business data.
What is a Written Information Security Plan?
A WISP turns information security from a collection of informal habits into an accountable business program. It records the safeguards an organization uses, who owns those safeguards, how risks are evaluated, and what happens when a security issue occurs.
"Written" matters because a business must be able to show that its security decisions are intentional, repeatable, and reviewable. A plan that exists only in the owner's memory, in scattered vendor portals, or in an employee handbook is difficult to operate and even harder to defend after an incident.
A practical WISP is not a single software product or a generic policy downloaded from the internet. It is a living set of business-specific decisions connecting people, technology, facilities, vendors, data, and response procedures.
For example, a medical office may focus on protected health information, secure communications, access controls, backups, and workforce training. A CPA firm may emphasize client tax data, identity information, financial records, email security, and remote access. A commercial property team may also need to account for cameras, badge systems, controllers, tenant platforms, and building networks.
The plan should identify the information the business has, where it resides, who needs access, what could go wrong, and how the organization reduces the resulting risk. It should also name the individuals or roles responsible for maintaining the plan.
A WISP is a business protection document: it makes security ownership, safeguards, and response expectations clear before a problem tests them.
Takeaway: A WISP gives an organization a documented, usable security operating model rather than a collection of disconnected tools.
Why does a business need a WISP?
Most security failures are not caused by a lack of concern. They happen because responsibilities are unclear, sensitive data is not inventoried, access accumulates over time, changes are made without review, or no one has rehearsed what to do when something looks wrong.
A WISP creates structure around those risks. It establishes who approves access, how former employee accounts are removed, what security training covers, how vendors are evaluated, how backups are protected, and who makes decisions during a suspected incident.
The business impact can be substantial. A compromised mailbox can expose invoices, payroll information, client communications, and account-reset requests. A lost device can place stored files at risk. An unprotected network device can create a path into systems that support daily operations.
Small and mid-sized businesses are not exempt from these challenges. They often have fewer internal layers, rely on cloud platforms and outside providers, and need staff to move quickly. That makes clear security expectations and dependable technical support especially important.
A WISP also helps leadership make better tradeoffs. Not every risk can be eliminated, but a documented risk review helps the organization decide which safeguards are necessary, which risks are accepted, who accepts them, and when the decision must be reconsidered.
For firms operating across the Atlanta area, Norcross, Peachtree Corners, and the I-85 business corridor, a WISP can bring consistency to offices, remote workers, shared workspaces, and multi-tenant environments. It is particularly useful where business IT and physical systems overlap.
Takeaway: A WISP helps protect revenue, client trust, operations, and decision-making - not merely data files.
What should a WISP include?
The right plan is proportional to the organization's size, data, systems, regulatory obligations, and operational risk. A smaller business does not need a large-enterprise binder, but it does need clear controls that match how it actually works.
Each section should describe both the rule and the operational reality behind it. For instance, an access-control policy is stronger when it identifies the approval process, account owner, review frequency, privileged-account protections, and offboarding steps.
| WISP component | What it addresses | Useful evidence |
|---|---|---|
| Security ownership | Who is accountable for the plan, approvals, reviews, and incident decisions. | Named security coordinator, leadership approval, review schedule. |
| Data and system inventory | What sensitive data exists, where it is stored, processed, transmitted, and backed up. | Application list, device inventory, data-flow notes, vendor list. |
| Risk assessment | Likely threats, vulnerabilities, business impact, and planned risk treatment. | Documented findings, assigned actions, accepted-risk decisions. |
| Administrative safeguards | Policies for hiring, training, access approval, acceptable use, and vendor oversight. | Training records, signed policies, onboarding and offboarding checklists. |
| Technical safeguards | Controls that protect systems and data from unauthorized access or disruption. | Multi-factor authentication settings, patch records, endpoint protection, backup reports. |
| Physical safeguards | Protection of offices, equipment, network closets, records, cameras, and access systems. | Visitor rules, key or badge procedures, secured equipment areas. |
| Incident response and recovery | How the organization detects, contains, investigates, communicates, restores, and learns. | Contact list, escalation process, recovery procedures, exercise notes. |
| Ongoing review | How the plan stays accurate as systems, vendors, staff, and threats change. | Periodic reviews, change records, updated risk assessments. |
Core technical safeguards commonly include unique user accounts, multi-factor authentication, secure configuration, timely patching, endpoint protection, encryption where appropriate, secure backups, network segmentation, logging, and controlled remote access. The exact control set should follow the risk assessment rather than a generic checklist.
Vendor management belongs in the plan because sensitive data frequently moves through cloud platforms, payroll services, legal software, payment providers, phone systems, managed service providers, and specialized applications. The organization should understand what each provider receives and what security responsibilities remain internal.
Physical security deserves the same attention as digital security when systems support occupied buildings or operations. A compromised controller, exposed camera system, or poorly secured network closet can become a business continuity issue, not simply an IT ticket.
Takeaway: A complete WISP connects governance, people, technical controls, facilities, vendors, and response procedures.
Which compliance requirements and frameworks can affect a WISP?
A WISP may be a direct legal or contractual requirement, or it may be the practical document used to demonstrate a broader security obligation. The applicable requirements depend on the organization's industry, data, services, customers, and location.
Organizations subject to the FTC Safeguards Rule must maintain an information security program that includes written elements and is appropriate to their size, complexity, activities, and sensitivity of customer information. Many financial institutions and businesses within the Rule's scope use a WISP as the central record of that program.
Healthcare organizations and their business associates have obligations under HIPAA to perform risk analysis and implement appropriate administrative, physical, and technical safeguards. A WISP can organize those activities, but it does not replace the detailed HIPAA work of risk analysis, policy implementation, documentation, and ongoing review.
Businesses that accept payment cards must meet applicable PCI DSS responsibilities. Security policies, access management, network controls, incident procedures, and evidence of operation may all support that work. A WISP should clearly define scope rather than implying that one document alone creates PCI compliance.
Organizations working with Department of Defense information may have contractual cybersecurity obligations connected to CMMC and related requirements. Those organizations need a plan aligned to their actual system scope, contractual commitments, assessments, and evidence expectations.
State privacy, breach-notification, insurance, client-contract, and lender requirements can also influence the plan. A business should have qualified legal, compliance, insurance, and technical guidance where its obligations are uncertain or high-impact.
GDS Technology provides IT compliance services, including support relevant to HIPAA compliance, PCI compliance, FTC compliance, and CMMC compliance. The goal is to translate applicable security expectations into workable business practices.
Takeaway: Compliance may shape a WISP, but the plan must be tailored to the organization's real data, systems, and obligations.
How do you create and maintain a useful WISP?
Begin with business discovery, not a policy template. Identify the services the organization delivers, the information it handles, the systems it depends on, the people who need access, and the operational consequences if those systems become unavailable or exposed.
- Assign a responsible owner or security coordinator with authority to gather information and drive decisions.
- Inventory data, devices, applications, cloud services, network equipment, physical systems, and third-party providers.
- Map sensitive information from collection through storage, use, sharing, retention, and disposal.
- Perform a documented risk assessment that considers threats, vulnerabilities, likelihood, business impact, and existing safeguards.
- Select reasonable administrative, technical, and physical safeguards, then assign an owner and target action for each gap.
- Document incident response, communications, backup recovery, vendor escalation, and decision authority.
- Train personnel on their responsibilities and retain evidence that the training occurred.
- Review and update the plan after material changes, incidents, new vendors, office moves, system replacements, or scheduled reassessments.
Good WISP documentation is specific enough to guide action without becoming impossible to maintain. Avoid writing policies that promise controls the business does not operate. If a safeguard is planned but not yet active, record it as a remediation item with an accountable owner instead of presenting it as complete.
Testing is essential. Confirm that backups can be restored, offboarding actually removes access, multi-factor authentication covers the intended accounts, and incident contacts can be reached. A plan that has never been tested may fail at the moment the organization relies on it most.
For a deeper discussion of how incident decisions affect building-connected systems, see the Built, Wired & Secured article on isolating infected devices without spreading risk.
Takeaway: A useful WISP begins with accurate discovery, assigns ownership, and is tested and revised as the business changes.
What does a mature WISP program look like in daily operations?
A mature program does not live only in a compliance folder. It shows up in normal work: new employees receive appropriate access, departing employees are removed promptly, updates are managed, suspicious messages are reported, and business owners know whom to call when something appears wrong.
Leadership receives understandable risk information, not just technical alerts. They can see which risks are being addressed, which require investment, what third parties handle sensitive information, and whether critical recovery processes have been tested.
Employees understand that security is part of service delivery. They know how to recognize common risks, use approved tools, protect client information, report lost devices, and escalate potential incidents without fear of being blamed for asking a question.
Technical controls are monitored and maintained. The organization does not assume that a tool remains effective simply because it was deployed. Accounts, endpoint health, patching, backups, alerts, vendor access, and configuration changes receive routine attention.
Real service behavior reinforces this approach. Kawal, a professional-services client, noted, "GDS followed up the next day to make sure the door sensor issue is resolved. That kind of attention shows real customer service." Verification and follow-through are valuable security habits because a closed ticket is not always the same as a resolved business risk.
For commercial real estate teams, maturity also means considering operational effects. An alert involving badge readers, cameras, HVAC-related controllers, or tenant systems may require different containment and communication decisions than a standard office workstation issue. The Built, Wired & Secured article on cybersecurity managed services with building context explains why that distinction matters.
Takeaway: A mature WISP is visible in disciplined daily decisions, accountable follow-through, and tested recovery readiness.
What WISP mistakes should businesses avoid?
The most common mistake is treating the WISP as a document-purchasing exercise. A polished template can provide structure, but it cannot identify the organization's actual data flows, decision-makers, vendors, physical systems, or unaddressed technical gaps.
Another mistake is assigning responsibility without authority. A security coordinator needs support from leadership, access to the right information, and a clear escalation path. Security cannot be effective when the person responsible cannot obtain decisions, resources, or cooperation.
Some businesses focus only on technical tools. Firewalls, endpoint software, and cloud platforms are important, but they cannot replace access reviews, workforce training, vendor oversight, physical safeguards, incident procedures, and informed leadership decisions.
Others overpromise in writing. A policy saying that every system is monitored, every backup is tested, or every vendor is assessed becomes a liability if the organization cannot show that the process occurs. Accuracy is stronger than aspiration.
Ignoring changes is equally risky. A WISP can become outdated when an organization adopts a new cloud application, opens an office, changes a payment process, adds remote workers, acquires a business, or connects operational technology to its network.
Finally, businesses should not assume an incident response plan is enough on its own. Incident response explains what to do after a problem is detected; a WISP provides the broader governance and preventive safeguards that help reduce the likelihood and impact of that problem.
Takeaway: A WISP fails when it is generic, unsupported, inaccurate, or disconnected from day-to-day operations.
How does GDS Technology help businesses build and operate a WISP?
GDS Technology serves small and mid-sized businesses in Atlanta, Norcross, the Greater Atlanta area, Indianapolis, and remote environments across the United States. As a Technology Partner, GDS helps organizations connect security planning to the systems, people, facilities, and business outcomes that depend on it.
That work can include risk-focused discovery, managed IT support, cybersecurity services, cloud administration, backup and recovery planning, compliance support, and practical documentation. GDS can help a business move from scattered security practices to accountable processes that staff can follow.
Reliable operations support a WISP because plans must be put into practice. Through managed IT services, GDS can help maintain the technology environment that supports access management, device health, patching, security tools, documentation, and user support.
GDS also supports organizations that need to connect cyber risk with physical infrastructure. Its services include structured cabling and low-voltage work, business video surveillance systems, and commercial real estate technology support. That perspective is valuable when office networks, tenant operations, access systems, and connected building devices affect continuity.
Security planning should include recovery. GDS offers data backup and recovery services and disaster recovery planning to help businesses prepare for system disruption and validate that important information can be restored.
The appropriate scope depends on the organization's environment, compliance needs, locations, and existing safeguards. GDS can help identify what belongs in the plan, what is already operating effectively, and which gaps need practical remediation.
Takeaway: GDS Technology helps businesses turn a WISP from a compliance document into an operating security program built around dependable service and business protection.
Frequently Asked Questions
Is a WISP required for every business?
Not every business is subject to the same explicit WISP requirement, but every business that handles sensitive information benefits from a documented security program. Specific obligations can arise from the FTC Safeguards Rule, HIPAA, PCI DSS, CMMC-related contracts, state laws, client agreements, insurance conditions, and industry expectations.
What is the difference between a WISP and an incident response plan?
A WISP is the broader information security program. It addresses governance, risk assessment, training, access, vendors, technical safeguards, physical safeguards, and ongoing review. An incident response plan is one component of that program, focused on detecting, containing, investigating, communicating about, and recovering from a suspected security incident.
Who should be responsible for a WISP?
Leadership should designate a security coordinator or responsible role with enough authority to collect information, recommend safeguards, track remediation, and escalate decisions. The designated person does not need to perform every technical task, but leadership remains accountable for supporting the program and making risk decisions.
How often should a WISP be reviewed?
A WISP should be reviewed on a defined recurring schedule and whenever meaningful change occurs. Examples include new systems, cloud providers, offices, remote-work arrangements, payment processes, acquisitions, personnel changes, incidents, or findings from testing. The review should confirm that documented practices match the current environment.
Can a WISP be based on a template?
A template can be a useful starting structure, but it is not a completed WISP. The plan must accurately reflect the organization's data, systems, vendors, workforce, physical environment, safeguards, risks, and responsibilities. Generic statements should be replaced with specific procedures and evidence that the business can actually maintain.
Does having cybersecurity software mean we have a WISP?
No. Cybersecurity software can be an important technical safeguard, but a WISP also covers ownership, risk assessment, policies, training, user access, vendors, physical safeguards, incident response, recovery, and review. Software without defined processes and accountable oversight does not create a complete security program.
What information should a risk assessment identify?
A risk assessment should identify sensitive information, important systems, likely threats, vulnerabilities, existing safeguards, potential business impact, and actions needed to reduce risk. It should also document who owns corrective actions and whether leadership accepts any remaining risk. The assessment gives the WISP a factual basis for security decisions.
