ATALAIAMost security policy sets are written for auditors and read by nobody else. They run to dozens of pages, describe tools that were replaced two years ago and are updated in a rush before each certification. Engineers learn that policy is something that happens to them once a year.
We think that is backwards. A policy is only useful if the people who build and run systems can read it in a few minutes, recognise their own work in it and see that it is checked automatically. Here is how we would write them.
Short beats complete
A good engineering policy fits on one screen. It states what must be true, who owns it and how you will know. It leaves the how to standards and runbooks, which can change without a policy review.
Policy: Source code changes
Owner: Head of Engineering
Applies to: all repositories that build or deploy production software
1. Changes to default branches go through a pull request.
2. At least one reviewer who is not the author approves the change.
3. Secrets are never committed; CI blocks commits that contain them.
4. Exceptions are recorded with an owner and an expiry date.
Checked by: branch protection export and CI job results, monthly.That is the whole policy. Anyone can tell in a minute whether their repository complies. A long version with background, definitions and tool names belongs in a separate standard that links back here.
Map statements to controls
Every numbered line in a policy should map to at least one control, and every control to an owner and a check. If a line has no control behind it, either add one or delete the line.
| Policy line | Control | Owner | Check |
|---|---|---|---|
| Changes go through a pull request | Branch protection on default branches | Platform team | Source control API export |
| Independent review | Required approvals, no self-approval | Platform team | Same export, review settings |
| No committed secrets | Gitleaks in CI, push protection | Security | CI job results per repository |
| Exceptions recorded | Exception register with expiry | Security | Register review, expired items flagged |
This table is also the thing auditors actually want to see. It shows design, ownership and operation in one place.
Evidence from the pipeline, not screenshots
The worst part of most audits is evidence collection: screenshots of settings pages, gathered by hand, true on one afternoon. Your platforms already know the answers. Ask them on a schedule and keep the output.
- CollectA scheduled job queries source control, CI and cloud APIs for the settings each control depends on.
- EvaluateResults are compared with the policy, producing pass, fail or exception per asset.
- StoreRaw output and results are written to an append-only bucket with a date in the path.
- ReportOwners see failures as tickets; auditors see the history.
# evidence: default-branch protection, one JSON file per run
gh api repos/your-org/payments-api/branches/main/protection \
> "evidence/$(date -u +%F)/payments-api-branch-protection.json"Once evidence comes from the line itself, policy stops being a document and becomes a set of checks with an owner.
Where the frameworks fit
Teams often start from a framework and work down to policy. It is usually easier the other way round. SOC 2 and ISO 27001 both expect documented policies, assigned ownership and evidence that controls operate over time. NIS2 brings risk management and incident reporting duties for organisations in its scope. The EU Cyber Resilience Act adds requirements for products with digital elements, including vulnerability handling and secure development across the product's support period.
Short, mapped policies with automated evidence serve all of these, because they all reward the same thing: controls that demonstrably run. Whether a given framework applies to you, and what exactly it requires, is a question for your legal and compliance advisers. This post is not legal advice.
What we would do
- Pick your three most important policies, typically source code changes, access management and vulnerability handling, and rewrite each to fit on one screen.
- Build the mapping table for those three. Delete any line that has no control.
- Automate one evidence check this month, store its output with a date, and show it to the owner.
- Set a review date on every policy and put it in a calendar, not in the document footer.
When engineers can read the policy, see the check and fix the failure themselves, the audit becomes a review of work already done.
Where this sits on the line
In the tower (in development):