Introduction
Building a Written Information Security Program (WISP) is the practical work of assembling, approving, and maintaining the policies, procedures, roles, and evidence routines that show how your organization protects systems and data.
Many teams already have fragments: an acceptable use page in Notion, a half-finished incident runbook, a SOC 2 control matrix, and a vendor spreadsheet. A WISP is not a synonym for a single PDF. It is the coordinated program documentation that ties management intent to day-to-day operation. In regulated or buyer-driven markets, customers and counsel often ask whether you "have a WISP" as shorthand for a living security program with owned documents and proof.
In plain language: this guide is an operating playbook for creating and maintaining a WISP that stays aligned to how you actually work. For the short definition of the top-level policy document, see What Is an Information Security Policy?. Related pages include gap analysis, control mapping, exception management, continuous compliance, What Is SOC 2 Evidence?, and audit evidence collection.
What Is a WISP?
A Written Information Security Program is the documented set of policies, standards, procedures, and program elements that describe how an organization manages information security risk for a defined scope.
Depending on industry and counsel, "WISP" may refer to:
- A required program under certain state or sector expectations (exact legal duties vary; confirm with counsel for your jurisdictions)
- A buyer or insurer questionnaire item meaning "show us your security program documents"
- An internal packaging of ISP plus supporting procedures used for SOC 2 readiness or ISO 27001-oriented work
This resource describes common operating practice for SaaS and technology teams. It is not legal advice and does not quote statute text.
A WISP is not:
- A one-time consultant binder that never updates
- A glossary definition alone
- Automatic proof that controls operated across an audit period
- A substitute for ISO 27001 certification or a SOC 2 report
Why a WISP Matters
Without a written program, security expectations live in Slack lore and tribal knowledge. That breaks under hiring growth, customer diligence, and Type 2 periods.
A WISP matters because:
- It gives leaders, engineers, and auditors a shared baseline for access, change, vendors, incidents, and data handling.
- It anchors acknowledgements, training, and exception management to approved rules.
- It reduces contradictory procedures that create control drift.
- It speeds customer security reviews when packets are current and owned.
- It clarifies who approves risk and who remediates findings.
A short, approved, lived program beats a long unread archive.
WISP vs Information Security Policy vs ISMS vs SOC 2 Evidence
Keep packaging language precise.
| Concept | Primary job | Typical artifact | Common confusion |
|---|---|---|---|
| Information security policy (ISP) | Top-level principles, roles, and expectations | Approved policy PDF or controlled doc | Treating the ISP as the entire WISP |
| WISP | Program package: ISP plus supporting procedures/standards and program elements | Policy library + ownership + review cadence | Believing one file equals a living program |
| ISMS (ISO 27001 theme) | Management system for information security with scope, risk, and continual improvement | Scope, risk treatment, SoA-style mapping, internal checks | Claiming certification without an accredited certificate |
| SOC 2 evidence | Dated proof controls operated for chosen criteria over a period (Type 2) | Tickets, exports, reviews, logs | Treating policy text as operating effectiveness |
You can reuse one document set across SOC 2 readiness and ISO-oriented themes through honest control mapping. The assurance products remain different.
What a Practical WISP Usually Contains
Content varies by size and risk. Common building blocks:
- Scope statement. Systems, data types, locations, workforce (employees, contractors), and relevant third parties covered.
- Information security policy. Management-approved principles and roles (ISP glossary).
- Topic policies or standards. Access, acceptable use, encryption expectations at policy level, logging/monitoring, change, vendor risk, data classification and retention themes, backup/recovery, incident reporting.
- Procedures and runbooks. Step-by-step how-to for tools you actually use (Okta, GitHub, cloud consoles, ticketing).
- Roles and RACI. Security owner, control owners, managers, workforce duties, escalation.
- Risk and exception paths. How risks are assessed, how deviations are approved, how findings remediate.
- Training and acknowledgement. Cadence, audiences, completion tracking.
- Vendor and third-party elements. Intake, review depth by risk, ongoing monitoring themes (vendor management for SOC 2).
- Incident and continuity hooks. Links to incident management, business continuity, and disaster recovery plans when in scope.
- Document control. Versions, effective dates, approvers, publication location, review calendar.
Keep the ISP principle-level. Put tool-specific steps in procedures that can change without rewriting leadership policy every sprint.
Step-by-Step: How to Build or Refresh a WISP
1. Clarify drivers and scope
List why you need a WISP now: customer contracts, insurer asks, SOC 2 timeline, ISO interest, or internal governance. Define scope boundaries so you do not write a fictional global program for systems you do not operate.
2. Inventory what already exists
Collect current policies, wiki pages, runbooks, control matrices, and prior auditor requests. Mark each as current, stale, or conflicting.
3. Run a focused gap analysis
Compare current state to the program elements you need for your frameworks and buyers. Prioritize missing access, change, incident, vendor, and policy acknowledgement pieces first. See gap analysis.
4. Draft the ISP and cascade documents
Write or refresh the ISP, then standards and procedures that implement it. Prefer plain language. Name tools you use. Remove copy-paste clauses about products you retired.
5. Assign owners and approval
Every document needs an owner and an approver path. Record approval dates and version IDs. Board or executive approval may be required for the ISP in your governance model.
6. Publish and acknowledge
Publish controlled copies where people can find them. Run hire-time and periodic acknowledgements for the ISP and acceptable use. Track completion exports for the audit period.
7. Connect to operating controls
Map WISP sections to controls and evidence sources: access reviews, change tickets, vendor packets, incident tickets, monitoring health. Without this link, the WISP is theater.
8. Operate exceptions and remediation
When practice cannot meet policy yet, open time-bounded exceptions. When audits find misses, remediate with verification. Related: Exception Management and Audit Findings Remediation.
9. Review on cadence
Schedule at least annual ISP review and event-driven updates after major product, org, or incident changes. Update procedures when tooling changes so documents match reality.
10. Keep evidence continuous
Retain dated approvals, acknowledgements, training completions, and linked control proof year-round (continuous compliance).
Evidence by Program Stage
Illustrative artifacts. Adapt to your stack.
| Stage | Example evidence to retain |
|---|---|
| Scope | Scope memo, asset inventory for in-scope systems |
| Policy approval | Signed or ticketed approval, version, effective date |
| Publication | Location of controlled copy, announcement record |
| Acknowledgements | Completion export with names, dates, policy version |
| Procedures | Current runbooks mapped to policy sections |
| Control linkage | Control matrix / mapping to SOC 2 or ISO-oriented themes |
| Exceptions | Open and closed exception records with owners and end dates |
| Training | Security awareness completion exports when claimed |
| Reviews | Annual review notes, change summaries |
| Operating proof | Access, change, vendor, incident evidence across the period |
Prefer systems of record. See audit evidence and audit evidence collection.
What Good Looks Like
- One owned policy library with clear current versions
- ISP short enough that people read it; procedures detailed enough that engineers can follow them
- Roles named as humans or teams, not only as vague "Security"
- Acknowledgements tied to the version people actually received
- Exception path that is used honestly instead of silent waivers
- Mapping from WISP topics to live controls and evidence sources
- Review calendar that actually fires
- Alignment between written least privilege themes and real IAM
- Customer packet that can be assembled without inventing documents overnight
Common Mistakes
- Buying a generic template and never localizing tool names or owners
- Treating WISP as a one-week project before a sales deadline, then abandoning it
- Stuffing firewall rules into the ISP so every change needs executive rewrite
- Procedures that contradict the ISP with no exception record
- Acknowledgement campaigns for the wrong version
- No document control: five conflicting "current" PDFs in email
- Claiming continuous readiness while policy language drifts from production (control drift)
- Confusing having a WISP folder with having Type 2 operating evidence
- Writing for auditors only and ignoring onboarding usability
- Skipping vendor and contractor coverage when they touch production
SOC 2 and Audit Period Implications
For SOC 2 Type 1, auditors care whether security policies and related processes are suitably designed for the system description and criteria in scope.
For Type 2, auditors evaluate operating effectiveness over the period. Policy existence alone does not prove controls ran. They may sample acknowledgements, whether procedures match observed workflows, how exceptions were handled, and whether access and change controls operated as claimed.
Practical implications:
- Keep the WISP current before and during the period, not only at kickoff.
- Preserve version history so you can show which policy applied when.
- Connect WISP claims to key controls and evidence packs.
- Prepare for questions about prior findings and open exceptions.
Details: SOC 2 Type 1 vs Type 2, SOC 2 Trust Services Criteria Explained, how to prepare for a SOC 2 audit.
This guide describes common practice. It does not quote AICPA standards, does not assert that any specific clause is mandatory for every company, and does not replace your auditor. Auditflo.co does not issue SOC 2 reports or certify compliance.
ISO 27001 and Multi-Framework Reuse
If you also pursue ISO 27001 themes, a WISP-style package often overlaps with ISMS documentation needs: policy, roles, risk handling, control operation, internal checks, and improvement. Reuse evidence through control mapping. Do not claim certification without an accredited certificate. See ISO 27001.
Roles and Ownership Lite
Clarify who does what so the WISP does not become "compliance's problem" the week before fieldwork:
- Executive sponsor: approves ISP direction and funds remediation.
- Security / GRC: maintains document control, mapping, ageing of exceptions, auditor coordination.
- Control owners: keep procedures true to systems they run; produce evidence.
- Engineering / platform: implement access, change, monitoring technical controls.
- People / HR partners: joiner-mover-leaver signals and training logistics.
- Legal / counsel: jurisdiction-specific WISP obligations when applicable (outside this guide's scope).
- Internal audit (when present): tests whether the written program matches reality (internal audit).
Sample 90-Day Build Plan
Hypothetical schedule for a small SaaS team starting from partial documents. Adjust to your risk and auditor timeline.
| Window | Focus | Exit criteria |
|---|---|---|
| Days 1 to 15 | Scope, inventory, gap list, owner assignments | Written scope; ranked gaps; named owners |
| Days 16 to 45 | ISP refresh, priority procedures (access, change, incident, vendor) | Approved ISP; procedures published for top risks |
| Days 46 to 70 | Acknowledgements, control mapping, exception workflow live | Acknowledgement export path; mapped controls; exception intake used |
| Days 71 to 90 | Evidence dry run, fix mismatches, set review calendar | Sample evidence pack for one month; calendar invites for annual review |
Treat this as a planning aid, not a guaranteed path to any report or certificate.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams keep continuous evidence collection and audit-period history so WISP-linked controls stay tied to dated artifacts instead of a last-minute zip file.
With control mapping support and history across common systems such as GitHub, Jira, Okta, AWS, and Google Workspace, you can show how access, change, and related controls operated while your written program stays current.
AuditFlo is framed here as evidence and readiness support for the security program your organization defines. It does not write your WISP for you, does not approve policies, does not issue SOC 2 reports, does not certify ISO 27001, does not guarantee compliance, and does not replace auditors or counsel.
To see the workflow for your stack, request a demo.
Final Thoughts
A WISP succeeds when documents, owners, approvals, acknowledgements, and operating controls tell the same story. Start with scope and an honest inventory, refresh the ISP and cascading procedures, assign humans, publish and acknowledge, map to evidence, run exceptions openly, and review on cadence. Glossary pages define the policy building blocks. This playbook is the operating model for assembling and maintaining the program so customer diligence and SOC 2 fieldwork review a living system rather than reconstructing one.
Is a WISP required for every company?
Not universally. Some jurisdictions, sectors, contracts, or insurers may expect a written program. Many SaaS buyers ask for one during diligence even when no single statute applies. Confirm obligations with counsel for your facts. This page is not legal advice.
Is the information security policy the same as the WISP?
Usually no. The ISP is the top-level policy. A WISP typically packages the ISP with supporting standards, procedures, and program elements. Some organizations label the whole package "WISP."
How often should we update the WISP?
Review the ISP at least annually and after material changes. Update procedures whenever tools or ownership change so documents match operations.
Can one WISP support SOC 2 and ISO 27001?
Often yes for overlapping themes, if you map controls honestly and keep scope clear. You still may need distinct assurance deliverables (SOC 2 report vs ISO certificate).
What evidence do auditors usually want related to the WISP?
Common asks include the current approved policy set, version/approval records, acknowledgement exports, and proof that related controls operated. Exact samples depend on your auditor and scope.
How is this different from the information security policy glossary page?
The glossary page defines the top-level policy. This resource is a build-and-maintain playbook for a full written program: inventory, drafting, ownership, acknowledgements, evidence, SOC 2 period implications, and FAQ.
What if our procedures still lag the tools we use?
Open time-bounded exceptions, prioritize procedure rewrites for high-risk paths (production access and change), and avoid claiming controls you cannot evidence. Silent drift is worse than a governed gap.