Learning how to document a security control takes about twenty minutes per control, and the finished document fits on one page. You are writing down five things: what the control is, who operates it, how often it runs, what output it produces, and where the record of it being done is kept. Anything beyond those five fields is usually a procedure, a policy statement or a tool manual wearing a control document’s clothes.
Before going further: this article is about writing, not about obligations. Nothing here says whether any control document satisfies anything, and nothing here tells you which controls you need. Which frameworks, standards and obligations apply to an organization varies by organization, by industry and by jurisdiction, and working that out belongs with a qualified professional who knows your situation. What follows is the documentation mechanics, which are the same regardless of what somebody is asking you about.
What a control document actually is
A control document is a short written description of one recurring piece of work and the trail it leaves behind. It is not the work itself, and it is not proof the work happened. It is the description that lets somebody else understand the work, pick it up, or go and look at the records.
The distinction worth holding onto is between the description and the record. A control document says “access is reviewed quarterly by the operations lead, who signs the review sheet.” The record is the signed review sheet from last quarter. A reader who only has the first will reasonably ask for the second.
One control, one page, one owner. Bundling three controls into one document is the most common reason a control set becomes unreadable, because it makes the frequencies and owners impossible to separate later.
How to document a security control: the five fields
Write them in this order every time.
- What the control is. One or two sentences in plain language, describing the activity rather than the tool. “Administrative account access is reviewed and either confirmed or removed.” Not “we use the console’s review feature.” The tool changes; the control usually does not.
- Who operates it. A named role, and behind that a named person. Write “Operations lead (currently J. Doe)” so the document survives the person leaving. Add a second name as backup where the control cannot wait for one person’s return.
- How often it runs. Pick a frequency you will actually hold to and state it plainly: daily, weekly, monthly, quarterly, annually, or on a trigger. A trigger-based control needs the trigger written out. “On notification that a person has left the organization” is a frequency; “as needed” is not.
- What output it produces. The thing that exists afterward because the work happened. A signed sheet, an exported list, a dated note, an approval message, a completed form. If a control produces no output, it produces no record, and a control with no record is indistinguishable from a control nobody runs.
- Where the record is kept. The folder, the file naming pattern, and how long records are retained. Write the actual location, not “in our systems.”
Add two optional fields when they apply: what happens when the control cannot be run on time, and what the control depends on. Both save a conversation later.
The shape on the page
Keep every control document identical so a reader can scan ten of them quickly.
| What you write | |
|---|---|
| Control name | Short, specific, no tool names |
| Description | One or two sentences on the activity |
| Owner | Role, then current person, then backup |
| Frequency | A date rule or a written trigger |
| Output | The artifact the work leaves behind |
| Record location | Folder path and naming pattern |
| Retention | How long records are kept |
| Last updated | Date and who changed it |
The last row is the one people skip and the one that matters most a year on. A control document with no update date reads as a guess about how things used to work.
Writing from what happens, not from what you intend
Interview whoever does the work and write down what they actually do. Then, separately, mark the places where current practice and intended practice differ. Those marked places are your own improvement list, and keeping them visibly separate from the description is what keeps the description honest.
The temptation is to document the better version. Resist it. A document describing a quarterly review nobody has ever run has turned a gap into a written contradiction, which is worse than the gap by itself. The right entry is the real frequency with a dated note about the intended change.
Watch the verbs. “Is reviewed,” “is approved,” “is exported” describe a control. “Should be reviewed,” “is important to review,” “we aim to review” describe an ambition, and a reader notices the difference immediately.
Use the same vocabulary across the whole set. If one document says “approved” and the next says “signed off” for the same act, you will spend time later proving they mean the same thing.
Knowing how to document a security control is not the same as operating one
The document describes; the records demonstrate. Writing the page does not make the work happen, does not make it happen correctly, and does not establish anything about your organization to anyone else. Documentation is not a credential and it is not an outcome.
This matters practically, not just philosophically. The usual failure is a tidy control set with nothing behind it: twelve well-written pages, zero dated records. The second most common failure is the reverse, a drawer full of records nobody can interpret because no document says what the records were supposed to show.
So pair them. Every control document names an output; every output lands in a named place as the work happens. If writing the “where the record is kept” field is hard because no record exists, you have found the real work, and it is the record rather than the page.
Keeping the control set current
Give every control document a review date, the same as your written policies, and stagger the dates so you are never re-reading the whole set at once. Reviewing a control document means three checks: does the described activity still happen, does it still happen at the stated frequency, and does the record still land where the document says.
Four events should trigger an off-cycle update, because each one makes at least one control document inaccurate the day it happens:
- The person named as owner changes role or leaves.
- The tool or platform the work happens in is replaced.
- The frequency slips and the new frequency is the real one.
- The place records are stored moves.
Keep the superseded version of the page rather than overwriting it. Over time the sequence of versions is the clearest available picture of how the work actually developed, and it costs nothing but a folder.
One more habit worth building: when somebody asks you a question about a control and you answer it from memory, add the answer to the page. Questions are free research into what your documentation is missing, and the second time it gets asked you want the page to already say it.
A set of thirty one-page control documents, each honest, each dated, each pointing at a real record location, is a modest week of writing and it removes a category of scramble from your year. To see which control documents your organization is missing and in what order to write them, work through the Trust Center Document Checklist page on this site.