Skip to main content

Segregation of duties

This page explains how Better Comply makes sure the person who creates a regulated record cannot also be the one who approves it, and that this is enforced by the server rather than by hiding a button.

Who this is for

Quality and compliance owners, auditors, and administrators. Quality Admins meet this control in the Quality Review Queue.

Why it matters​

A control record is only credible if more than one person stood behind it. If the author of a training could also approve it, a single person could push unreviewed content live. Segregation of duties (sometimes "separation of duties") is the principle that creation and approval are different responsibilities held by different people. It underpins ISO 9001 §7.5.3 change control and the 21 CFR Part 11 expectation that a signed approval is a meaningful, independent act.

How it works for training versions​

When someone authors a training version, it lands in pending review. It is not active and is not live to learners. A reviewer then approves and activates it from the Quality Review Queue.

The creator cannot be the approver

The approval route refuses the request when the approver is the same person who created the version. The server returns a segregation-of-duties error; it does not quietly accept the approval. The user interface also disables the Approve and Reject buttons on your own version, but that is only a courtesy. The real guarantee is the server-side check, so the rule holds even if the button is bypassed.

Approval is gated by more than identity. To approve a version, the reviewer must:

  • Be a Quality Admin or Corporate Admin.
  • Supply a change reason of at least 10 characters.
  • Confirm the version cites at least one source.

The approval emits fail-loud approve_content and activate_version audit entries. The prior active version stays in force until this approval completes, so there is never a gap. See Evidence and immutability for why the prior version cannot be edited in the meantime.

A note on what was closed​

An older path let manually-authored versions self-approve and go active in one step on the client. That hole was removed. Every content-bearing version - whether drafted with AI assistance or written by hand - now lands pending review and is approved by a different person.

How it works for controlled documents​

The controlled-document lifecycle separates the same way. Submitting a document for review, approving it, making it effective, and obsoleting it are distinct lifecycle actions, each gated by the caller's role. The approval is an electronic signature recorded server-side. The person who submits a document for review is not, by the design of the workflow, the person who signs its approval.

Each lifecycle transition is a fail-loud audit action, and the approval signature is immutable once written. See Electronic signatures.

Defense in depth​

Segregation of duties is enforced at two layers:

  1. The server route rejects a same-person approval and re-checks the approver's role.
  2. Row Level Security in the database scopes who can see and act on review tasks at all.

The user-interface guards (disabled buttons, filtered queues) sit on top of these. An auditor can rely on the lower two layers regardless of the UI.

What to tell an auditor​

  • An author's own training version cannot be approved by the author; the server refuses it.
  • Approval requires a Quality or Corporate Admin, a change reason, and at least one cited source.
  • The same separation governs the controlled-document lifecycle.
  • The check is server-side, with RLS underneath, not a hidden button.