Do a control once.
Covered everywhere.

Build multi-framework compliance around how your organisation actually works

An access review can support several compliance programmes. Its value, however, depends on which systems it covers, who reviewed the accounts and whether exceptions were resolved. Attaching the same spreadsheet to several questionnaires does not establish that every requirement has been met.

Multi-framework compliance brings shared work together while preserving the differences between management standards, legal obligations and assurance engagements. The practical goal is a defensible chain from requirement to control, evidence, finding and decision. That chain should help operational teams improve security, not simply make an assessment look complete.

Why use one control library?

Start with activities your organisation performs: remove access when someone leaves, test recovery procedures, assess a critical supplier. Define each control through its objective, owner, scope, operating frequency, testing method and expected evidence.

Map framework requirements onto those controls rather than creating a separate operating procedure for every framework. This keeps the implementation understandable and gives teams a common place to explain changes or investigate failures.

Shared ownership does not mean identical results everywhere. A control may work for the production environment but remain incomplete in a subsidiary. Record implementation and testing results at the appropriate level. Otherwise, a single green status can hide an important gap.

The library should also distinguish control design from operating effectiveness. A sensible procedure can exist without being followed. Conversely, a useful security practice may operate reliably but lack documented ownership or sufficient evidence.

Map requirements without claiming automatic equivalence

Framework mappings indicate where work can be reused. They do not make different obligations interchangeable. Consider what each framework asks you to demonstrate:

• ISO 27001: an information security management system based on risk assessment, risk treatment and improvement. The Statement of Applicability explains necessary controls and justifies exclusions from the Annex A reference controls.
• NIS2: cybersecurity risk management for entities within scope, including areas such as incident handling, continuity and supply chain security. Applicability requires examination of the entity and relevant national rules.
• DORA: ICT risk management and digital operational resilience for financial entities within scope, including testing, incident management and ICT third-party risk.
• GDPR: appropriate security for personal data processing. Security evidence does not establish a lawful basis, satisfy transparency duties or demonstrate that individual rights are handled properly.
• SOC 2: an examination of controls at a service organisation against the relevant Trust Services Criteria. It produces an attestation report, not an ISO-style certification.
• AI Act: applicable obligations associated with AI systems and organisational roles. Cybersecurity controls can contribute, but do not replace AI-specific assessment, documentation or human oversight where required.

For example, privileged access reviews may support security objectives across several frameworks. The same evidence cannot, by itself, demonstrate that an AI system has appropriate human oversight or that a financial entity has addressed contractual requirements for ICT suppliers.

For every mapping, record the requirement, relevant control, rationale and remaining work. Classify coverage as full or partial only after considering the actual scope. A framework label attached to a control is not a compliance conclusion.

Collect evidence that explains what happened

A policy describes intended behaviour. Operational evidence demonstrates execution. For an access review, retain the account population examined, reviewer decisions, identified exceptions and records showing that corrective changes were completed.

Each evidence item should identify:

• its source and collection date;
• the system, population and period covered;
• the person who checked its relevance;
• the control and conclusion it supports;
• access restrictions and retention expectations.

Prefer a traceable record over an isolated screenshot. Where an export is used, document its filters so reviewers can understand what was excluded. Limit personal information and avoid placing credentials or sensitive operational details in broadly accessible audit folders.

Evidence reuse also needs boundaries. A current configuration export may support a point-in-time assessment but cannot establish continuous operation over an earlier reporting period. Match evidence to the question being tested.

Turn gap analysis into an executable action plan

Assess the difference between applicable requirements, control design and observed operation. Separate missing controls, incomplete deployment, failed operation and insufficient evidence. These findings have different causes and should not receive the same corrective action.

Prioritise by risk and operational dependency, not simply by how many requirements a control maps to. A weakness affecting a critical service may deserve attention before a documentation gap linked to several frameworks.

Each action needs an accountable owner, target date, dependencies, resources and closure criteria. Replace “improve backups” with an outcome such as “complete a restoration test for the service and obtain the service owner’s acceptance of the result.” Verify that outcome before closing the finding.

Where remediation cannot happen immediately, document the interim measures and the decision about residual risk. Such a decision does not remove a binding legal obligation.

Use audits and management review for different purposes

An audit-ready record connects the requirement, control, test result, supporting evidence and corrective action. Before sharing it, check that the scope and reporting period match the assessment. Make unresolved exceptions visible rather than burying them in attachments.

Internal audits examine implementation and identify weaknesses. Management review turns findings into decisions about resources, priorities, risk treatment and improvement. Present persistent gaps, blocked actions and changes that may affect the compliance scope.

Record the decisions, their owners and the follow-up expected. A dashboard is useful when it explains where leadership intervention is needed, not merely when it displays a completion percentage.

A practical six-step implementation path

1. Set the scope. Identify entities, services, systems and data, then confirm which frameworks and obligations apply.
2. Inventory existing controls. Describe real practices, assign owners and remove duplicate descriptions without losing local differences.
3. Validate mappings. Explain how each control supports requirements and identify partial coverage or justified non-applicability.
4. Test and collect evidence. Check operation, document the assessment method and record exceptions against the relevant scope.
5. Resolve priority gaps. Assign actions, address dependencies and verify outcomes before accepting closure.
6. Review and maintain. Use audits and management review to adjust controls as services, suppliers and obligations change.

How Domyno supports the operating model

Domyno combines a SaaS platform with a dedicated human expert. Controls & compliance brings together one control library, more than 28 frameworks, evidence, action plans and the Statement of Applicability. Agents prepare work; a human validates it.

Risk, asset, supplier and documentation modules provide the surrounding operational context. More than 300 connectors, including on-premises Active Directory, offer connections to existing sources. Collected data still requires interpretation: availability of an export is not proof that a requirement has been met.

For organisations extending their programme, NIST CSF and HIPAA provide additional areas to examine against their specific scope rather than treating an existing mapping as sufficient.

To discuss your control library, evidence requirements and next assessment, request a demo.