Docs

Appearance

Requirements ​

Requirements represent the “what” in a framework: the obligations that come directly from the underlying regulation or standard.

What this is ​

Requirements are the compliance “contract” you are trying to satisfy for a project scope. They are:

  • framework-derived (they preserve the source document structure)
  • mapped to controls (so you implement once and reuse)
  • fulfilled deliberately (so an owner records the attestation that the obligation is satisfied)

For the end-to-end model, see Governance Operating Model.

Where in Modulos ​

  • Project → Requirements to browse obligations, filter by framework, and track fulfillment
  • Requirement detail to review mapped controls and mark the requirement fulfilled when ready

Who can do what ​

Permissions

  • Most project members can view requirements and their mapped controls.
  • Project Owners assign requirement owners and manage scope.
  • The requirement owner marks a requirement as fulfilled.
Requirement detail view showing mapped controls, executed progress, and fulfillment status.
A requirement preserves the framework obligation and shows which controls are mapped to fulfill it. UI shown in light mode.
  1. 1
    Requirement context
    The header preserves framework codes and keeps traceability to the source.
  2. 2
    Fulfillment status and owner
    Requirements track not fulfilled to fulfilled; the owner attests when it is satisfied.
  3. 3
    Mapped controls progress
    The executed controls rollup helps you see how close the obligation is to being reviewable.
  4. 4
    Mapped controls list
    Requirements link to controls so implementation work is reusable across frameworks.

How it works ​

Requirements are framework-derived ​

When you add a framework to a project, Modulos creates requirements that preserve the framework’s codes and structure. This protects traceability: auditors can see exactly which obligation a control and evidence item is intended to satisfy.

Controls implement requirements ​

Requirements do not contain implementation work. They link to controls that implement the obligation.

This enables:

  • many requirements → one reusable control
  • one requirement → multiple controls (when the obligation needs multiple measures)

Status and readiness are different ​

Requirements have a fulfillment status:

  • Not fulfilled → Fulfilled
  • optionally Out of scope for non-applicable items

They also have a separate ready for review signal.

This is the non-obvious part: in Modulos, fulfillment is an attestation step.

What “ready for review” means ​

A requirement becomes ready for review once all linked controls are in a final state (typically executed or out of scope). This is a prompt to the requirement owner:

  • review the linked controls and their evidence
  • confirm the obligation is satisfied for this project scope
  • then mark the requirement fulfilled
Requirement ready for review banner with a mark as fulfilled action and the comments and logs history.
When all linked controls are final, the requirement becomes ready for review and the owner can mark it fulfilled. UI shown in light mode.
  1. 1
    Ready for review banner
    Signals the requirement owner that all linked controls are final and it is time to attest.
  2. 2
    Mark as fulfilled
    Records the fulfillment decision as part of the audit trail.
  3. 3
    Comments and logs
    Shows why the requirement became ready and captures the rationale for the decision.
  4. 4
    Status and owner
    Fulfillment status stays explicit until the owner attests.

Marking a requirement as fulfilled ​

Only the requirement owner can mark a requirement fulfilled, and only when all linked controls are final.

This records the decision “this requirement is fulfilled” as part of the audit trail.

The diagram below shows how a requirement becomes ready for review once all linked controls are final, and how the owner attests by marking it fulfilled.

How to use it ​

1

Start from frameworks

Add the right frameworks so requirements match your audit scope

2

Assign a requirement owner

An owner is accountable for fulfillment decisions and keeps the requirement moving

3

Execute linked controls

Implement the mapped controls and attach evidence to control components

4

Review when ready

When the requirement becomes ready for review, validate evidence and rationale

5

Mark fulfilled

Record the attestation decision once all linked controls are final

Important considerations ​

  • Requirements are obligations, not tasks. Use controls to capture implementation work.
  • “Fulfilled” should be defensible with evidence. If you cannot explain it to an auditor, it is not fulfilled yet.
  • Use “Out of scope” sparingly and align it with the project scope statement so exclusions are auditable.
Governance Operating Model

How requirements connect to controls, evidence, and reviews

Frameworks in Modulos

Templates, versions, and mapping model

Controls

Where implementation work happens

Reviews & Statuses

Approval workflow for audit trails