Operating Model

Testing in Modulos turns operational signals into governance-grade verification. You connect a project to trusted data sources, define tests over metrics, and link results to controls so audits reflect what is actually happening.

Continuous verification

Testing reduces governance to measurable signals you can monitor over time.

Connect

Add sources and identify the signals you want to trust

Test

Define conditions and schedules over metrics

Respond

Treat failures as drift and fix root causes

Prove

Link results to controls and preserve audit trail

Where to do what

Testing work is split between project settings and project execution.

What you want to do	Where in Modulos	Output
Configure sources that provide testing data	Project → Settings → Sources	Project sources
Create and manage tests	Project → Testing	Test library
Run a test manually	Project → Testing → select a test → Run	Test result
Review historical outcomes and details	Project → Testing → select a test → Results	Result history
Link a test to a control	Project → Testing → select a test → Linked controls	Traceability to governance

123

The Testing view summarizes outcomes and lets you create and manage tests over time. UI shown in light mode.

1. 1
   Status tabs

   Filter tests by latest outcome across all runs.
2. 2
   New Test

   Create a test that evaluates a metric condition.
3. 3
   Latest result

   See whether the most recent run passed, failed, or errored.

Who can do what

Permissions are a combination of your organization role and your project role.

Project roles

• Owner and Editor can create, update, and run tests, and manage sources.
• Reviewer and Auditor can view tests and results for assurance and audit purposes.

Organization admin access

Organization Admins typically have full administrative access across the organization, including the ability to view and edit all projects.

How testing works in Modulos

Testing is built from four objects:

• Sources: project-level service accounts used to retrieve signals.
• Metrics: named measurements, either discovered in a source or defined inside Modulos.
• Tests: one condition over one metric, with an optional schedule.
• Results: timestamped outcomes with status and details.

When a test runs, Modulos retrieves the latest available data point for the metric within a lookback window and evaluates the condition.

Tests can be linked to controls. When linked, failures become easier to operationalize:

• control owners see drift against what the control is supposed to guarantee
• reviewers and auditors can trace results to specific control statements and evidence

How to use this

1

Connect sources

Use stable service accounts and validate connections

2

Define a few high-signal tests

Start with metrics that reflect control outcomes

3

Assign ownership

Make one person responsible for investigating failures

4

Link tests to controls

Turn operational monitoring into audit-ready verification

5

Review trends regularly

Treat failures as drift and improve controls over time

Important considerations

• Testing is most valuable for continuous monitoring of a control’s effectiveness, not for writing control narratives.
• Prefer tests that are stable and hard to game: outcome metrics beat vanity metrics.
• If a test shows error, fix the data path first. If it shows failed, treat it as drift in the system or control implementation.
• Schedule times are shown in your local timezone.

Related pages

Sources

Project sources, supported types, and how secrets are handled

Tests & Schedules

Conditions, operators, schedules, and linking tests to controls

Results & Remediation

Interpret outcomes, triage failures, and build a continuous remediation loop

Project Settings

Where sources and framework settings live at the project level

Governance Operating Model

How controls, evidence, and reviews work together