Structure a security knowledge base around the moments an engineer needs help: "what do I do right now", "what is the rule", "why was it decided", "how do I do this task", and "who do I ask". Five sections, one owner each, and a front page that answers the most common questions in one click.
Why org charts make bad folder trees
Security teams tend to file documents the way they are organized: application security, cloud security, GRC, incident response. An engineer does not know which team owns the answer. They know they have a failing build, a customer questionnaire, or a suspicious alert.
If the first click asks them to guess a team, they will skip the wiki and ask in chat. Structure by intent and the same pages become far easier to find.
The five sections
| Section | Question it answers | Typical pages |
|---|---|---|
| Act now | What do I do in the next hour? | Runbooks, escalation paths, contacts |
| Rules | What am I expected to do? | Policies, standards, approved lists |
| Reasons | Why is it this way? | Decision records, risk acceptances, threat models |
| How to | How do I complete this task? | Step by step guides, templates, examples |
| People | Who owns it and who can help? | Owner directory, office hours, channels |
Keep the split strict. A runbook that also explains the history of a decision becomes too long to use during an incident. Link to the reason instead of pasting it in.
Steps to set it up
- Collect the last 30 days of security questions from chat, tickets and code review. Group them by intent, not by topic.
- Create the five sections as top level pages. Resist adding a sixth for "miscellaneous".
- Move or rewrite the ten pages that would have answered the most questions. Leave the long tail where it is for now.
- Add a front page with the ten most asked questions, each linking straight to its answer.
- Assign one named owner per section, and one per page inside it.
- Put a review date on every page so stale ones are visible. See keeping runbooks true for one way to do that.
Naming and depth
Two levels of nesting is usually enough. Past three, people stop browsing and rely on search, so titles matter more than folders. Write titles as the thing a person would type: "Rotate a leaked API key" beats "Credential lifecycle procedure".
Avoid duplicating pages across sections. One canonical page, linked from wherever it is relevant, stays correct longer than three copies that drift apart.
What to leave out
Do not turn the knowledge base into an archive of everything the security team ever wrote. Slide decks from a past training, scan exports and meeting notes belong elsewhere. If a page has no owner and no reader, retire it.
Also keep sensitive material out of the broad wiki. Details such as unpatched findings for a named system need tighter access than a how to guide. See what should never go in a security wiki.
A Safeguard note
If your knowledge base documents your vulnerability and dependency process, it helps when the facts it quotes come from a live source. Safeguard's dependency scanning and SBOM generation give you a current inventory to link to, and you can start with the free scan at gold.safeguard.sh/scan.
Quick check
How many pages should a first version have?
Twenty to thirty good ones. Cover the top ten questions, the incident basics and an owner directory. A small accurate set beats a large stale one.
Should the knowledge base live in a wiki or in a Git repository?
Either works. A repository gives review history and ownership rules, a wiki is easier for non engineers to edit. Pick one source of truth and link to the other.
Last reviewed: 19 October 2026.
