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 three 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. Pick a cadence on the category, any schedule your organization defines. 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.
• Per review — a record with a review schedule whose periodic review has fallen due (see below).

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.

Periodic review

Some records are not one-off event logs but standing registers: an interested-parties list, a context register, an inventory kept as a document. Those need to be re-validated on a schedule even though no new entry is produced. Pick a review schedule on the record, any schedule your organization defines, and devguard tracks the rest: the next review date appears on the detail page and in the Deadlines view, and the assignee is reminded when it falls due.

A review has two outcomes. If the text needs to change, edit and finalize as usual; cutting a new version counts as the review and restarts the clock. If the text is still accurate, Mark as reviewed records exactly that, without creating a new version. Anyone with Records write permission can mark a record reviewed; records have no approval gate.

Both clocks are schedules now, so it is worth being precise about which is which. They are two separate obligations, not a default and an override: the category cadence asks for the next record to be produced, the review schedule asks for this record's text to be confirmed still accurate. A record can sit on its own review schedule while its category produces entries on another, and the record's Periodic review panel names the category's cadence underneath its own so the two are never mistaken for one setting.

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.

Comments

Every record's detail view has a Comments tab for discussing it in place, so the reasoning behind a decision stays attached to the record instead of living in a chat thread nobody can find later.

Write a comment with light formatting (bold, italic, underline, lists), reply to any comment (replies cannot be nested further), and edit or delete your own. Deleting a comment that has replies leaves a placeholder so the conversation still reads in order.

Type @ to mention a colleague. They are notified in the app and by email, and can adjust how often they hear about comments under Account → Notifications.