How Tidal works

Tidal is built around a five-layer outside-in model: you start with external requirements (laws, frameworks) and translate them inward to the operational security & compliance measures your organisation actually implements. This page explains each layer and shows how the entities connect.

The outside-in approach

How Tidal works — five layers from external frameworks to operational plans

The architecture follows a top-down flow: compliance requirements from the outside world drive the controls your organisation selects, which are then applied to your specific assets and risks, monitored through tasks and tests, and kept current by plans on a recurring schedule.

Entity relationships

The diagram below shows how the core data entities in Tidal Control relate to each other.

Entity relationship diagram — how Framework, Control, Asset, Risk, Task, Test and Plan connect

Reading the diagram:

Solid arrows show direct relationships (e.g. a Plan generates Tasks; a Control applies to Assets).
Dashed arrows show optional or orchestration relationships (e.g. a Task fulfils a Control; a Risk is mitigated by Controls).

The five layers explained

Layer 1 — Frameworks & Requirements

Frameworks are the external compliance requirements your organisation must meet: ISO 27001, GDPR, NIS2, SOC 2, and more than 30 others. Each framework is structured hierarchically:

Framework (e.g. ISO 27001)
Chapter / Domain (e.g. A.5 Organisational Controls)
Requirement (e.g. A.5.1 Policies for information security)

Tidal maps all requirements from all supported frameworks to a shared control library, so activating a new framework is largely a matter of seeing which of your existing controls already cover it.

Layer 2 — Controls

Controls are the concrete operational security & compliance measures your organisation implements to satisfy framework requirements. Tidal provides pre-built control libraries across multiple domains — security & compliance, quality, AI governance, environmental, and more — each mapped across the relevant frameworks.

Two types:

Policy controls — documentation and policies (e.g. Information Security Policy, Acceptable Use Policy)
Operational / technical controls — processes and technical measures (e.g. access rights management, MFA, patch management)

Because one control can satisfy requirements from multiple frameworks simultaneously, you implement once and comply with many.

Layer 3 — Assets & Risks

Assets are the systems, services, and organisational units you want to protect: cloud platforms, SaaS applications, databases, physical locations, personnel groups, projects, departments, business units, or business processes. Each control is linked to the assets it applies to, giving compliance a concrete, organisation-specific context.

Risks are identified threats linked to assets. Tidal provides a standard risk library based on IRAM V2. Controls are mapped to the risks they mitigate, so you can trace from any risk to the controls that reduce its likelihood or impact.

Layer 4 — Tasks & Tests

This layer provides evidence that controls are actually implemented and working.

Tasks are manual work items: write a policy, run a training session, perform an internal audit. They have an owner, a due date, and can carry uploaded evidence.
Tests are automated checks: Tidal (or an integration) verifies a configuration and records a pass/fail result. Examples include checking whether MFA is enabled for all users in Microsoft 365, or whether all S3 buckets in AWS are private.

Together, tasks and tests give auditors a continuous, traceable record of compliance activity throughout the year — not just at audit time.

Layer 5 — Plans (PDCA)

Plans are recurring schedules that orchestrate when tasks are generated and tests run, implementing the Plan-Do-Check-Act cycle:

Plan-by-Control — one task is created covering all assets linked to that control.
Plan-by-Asset — a separate task is created per asset (useful for asset-specific reviews like quarterly access rights checks).

Plans automatically regenerate tasks on the configured frequency — annually, quarterly, monthly — to collect evidence for specific control and asset combinations. This ensures evidence is gathered continuously throughout the year, not just before an audit.

End-to-end example

A risk-based trace through the architecture for "unauthorised access to customer data":

Layer	Entity	Example
Frameworks	ISO 27001 A.9.2	User access management
Controls	B03	Access rights management
Assets	AWS RDS	Customer database
Risks	Risk-047	Unauthorised access to sensitive data
Tasks	Task	Quarterly access rights review
Tests	AWS test	Are all IAM users still active?
Plans	Quarterly plan	Generates review task every 3 months

When the test turns red (a stale IAM user is detected), it surfaces immediately on the control, framework, and dashboard views — giving your team a clear action item to resolve.