Compliance control catalog

What a control catalog is

A control is one specific safeguard you have committed to operate - "access to production is granted per person and reviewed every quarter", "backups are restored and tested twice a year". Frameworks such as ISO/IEC 27001 (Annex A) and SOC 2 (the Trust Services Criteria, for example CC6.1) are essentially long lists of controls plus the requirement that you can show, over time, that each one is in place and still working. That last part is called attestation: a named person states, on a date, that the control is operating as described.

The compliance control catalog is where orboto keeps that list and that history. Added in v0.212.0 You catalog the controls you care about, assign each an owner and a cadence (how often it must be re-confirmed), and orboto reminds the owner when an attestation is due. When an auditor or a customer's security team asks "show me who confirmed control X, and when", you export the answer instead of reconstructing it.

It sits on Admin -> Governance, as the compliance controls card, next to decision records, the risk register and on-call and escalations. It is an Enterprise feature; see the governance overview for how it behaves on other editions.

No framework is preloaded

orboto does not ship ISO 27001, SOC 2 or any other framework's control list, and it does not check your controls against a standard. The catalog starts empty and holds exactly what you enter. The framework field is free text: ISO 27001, SOC 2, BSI C5, or an internal label like Company policy. The add form pre-fills ISO 27001 as a convenience; overwrite it as needed. If the field is left empty, the framework is stored as custom.

You decide which controls belong in the catalog. Copy the reference and title from the standard you are working with, and describe how your organization implements it in the description.

The fields of a control

The add form on the card takes framework, ref, title and cadence. Owner, description, status and evidence links are set through the API (PATCH /admin/governance/controls/{id}).

Attestation cadence and reminders

Each control has a next attestation due date: the creation date plus the cadence, and after every attestation the attestation date plus the cadence. Changing a control's cadence recalculates the date from the last attestation (or from now when there is none yet).

The list is sorted soonest-due first, so it reads as a work queue. A control whose date has passed shows Attestation overdue in red; otherwise it shows Attest by with the date.

Once a day orboto scans active controls that are due or overdue and sends a Control attestation due notification to the owner, or to every super-admin when the control has no owner. A control is reminded at most once per 24 hours, and the reminder state is cleared by the next attestation. Retired controls are skipped.

Attesting a control

An attestation is a signed-off statement with a decision:

• Compliant - the control operated as described.
• Non-compliant - it did not; the statement says what went wrong.
• Not applicable - the control does not apply in the period.

On the card, Attest compliant and Non-compliant each ask for a statement ("what you are confirming"). The Not applicable decision, an evidence note (up to 5,000 characters) and an optional review period (start and end) are available through the API (POST /admin/governance/controls/{id}/attest). Statements are required and limited to 5,000 characters.

Recording an attestation does three things: it appends a new attestation row with your identity and the time, it moves the control's last-attested and next-due dates forward, and it writes a compliance_control.attested entry to the audit log.

Attestations are append-only

There is no way to edit or delete a single attestation. A correction is a new attestation that supersedes the earlier one, and both stay visible: click History on a control to see every attestation, newest first, with the decision, statement, who and when. This is what makes the trail usable as evidence, the same pattern as sign-offs on decision records.

Deleting a control removes the control together with its attestations, so it is reserved for entries created by mistake. To stop attesting a control you no longer operate, set its status to retired instead: the history stays and the control leaves the default list (GET /admin/governance/controls?all=true includes retired ones).

A worked example

ACME wants to show that access to its systems is reviewed regularly. The security lead adds two controls:

1. Framework ISO 27001, ref 5.15, title "Access control", cadence 90 days. The description says access is granted per person, by role, and reviewed quarterly by the CTO.
2. Framework SOC 2, ref CC6.1, title "Logical access security", cadence 90 days, with an evidence link of type doc pointing to the access review procedure.

Both controls get the CTO as owner through the API. Ninety days later the CTO receives a Control attestation due notification, runs the access review, opens the governance page and clicks Attest compliant on each control with the statement "Q3 access review completed, 2 accounts removed, no exceptions." Both controls roll forward another 90 days. When ACME's customer asks for evidence, the security lead exports the catalog and hands over one file listing both controls with every attestation.

Exporting the catalog

The Export button on the card downloads compliance-controls-export.json: every control, retired ones included, each with its complete attestation list, and a generation timestamp. Exporting is itself recorded in the audit log (compliance_control.export). Auditors see the same data on the card without exporting.

Permissions

Splitting write and attest lets you separate the person who defines a control from the person who confirms it operates. Every mutation - create, update, delete, attest, export - is written to the audit log with the actor.