Documenting Roles, Not Just Rules: A NIST Project That Got Personal

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’s our access-control policy, here’s our change-management procedure, signed, dated, shelved. That’s what most companies still produce, and it’s why most policy manuals are furniture. I wrote a manual on NIST 800-53 early in my writing career, a big project and nine months of consulting. That standard gets really nitty gritty, all the way down to the lowest level, and it was a pain in the butt.

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 can’t 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 didn’t, and against the C-suite a consultant has very few levers. 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. That was upside down, because the people with the most authority over the controls were the ones most free to skip the conversation about them.

How do you document roles for segregation of duties?

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 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. That mismatch is a finding in its own right, and it’s the most useful thing an interview like that can produce.

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, and that’s 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’d 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.

Why does the CFO matter in segregation of duties?

The revealing moment of the project involved segregation of duties, the control that says the person who authorizes a payment mustn’t be the person who executes it. This is one of the oldest fraud controls in existence, and I assumed everyone in finance knew it instinctively.

The CFO didn’t 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 wasn’t confused about the control; he objected to the constraint, meaning 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 justifies its inconvenience isn’t 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 where one person holds both sides of a transaction. The CFO who wants both sides isn’t describing a threat, necessarily. But he’s describing the shape of one.

Any board that lets its CFO both approve and cut checks is betting the company on one person’s character. I’d never advise a client to make that bet, however much they trust the person in the chair, because the control protects a CFO who’s doing nothing wrong too.

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’s right there in the manual: your role owns this step, here’s the procedure, and here’s where you bypassed it. Auditors love this structure, incident reviews resolve in minutes instead of meetings, and the organization gets more honest, because ambiguity was where the dishonesty used to hide.

For executives writing about governance, this is the material readers can’t get from the structure 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 frameworks are public and everyone quotes them. I’d push any executive who has lived through a project like this to write about the resistance, because leaving it out produces one more governance book that reads like the standard it describes.

For more from this series, see The Cybersecurity Hub: breaches, audits, and hard-won security lessons from more than three decades in the trenches.

Frequently Asked Questions