> ## Documentation Index
> Fetch the complete documentation index at: https://www.docusnap.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Approving a Document

> Create a controlled document, write it, set the roles, request approval and decide.

We carry a policy from creation to approval: create it as a controlled document,
write the content, set *Responsible* and *Approver*, request approval, decide. At
the end stands version 1.0.

## Starting point

Docusnap Sports GmbH is preparing its ISO 27001 certification. For the control
*Review access rights regularly* a policy is still missing: who grants access
rights, and at what cadence they are reviewed. The IT Security Officer writes it,
the IT Manager approves it. The tenant has *Strict Mode* enabled: requesting and
approving are separate roles.

## 1. Create the controlled document

<Steps>
  <Step title="Open the dialog">
    *Document* opens the dialog *Create New Document*.
  </Step>

  <Step title="Set the title and turn on document control">
    *Title*: *Access Control Policy*. Switch on *Controlled Document* — that
    makes *Type* mandatory.
  </Step>

  <Step title="Choose the type">
    *Type*: *Policy*. Language, format and export settings stay on their
    defaults.
  </Step>

  <Step title="Create">
    *Create Document*. The document opens as a tab with the chapter
    *Introduction*.
  </Step>
</Steps>

<Note>
  Whether a document is controlled is decided when it is created. It cannot be
  changed afterward.
</Note>

## 2. Write the content

On the *Content* tab we switch to edit mode with *Edit*. We rename the chapter
*Introduction* to *Scope* by double-clicking it and create a second chapter
*Granting and Review*: who grants access rights, quarterly review. *Save*. The
document stays in status *Draft*.

## 3. Set the responsible person and the approver

<Steps>
  <Step title="Edit the properties">
    Tab *Properties*, pencil icon. Anyone can edit this tab, regardless of the
    right to the content.
  </Step>

  <Step title="Set the responsible person">
    The IT Security Officer. Without *Responsible* the content is locked for
    everyone.
  </Step>

  <Step title="Set the approver">
    The IT Manager. In *Strict Mode*, *Responsible* and *Approver* must not be
    the same person; the page reports this immediately.
  </Step>

  <Step title="Save">
    Without both roles, no approval can be requested on the *Document Control*
    tab.
  </Step>
</Steps>

## 4. Request approval

<Steps>
  <Step title="Fill in the request">
    Tab *Document Control*. *Version*: *Major Version* — the first version
    becomes 1.0. *Change Reason*: "Initial version for inclusion in the ISMS".
  </Step>

  <Step title="Review the changes">
    *Show Changes* shows the entire content as new. There is no earlier version.
  </Step>

  <Step title="Submit the request">
    *Request Approval* sets the document to *In Review*. The content is locked
    until a decision is made.
  </Step>
</Steps>

## 5. Decide

The IT Manager sees the request: *Requested Version*, *Change Reason*,
requester, date. *Approve* sets the document to *Approved* and writes version
1.0.

<Note>
  *Reject* requires a *Reason* and sets the document to *Draft*. The responsible
  person can revise it and submit again.
</Note>

## Result

Tab *Overview*: *Valid Version* 1.0 with approver, date and change reason. Tab
*History*: *Versions* lists 1.0 as *Valid*; the approval history contains the
request.

<Warning>
  Writing on costs the approval. *Edit* on the *Content* tab asks back: saving
  sets the document to *Draft*, and a new approval is needed. Version 1.0 stays
  intact.
</Warning>

## Next steps

Attach the policy to the control as evidence:
[Documentation Fundamentals](/docs/en/documents/overview#a-document-as-evidence).
Trace the path for an audit:
[Producing Evidence for an Audit](/docs/en/documents/tutorial-audit-evidence).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.