Reviews & Statuses

Statuses communicate progress. Reviews make status changes auditable.

The non-obvious part of Modulos governance is that different objects use status differently:

• controls use execution status and get approved via reviews
• requirements use fulfillment status and become “ready for review” once controls are final

For the full model, see Governance Operating Model.

The diagram below shows how status changes, review decisions, and exports connect into an audit trail.

Audit trail

A user action becomes a durable audit trail through object logs.

Action

Update control

Attach evidence

Approve review

Capture

Log entry on objectDurable

Timestamp, actor, before/after — kept on the object. This is the auditor's source of truth.

Notification to assignee

Personal queue, dismissable — moves work along but is not the audit record.

Audit trail

Comments and Logs

whowhatwhenwhyevidence

Reviews, approvals, and rejections land on the same trail. Auditors trace the thread from any object.

Notifications are personal and dismissable; logs are durable and auditable. Encourage teams to capture rationale in comments — that's what closes the loop for an auditor.

Concept-specific status

Different concepts have different status semantics:

The diagram below compares control execution and requirement fulfillment at a glance.

Controls vs requirements

Same trail, different jobs: implementation versus obligation.

Concept

Controls

Status

Not executedExecuted

Approval

Review request+Reviewer decision

Locks

Executed controls become audit-sensitive — edits restricted to preserve integrity.

Concept

Requirements

Status

Not fulfilledFulfilled

Readiness

Becomes ready when all linked controls are final.

Fulfillment

Requirement owner attests by marking fulfilled.

WhyControls are implementation units; requirements are obligations. The two statuses live side by side because they answer different audit questions.

Controls

Controls track execution state: Not executed → Executed.

In practice, teams use reviews so the change is auditable:

• the implementer requests a status change and assigns reviewers
• reviewers approve or reject
• the decision is stored and visible in the audit trail

Once a control is executed, it becomes audit-sensitive and edits are restricted to preserve integrity.

Requirements

Requirements track fulfillment state:

• Not fulfilled → Fulfilled
• optionally Out of scope or Archived

Requirements also have a separate ready for review signal. A requirement becomes ready for review once all linked controls are final, and the requirement owner can then mark it fulfilled.

Review workflow and “stale” decisions

Reviews are used to approve status changes for controls (and other reviewable objects such as assets).

A review represents a requested status change for a specific object, assigned to one or more reviewers.

In the current backend workflow:

• a review stores the old status and the requested status
• a reviewer can approve or reject
• the first decision updates the object status
• any other pending reviews for the same object are marked stale once a decision is made

This reduces ambiguity and preserves a single authoritative decision for each status change.

The diagram below shows the typical lifecycle of a review request and how “stale” decisions are handled.

Review lifecycle

A request moves the control through the lifecycle. Reviews decide. Stale requests step aside.

Draft / not executedcontrol owner is implementing

Request review

In reviewpending review requests

Approval

Executedaudit-sensitive after approval

Review decision overlay

Pending review

awaiting reviewer decision

Approved

applies status change

Rejected

keeps prior status

Stalesuperseded pending reviews — newer request takes precedence and the older one steps aside.

Cancel request — returns to prior state

Reviews record the decision; logs preserve the history. Approvals make the change audit-sensitive — reverting requires an explicit reason.

1234

Reviews happen inside the object’s Comments and Logs: reviewers approve or reject and leave rationale as part of the audit trail. UI shown in light mode.

1. 1
   Review request

   When a status change is requested, reviewers see a banner and can open the review.
2. 2
   Review comment

   Capture rationale so auditors can follow the decision later.
3. 3
   Approve or reject

   The decision applies the status change or keeps the prior status.
4. 4
   Current state

   Status and reviewer assignment provide the context for the decision record.

How people use this in practice

Control execution: implement → review → execute

Typical workflow:

1. An editor (or control owner) implements the control by completing components and attaching evidence.
2. When ready, they request a status change to executed and choose one or more reviewers.
3. Reviewers approve or reject in the control’s Comments and Logs.
4. The decision becomes part of the audit trail.

Requirement fulfillment: ready for review → fulfill

Requirements do not use review requests.

Typical workflow:

1. Controls mapped to the requirement are executed.
2. The requirement becomes ready for review.
3. The requirement owner validates that the linked controls and evidence satisfy the obligation.
4. The requirement owner marks the requirement fulfilled.

Reopening work without losing integrity

In continuous governance, things change:

• a system changes
• a vendor changes
• an incident reveals a missing control

Modulos is designed to allow reopening work while preserving the “why”:

• reopening an executed control should be deliberate and explainable
• when requirements are already ready for review, reverting controls requires an explicit reason

Related pages

Governance Operating Model

How reviews and readiness create audit-ready traceability

Controls

Request status changes and capture reviewer decisions

Requirements

How readiness and fulfillment work for obligations