--- title: Document Library description: Generate, edit, review, approve, and publish the policies CMMC requires — with merge fields, CMMC clause highlighting, full revision history, and PDF/Word export. Publishing turns a policy into control-linked evidence. navigation: icon: i-lucide-file-text --- # Document Library The **Document Library** (also called the Policy Generator) is the in-app home for the written policies CMMC and NIST SP 800-171 expect you to maintain. Instead of wrestling with Word templates on a shared drive, you **generate** a policy from a professionally drafted starting point, **edit** it in a rich document editor, move it through a **review and approval** workflow, and **publish** it — the one step that turns a finished policy into evidence linked to the practices it satisfies. Every policy lives as a single, stable document with a complete **revision history**: who changed what, when, why, and whether the change was material. That history is your audit trail, and publishing keeps your compliance posture, SSP, and assessment evidence pointed at the currently-approved version. ::note Find it in the sidebar under **Document Library** (`/dashboard/policy-templates`). Viewing is open to every role that can read compliance data; generating and editing require an editor role, and approving or publishing requires an approver role — see [Permissions](#permissions). :: --- ## Key concepts ### The policy catalog The library ships with a curated catalog: a ready-to-generate policy for **each CMMC control family** — the fourteen families that organize the NIST SP 800-171 practices (Access Control, Awareness and Training, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System and Communications Protection, and System and Information Integrity). Additional families that align to newer NIST guidance — Planning, System and Services Acquisition, and Supply Chain Risk Management — are available as well. Each catalog entry appears as a row in your **required-document checklist** with its current status, whether a published version exists, and when the policy is next due for review. You can also add your own **custom** policies beyond the catalog, or **upload an existing document** you already maintain instead of generating one. ### Lifecycle status A policy moves through a lifecycle. The status tells you exactly where the document stands and who can act on it next. | Status | Meaning | | --- | --- | | :badge[Not started]{color="neutral"} | In the catalog, not yet generated | | :badge[Draft]{color="info"} | Being written or edited | | :badge[In review]{color="warning"} | Submitted, awaiting approval | | :badge[Approved]{color="success"} | Approved, not yet published | | :badge[Published]{color="success"} | Live — surfaced as control-linked evidence | ::tip Approval and publishing are **separate, deliberate steps**. A policy can be approved and still not count as evidence until you publish it — which keeps an approved-but-not-yet-live document from prematurely showing up against your controls. :: ### Merge fields Generated policies come pre-filled with your organization's details through **merge fields** — placeholders the system resolves for you at generation time, including your organization name, the effective date, your CMMC level, your named security contacts and affirming official, and the list of your in-scope systems. You never hunt-and-replace "[Company Name]" by hand. ### Fill-in placeholders Beyond the auto-filled merge fields, templates carry two kinds of placeholders you complete while editing. Each shows as a colored `[bracket]` until you answer it, and the checklist counts how many remain. | Placeholder | What it is | | --- | --- | | :badge[Decision]{color="error"} | A required choice you must make (e.g. a defined value or approach) | | :badge[Fill-in]{color="info"} | A value to supply — some are shared across policies | ::note Shared **fill-in** values are collected once in a **Repeat Values** panel and applied everywhere they appear, so a detail you enter in one policy flows into every draft that uses it. A placeholder counts as complete the moment its brackets are replaced with a real value. :: ### CMMC clause highlighting Passages that answer a specific NIST SP 800-171 practice are **highlighted** and carry a hover tooltip naming the practice they address. This shows — to you and to an assessor reading the exported document — exactly which requirement each clause satisfies, so nothing is left implicit. --- ## Using the Document Library The main page shows your required-document checklist. Opening a policy takes you into the editor workspace, with its version history alongside. ### Generate a policy from a template ::steps{level="4"} #### Pick a policy from the catalog From the checklist, choose a policy that hasn't been started and generate it. #### Let the merge fields fill in Your organization details — name, effective date, CMMC level, security contacts, and in-scope systems — are resolved automatically into the new draft. #### Review what's left to complete The draft opens with any **decision** and **fill-in** placeholders flagged. The checklist shows how many of each still need an answer. :: ::tip Prefer to bring your own document? Use **upload** instead of generate to attach an existing policy you already maintain — it enters the same review-and-publish workflow. :: ### Edit the document ::steps{level="4"} #### Open the editor Open the policy to edit its working draft in the rich document editor — headings, lists, tables, and inline images are all supported. #### Complete the placeholders Replace each `[bracket]` with your answer. Fill-in values that are shared across policies can be entered once in the **Repeat Values** panel. #### Save your work Save the draft as you go. Your changes are kept on the working version without disturbing any previously published copy. :: ::note While you edit, **CMMC clause highlighting** marks the passages that answer specific practices. Hover any highlighted clause to see which requirement it satisfies. :: ### Submit for review ::steps{level="4"} #### Write a change summary When the draft is ready, submit it for review. A short **summary of the change** is required, and you flag whether the change is **material**. #### Hand it to an approver The policy moves to **In review**. An approver can then approve it or **request changes**, which sends it back to you as a draft. :: ### Approve An approver reviews the in-review version and **approves** it, which records the approver and a timestamp and moves the policy to **Approved**. Approving does not yet make the policy count as evidence — that happens at publish. ### Publish Publishing is the step that makes a policy **count**. It is the only action that surfaces the document as evidence linked to the practices it covers. ::steps{level="4"} #### Publish the approved version An approver publishes the approved policy. The system renders the final PDF and marks this version as the live one. #### It links to your controls The published policy is attached as evidence to **every objective in its control family**, across each of your assessments — so the practices it answers show supporting documentation automatically. #### A review date is set Publishing stamps a **review-due date** one year out, so the policy comes back around for renewal on schedule. :: ::warning Re-publishing after a later edit **supersedes** the previous version and updates the same evidence in place — your control links never point at a stale document, and evidence is never left dangling. Only a currently-published version is ever surfaced as evidence. :: ### Track revision history Every policy keeps a full **change log**. Each entry records the version label, its status, the editor and approver, the timestamps, the **change summary**, and whether the change was flagged material — with the rendered PDF available for published versions. Use it to see how a policy evolved and to demonstrate a controlled document process to an assessor. ### Export to PDF or Word Any policy can be exported as a **PDF** or a **Word (DOCX)** document — the same content, formatting, and CMMC clause highlighting in a portable file you can share, print, or hand to an auditor. --- ## Permissions Access is governed by three permissions in the role matrix. | Capability | Permission | | --- | --- | | View the catalog, drafts, revision history, and exports | :badge[VIEW_POLICIES]{color="neutral"} | | Generate, edit, submit for review, upload documents | :badge[MANAGE_POLICIES]{color="info"} | | Approve, request changes, and publish | :badge[APPROVE_POLICIES]{color="warning"} | `VIEW_POLICIES` is held by every non-platform role, including Assessor (read-only). `MANAGE_POLICIES` is held by Org Admin, Org User, MSP Super, and MSP Admin. `APPROVE_POLICIES` — the gate on publishing evidence — is held by Org Admin, MSP Super, and MSP Admin, **not** Org User (who can write and submit, but not approve) or Assessor. ::warning Because **publishing is the only path that creates control-linked evidence**, the ability to publish is deliberately restricted to approver roles. An editor can take a policy all the way to *In review*; an approver decides when it goes live. :: --- ## How it works Extra detail on how the library behaves — product behavior, not internals. ### One stable document, many versions Each policy is a **single stable document** per organization. Editing, submitting, approving, and publishing all operate on **versions** of that one document, so its identity — and the evidence links pointing at it — stay put across its entire history. A new round of edits creates a new working version on top of the published one; the published copy stays live until the new version is itself published. :::field-group ::field{name="Working version"} The draft currently open for editing. Saving and submitting act on this version. :: ::field{name="Published version"} The live copy that counts as evidence. Replaced in place when you publish again. :: ::field{name="Change summary" type="required to submit"} A short note describing the change, captured when a draft is submitted for review. :: ::field{name="Material flag"} Marks whether a change is significant, recorded on the version for the audit trail. :: ::field{name="Review-due date" type="one year"} Set on publish, so the policy returns for renewal on schedule. :: ::: ### Generation fills in what it can When you generate a policy, the merge fields pull from your live organization data — your legal or display name, your named security and affirming contacts, your highest CMMC level across assessments, and your in-scope system names (rendered as readable sentence text). Where a value isn't set yet, the draft uses a sensible fallback and leaves a placeholder you can complete. ### Publishing links across your whole assessment On publish, the policy attaches to **every objective in its control family** — matched by the family the policy belongs to — across all of your assessments at once. That's why a single published policy can satisfy the documentation expectation for many practices in one step, and why re-publishing cleanly refreshes those links rather than accumulating stale ones. ::note Optional **NIST SP 800-171 Revision 3** content can be included in a policy's editor view and its exports for organizations aligning to the newer revision. :: --- ## Related features :::card-group ::card{title="Evidence" icon="i-lucide-folder-check" to="https://app.dibfi.com/dashboard/systems"} Published policies appear as evidence linked to the practices they satisfy. :: ::card{title="Compliance Ops" icon="i-lucide-calendar-check" to="https://app.dibfi.com/dashboard/compliance-ops"} Schedule the recurring policy review as an operational task. :: ::card{title="SSP Export" icon="i-lucide-file-text"} Your published policies feed the documentation behind your System Security Plan. :: :::