Required Documents
Working with required documents
Filling a required document works the same three ways a policy does: write it in the editor, upload a file, or link to one held elsewhere. What's specific here is the recurring part — every cycle adds a document rather than replacing the one before it.
Starting a required document
Clicking Start on a required document offers three routes:
1. Create with editor
- Write the document from scratch in the built-in editor
- Full word processing capabilities
- Automatic version control
- Integrated approval and review flow
2. Upload file or use already uploaded document
- Upload PDF or Word documents
- Keep your existing tooling and workflow
- Recognisable afterwards by the paperclip icon
- Integrated approval and review flow
3. Link to an external location
- Point at a document held in another system via URL
- Editing and version management stay outside Tidal
- Approvals and reviews still happen in Tidal
Uploading suits required documents more often than it suits policies. Audit reports, management reviews and network diagrams are usually produced outside Tidal and arrive as a finished PDF, whereas a policy benefits from living in the editor where it can be revised.
Using templates
Some required documents and policies come with a Tidal template: a prepared document you edit rather than a blank page.
Where templates come from:
- With a Tidal templates licence - Applicable documents arrive already filled in and sitting at "Draft", ready for you to adapt and approve. You don't write them from scratch.
- Without one - Choosing "Create with editor" opens a blank starter layout with a title page and a spot for a table of contents, which you fill yourself.
Either way the template is just content in the editor. You can rewrite any part of it, add or remove sections, and build your own heading structure — nothing about the template is fixed once it's in your document.
Templates apply to both Policies and Required Documents. A licence covers the applicable documents in both sections.
Approving a document
- Open the document by clicking its name
- Check the content in view mode
- Click "Approve" at the top of the page
- Add a version number and comment in the dialog that opens
- Confirm the action - the status becomes "Approved", its test passes, and the approval date starts the 12-month review clock
Approval works identically for required documents and policies, including approving several at once from the overview and revoking an approval afterwards.
Those flows are documented once, in Approving and managing Policies, and apply here unchanged — read "policy" as "required document" throughout.
Approved documents are read-only, which is what makes their status and history trustworthy. To change an approved document, click "Create new draft" — Tidal copies the content into a fresh draft and keeps the approved version live until you approve the new one.
Filing the next cycle
This is where required documents part ways with policies. When the next internal audit report, management review or other periodic document is ready:
- Open the required document in the Documents overview
- Add the new document - upload the file, or create it in the editor
- Approve it when it's complete
- The earlier documents stay available under the same required document
The result is a stack of documents under one obligation: the 2024 report, the 2025 report, the 2026 report, each approved on its own date.
Don't meet a new cycle by editing the previously approved document. That produces a new version of the old report — the policy pattern — and you lose the distinction between the report that covered last year and the one covering this year. An auditor asking for three years of reports needs three documents.
Keeping track of what's due
You don't have to remember the cycle. The test attached to the document does it for you.
Every required document and policy has its own test, and that test only passes while there is an approval less than a year old. Once the last approval passes the one-year mark:
- The document moves to "To Review" in the overview
- Its test starts failing
- The control the test is linked to loses effectiveness, and your compliance status shows it
That failing test is the reminder. It's the reason every required document and policy is wired to a test in the first place, and why a document that's a year out of date can't quietly stay that way.
Where to see it:
- The status filter on the overview lists everything currently at "To Review"
- The Tests page shows the failing test and which control it affects
- The document history in the side drawer shows what you filed and when
- The side drawer also shows the next review date, a year after the last approval
This only bites while the document is in scope. A required document whose test is linked to no control is out of scope, so its test doesn't count towards anything and an expired approval passes unnoticed.
Read more about this in Getting started with Required Documents.
Next steps
- Understand the scope rule in Getting started with Required Documents
- Compare with the policy lifecycle in Creating and editing policies
- Follow up on failing tests via Getting started with Tests