Most compliance tools organise work by framework: one list for ISO 27001, another for the GDPR, and another for NIS2. The result is work being duplicated three times over and evidence scattered across different systems. iComply turns this model on its head: it organises by control, and the frameworks are then viewed in relation to those same controls.

The data model

Four objects and the relationships between them underpin everything else:

Requirement — a specific clause in a standard or law (e.g. ISO 27001 A.5.17, GDPR Art. 32, NIS2 Art. 21).
Controlo — a medida operacional que a organização implementa (ex. “MFA imposta em todos os acessos remotos”).
Risk — what controls mitigate, including probability, impact and risk appetite.
Evidence — documentary proof that the control is working.

The relationships are many-to-many: one control meets several requirements, one requirement may call for several controls, and one piece of evidence may support several controls. It is this topology that eliminates duplication.

A concrete example

Consider the ‘Mandatory multi-factor authentication’ control. Once implemented and with supporting evidence attached, it simultaneously satisfies:

ISO 27001 — A.5.17 (authentication information)
NIS2 — Article 21 (risk management measures)
DORA — ICT risk management requirements
SOC 2 — CC6.1 (logical access controls)
GDPR — Article 32 (security of processing)
CIS Controls — Control 6 (access management)

With a framework-based tool, you’d have to answer the same question six times and upload the same evidence six times. Here, you only have to answer it once.

States of a control

Each control has a status that feeds directly into the dashboard and reports:

Not started — identified but not yet working.
Under implementation — work in progress, with a designated person and a deadline.
Implemented — operational, with valid supporting evidence attached.
Under review — has reached the review milestone and is awaiting validation.
Non-compliant — failed a test or audit; automatically triggers a CAPA action.
Not applicable — outside the scope, with justification recorded for the auditor.

How to map a control

Open Controlos → Biblioteca and select the control.
On the ‘Mapping’ tab, view the requirements already mapped by the frameworks’ official libraries.
Add manual mappings where your specific circumstances require it — for example, a requirement under national legislation.
Rate the strength of the mapping: fully satisfies, partially satisfies, or contributes. A requirement that is only partially satisfied will continue to appear as incomplete until it is covered by another control.

You don’t need to start this work from scratch. iComply provides pre-built mappings between the supported frameworks; your job is to validate and supplement them.

Customised controls

In addition to the official libraries, you can create your own controls — whether to meet a client’s contractual requirements, comply with internal policy or adhere to sector-specific legislation. A custom control behaves exactly like any other: it accepts evidence, is included in audits and can be mapped to requirements.

Recommendation: before creating a new control, check whether one already exists that covers the same measure. Libraries bloated with near-duplicate controls are the main reason why governance programmes become impossible to maintain.

Linking controls to risks

In Risco → Registo, match each risk with the controls that mitigate it. This has two important effects:

Calculated residual risk — the inherent risk is reduced on the basis of the effectiveness of the associated controls, rather than being estimated manually.
Automatic prioritisation — when a control fails, the risks that depend on it are immediately flagged, showing where to take action first.

Frequencies and continuous guarantee

A one-off check is like a snapshot; when carried out regularly, it is a vital indicator. Set the review frequency according to the level of criticality — monthly for privileged access, annually for a top-level policy. When the date arrives, the platform notifies the person in charge, the status changes to ‘Under review’ and the dashboard reflects this.

It is this mechanism that replaces the frantic rush in the weeks leading up to the audit with a stable working routine.

Best practice

One check, one measurement. If the description of the control contains ‘and’ several times, there are probably two controls.
Set out operational controls, not aspirational ones. “MFA required for all remote access” is auditable; “strengthen access security” is not.
Always appoint a specific person to be responsible. Controls with no owner are not executed.
Do not force mappings. Marking a requirement as satisfied when the control only partially addresses it creates a false sense of security and is detected during an audit.
Review the library once a year. Remove any duplications and controls that are no longer applicable.