Read the policy before you sign it

A company needs a security program, usually because a big customer sent over a questionnaire or sales promised a SOC 2 report by the end of the year. They bring in a virtual CISO, and a few weeks later a folder shows up with twenty or so polished policies: access control, change management, incident response, vendor management, encryption, acceptable use. Leadership looks them over in one meeting and approves them. A few months later the audit starts, and the auditor tests the company against those documents line by line.

Why it happens

A vCISO works across many clients, and a template library helps them deliver quickly. Leadership often doesn’t feel qualified to argue with a security expert about how often firewall rules should be reviewed, and there’s a deadline. The policies read well and cite the right frameworks, so they get signed. But a template is written for a generic company, and nobody checked it against this one.

Policies with the placeholders still in them

Some companies skip the vCISO and clone a policy set from a free template library. I regularly see these go into an audit with the placeholders still in them: “[Company Name]” in the purpose statement, “<insert date>” under the review history, a policy owner listed as “TBD,” and sometimes the name of whatever company wrote the first template.

An auditor who finds a placeholder learns that no one read the document before approving it. That puts every other policy in the set under suspicion, and it usually means the review and approval records are wrong too, which is a finding of its own.

The auditor tests what you wrote

In a SOC 2 or ISO 27001 audit, the auditor measures you against your own documents and asks you to prove you do what they say. If a policy says something happens, expect a request for evidence that it happened across the whole audit period, usually with samples.

Every “shall” and “must” in a policy is a commitment someone will have to back up. These are some I see in template policies that don’t match the company that signed them:

• Access reviews every quarter, when the company reviews access once a year or only when someone leaves.
• A change advisory board that meets weekly, at a company with six engineers and no such meeting.
• Log monitoring through a SIEM the company has never bought.
• Physical security controls for an office and a server room, at a company that is completely remote and runs everything in the cloud.
• Mobile device management on every device that touches company data, including personal phones used to check email.
• Roles like “Information Security Officer” and “Data Protection Officer” that nobody holds.

Each is a reasonable control for some companies. At this one, the auditor asks for evidence, finds none, and notes it as an exception in the report. Customers read those reports, and an exception gets their attention even when the underlying risk is small.

Templates widen your scope

Templates are written to cover a lot of ground, so they often mention data types, systems, and obligations that don’t apply to you. A policy that covers protecting cardholder data, health information, or a data center you don’t operate invites the auditor to ask about each. You’ll spend audit time explaining why half a policy doesn’t apply. In the worst case, you’ve described an environment bigger and more regulated than yours, and you have to build controls for it or rewrite documents in the middle of an audit period.

Words such as “all” cause the same problem. “All employees and contractors complete security training within 30 days of hire” sounds fine until someone asks about the short-term contractor who started last month and never got an account in the training system.

What to do instead

Keep the vCISO, and keep the templates as a starting point. Treat the policy set as a description of how your company works, and check that it’s correct before anyone signs it.

1. Start with what you actually do. Before anyone writes a policy, get a plain picture of the environment: the systems you run, where your data lives, who has access, how changes get made today, and how big the team is. Write policy to fit that picture, and decide which gaps you want to close and when.
2. Read each policy with the person who runs that process. Sit down with whoever handles access, deployments, or vendor reviews and go through it together. For every requirement, ask them to show you how it happens today. If they can’t, either change how you work or change the policy before you sign it.
3. Write down what’s in scope. Name the systems, locations, and data types the program covers, and take anything outside that out of the policies. If you don’t handle card data, the policies shouldn’t mention it.
4. Keep the specifics where they’re easy to change. The policy should state what the company commits to and who owns it. Exact review frequencies, tools, and step-by-step instructions can live in standards and procedures the process owner can update without another leadership approval. Auditors test those documents too, so they still need to be accurate, but keeping them current takes much less effort.
5. Map every requirement to evidence ahead of the audit. A simple list works: the requirement, who owns it, how often it happens, and what proves it happened. Any line without evidence is one you get to fix before the auditor finds it.
6. Ask your vCISO to walk you through every policy. A good one will be glad you asked and will tailor the documents. If they resist changing the templates to match how you operate, raise it before you renew the engagement.

Where to start

If you have a policy set you’ve never read line by line, start with the one your auditor is most likely to test first. For most companies, that’s access control. Search it for brackets and “TBD” first, then read it with the person who runs access reviews and ask them to show you the evidence for each requirement. Within half an hour, you’ll know whether the rest of the set needs the same treatment.