Security teams write a lot. Policies that must be read and acknowledged, answers to customer questionnaires, summaries for auditors, reports for leadership. These documents are only useful if they match what is actually true in your environment. Safeguard Docs is the document space inside Safeguard, built so that the writing stays close to the data.
What it is
Safeguard Docs is for the documents that security and compliance work produces. It sits alongside the rest of the platform, so a policy can point at the controls it covers, an answer can point at the evidence behind it, and a report can pull in current numbers. Safeguard is chat first, so you can ask for a first draft in words and then edit it like any document.
Separately, the docs.safeguard.sh site is the product documentation, organized into areas such as Getting Started, SBOM, Compliance and GRC, Policies and Gates, and Administration. This post is about the documents you write, not that reference site.
What people write in it
- Policies. A plain language policy, linked to the controls and frameworks it supports, ready for people to read and acknowledge.
- Questionnaire answers. Drafted from your evidence library, with items that need human sign off flagged.
- Audit write ups. Short explanations of how a control operates, attached to the artefacts an auditor will ask for.
- Runbooks. What to do in the first hour of an incident, with the owners named.
- Reports. Weekly and monthly summaries for leadership.
Why it matters
Documents drift. A policy says one thing, a system does another, and the gap shows up at the worst time, in an audit or a customer review. Keeping the document next to the control and the evidence makes the gap visible early. It also means a new hire can find the current answer instead of an old attachment.
Examples
A founder is asked for a vulnerability management policy by a customer. They ask for a draft, edit the response times to match what the team really does, link the scan schedule as evidence, and send it. A compliance lead takes a questionnaire, lets the draft answers fill in from the evidence library, and spends their time on the five answers that need judgment.
Good habits
- Write what you do, not what you wish you did.
- Give every document an owner and a review date.
- Link claims to evidence instead of repeating them.
- Have a person approve anything that leaves the company.
- Never say a framework is certified when it is an attestation or a plan. Use the exact wording your auditor uses.
Quick check
Why keep documents next to controls and evidence?
So that gaps between what the document says and what the system does show up early, before an audit or a customer review.
