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’ve written the good kind.
I wrote the security policies and procedures for a company against two federal standards, the NIST Cybersecurity Structure and NIST 800-53. Now I ghostwrite books for CISOs and security founders. It’s the same job at a different scale. Getting what an expert 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 two details almost nobody bothers with.
Tie the responsibility to the title, the accounts payable supervisor approves the wire transfers, and the policy survives every personnel change.
It makes me a little crazy how much effort goes into documents nobody can use. Somebody spent weeks producing those binders, the auditor walked out satisfied, and six months later an employee facing a real decision can’t find one sentence telling them what to do or whose call it is. I think a policy that can’t answer that question has failed at the only job it had.
Most company policies are useless. Technically correct and completely ignored until an auditor asks where they are.Share on X
The first detail is the one I’d fight hardest for.
Every step in a procedure should name the job title responsible for it. A policy that hands a step to “IT” or “management” is useless, because a department can’t be called into a meeting and asked why the step got skipped. Whoever holds a title can.
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’s obsolete the moment someone changes jobs.
My take
Name a job title on every step, or don’t bother writing the policy. A step assigned to IT or management belongs to nobody, and nobody gets called into the meeting when it’s skipped. Titles survive people quitting and getting promoted. Names don’t. Then list every standard each policy answers to, so people can find it when a real decision lands on their desk. A binder that satisfies the auditor and helps no employee has failed.
What is segregation of duties in a security policy?
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’s 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 can’t print. The printer can’t approve. The document spells out exactly who owns which half, so there’s 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. That’s far rarer and far riskier for them. The control 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 second detail solves a problem most companies don’t know they have, and it’s the one that embarrasses them in front of auditors.
Compliance structures overlap constantly. A single control, like segregation of duties or access logging, might satisfy several structures at once. 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 structures asking for it are different.
Most companies handle this badly. They keep a separate binder for each structure. 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’re all describing the same thing. It’s wasteful, it’s confusing, and it guarantees the four versions will drift apart until they contradict each other.
Then an auditor finds the contradiction, and somebody has to sit in a conference room explaining why the PCI policy and the SOX policy describe the same control two different ways. The person answering for it usually didn’t write either version. They inherited a filing system that guaranteed the mess years before they arrived, and I think that’s an unfair spot to put anyone in.
The documents I wrote did it differently. Each policy listed every structure it answered to. If a procedure fell under PCI, I noted that right there in the document. If it also fell under SOX, I noted that 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 didn’t 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.
Companies that dread their audits have usually built their documentation for the auditor instead of for themselves, and they pay for it every year in overtime, scrambling, and findings they could have seen coming.
It’s easy to dismiss policy writing as bureaucracy. Real work happens at the firewall and the server, the thinking goes, not in a document. That’s exactly backwards.
A security program is only as good as whether people do the things it requires. Tools don’t enforce themselves. Someone has to own the patching, the access reviews, the duty separation. If the policy doesn’t 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.
That one is a costly gap. A company spends real money on a tool, the console lights up in the security office, and no policy assigns anyone to read it. The alerts pile up unread, and after the breach, the logs show the tool saw every step happen. The document is where security stops being a collection of good intentions and becomes a set of assigned, auditable responsibilities. That’s governance. It’s the layer that makes all the technical work happen and keep happening, and it’s the layer most companies treat as an afterthought.
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
Strip away the jargon and a security policy should let any reasonable person know what’s required, who’s responsible for it, and which rules it satisfies, without having to ask anyone.
Name the responsible title for every step, so there’s never a question of whose job it is. List every structure each policy answers to, so the right document is always findable and there’s 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 runs on.
Most companies never get there. They write policies to pass an audit, file them, and forget them, and I’d call that negligence with a compliance stamp on it. When something goes wrong at one of those companies, everyone points at everyone else. The companies that write policies naming names and connecting the dots are the ones where, when something goes wrong, somebody already knew it was their job to prevent it.
Frequently Asked Questions
Two things most companies skip. First, it names who’s responsible for each step by job title, so responsibility survives personnel changes and there’s never a question of whose job it was. Second, it lists every compliance structure each policy answers to, so the right document is findable and there’s only one version to maintain. Without those, a policy is decoration.
Because names change and titles don’t. 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’s how fraud and errors happen. One person by title approves a check, a different person by a different title prints it. The approver can’t print and the printer can’t approve, so committing fraud would require two people to collude. That’s 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. That looks terrible to an auditor. Tagging one policy with every structure it satisfies keeps a single current version and makes audits simple.
No, it’s governance, and it’s what makes the technical work happen. Tools don’t enforce themselves. If the policy doesn’t 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. Anyone can look up the structure. The value in a security book is the judgment about making it real inside an organization. You can see how I work on the cybersecurity ghostwriting page.
