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.

1234

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

1234

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.

Requirement readiness

Each linked control must be final before the requirement is ready for review.

Linked controls

Control AExecuted

Control BExecuted

Control COut of scope

Requirement

Requirement

Risk management

Becomes ready when all linked controls are final.

Readiness

Ready for reviewAll linked controls are final

FulfilledOwner attests after review

A requirement cannot be fulfilled unless all linked controls are final — executed, or explicitly marked out of scope with a reason.

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.

Related pages

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