Most advice about information security policies is written for big companies. But what about the vast middle – those companies that have grown beyond their "move fast and break things" phase but aren't Fortune 500 behemoths?

They're in an interesting position: big enough to need formal security policies but most are too lean to have dedicated security teams implementing them.

And when founders or executives at these companies realize they need security policies, they typically grab some templates and try to wing it, which usually ends as you’d expect.

The template approach usually results in policies that may look good on paper but don't match reality. And then they gather dust because no one knows how to actually implement them. And it opens them up for liability when they’re facing a judge after a data breach who asks why they didn’t follow what their security policy said.

The Security Policy Trap

The fundamental problem is that most people think of security policies as documents to be written rather than practices to be implemented.

This is backwards.

A security policy isn't like a terms of service agreement that you write once and forget about. It's more like a constitution – a living document that shapes how your organization operates in reality.

Here's what usually happens: Someone (maybe a potential client or your board) asks how you protect their data or says you need formal security policies. Or the IRS says you need written Information Security Policy (often referred to as a WISP), or you need a Systems Security Plan (SSP).

You find some templates online or ChatGPT one, change the company name, and congratulate yourself on checking that box.

Six months later, you discover that half your employees are sharing passwords through Slack because your password policy was impossible to follow in practice. Or more likely, no one knew you had the policy in the first place.

Start with Reality

The right approach is to start with your actual security needs and work backward to the policy, not the other way around. This seems obvious, but it's surprising how many companies do the opposite.

First, understand what's driving your need for security policies. Are you in defense manufacturing dealing with CMMC? Handling financial data under the FTC Safeguards Rule? In healthcare, dealing with HIPAA? Handling credit card data under PCI DSS? Or are you just trying to implement basic security hygiene? Different drivers require different approaches.

The information security policy templates from CIS or SANS are excellent starting points, but they're just that – starting points. The real work is in customization and implementation.

The Implementation Framework

Here's a practical framework we've seen work.‍

1. Start with your data and assets

Instead of beginning with policy templates, start by mapping out what you're actually trying to protect. What sensitive data do you handle? What systems are critical to your operations? Where are your crown jewels?

This inventory process can be tedious but it is crucial. And 80% documentation may be good enough! But you can't protect what you don't know about. More importantly, this process will start to reveal the gaps between what you think you're doing and what's actually happening.

2. Understand your real risks

Most template risk assessments focus on theoretical risks and don’t care that saying we patch 100% of all vulnerabilities is an impossibility.

Instead, think about what could actually go wrong in your specific context. If you're a SaaS company, your biggest risk might be a developer accidentally pushing credentials to a public GitHub repo. If you're an accounting firm, it might be an email account compromise giving access to your client’s tax records. If you're in healthcare, it might be employees accessing patient records they shouldn't.

3. Write policies that reflect reality

Now you can customize those templates based on your actual needs. The key is to make them specific enough to be meaningful but flexible enough to be practical.

Good policies aren’t so different from the rules of a simple board game. You collect $200 when passing go." Everyone needs to understand them easily, they should make the game work better (not just exist for their own sake), and they need to be ones players will actually follow rather than house-ruling around them.

If your policy mandates complex password requirements but doesn't mention password managers, you're probably doing it wrong. If it says you securely destroy sensitive data, but employees are selling their old laptops on eBay, you’re probably doing it wrong.

4. Implementation is everything

This is where most companies fail. They have great policies that no one follows. The key is making security practices as frictionless as possible while maintaining appropriate controls. Software teams have the concept of paved roads; economists have their nudges, and habits are built by making things easy. Some practical tips -

• Break down the implementation into small, manageable chunks
• Start with the highest-impact, lowest-effort changes
• Make it easy for employees to do the right thing (and hard to do the wrong thing)
• Build security reviews into existing processes rather than creating new ones
• Use automation when possible
• Get buy-in from leadership and management

And policies should be reviewed by your legal team or advisor since they impact business liability. They should be adopted and supported by leadership. Employees should understand what these policies are and what their expectations are.

If people aren’t aware of the policies, incapable of following them, or unmotivated to comply, outcomes start to break down.

The Review Cycle

Security policies aren't fire-and-forget. They need regular review and updates. But this doesn't necessarily mean scheduling meaningless quarterly meetings where everyone nods along as someone reads through policy documents.

Instead, treat policy reviews like a business review or code review or post-mortem. What's working? What's being ignored? What needs to be updated based on new threats or changes in the business? Do we need to assess our controls and assumptions?

And keep the procedures and reference documents regularly updated rather than waiting for a calendar reminder. New software, vendors, data, inventory, controls, etc - keep track of them as changes occur.

The Human Element

The most overlooked aspect of security policies is the human element. Your employees need to understand not just what the policies are, but why they matter. This doesn't mean boring security awareness training – it means automating away as much as possible and helping them understand how their daily work can impact the security of the business and its data.

When explaining policies to employees, focus on the why, not just the what. Don't just tell them to use unique passwords – explain how password managers make their lives easier while making it harder for attackers.

Explain that while multi-factor authentication adds an occasional extra step to logins, it protects against stolen and re-used passwords.

Explain what happens if they download and run an untrusted program by showing them what ransomware looks like and how it affects a computer.

Demo what a targeted phishing attack looks like with man-in-the-middle software that can steal multi-factor authentication tokens.

Show them. Tell stories. Make it memorable.

Common Failure Modes

We've seen several ways this process typically fails.

1. The "Perfect Policy" Problem. Don’t spend months trying to write the perfect policy. Start with something good enough and iterate.
2. The Compliance Checkbox. Don’t treat policies as a compliance exercise. Use them as a practical security framework.
3. The Fire-and-Forget Mistake: Don’t review create a policy then set it on a shelf forever and ever collecting dust. Keep policies alive and updated as your organization and threats evolve.
4. The All-or-Nothing Approach: Don’t try to implement everything at once. Instead, take an incremental approach. Walk before you run.

Making It Work

The key to successful security policies is treating them as a framework for actual security practices rather than just documents to satisfy auditors. Start with reality, keep it practical, and focus on implementation rather than documentation (though the auditors will still want that documentation).

If you want to understand the difference between policies, procedures, and playbooks, check out our simple guide here - Policies, Procedures, and Playbooks.

‍