A control narrative is a short, plain-language description of one control: what risk it addresses, who operates it, how often it runs, which system it runs in, and what record it leaves behind. An auditor reads it to know what to test. Write it so a new engineer could follow it without asking you.
Why the narrative matters more than the policy
A policy says what the company intends. A narrative says what actually happens on a Tuesday. Auditors compare the two, then sample real records to see whether the narrative is true. If your narrative says "all production changes are peer reviewed" and the sample contains a direct push, the gap is in the narrative or the practice, and either way it becomes a conversation.
That is why engineers, not only compliance staff, should draft them. You know that the review rule is enforced by branch protection, that two repos are exempt, and that hotfixes use a different path. The narrative should say all of that.
The six fields every narrative needs
| Field | Question it answers | Example wording |
|---|---|---|
| Objective | What goes wrong without this? | Unreviewed code reaches production |
| Owner | Who is accountable? | Head of Platform |
| Operator | Who or what performs it? | GitHub branch rules, plus the PR author and reviewer |
| Frequency | When does it run? | On every pull request to main |
| System and scope | Where, and what is covered? | All repositories in the production org, except the docs repo |
| Evidence | What record proves it ran? | PR approval records, retained for the audit period |
If one field is vague, the control is vague. "Periodically" is not a frequency. "The team" is not an owner.
Steps to write one
- Pick one control, not a whole framework section.
- Describe the real process as it runs now. Watch someone do it if you can.
- Name the enforcement mechanism. Is it a technical block, a reminder, or a habit?
- List the exceptions and say how they are approved and recorded.
- State where the evidence lives and how long it is kept.
- Have the operator read it and mark anything untrue.
- Date it and give it a review owner.
Keep each narrative to a paragraph or two. If it needs a page, it is probably two controls.
A worked example
Here is a narrative for change review, written the way an engineer might say it:
"To reduce the risk of unreviewed code in production, every change to the main branch of a production repository requires one approving review from someone other than the author. This is enforced by branch protection, so a merge is blocked without it. Repository administrators can bypass the rule for emergencies; each bypass must have a linked incident ticket within one business day. Approval records are kept in the source control system and exported monthly to the evidence folder. The Head of Platform reviews the bypass list each quarter."
Notice what it admits: administrators can bypass. That honesty is what makes it credible. NIST's change control family asks organizations to determine and document which types of changes are configuration controlled, review and approve them, and retain records of the decisions. A narrative like this maps onto that cleanly without copying the language.
Common mistakes
- Copying framework wording instead of describing your system.
- Describing the tool instead of the control ("we use GitHub").
- Leaving out exceptions, which auditors will find anyway.
- Never updating it after a process change.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one control can map to several framework requirements, then check that your narrative covers the shared facts once.
Quick check
How long should a control narrative be?
One to three short paragraphs. If it covers more than one owner, frequency or system, split it into two controls.
Who should write it?
The person who operates the control, with compliance staff editing for clarity. The operator knows what really happens.
Do narratives need updating?
Yes. Review them at least once a year and whenever the process, tool or owner changes.
Safeguard includes compliance and evidence automation and policy gates that can map scan and review records to framework controls, which gives narratives a consistent evidence source. You can run a free scan at gold.safeguard.sh/scan.
Sources
- GitHub Docs: About protected branches
- NIST SP 800-53 CM-3, Configuration Change Control (CSF Tools reference)
Last reviewed: 19 October 2026.
