Docs

Appearance

Governance Operating Model ​

Governance in Modulos is a continuous operating process: define scope, implement controls, collect evidence, and keep decisions reviewable as systems change.

What this is ​

Modulos governance is built on a simple idea: separate obligations from implementation.

  • Frameworks define what applies.
  • Requirements preserve the source structure and define what must be fulfilled.
  • Controls define how you fulfill requirements and enable reuse across frameworks.
  • Evidence is attached to control components so claims stay precise and traceable.
  • Reviews make status changes auditable and create durable decision records.

Where in Modulos ​

Governance work happens inside projects:

  • Project → Requirements to track obligations and fulfillment
  • Project → Controls to implement controls and manage execution
  • Project → Evidence to upload, manage, and reuse evidence items
  • Project → Assets to maintain living documentation and export it as Markdown
  • Project → Settings → Frameworks to add frameworks and manage framework versions
  • Project → Dashboard to monitor progress and export project snapshots

Who can do what ​

Permissions

  • Project Owners configure frameworks and access, resolve blockers, and can act as reviewers.
  • Editors implement controls, attach evidence, and keep work items up to date.
  • Reviewers approve or reject review requests for auditable status changes.
  • Auditors have read-only access focused on traceability and evidence.

In addition to project roles, individual items have assignees:

  • Control owner is responsible for executing the control and maintaining evidence.
  • Requirement owner is responsible for marking a requirement fulfilled once its linked controls are final.

How it works ​

Object model and traceability ​

At a high level, Modulos creates an audit trail by linking work items together:

  • frameworks → requirements
  • requirements ↔ controls
  • controls → components → evidence
  • status changes → reviews and logs → exports

The platform separates:

  • concept status (the current state of a work item)
  • review decisions (who approved a status change and why)

This keeps execution fast while still producing audit-ready traceability.

The diagram below shows the core governance objects and how traceability flows from frameworks to evidence and review decisions.

Controls: execution and approval flow ​

Controls use a simple execution model: Not executed → Executed.

How teams typically use controls:

  1. Implement: the control owner completes the control’s components and attaches evidence.
  2. Request approval: when the control is ready, the owner requests a status change and assigns one or more reviewers.
  3. Review: reviewers approve or reject the request. The decision is stored and shown in the audit trail.
  4. Locking: once a control is executed, it becomes audit-sensitive and edits are restricted to preserve integrity.

If you need to move an executed control back to not executed after related requirements are ready for review, Modulos requires an explicit reason. This preserves “why we reopened this” for auditors.

See Controls and Reviews & Statuses for the visual workflow and review mechanics.

Requirements: readiness and fulfillment flow ​

Requirements represent obligations. Their fulfillment status is Not fulfilled → Fulfilled.

What makes requirements non-obvious is that Modulos treats fulfillment as an attestation step:

  • Requirements become ready for review once all linked controls are in a final state.
  • The requirement owner then marks the requirement Fulfilled to record the decision that “this obligation is satisfied for this project scope”.

This separation keeps responsibility clear:

  • control owners implement and prove
  • requirement owners attest that the obligation is met

See Requirements for the readiness signal and fulfillment workflow.

Evidence: reuse with integrity ​

Evidence is linked to control components (sub-claims), not just the control as a whole. This enables:

  • precise traceability (“this file supports this claim”)
  • evidence reuse across multiple controls without losing context

Evidence becomes locked once it supports executed controls. This prevents “after-the-fact” changes to audit artifacts.

How to use it ​

1

Add frameworks

Select the standards and regulations that apply to the project scope

2

Assign owners

Set control and requirement owners so responsibility is clear

3

Execute controls

Fill components, attach evidence, and keep narratives current

4

Request reviews

Use reviewers to approve status changes and create decisions

5

Fulfill requirements

When requirements are ready, mark them fulfilled as the attestation step

6

Export and audit

Generate point-in-time exports once scope and status are stable

Important considerations ​

  • Treat governance as continuous. Re-run reviews and refresh evidence as systems, vendors, and data change.
  • Separate duties where possible: implementers execute controls, reviewers approve, and auditors observe.
  • Attach evidence to the smallest meaningful claim (the component), not just the control.
  • Freeze framework updates when nearing audit completion so scope does not shift.
Frameworks in Modulos

How frameworks are versioned, applied, and mapped to work

Requirements

Obligation tracking, readiness, and fulfillment workflow

Controls

Implementation units, evidence linkage, and execution workflow

Evidence

Evidence library, uploads, and reuse with integrity

Reviews & Statuses

Review requests, decisions, and audit-ready approvals

Reports & Exports

Point-in-time snapshots for audits and stakeholders