Security Policies: Why Most Companies Have Them and Almost None Follow Them

A 70-person company lands its first enterprise customer. The customer's security questionnaire asks for the information security policy, the acceptable use policy, the incident response plan, and the access control policy. Someone in operations finds a folder of templates downloaded two years ago, fills in the company name, and sends them over. The deal moves forward. Nobody in the company has read those documents since.

This is the normal state of security policy at growth-stage companies. The documents exist because a customer, an insurer, or an auditor asked for them. The behavior they describe does not exist, because nobody was ever put in charge of making it real.

Why a Policy on Paper Protects Nothing

A security policy is a statement of intent. It says how the organization expects people to handle passwords, devices, customer data, and vendor access. It does not enforce anything. Enforcement comes from configuration, habit, and accountability, and a folder of PDFs supplies none of the three.

The gap matters because the risk sits in ordinary behavior. Verizon's 2025 Data Breach Investigations Report found that roughly 60% of breaches involved a human element, meaning error, manipulation, or misuse. The 2026 edition puts the figure at 62%. Those are not exotic attacks against hardened systems. They are phishing clicks, shared credentials, misdirected files, and unmanaged devices, which are exactly the behaviors a policy is supposed to govern.

Small and mid-sized organizations carry the heaviest load. The same 2025 report found that ransomware appeared in 88% of breaches involving small and medium-sized businesses, compared with 39% at large enterprises. A company with 50 to 200 employees rarely has a dedicated security team to catch the drift between what the policy says and what people do.

IBM's 2025 Cost of a Data Breach Report puts the global average cost of a breach at $4.44 million. A company at the low end of the mid-market will see a smaller absolute number, but the proportion is what hurts. A $2 million incident at a $15 million company is more than 13% of annual revenue, with no security team on staff to absorb it.

Where Employees Actually Stand

Employees do not ignore policies out of malice. A Gartner survey of 1,310 employees in mid-2022 found that 69% had bypassed their organization's cybersecurity guidance in the previous 12 months, and 74% said they would be willing to bypass it to achieve a business objective. Gartner's read of the data is that most intentional violations come from a perception that following the rules gets in the way of getting work done.

That finding reframes the problem. If the policy says every file must be shared through the approved platform, and the approved platform takes six clicks while email takes one, the policy loses. If it requires manager approval before installing software, and approval takes four days, people install software. The policy was written for an ideal workday nobody has.

Five Ways Policies Fail in Practice

1. The policy was borrowed, not built. Templates are a fair starting point. A policy that describes a security operations center, a quarterly penetration test, and a full-time compliance officer, at a company with none of those, describes a different organization. Employees notice, and so do auditors.

2. Nobody owns it. A policy with no named owner has no one to update it, answer questions about it, or notice when reality has drifted away from it. Ownership is usually the missing piece. If your company has no CISO, deciding who holds that role in practice is the first policy decision, not the last.

3. It contradicts the tools. The policy says multi-factor authentication is required everywhere, but three legacy systems do not support it, and there is an exception nobody wrote down. Every undocumented exception teaches the organization that the policy is optional.

4. Nobody has been trained on it in plain language. A 14-page document acknowledged with a checkbox during onboarding is not training. People remember the two or three rules that touch their daily work, and only if someone explained why those rules exist.

5. It has no evidence trail. When an insurer or auditor asks whether the policy is followed, the honest answer is often "we think so." Without logs, acknowledgment records, and review dates, a policy is an assertion.

A Five-Step Framework for Policies That Get Followed

This is the framework Elevaire uses when a client's policies exist but the behavior does not. It assumes a company of 25 to 200 employees and no dedicated security staff. It works whether the policies were written by hand, adapted from templates, or produced for a past audit.

1. Cut the set down to what you can enforce. Start with the policies that map to real risk: information security, acceptable use, access control, incident response, and vendor management. Five documents people follow beat twenty they do not. Anything you cannot currently enforce or evidence should be rewritten to match reality or removed until you can.
2. Name one owner per policy. The owner is an accountable individual, not a committee. At many companies the owner is the COO, the head of finance, or the internal IT manager, with a fractional CIO or IT leader advising. The owner approves changes, fields exceptions, and signs the annual review.
3. Write a one-page summary for every policy. The full text stays for auditors and lawyers. Employees get a single page in plain language: what the rule is, why it exists, what to do instead when it is inconvenient, and who to ask. If a summary needs more than a page, the policy is doing too much.
4. Attach every rule to a control. A rule that says laptops must be encrypted should be backed by a device management setting that checks encryption and reports failures. A rule that says access is removed at termination should be backed by an offboarding checklist with a named person and a deadline. If a rule has no control behind it, decide whether to build the control or drop the rule.
5. Set a review cadence and keep the evidence. Review each policy at least annually and after any major change in tools, structure, or customer commitments. Record who reviewed it, when, and what changed. Keep employee acknowledgments with dates. This is the evidence trail that makes a policy credible.

What Auditors, Insurers, and Customers Look For

Formal frameworks treat policy as a starting point, not a finish line. The NIST Cybersecurity Framework 2.0 places policy under its Govern function, and the language is specific: a cybersecurity policy should be established, communicated, and enforced, and reviewed and updated as circumstances change. Establishing it is one third of the job.

SOC 2 and ISO 27001 assessments apply the same logic. Auditors generally expect policies to be approved, reviewed at least annually, and acknowledged by the people they cover, and they test whether the organization actually operates the way its documents say. A policy that describes controls that are not running is a finding, not a pass.

Cyber insurers have moved the same direction. Applications now ask about specific controls such as multi-factor authentication, backup testing, and endpoint protection, and a claim can be contested when the application overstated what was in place. A policy that promises a control the company does not run creates its own legal exposure.

Enterprise customers add a fourth audience. Vendor questionnaires increasingly ask for evidence rather than documents, such as screenshots of configurations, sample access reviews, and training records. Companies that built policies to answer questionnaires find that the next questionnaire asks for proof.

The Cost of the Gap

Consider a 90-person professional services firm with a written acceptable use policy that prohibits storing client files on personal cloud accounts. Nothing technical stops it. An employee shares a project folder through a personal account to work from home, the account is compromised, and client data is exposed. The firm now faces client notification, possible contractual penalties, and a hard conversation about why a written rule was never backed by a control.

The direct costs are visible: forensics, legal review, notification, and lost billable time. The larger cost is trust. The client asks for the policy, then asks whether it was followed. The honest answer damages the relationship more than the incident did.

Compare that with a firm that has fewer policies but operates them. The policy is one page, a sharing control blocks the personal account, and the annual review is on file. The same employee hits a block, asks who to talk to, and gets an approved way to work remotely. Nothing is exposed and no one calls a lawyer.

Where Fractional IT Leadership Fits

Most companies in this range do not need a full-time security hire to fix this. They need someone who owns the connection between policy, tools, and behavior. That is a technology leadership job: deciding which risks matter, which controls are worth their cost, and how to phrase a rule so people follow it.

Elevaire's fractional IT leadership work in Compliance and Security typically starts with a policy-to-reality review. We compare what the documents say with what the environment enforces, list the gaps, and rank them by risk and cost to close. Your managed service provider keeps handling day-to-day operations, patching, and monitoring. We make sure the policies it works under match the controls it is running, and that someone inside your company owns them.

Frequently Asked Questions

How many security policies does a 50-person company actually need?

Most need five to eight: information security, acceptable use, access control, incident response, vendor management, and often data retention and remote work. If you pursue SOC 2 or ISO 27001 you will add several more. Start with the minimum you can enforce and expand as controls mature.

Are downloaded policy templates a bad idea?

No, they save time. The problem starts when they are adopted without editing. Remove any control your company does not run, add the ones it does, and have the named owner read the result. A tailored template is a solid policy. An untouched one is a liability.

How often should security policies be reviewed?

At least once a year, and again after major changes such as a new core system, a merger, a new regulatory obligation, or a significant incident. Record each review with a date and a name, because auditors and insurers ask for that evidence.

How much does it cost to fix policies that nobody follows?

For a company of 25 to 200 employees, a policy-to-reality review is typically a matter of weeks of part-time leadership time, not a new headcount. Closing the gaps depends on what the review finds. Many fixes are configuration changes in tools you already license, such as device management, identity, and email settings, so the spend is often lower than expected.

How does this work alongside our existing MSP or IT team?

Your MSP or internal team keeps running day-to-day operations, and Elevaire works with them, not around them. We set the policy direction, translate it into requirements for the team, and check that the controls are actually in place. Nobody is replaced, and the people who manage your systems get clearer instructions.

How do we get started?

Pick one policy, usually access control or acceptable use, and answer three questions: who owns it, what tool enforces it, and where is the evidence. If you cannot answer all three, that policy is a good first project. Repeat across the rest of the set.