Often yes. Keeping runbooks, standards and FAQs as plain text in Git gives you review, history, owners and the ability to block changes that skip documentation. It suits engineering heavy teams, but keep sensitive material out and make editing easy for people who do not use Git.
What docs as code means
Write the Docs describes it as writing documentation with the same tools as code: issue trackers, version control, plain text markup such as Markdown, code review and automated tests. It lists benefits such as writers integrating better with development teams, developers often writing a first draft, and the option to block merging of new features that lack documentation.
Why it fits security docs
| Need | What Git gives you |
|---|---|
| Know who changed a rule and why | Commit history and pull request discussion |
| Make sure a second person reviews | Required reviews and code owners |
| Keep docs near what they describe | Docs in the same repository as the service |
| Detect broken links and old pages | Automated checks in CI |
| Track versions of a standard | Tags and releases |
On code owners: GitHub documents that a CODEOWNERS file assigns responsible people or teams to paths, and that they are automatically requested for review on matching pull requests. See owners and review dates.
What to keep in Git, and what not
Keep in Git:
- Runbooks, standards, guidelines and decision records.
- FAQ entries and the glossary.
- Templates, such as the service security card.
Keep out of Git, or in a restricted repository:
- Credentials of any kind, even test ones.
- Raw customer data and unredacted screenshots.
- Details of unfixed flaws in named systems.
See what should never go in a security wiki. The same rules apply, and Git history is permanent, which makes mistakes harder to undo.
A week to start
- Day 1. Create a repository with a README, a template and a CODEOWNERS file.
- Day 2. Move five high traffic pages in as Markdown. Leave the old versions with a "moved" pointer.
- Day 3. Add a link checker and a spell check to CI.
- Day 4. Require one review on pull requests, with owners auto requested.
- Day 5. Publish the repository as a browsable site, and add front matter fields for owner and last reviewed.
Add a front matter check later that fails the build when a review date is more than a set age.
Lower the barrier for non engineers
Not everyone is comfortable with Git. Offer a web editor, a simple form that opens a pull request, or a suggestion channel so legal, HR and compliance colleagues can contribute without learning a command line.
Link docs to enforcement
When a doc says a rule applies to pull requests, link to the check that applies it. A written rule and a gate that matches it reinforce each other. See written rule or enforced check.
Sources
Where Safeguard fits
Repositories also hold your code, and Safeguard's dependency scanning, SBOM generation and policy gates apply to them. Start with the free scan at gold.safeguard.sh/scan.
Quick check
Is a wiki still fine?
Yes. A wiki is easier for broad editing. What matters is a single source of truth, an owner and a review date, whichever tool you use.
Does docs as code need a writer?
No. Engineers can write the first draft. A reviewer with an eye for clarity helps a lot.
Last reviewed: 19 October 2026.
