Versions, reviewers and files
Governance → Policy Management → (a document) → Versions
Every change to a governing document creates a new version rather than overwriting the old one. Old versions stay readable, which is what lets you answer "what did our policy say in March?" — the question an investigation always asks, and the one an overwritten document cannot answer.
What a version carries
| Version label | 1.0, 2.1 — unique within the document |
| Title | As at that version |
| Change reason | Why this version exists. Required, at least 10 characters |
| Status | Its own lifecycle state |
| Body | English and Arabic Markdown |
| File | The uploaded PDF or Word artefact, its size and type |
| Dates | Effective, approved, published, retired — stamped by transitions |
| Who | Created by, approved by |
The change reason is not optional and not decoration. It is the entry in the document's change log that a reviewer reads to decide whether the change is material, and that an auditor reads years later to understand why the document moved. "Updated" is a wasted field; "Section 4 rewritten after the Q2 access review findings" is the record.
How versions get created
| Route | Creates |
|---|---|
| Uploading a new file | A draft version, label auto-bumped from the last one |
| Saving content by hand | Writes to the latest draft, or creates one |
| Drafting with AI | A new draft version each run |
| Accepting a redline proposal | A new draft version carrying the revision |
Version labels auto-increment on the last dotted segment — 2.1 becomes 2.2
— unless you supply one. A label already used on that document is refused as a
duplicate rather than silently renamed.
Reviewers
Reviewers are assigned per version, not to the document in the abstract. That is deliberate: being asked to review v3 says nothing about v4, and the record needs to show who was asked for each.
A reviewer is either required or not. Assigning the same reviewer twice is a no-op rather than an error, so re-sending an assignment list is safe.
The roster is separate from what people actually did. "Assigned to review" and "took an action" are different facts, kept in different places — a reviewer who never responded is visible as exactly that, rather than being invisible.
Reviewers
Reviewers are named on the policy, and naming someone is a real act: a document cannot be submitted for review until at least one required reviewer is assigned, and it cannot be approved until every required reviewer has approved it.
Each reviewer is either:
- Required — their approval gates the document.
- Advisory — their opinion is recorded and shown, but does not gate. An advisory reviewer who returns the document still sends it back; advisory means your approval is not required, not that your objection is ignored.
Assigning someone notifies them immediately — in the app and by email — with a link straight to the document. Before this, a reviewer found out they were a reviewer by being told in person.
Remove a reviewer if they leave or were named by mistake. It is the release valve: a required reviewer who can never respond would otherwise hold the document in review indefinitely. Removing them does not erase anything they already did.
Approvals
Governance → Policy Management → (a document) → Approvals
Each decision records who, what, when, any comment, and the version it was given against. Three things are enforced:
Every required reviewer must approve. The panel shows the count — 3 of 5 required approvals — so the blocker is visible rather than discovered on a failed click.
You cannot approve what you wrote. Neither the author of the version under review nor the person who last edited its text may approve it. This is segregation of duties, and it is the difference between an approval and a signature on your own work.
Returning resets the round. Any reviewer can send the document back to draft. When it is resubmitted, everyone approves again — including those who had already approved. Their earlier decisions stay in the history; they simply no longer count toward the current round.
There is no button anywhere that sets a document to approved directly.
Approval is what happens when the last required reviewer approves. Attempting
to set the status by any other route is refused.
My Reviews lists what is waiting on you personally, the same way My Acknowledgments does.
The uploaded file
The file card sits above the tabs on every document page.
Accepted formats: PDF, DOCX, DOC. Maximum size: 100 MB. PDFs preview inline in the page; Word documents are downloadable.
How the file gets there depends on what your installation has, and the platform picks for you:
- With object storage (S3, or an S3-compatible service such as MinIO) the browser uploads directly to storage, bypassing the application entirely, and a second call confirms it landed. This is what lets a 40 MB ISO 27001 Statement of Applicability upload at all on a hosted deployment.
- Without it — the usual on-prem case — the file uploads through the application into the database, in one step. Nothing external is required, which is the point: an air-gapped installation has working policy files with no object storage to run.
Either way the experience is the same: pick a file, watch the progress bar, and the version appears.
Files are stored per organisation, per policy, per version, so two organisations on the same installation can never reach each other's documents.
Download issues a signed link valid for five minutes — long enough for a click, short enough that a link copied out of a browser is worthless by the time anyone else tries it. Every download is written to the audit log against the version, so "who read the Acceptable Use Policy v2.1?" has an answer.
A version cannot be published until its file has been confirmed in storage — not merely selected. Starting an upload and abandoning it leaves a draft version that stays unpublishable, which is the intended outcome: the artefact is the record of what was issued.
Where files are stored
With object storage configured, policy files live in your bucket, keyed per organisation, per policy, per version. Without it they live in the application database, in the same store the audit and third-party-risk modules use for evidence.
Downloads behave identically either way — a signed link with a five-minute life, and an audit-log entry against the version. Nothing about a policy's lifecycle, approvals or attestation depends on which backend is in use.