Somewhere in your organization, there’s a document called “Information Security Policy.” It was probably written by a consultant, or copied from a template, or authored by someone who left three years ago.

Nobody has read it this year. It references technologies you no longer use. It mandates procedures nobody follows. And it will become critically important approximately thirty seconds before your next audit.

Most security policies share this fate. They’re created for compliance, filed for auditors, and ignored by everyone who does actual work. This is a waste of everyone’s time.

Policies should change behavior. If they don’t, they’re liability documents—evidence that you knew what you should do and chose not to do it.

Here’s how to build documentation that actually works.

The Hierarchy: Policies, Standards, Procedures, Guidelines

Before writing anything, understand what you’re writing.

Policies are high-level statements of intent. They answer “what must we do?” and “why?” They rarely get updated, apply organization-wide, and require executive approval.

Example: “All user accounts must be protected with multi-factor authentication.”

Standards define the specific requirements to meet a policy. They answer “what specifically?” and are more technical than policies.

Example: “MFA must use hardware tokens or authenticator apps. SMS-based MFA is not permitted for privileged accounts.”

Procedures are step-by-step instructions for implementing standards. They answer “how exactly?” and are detailed enough that someone unfamiliar with a task can complete it.

Example: “To enable MFA for a new user: 1. Navigate to Admin Console → Users → Select User → Security → Enroll MFA…”

Guidelines are recommendations rather than requirements. They answer “what should we do?” for situations where flexibility is appropriate.

Example: “Consider using hardware security keys for executives and administrators who are frequent phishing targets.”

Most organizations confuse these levels. They write policies with procedure-level detail, creating documents that are both too specific (they break when tools change) and too vague (they don’t tell people what to actually do).

Keep policies short and stable. Put the detail in standards and procedures, which can update without executive review.

What Policies Do You Actually Need?

Every framework has a list. ISO 27001 wants 114 controls documented. NIST CSF maps to hundreds of subcategories. Attempting to write a policy for each control results in thousands of pages nobody reads.

Here’s a minimal viable policy set for a mid-sized organization:

1. Information Security Policy

The umbrella document. Establishes that security is important, leadership is committed, everyone is responsible. Defines scope, roles, and how other policies relate.

This is usually required for compliance. Make it short and stable. Executive approval means you don’t want to update it often.

2. Acceptable Use Policy

What employees can and cannot do with company systems. Covers personal use, prohibited activities, monitoring disclosure, and consequences for violation.

This gets read—usually during onboarding. Keep it in plain language. Employees need to understand it without legal interpretation.

3. Access Control Policy

How access is granted, reviewed, and revoked. Covers the principle of least privilege, privileged access management, access reviews, and separation of duties.

The corresponding procedures matter here. A policy that says “access requires manager approval” means nothing if there’s no process for actually getting or reviewing approval.

4. Data Classification and Handling Policy

What categories of data exist, how each must be protected, and who can access each category. Without classification, everything gets treated the same—either over-protected (blocking business) or under-protected (creating exposure).

Keep classifications simple. Three or four levels maximum. “Public, Internal, Confidential, Restricted” works for most organizations.

5. Incident Response Policy

What constitutes a security incident, how to report one, who responds, and what happens during and after an incident.

This is different from an incident response plan (which is a detailed procedure). The policy establishes authority and responsibility. The plan tells you what to actually do.

6. Vendor Security Policy

How third parties are assessed, what security requirements apply, and how vendor relationships are monitored. As supply chain risk grows, this policy increasingly matters.

Tier your requirements by vendor risk. A marketing analytics tool doesn’t need the same scrutiny as your cloud infrastructure provider.

7. Change Management Policy

How changes to systems are proposed, approved, tested, and implemented. Prevents both security incidents (untested changes breaking things) and audit findings (unauthorized modifications).

This overlaps with IT operations. Security’s role is ensuring security considerations are part of the change process, not creating a separate process.

Additional policies depend on your industry and risks. Healthcare needs HIPAA-specific policies. Financial services needs data retention policies. Everyone doing business in Europe needs GDPR documentation. Start with the core set, then add based on your specific requirements.

Writing Policies That Get Followed

Keep them short. A ten-page policy won’t be read. A one-page policy might be. Say what’s required, why it matters, and where to find more detail. Stop there.

Use plain language. “Employees shall ensure credential confidentiality” means nothing to most people. “Don’t share your password” is clear. Write for your least technical employee.

Be specific about requirements. “Strong passwords are required” is unenforceable. “Passwords must be at least 12 characters” is testable. If it can’t be measured, it can’t be enforced.

Distinguish “must” from “should.” Must means required—violation has consequences. Should means recommended—good practice but flexible. Mixing these creates confusion about what’s actually mandatory.

Include the “why.” Compliance policies are followed reluctantly. Policies that explain their purpose are followed because people understand the reasoning. “MFA is required because password compromise is the leading cause of breaches” is more persuasive than “MFA is required per policy X.”

Make exceptions explicit. Every rule has edge cases. Document how exceptions work. Who can approve them? How are they documented? When do they expire? Undocumented exceptions become permanent gaps.

Review and sunset regularly. Policies that reference deprecated systems undermine credibility. Annual review with version control prevents drift. If a policy hasn’t been reviewed in two years, it probably doesn’t reflect reality.

The Implementation Gap

Writing policies is easy. Getting people to follow them is hard.

Communicate, don’t just publish. A policy in SharePoint is invisible. When policies change, actively communicate the change through channels people actually use. Town halls, team meetings, Slack announcements—wherever your organization’s attention actually is.

Train on procedures, not policies. Don’t train employees on policy text. Train them on what to do. “Here’s how to report a suspected phishing email” is actionable. “Per Policy 4.7, users must report security incidents” is not.

Make compliance easy. If following the policy is harder than violating it, the policy loses. Want people to use MFA? Make enrollment painless. Want people to report incidents? Make reporting simple and consequence-free. Remove friction from the secure path.

Audit and enforce. Policies without consequences are suggestions. If violations are never detected or addressed, rational employees learn that policies are optional. This doesn’t mean punitive culture—it means consistent enforcement that makes policy compliance expected rather than exceptional.

Measure compliance. If you can’t tell whether people are following the policy, you can’t improve it. For technical controls, automate measurement (what percentage of accounts have MFA enabled?). For behavioral controls, spot-check and survey.

Procedure Writing That Works

Procedures are where policies meet reality. They need to be detailed enough for someone unfamiliar to complete the task correctly.

Use numbered steps. Unordered paragraphs require interpretation. Numbered steps can be followed mechanically. “1. Log into the admin console. 2. Navigate to Users. 3. Select the user account…” is easier to follow than a paragraph describing the same thing.

Include screenshots. For technical procedures, visuals prevent mistakes. They also reveal when interfaces have changed—if your screenshots don’t match reality, your procedure is out of date.

Name specific tools and locations. “Update the relevant system” is useless. “Log into Okta at [URL], navigate to Directory → People” is actionable. Specificity enables execution.

Document the expected result. “If successful, you will see a confirmation message: ‘MFA enrollment complete.’” This lets the person know they’ve done it right—or that something has gone wrong.

Assign ownership. Every procedure needs an owner who keeps it current. When the tool changes, someone is responsible for updating the documentation. Without ownership, procedures drift.

Store them accessibly. Procedures buried in obscure SharePoint folders won’t be used. Put them where people can find them—in the tools themselves if possible (contextual help), in a well-organized knowledge base if not.

A Word on Policy Automation

The next evolution is policy-as-code: security requirements expressed in machine-readable formats that can be automatically enforced and tested.

Instead of a document saying “all S3 buckets must be encrypted,” you have a rule that checks bucket encryption and blocks or alerts on violations. The policy is enforced by system, not by human diligence.

This isn’t possible for everything—behavioral policies require humans. But for technical controls, automation beats documentation. You can’t forget to follow a rule that’s enforced by code.

If you’re early in policy development, think about which requirements can eventually be automated. Structure your standards with automation in mind. The document is the bridge to eventual enforcement, not the permanent answer.

Getting Started

If you’re staring at a blank page—or a folder full of stale policies—here’s a practical sequence:

Week 1-2: Audit existing documentation. What do you have? When was it last updated? Is any of it followed?

Week 3-4: Define your core policy set based on compliance requirements and actual risks. Don’t boil the ocean—start with the minimum necessary.

Week 5-8: Write or update policies, keeping them short and focused on requirements. Develop procedures for the most critical activities.

Week 9-12: Communicate and train. Don’t just publish—actively ensure people know what changed and what’s expected.

Ongoing: Establish review cadence. Set calendar reminders for annual policy review. Assign procedure owners. Build the habit of keeping documentation current.

The goal isn’t perfect documentation—it’s documentation that improves security. A simple policy that changes behavior is worth more than a comprehensive framework that nobody reads.