Policies & document management
Zovos treats a policy as a governed object with a lifecycle rather than a file in a folder. This article covers the whole path of drafting, approval, publication and attestation. It also covers the document library that holds everything else your program produces.
The policy register
Governing docs is the register. Each row shows the document, its tier, its version, its owner, its status, its review date, and how many citations it maps to. Tiers run policy, standard, procedure, and guideline, and the tier matters. It decides where the document routes for approval, with policies going to the board and lower tiers routing to management.
Review status reads current, due soon, or overdue, and overdue reviews surface on the Dashboard. Row actions cover attesting and retiring. An overflow menu holds edit review window, coverage, version diff, waivers, version history, attestation campaigns, and custom fields where your workspace has defined fields for policies.
A policy reads In breach when an open finding linked to it is past its remediation date. The pill names each such finding and the date it was due. Nobody sets it by hand, because it is derived from the findings linked to the policy.
Edit review window is the answer to "our review dates are wrong". It takes the effective date, the review cadence, and the approval record for a key policy, meaning the approving body and the date it approved. The next review date is recomputed from the first two rather than typed in. Name, version, owner and tier are not editable through that route, and there is still no delete. Retiring a policy is the end of its life.
The register carries the shared register tools too: saved views, spreadsheet import and the audited import-ready export described in Dashboard & daily triage.
Drafting
Authoring happens in Drafts, a collaborative editor with presence, organized in a folder tree for policies, standards, procedures, AI drafts, gap reports and exam packages. The editor has four tabs for edit, history, comments and suggestions. A citation rail keeps the obligations you are writing against next to the text.
Two things make it usable for a compliance team rather than a document tool:
- Suggesting mode turns your edits into tracked changes instead of direct edits, so a reviewer sees exactly what you proposed.
- Comments can be marked internal, which hides them from any examiner session. Internal deliberation stays internal.
Exports are PDF, DOCX and redline DOCX. If your legal counsel or a board member works in Word, Send for Word review sends the draft out as a redline and pulls tracked changes back as a review-pass version. This needs your SharePoint connection in place first. Without one, the send is refused rather than half-completed. It is a checkout rather than a sync. There is one active review session per draft, an explicit conflict state if the base document moved underneath, and no silent merge. You can always cancel a review session.
Sign-off inside the editor is a native e-signature. It requires you to re-authenticate before signing, binds the signature to the document's content hash, and is blocked while unresolved suggestions remain.
Approval and publication
From a draft you either submit for approval or publish a version directly with a recorded rationale. Submitting routes the version through the approvals queue described in Approvals & delegation of authority. On approval the version becomes effective.
Version history is where the governance record lives. Each version can carry a record reference with the approving body, the board minute reference, and the meeting date. It exports as an official DOCX or PDF. If you publish approved policies to SharePoint, that happens from here too.
Every new version declares its change type, and the distinction is enforced rather than advisory:
- Material. A material change invalidates the existing sign-off and requires re-attestation.
- Editorial. The sign-off stands and no re-attestation is needed, but calling a change editorial requires a justification.
Attestation
Attestation is a named person recording that they have read and accept a document. The Attest row action is an approver sign-off, open to people whose role can approve policies, such as owner and board, and it requires a rationale. Everyone else confirms they have read a document by responding to its attestation campaign. Launch a campaign with a name, a due date and a recipient list. The register rolls up completion as a count, exports a completion record, and closes when you close it.
A material change puts a Needs re-attestation badge on the policy until the affected people sign again. A policy that has never been signed on any version reads Never attested instead. Exceptions and waivers against a policy are handled separately, with a reason, an expiry date, compensating controls and an approving body, and they move through active, pending, expired or revoked.
Sending a version for signature
From a policy version's history you can send the filed official PDF out for signature. It is the artifact you filed that goes out, never a generated stand-in, so the document a board chair signs is provably the document your reviewer approved.
There are two routings:
- Policy attestation. The request is routed into an open attestation campaign for that same version. Recipients come from the campaign's roster. On completion the attestation records are written and the signed copy lands back as evidence against the version it belongs to.
- Board sign-off. The request is addressed to named signers picked from your team roster, whose addresses come from your identity provider. Manual entry stays available for an external signer such as an outside director or counsel. A member the roster holds no address for is shown as unpickable rather than guessed at. On completion the signed PDF is archived and audited.
Sending is an owner-level action and is refused in an examiner session. Which e-signature provider you can send through depends on what you have connected. See Connecting integrations.
The document library
Document review, opened from Documents in the My work group, is where everything else lands. That includes evidence, board memos, vendor artifacts, and procedures you have not yet brought under governance. Drag and drop PDF, DOCX, TXT and Markdown files.
The processing pipeline is visible, and it fails closed. A file uploads, is quarantined pending a virus scan, then indexes for retrieval, and only clean, scanned versions are ever indexed. A file that fails the scan is blocked and reported as blocked. Re-uploading a document you already hold is handled explicitly as a New version of that record, rather than as a second copy in the library.
The reader pane shows evidence links, version history, and mapped frameworks with a match percentage. It also carries records disposition: a retention class and a status of within retention, due for disposition, on legal hold, or disposed. When a record reaches the end of its retention, it queues a record disposition review with an outcome of retain or clear for disposal. The review itself destroys nothing. It records a human decision, and disposal remains a separate, deliberate act.
A legal hold is more than a status on a document. Open the hold and you see what it actually preserves. That is the documents scoped under it, which you add to and remove while the hold is active, and afterwards its release record. A hold cannot be edited or deleted. Release is its auditable end, and the scope of a released hold stands as the historical record of what was preserved. Retention classes themselves are editable and removable, although the platform refuses to remove one that is still in use or is your default.
Notes and limits
Zovos is not your document management system of record. It ingests from SharePoint, Confluence, Google Drive, Box and legal DMS platforms, and it publishes approved policy versions back out to SharePoint and the legal DMSs. Most connectors are one-way ingest, though, and the Word round-trip is explicitly a review cycle rather than continuous sync.
Drafting agents produce proposals. A drafted policy carries a banner saying so, and it is never published without a person approving it.