Policy Management
Every policy is a promise. We track whether you’re keeping it.
Policies are the foundational artifact of your compliance program: your scans, your enforcement rules, your assessments and your maturity score all read from them. So we stopped treating them as documents. Every clause is tracked as an obligation, mapped to the controls it covers and marked by what proves it. Knowing which of your promises nothing can prove is the part you actually needed.
The obvious question
“Why wouldn’t I just ask ChatGPT for a policy?”
You can, and you’ll have a competent-looking document in about thirty seconds. The writing was never the hard part. What’s hard is everything that has to happen to that document over the next three years. ChatGPT emits prose, and prose can’t be watched, diffed by meaning, or enforced.
Policies are generated from how your business actually runs — workforce model, cloud providers, contractor mix, whether you're mid-acquisition. Not from a paragraph you wrote describing yourself at 11pm.
Every clause carries its control mappings and a revision history, and approvals are tracked per clause and per reviewer. A chat transcript has none of those. An auditor asks for all of them.
Published policies become executable rules in a real policy engine — sub-100ms evaluation, full violation lifecycle, and one-click enforcement on source control today with more platforms rolling out. That's the difference between claiming a control and operating one.
The unit of work
A policy is a document. A clause is a commitment.
“We review production access quarterly” is not just a sentence. It is a commitment with a control and a proof. We store it as a record, not text in a file, so the policy, the register and the by-control view always agree.
- Every clause maps to controls. See which clause is the only cover for a control before you touch it.
- Every clause shows its proof. Evidence-backed, unproven, or out of scope with a reason, right in the margin.
- Every clause keeps its history. Who changed it, why, and what you turned down.
Foundational
One policy, eight outcomes
A published policy on this platform isn’t a PDF filed in a drive. It becomes eight things a customer can act on — attestation, board metrics, scanner evidence, findings, red-team references, executable fixes, an immutable audit record. The value is the fan-out.
- ComplianceAttestation on every framework it maps to
- MaturityGovernance score reads what the policy says
- ReportingBoard decks show coverage and due-for-review
- ScannerScanner findings and policies land on one control
- FindingsEvery finding cites the policy it violates
- Red TeamEvery break references the policy it defeated
- RemediationViolations become executable fixes, not tickets
- Audit TrailEvery event lands on the tamper-evident record
One policy, eight surfaces. That’s why generation is unlimited in every tier — the value is what happens next.
Generation
The generator is not allowed to make up your details.
Ask a general-purpose AI for a backup policy and it can tell you restores are tested quarterly and logs are kept for 400 days. It does not know that. It picked plausible numbers, and now they are in a document you are about to hand an auditor.
- No invented specifics. A validator rejects any clause with a number, date or frequency you did not set.
- Nothing invented. Anything it cannot source from your business is flagged in the document, not guessed.
- Set once, updated everywhere. Change a value and every clause that uses it follows.
- Editable in place. Every edit is a recorded revision, not a rewrite.
- Fails closed. If a draft fails validation twice, you get an error, not an unchecked draft.
When things change
Changes arrive as one-clause edits, not a blank page.
Switch identity providers and three clauses now name one you no longer use. Regenerating would wipe your values, scope decisions and exceptions. Here, each affected clause gets a drafted edit with the reason it appeared. Accept it, keep your wording, or dismiss it with a note.
Example
You move from Google Workspace to Okta
All personnel sign in through Google Workspace Okta SSO.
You grow past forty people
All staff complete security awareness training within 30 days of joining.
You add a framework
Rebuild the policy and see what carries over, before anything goes live.
Coverage
The policies enterprise buyers expect — and dozens more
Every policy type below is generatable through the wizard, tailored to how your business actually runs, and mapped to every framework it touches. The tail is real: ~90 policy types across security, privacy, engineering, HR, and operations. Already have policies? Upload them as .docx, .odt, .pdf or .md (up to 5MB) and they are split into clauses, flagged for your review.
- Information Security Policy
- Access Control Policy
- Acceptable Use Policy
- Data Retention Policy
- Encryption Policy
- Incident Response Policy
- Business Continuity Policy
- Vendor Management Policy
- Supply Chain Policy
- Vulnerability Management Policy
- Change Management Policy
- Configuration Management Policy
- Asset Management Policy
- Media Protection Policy
- Physical Security Policy
- Remote Working Policy
- Backup Policy
- Logging Monitoring Policy
- Network Security Policy
- Cloud Security Policy
- Secure Development Policy
- Data Subject Rights Policy
- Breach Notification Policy
- Security Awareness Policy
- Personnel Security Policy
- + 66 more
Stakeholder Accountability
Every approval and every signature is on the record.
- Approvers see only the clauses assigned to them
- Edit a clause and its approval is voided
- Reminders at three and seven days for anyone unsigned
- Each signature records version, content hash, UTC time and channel
- The signature log is append-only and downloads as a CSV
Access Control Policy
v2.1.0 — Major UpdateEnforceability
We’ll tell you which of your promises nothing can prove.
Somewhere in a policy library is a promise of annual vendor reviews, and nobody has reviewed a vendor this year. An auditor finds it by sampling. You should find it first.
- Evidence backs it. Accepted evidence, with the date it was observed.
- Nothing proves it. No control, no evidence. A promise you would have to talk your way out of.
- Out of scope, with the reason. Excluded on purpose, with your answer and the date recorded.
- Not yet checked. Shown as a dash, never as a guess.
The register ranks what to fix first, starting with the clauses nothing proves that are the only cover for a control.
Enforcement
A policy engine, not a policy library
Every Vanta-class platform calls itself an “enforcement” tool. Ask what actually enforces and the answer is a Jira ticket. Ours ships a real engine.
- 297 shipped Rego rules across SOC 2, NIST CSF, ISO 27001, PCI DSS, HIPAA
- Sub-100ms per decision
- Simulate before activate: see the violations a rule would raise before you commit it
- AI-triaged priority, a risk score and remediation guidance on every violation
- One-click enforcement on source control today
It fires when a person confirms. Want it to act on its own? That is Trustworthy Autonomy
- P0MFA disabled on admin consoleOPEN
- P1Encryption-at-rest missing on 2 bucketsacknowledged
- P2Branch protection bypass on hotfix reporemediated
- P3Weak password policy on legacy tenantsuppressed
Immutable Record
An audit record no one can silently edit — including us
Every publish, approval, and attestation lands on a record your auditor can verify without our help. Cryptographically tamper-evident: if anyone touched the record after the fact, the check fails. External auditors verify against DigiCert or Sectigo directly — not our word for it, not our credentials required, not our cooperation asked. This is what “audit-grade” means when we say it.
Mechanism: SHA-256 hash chain, Merkle checkpoints anchored via RFC 3161 timestamp authorities (DigiCert primary, Sectigo fallback).
- Every publish, approval, attestation, and version bump lands on the tamper-evident audit record
- Auditors verify against DigiCert or Sectigo directly, without needing our credentials
- Full status history per policy: who authored, who reviewed, who approved, on what date
- The record survives even if we do not — the trust root lives with the timestamp authority, not with us
- Entries verified
- 12,847
- Sequence range
- 8,001 – 20,847
- Observation window
- 90 days
- Last verified
- 34s ago
SHA-256 hash chain, per-entry linking, Merkle checkpoints anchored via RFC 3161 TSA (DigiCert primary, Sectigo fallback). Trust root is the TSA’s public certificate; verification does not require our credentials.
How it scales
Every policy needs upkeep. The question is who does it.
The upkeep is work you can absolutely do yourself — in most companies it just doesn’t get done until an auditor asks.
Review dates come due.
every quarter · chased by hand
Someone watches the calendar, works out what changed since last time, writes the summary, then reminds four people to sign it.
01 Review queue
The queue surfaces what's due and routes it for approval.
Every policy carries a review cadence. The program view shows what is coming due and who still has to approve.
Your stack or vendors change.
nothing is watching for it
Someone has to notice the new identity provider or vendor, work out which clauses name the old one, and rewrite them.
02 Suggested edits
A drafted edit can appear on the clause it affects.
The edit arrives with the reason and the source. You accept it, keep your wording, or dismiss it with a note.
Your business changes shape.
no trigger, nothing surfaces it
You cross a headcount band, change industry or add a framework. The policies that assumed otherwise stay exactly as they were.
03 Suggested edits
New operating reality, new clause-level edits.
A change in your business context can draft edits on the clauses that mention it, so the work is reviewing a diff, not starting over.
Common questions
The questions buyers actually ask
Ready to turn policies into competitive advantage?
Generate your first policy and see which clauses nothing proves.
Reviewing enforcement impact on CI/CD pipelines...
Just now