A client hired me to build their NIST documentation, and I took an approach most policy projects skip. The standard deliverable in this world is a policies-and-procedures manual: here is our access-control policy, here is our change-management procedure, signed, dated, shelved. That is what most companies still produce, and it is why most policy manuals are furniture.
I documented roles. For every policy, the manual named which role was responsible for which piece of it, and gave each role its own procedure to follow. Not “checks shall be authorized and issued under appropriate controls” but this person authorizes, following this procedure; this different person issues, following that one. The policy stopped being an abstract statement about the company and became a set of specific obligations attached to specific chairs.
Four to five months of interviews
You cannot write role-level documentation from a template, because the roles are facts about the organization, and the only place those facts live is in people’s heads. So I interviewed everybody I could get my hands on, C-suite down, department by department, for four to five months.
Some people cooperated. Some were unhappy about it and did it anyway. Some simply did not, and here is a truth about governance work that consultants rarely say out loud: there are not many levers against the C-suite. Not many at all. When an executive declines to engage with the documentation of his own controls, the documentation notes what it can and the gap remains, visible to anyone who later asks why.
How role documentation actually gets built
The method was interviews, and the craft was in what the interviews extracted. Policies tell you what should happen; only people can tell you who actually does each piece of it, and their answers disagree in instructive ways. Ask three people who approves a vendor change and you may get three names, which is not a documentation problem, it is a finding. Every one of those disagreements was a place where accountability existed in nobody’s job and everybody’s assumption, and reconciling them, in writing, with names attached to roles and roles attached to procedures, was the actual work of the four to five months.
The drafts then went back to the people they described, which is where the second round of truth arrived. Reading your own responsibilities in print concentrates the mind. Some people discovered obligations they had been carrying informally for years; a few discovered obligations they had assumed belonged to someone else, and the someone else had assumed the reverse. Every such gap closed on paper was an incident that would never need a post-mortem.
The CFO wanted to approve the checks and cut them too. That is not a workflow preference. That is the shape of fraud.Share on X
The CFO and segregation of duties
The revealing moment of the project involved segregation of duties, the control that says the person who authorizes a payment must not be the person who executes it. This is one of the oldest fraud controls in existence, and I assumed everyone in finance carried it in their bones.
The CFO did not know what it was. That surprised me. What came next surprised me more: once he understood it, he opposed it. He wanted to be able to cut checks even though he approved them. He was not confused about the control; he objected to the constraint, which is to say he wanted to retain exactly the combination of powers the control exists to separate.
We wrote the segregation into the roles anyway. And the reason the control earns its inconvenience is not hypothetical to me. At another company I worked with, a colleague uncovered an employee cooking the books, systematic fraud from inside the finance function, and that person went to jail. Fraud happens precisely where one person holds both sides of a transaction. The CFO who wants both sides is not describing a threat, necessarily. But he is describing the shape of one.
Why is role-level documentation bulletproof?
The payoff came in accountability. With policies mapped to roles and roles mapped to procedures, nobody could weasel out with “I didn’t know that was my job.” It is right there in the manual: your role owns this step, here is the procedure, and here is where you bypassed it. Auditors love this structure, incident reviews resolve in minutes instead of meetings, and quietly, the organization gets more honest, because ambiguity was where the dishonesty used to live.
For executives writing about governance, this is the material readers cannot get from the framework documents: what NIST implementation looks like when it meets an actual org chart, an actual reluctant executive, and an actual fraud down the hall. The framework is public. The friction is the book.
For more from this series, see the The Cybersecurity Hub: breaches, audits, and hard-won security lessons from four decades in the trenches.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.