Document Governance

The Document Governance module is the layer that sits on top of your document management system (DMS). The DMS owns documents themselves: their files, versions, folder structure, access control. Document Governance owns the governance behavior around those documents: when each one becomes effective, when it needs review, who has to acknowledge it, how long it must be retained, and how it connects to the controls and obligations it implements.

This split matters. A policy document in the DMS is just a file with metadata. The same document, with a governance profile applied, becomes an audit-grade artifact with a published effectivity date, a defined review cycle, a tracked acknowledgement obligation, and a retention rule that can withstand scrutiny.

When you would reach for this

You set up document governance when:

A policy or procedure document needs to become effective on a specific date and the audit trail of that effectivity matters.
A document type (board policies, standard operating procedures, technical standards, work instructions) needs a periodic review cadence so it doesn’t quietly go stale.
A group of people must acknowledge they’ve read a document, and you need an auditable record of who acknowledged what version.
A document falls under a retention requirement (legal, regulatory, or internal) and you want the requirement to be tracked alongside the document.
A policy needs to be traced to the controls it implements, the obligations it satisfies, and the framework requirements it covers.

You don’t reach for this for the document’s content itself, version storage, or the folder tree (that’s DMS). And you don’t reach for it for the work that proves a control operates (that’s Evidence). Document Governance is the governance layer about documents.

What lives in document governance

Several record types working together:

Document governance profile is a reusable template describing the governance behavior for a class of document. For example: “board policies” has a 2-year review cadence, a 7-year retention, and requires acknowledgement by all board members. “Standard operating procedures” has a 1-year review cadence, a 5-year retention, and requires acknowledgement by named operational roles.

Profile version is a specific revision of a profile. Profiles evolve; older versions remain readable for documents that were assigned to them historically.

Folder default assigns a default profile to a folder in the DMS, so documents added to that folder inherit the profile automatically.

Profile assignment ties a specific document (or version) to a specific profile, overriding the folder default if needed.

Effectivity record captures when a document version becomes effective, when it’s superseded, and what the boundary moments were.

Review requirement captures when the next review is due, who is responsible, and the review outcome.

Acknowledgement requirement captures who must acknowledge a document version, by when, and the per-recipient acknowledgement status.

Retention requirement captures how long the document must be retained, the disposition action at end of life, and any legal hold state.

A worked example: a global engineering and construction firm governs its technical and procedure documents

A global engineering and construction firm runs hundreds of active projects across many disciplines (civil, electrical, structural, mechanical). It maintains a large library of technical standards, design manuals, safety procedures, and project standard operating procedures. Each kind of document has its own governance posture, and a missed review or untracked acknowledgement can be a serious safety or contractual issue.

The technical governance manager, Akira, sets up Document Governance like this.

Step 1: define governance profiles per document kind. Akira creates profiles for each major class:

engineering-design-standard — 3-year review cadence, 25-year retention (lifetime of typical projects + handover period), acknowledgement required by lead engineers in affected disciplines.
safety-procedure — 1-year review cadence, 10-year retention, acknowledgement required by every site supervisor.
project-sop — 2-year review cadence, project-lifetime + 5 years retention, acknowledgement required by project managers.
quality-manual — 1-year review cadence, indefinite retention, acknowledgement required by quality leads.
board-policy — 3-year review cadence, indefinite retention, acknowledgement required by named officer roles.

Each profile carries the structured detail (cadence, retention period, acknowledgement scope, escalation routing).

Step 2: assign defaults to DMS folders. In the DMS, technical standards live in /engineering/standards/, safety procedures in /safety/procedures/, and so on. Akira assigns the corresponding profile as the folder default. New documents added to a folder inherit the profile automatically.

Step 3: per-document overrides. A handful of documents need special handling (a joint-venture safety procedure with extra cross-organizational acknowledgement requirements). Those get a profile assignment that overrides the folder default.

Step 4: publish and record effectivity. When a new revision of a safety procedure is approved through the DMS workflow, the governance side records the effectivity: this version is effective from a specific date, supersedes the prior version, and triggers the acknowledgement requirement.

Step 5: acknowledgement tracking. Every site supervisor receives the new safety procedure and acknowledges it through the in-product workflow. The acknowledgement record captures who, when, against which version. Until acknowledgement is complete, the supervisors who haven’t acknowledged are surfaced for follow-up.

Step 6: scheduled review. The system surfaces upcoming review-due dates. Twelve months after the safety procedure was issued, the owning safety manager is prompted to review. They either confirm the document still represents current practice, mark it for revision, or supersede it with a new version.

Step 7: retention discipline. Documents reaching end-of-life on their retention rule are flagged for disposition. A document under legal hold doesn’t get disposed regardless of retention; the hold is captured here too.

Step 8: traceability to the governance program. Each policy or procedure is linked to the controls it implements, the obligations it satisfies, and the framework requirements it covers. When an auditor asks “show me the policy that implements requirement X,” you click through from the requirement to the document, see its effectivity, acknowledgement, and review history, and you’re done.

What you’ll see in the product

Document Governance shares its surface with the DMS so you don’t context-switch when working on a controlled document:

Inside any DMS document, a Governance tab shows:

The applied profile and folder default source.
Current effectivity status.
Review requirements with next-due dates.
Acknowledgement requirements with completion rates.
Retention requirements with end-of-life and disposition status.
Linked controls, obligations, evidence requirements, and framework nodes.

Under Governance → Document Governance, there are dedicated pages for:

Profiles (the template library).
Folder defaults (the assignment matrix).
Active assignments (per document/version).
Queues: effectivity events upcoming, review due, acknowledgements outstanding, retention reaching end-of-life.

The queue views are the day-to-day workspace for document governance: instead of every document showing up everywhere, the right people see the work they own surfaced as a queue.

Every change is captured in the workspace Audit Log.

Common workflows

Standing up document governance for the first time

Define profiles for each kind of document your organization governs.
Assign profile defaults to the DMS folders that hold each kind.
Walk the existing document library and verify each document picks up an appropriate profile (override where needed).
Schedule the first round of reviews and acknowledgements.

Publishing a new revision of a controlled document

The document is approved through the DMS workflow.
On publication, the system creates an effectivity record (this version effective from date X, superseding the prior version).
The acknowledgement requirement triggers; assigned recipients are notified.
The next review-due date is set based on the profile’s cadence.

Reviewing an aging document

The review-due queue surfaces the document.
The responsible reviewer assesses whether the document still reflects current practice.
Either confirm the current version remains valid (review-due date resets), revise the document (a new version is created and follows the publication workflow), or supersede with a different document.

Disposition at end of retention

The retention queue surfaces documents reaching end-of-life.
The responsible owner confirms the disposition action (archive, deletion, transfer).
If a legal hold applies, the document is not disposed regardless of retention.
Disposition decisions are captured in the audit trail.

Cross-referencing a policy to a framework

From the document’s Governance tab, link to the controls and obligations the document implements.
The links appear from the document side and from the control/obligation side.
An auditor walking a framework requirement clicks through to the implementing policy directly.

A note on what this is not

This module deliberately doesn’t create a parallel “policy register” outside the DMS. Policies, procedures, standards, manuals, work instructions are all documents in the DMS. Document Governance adds typed, audit-grade governance behavior on top of those documents without forking the source of truth.

If your team is tempted to build a “policy database” outside the DMS to track which policies you have, resist the temptation. The DMS holds the document; Document Governance holds the governance behavior; nothing else needs to exist.

Controls - documents typically implement controls.
Obligations - documents typically satisfy obligations.
Frameworks - documents map back to framework requirements through coverage links.
Evidence - acknowledgements and reviews can themselves serve as evidence.
Workspace governance - DMS lives in workspace governance; this module sits on top.