TL;DR
I wrote the security policies and procedures for a company against NIST CSF and NIST 800-53, and these days I ghostwrite books for the security leaders who live this work. Most policy documents fail for two reasons: nobody knows who owns each step, and nobody knows which rules apply. Good policy fixes both. It names who is responsible by job title, and it lists every framework each policy answers to. A policy nobody owns is a policy nobody follows. A policy you cannot find when you need it might as well not exist.
Most company policy documents are useless. Not wrong, just useless. They sit in a binder or a shared drive, technically correct and completely ignored, until an auditor asks for them and everyone scrambles to remember where they live.
I know this because I have written the good kind. I wrote the security policies and procedures for a company against two federal standards, the NIST Cybersecurity Framework and NIST 800-53. Now I ghostwrite books for CISOs and security founders, which is the same job at a different scale: getting what an expert actually knows out of their head and onto the page in a form other people can use. And the thing that made those policy documents work was not the policies themselves. It was two details almost nobody bothers with.
Most company policies aren’t wrong. They’re just useless. Technically correct and completely ignored until an auditor asks where they are.Share on X
A policy that names no one gets followed by no one
Here is the first thing that separates a real policy from a decoration. A good procedure says who is responsible for each step, by job title, not by name and not by vague reference to a department.
Why title and not name? Because names change. People quit, get promoted, move teams. If your policy says Jane approves the wire transfers and Jane leaves, the policy is instantly broken and nobody notices until something goes wrong. Tie the responsibility to the title, the accounts payable supervisor approves the wire transfers, and the policy survives every personnel change. Whoever holds that title inherits the responsibility automatically. This is a small detail that makes the difference between a document that stays true for years and one that is obsolete the moment someone changes jobs.
Take segregation of duties, one of the oldest controls in security and finance. The principle is simple. No single person should control a whole sensitive process from end to end, because that is how fraud and mistakes happen. So you split the steps across different people.
In a real policy, that looks like this. One person, by title, is responsible for approving a check. A different person, by a different title, is responsible for printing or generating it. The approver cannot print. The printer cannot approve. The document spells out exactly who owns which half, so there is never a question and never a gap. The reason is concrete: if one person could both approve and print a check, they could write themselves a check and cover it. Splitting the duty means fraud requires two people to collude, which is far rarer and far riskier for them. The control is not bureaucracy. It is a structural defense against one person being able to rob you.
That sounds obvious until you read most company policies, which say something like “appropriate controls will be maintained to ensure segregation of duties.” That sentence means nothing. It assigns nothing to no one. When something goes wrong, everyone points at everyone else, because the policy never said whose job it was.
A policy that says “appropriate controls will be maintained” assigns nothing to no one. When it breaks, everyone points at everyone else.Share on X
Naming the responsible title for every step does something powerful. It makes the policy enforceable. You can audit it. You can train to it. When a step gets skipped, you know exactly whose job it was. The policy stops being a wish and becomes a system. And it connects directly to the daily security grind, because the access reviews and duty separation in the policy are exactly the boring controls I describe in the boring security work that actually keeps you safe. The policy names who owns them. The daily work is doing them.
The same control answers to four different masters
Here is the second thing, and it solves a problem most companies do not even know they have.
Compliance frameworks overlap constantly. A single control, like segregation of duties or access logging, might satisfy PCI for payment data, SOX for financial reporting, NIST for federal standards, and a handful of others all at once. The control is the same. The frameworks asking for it are different.
Most companies handle this badly. They keep a separate binder for each framework. The PCI binder, the SOX binder, the NIST binder. The same control gets written four times, four slightly different ways, by four different people who have no idea they are all describing the same thing. It is wasteful, it is confusing, and it guarantees the four versions will drift apart until they contradict each other. Then an auditor finds the contradiction, and now you are explaining why your PCI policy and your SOX policy describe the same control differently, which looks exactly as bad as it is.
The documents I wrote did it differently. Each policy listed every framework it answered to. If a procedure fell under PCI, that was noted right there in the document. If it also fell under SOX, that was noted too. So anyone reading it knew immediately which requirements that single policy satisfied, and anyone looking for the right policy knew exactly where to find it.
One security control can satisfy PCI, SOX, and NIST at once. Most companies write it three times in three binders and let the versions drift apart.Share on X
That cross-referencing turned a pile of separate compliance silos into one connected system. When an auditor showed up asking about a SOX control, we did not go hunting through a SOX binder hoping it was complete. We went to the policy, saw it was tagged for SOX and PCI both, and knew it was current because there was only one version of it to keep current. This is the same principle behind passing audits without the last-minute scramble, which I cover in what eight PCI audits taught me. When the documentation is built right, the audit is just reading back what is already true.
Why this is really about governance, not paperwork
It is easy to dismiss policy writing as bureaucracy. Real work happens at the firewall and the server, the thinking goes, not in a document. That is exactly backwards.
A security program is only as good as whether people actually do the things it requires. Tools do not enforce themselves. Someone has to own the patching, the access reviews, the duty separation. If the policy does not say who, in plain terms, then the answer is nobody, and the control exists only on paper. This is the same reason the security tools I describe in most security tools are theater fail so often. The tool is bought, the dashboard glows, but no policy assigns anyone to actually use it, so it sits there protecting nothing.
The document is where security stops being a collection of good intentions and becomes a set of assigned, auditable responsibilities. That is governance. It is the layer that makes all the technical work actually happen and keep happening, and it is the layer most companies treat as an afterthought.
This is also why the security leaders I ghostwrite for end up with books worth reading. The value is never the framework itself, which anybody can look up. It is the judgment about how to make a framework real inside an actual organization, with actual people and actual politics. That is the part that only comes from having done it.
Tools don’t enforce themselves. If the policy doesn’t say who owns a control, the answer is nobody, and it exists only on paper.Share on X
What a good policy document actually does
Strip away the jargon and a security policy has one job. It should let any reasonable person know what is required, who is responsible for it, and which rules it satisfies, without having to ask anyone.
Name the responsible title for every step, so there is never a question of whose job it is. List every framework each policy answers to, so the right document is always findable and there is only ever one version to maintain. Do those two things and the policy stops being something you produce for auditors and starts being something the organization actually runs on.
Most companies never get there. They write policies to pass an audit, file them, and forget them. The good ones write policies that name names and connect the dots, and those companies are the ones where, when something goes wrong, somebody already knew it was their job to prevent it.
Frequently Asked Questions
Get the Free Guides
Join the list and get my condensed books, free. No spam, unsubscribe anytime.
By subscribing you agree to receive occasional emails. Unsubscribe anytime.
Two things most companies skip. First, it names who is responsible for each step by job title, so responsibility survives personnel changes and there is never a question of whose job it was. Second, it lists every compliance framework each policy answers to, so the right document is findable and there is only one version to maintain. Without those, a policy is decoration.
Because names change and titles do not. If the policy says Jane approves wire transfers and Jane leaves, the policy is instantly broken and nobody notices. Tie the responsibility to the title, the accounts payable supervisor approves wire transfers, and whoever holds that title inherits the duty automatically. The policy survives every staffing change.
A control where no single person controls a whole sensitive process end to end, because that is how fraud and errors happen. One person by title approves a check, a different person by a different title prints it. The approver cannot print and the printer cannot approve, so committing fraud would require two people to collude, which is far rarer and riskier.
Because the same control often satisfies PCI, SOX, NIST, and others at once. Writing it separately in four binders wastes effort and guarantees the versions drift apart until they contradict each other, which looks terrible to an auditor. Tagging one policy with every framework it satisfies keeps a single current version and makes audits straightforward.
No, it is governance, and it is what makes the technical work actually happen. Tools do not enforce themselves. If the policy does not say who owns the patching, access reviews, and duty separation, the answer is nobody and the control exists only on paper. The document is where security becomes a set of assigned, auditable responsibilities instead of good intentions.
Yes. I wrote enterprise security policies against NIST CSF and NIST 800-53, and I ghostwrite for CISOs and security founders. The value in a security book is never the framework, which anyone can look up, but the judgment about making it real inside an organization. You can see how I work on the cybersecurity ghostwriting page.