Policies that do something, not just say something.

A policy is only as good as its weakest sentence, and until now ours were stored as documents. Today they become something you can check: which of these promises is anything actually backing up?

Policy management is now clause by clause. Every policy is split into individual clauses. Each clause carries the controls it maps to and a proof state: backed by evidence, nothing proves it, out of scope with a recorded reason, or not yet checked. The state is shown in the margin of the document as you read it. You’ll find it under Business Controls, in the new Policies tab.

Which promises nothing can prove

The clause register lists every clause in every policy and ranks the ones to fix first: clauses nothing proves come first, and among those, the ones that are the only cover for a control. Each row shows how many controls the clause maps to, as a count, never a percentage. A mapping the platform only suggests, such as one read from a document you uploaded, is labeled as a suggestion and never counts as coverage. A mark for “enforced by a live control” is not live yet, so no clause is shown as enforced today.

A generator that won’t make up your details

Ask a general-purpose AI for a backup policy and it will invent your retention period. Ours can’t. A validator rejects any clause that carries a number, a date or a frequency that is not yours, and anything the generator cannot source from your business is flagged in the document instead of guessed. If a draft still fails validation after a retry, you get an error, not an unchecked draft.

Changes arrive as one-clause edits

Editing a clause records a revision, so a policy’s history is a list of changes, not full rewrites. When something in your stack, your vendors or your business context changes, a drafted edit can appear on the clause it affects, with the reason, the source and a risk level. Accept it, keep your current wording, or dismiss it with a note. A dismissed edit is recorded with your reason and the date, and it comes back for another look later.

What changes for you

• You can see which promises are unbacked. Every clause is marked by what proves it, and the register puts the riskiest gaps first. A clause we have not been able to check yet shows as a dash, not a guess.
• Updating a policy stops meaning regenerating it. Edit a clause in place, or review a drafted edit as a diff. The values you filled in, the scope decisions you recorded and your exceptions stay where you put them. You can still rebuild a policy’s structure; it arrives as a proposal, with a preview of what carries over.
• Approvals and attestation leave a record. Reviewers are assigned specific clauses, and an approval is tied to the exact revision they read, so editing a clause voids the pending approval on it. Once a version is approved, you can open an attestation in the app, by email or both; anyone who has not signed is reminded after three days and again after seven. The signature log records the version, content hash, UTC time and channel, and downloads as a CSV.
• A clause you cannot meet yet has a home. Log an exception on the clause with a reason, a compensating control, a risk level and an expiry. It shows on the clause while it is active, and stops showing as active when it expires.

Your existing policies

Nothing you already had is lost. Existing policies were split into clauses and flagged for review, so the register is where you work through them. You can also upload policies you already have (.docx, .odt, .pdf or .md, up to 5MB); each is split into clauses, flagged for your review, and shown as not yet checked until something proves it.

The full walk-through is on the policy management page. You can open it in your tenant at Business Controls → Policies.

Every policy is a promise. See which ones you’re keeping.