Records

Overview

Records are the documents your organization actually produces while running its ISMS: board-meeting minutes, management reviews, submitted access requests, whistleblower reports, penetration-test results, incident write-ups.

They are a third thing alongside policies and evidence, not a variation on either. A policy is a section-structured document that maps to controls and is gated by an approver. Evidence is body-less proof attached to a control. A record is an authored, dated document that belongs to a category — free-flowing text with no section structure and no control mapping. Each record is identified by a short code such as RE-001.

Core Functionality

Every record lives in a category, which defines the kind of document it is and supplies the template, cadence, owner and linked items its records inherit. You write the body in a simplified editor that keeps headings, lists, tables, images, the / command menu and : collection references, but drops the section structure and control-mapping panel that policies need.

Records move through a simple, manually set status:

There is no approver gate: anyone with write permission can move a record through these states.

Fields Explained

Versioning

Marking a record Final snapshots its title, content and attached files into an immutable version — v1, then v2, and so on. Versions are append-only and are listed on the record's Versions tab.

Editing a record that is already final reopens it as In progress. The existing version is untouched: it remains the document that finalization committed to. Finalizing again cuts the next version, optionally with a short changelog describing what changed.

This is why the numbering is a plain integer rather than a semantic version — a record has no notion of a breaking or a patch change, only a sequence of committed states.

Files

Each record can carry file attachments — a network diagram, a signed PDF, a penetration-test report — uploaded on the record's Files tab. These are distinct from images embedded inline in the body, and distinct from linked evidence.

Attached files are captured in the version snapshot, so a finalized record records which files it was finalized with.

Linked Items

Links to controls, risks, assets, vendors and evidence are managed on the category, and every record in that category inherits them.

These are plain associations. They make a category's records discoverable from the linked item and leave an audit trail, but they never change control coverage — Records is deliberately outside the coverage engine. If you need something to count toward coverage, use evidence.

Deadlines

Records surface in Deadlines two ways:

• Per record — a record with a due date that is not yet final.
• Per category — a category with a recurring cadence, such as a six-monthly ISMS management review. The next due date is calculated from the last finalized record in that category, so a review completed late still spaces the next one a full period out.

A category with a cadence but nothing finalized yet has nothing to count from and shows no due date until its first record is finalized.

Best Practices

• Create the category first: it carries the template and cadence, so records filed into it start consistent.
• Finalize a record when it is genuinely done — that snapshot is what an auditor will read.
• Use the changelog when re-finalizing so the version history explains itself.
• Keep due dates on records that are one-off work, and cadences on categories that recur.