How do you turn compliance management into demonstrable control?

How to translate requirements from laws, standards and contracts into one working whole

Compliance management has a dusty reputation among many professionals. It conjures up images of ticking off lists, collecting evidence and keeping the auditor happy. That image sells the discipline short. Well-designed compliance management is the process that translates external and internal requirements into concrete controls, and then makes it demonstrable that those controls work. The difference between an organisation that scrambles to assemble evidence in a panic every year and an organisation that passes audits as a matter of routine lies almost entirely in this process. This article explains how to set up compliance management for information security and privacy, and how to fold the AI Act into it from the start.

In short

• Compliance management translates requirements from legislation, standards, contracts and internal policy into controls, and makes their operation demonstrable.
• Compliant is not the same as secure: compliance is rule-driven, security is risk-driven, and the two processes must feed each other.
• The process has five steps: requirements register, applicability analysis, translation into controls, monitoring and measuring, and reporting and adjusting.
• One shared set of controls serving all frameworks prevents doing the same work three times.
• The compliance process coincides with the four phases of the Kantyra model: detect, assess, resolve and demonstrate.

Compliant is not the same as secure

A warning is needed first: compliance and security overlap strongly, but they do not coincide. Compliance is rule-driven, because you satisfy a requirement someone else has formulated. Security is risk-driven, because you manage a threat that is relevant to your organisation. An organisation can meet every formal requirement and still be vulnerable, for instance because the requirements lag behind the threat landscape or because controls exist on paper but do not work in practice. Conversely, a well-secured organisation can still have a compliance problem, because it cannot demonstrate its own level of control.

The practical conclusion is that compliance management should never take the place of risk management, but that both processes should feed each other. Legal requirements form the floor and the framework, while the risk analysis determines what your organisation needs on top of that.

The playing field and the requirements coming your way

For information security and privacy, requirements arrive from four directions. The first source is legislation. The GDPR governs the processing of personal data and applies to virtually every organisation. The Cyber Security Act (Cbw), the Dutch implementation of the European NIS2 directive, imposes a duty of care, a reporting duty and a registration duty on organisations in essential and important sectors, with explicit responsibility for the board. For the financial sector, DORA is added, and sectors such as healthcare and government have their own frameworks, such as NEN 7510 and the BIO.

The second source is standards you embrace voluntarily or contractually, with ISO 27001 as the best-known example. Formally, certification is not a legal obligation, but as soon as customers ask for it or you promise it in contracts, the effect is the same. The third source is the contracts themselves, such as data processing agreements, security annexes to procurement contracts and connection conditions of chain partners. The fourth source is internal policy, because your own policy rules are also requirements you must demonstrably meet.

And then there is the AI Act, the European regulation on artificial intelligence, which is entering into force in stages. For most organisations its impact is still limited, but not zero. The obligation to ensure sufficient AI literacy among staff already applies, and anyone deploying AI systems must know which risk category they fall into. The lesson from twenty years of privacy legislation is that you should not pick up such regulations only when the final deadline approaches. Include AI systems in your processing register and your asset overview now, and the AI Act will later grow into your existing compliance process instead of becoming a separate track. In Kantyra this has its own place: the AI module contains an AI register in which every system carries its role, risk category and human oversight, linked to the supplier, the asset and the processing activity.

The compliance process in five steps

Compliance management is a cyclical process, not an annual event. At its core it consists of five steps.

The first step is the requirements register. Bring all relevant laws and regulations, standards, contracts and policy documents together in one register, with the owner, the applicability and the main obligations per source. This register is the foundation of everything that follows. Many organisations skip this step and work framework by framework, and that is exactly where duplicated work and blind spots arise. In Kantyra, the compliance register is that single place: the frameworks for the Cbw (NIS2), the GDPR, ISO 27701, the AI Act and ISO/IEC 42001 are built in, and you add your own frameworks, such as contract requirements, NEN 7510 or internal policy, by hand or by importing them from Excel, after which they run along in the same register. Every requirement carries a status, an owner and an explanation.

The second step is the applicability analysis. Not every requirement applies to every organisation or every system. Under the Cbw, the first question is whether your organisation falls under the act at all, and if so, whether as an essential or an important entity. Under the GDPR, your role as controller or processor determines which obligations rest on you. Under the AI Act, the risk category of a system determines the regime. Record these analyses including their justification, because even the decision that something does not apply must be accountable later. In Kantyra you mark a requirement as not applicable with an explanation attached, and for the Cbw question itself the platform contains a self-assessment that walks through the duty of care, the reporting duty and the registration duty. For AI systems there is a dedicated risk classification, which tests each system for prohibited practices, high risk and transparency obligations.

The third step is the translation into controls. This is where the real work happens, because every applicable requirement is linked to one or more concrete controls, with an owner and an implementation status. The smartest approach is a shared controls framework. The GDPR asks for appropriate technical and organisational measures, the Cbw for risk management measures and ISO 27001 for the controls from Annex A, and those three collections overlap for the most part. Whoever maintains one set of controls and links every control to all the frameworks it covers demonstrates compliance with a single piece of evidence towards several regulators and auditors. Whoever keeps a separate list per framework does the same work three times. Kantyra is built exactly this way: you link one control simultaneously to requirements from several frameworks and to the Annex A controls of ISO 27001, so that the shared framework is the standard way of working rather than an ambition.

The fourth step is monitoring and measuring. A control you have implemented but never test slackens unnoticed. Determine per control how you establish that it works, for instance through automated checks, samples, internal audits or management reports. Record the evidence at the moment it arises and not afterwards; demonstrability is a property of your daily processes, and whoever organises it afterwards as an archiving project is too late. In Kantyra, the evidence therefore attaches directly to the object itself: you link evidence items (a file or a reference) to a requirement, a control or a finding, and every control has an effectiveness test with a planned date that returns as a task when it approaches.

The fifth step is reporting and adjusting. Deviations get an owner, a remediation deadline and, where necessary, a formally accepted residual risk. The aggregated picture goes to the executive board periodically, which under the Cbw is itself responsible for supervising risk management and must actively keep itself informed about risks, measures and incidents. Changes in laws and regulations feed the requirements register, and with that the cycle starts again. In Kantyra, deviations land in the findings register, with source, severity, handler and deadline (audit reports can be imported in one go), a formally accepted residual risk runs through the exception register with four-eyes approval, and the compliance register shows the progress per framework.

Roles and responsibilities

Compliance management touches several functions, and that is precisely why it needs a clear division of roles. The line is and remains owner of compliance within its own process, just as the line owns the risks. The compliance function, the CISO and the central privacy officer together form the second line. They translate requirements, review compliance and advise, but do not take over the responsibility. The data protection officer additionally holds a legally anchored, independent supervisory role on GDPR compliance. Internal audit forms the third line and provides independent assurance over the whole.

In smaller organisations these roles partly coincide in one person. That is workable, as long as the organisation stays aware of the different hats. Whoever designs the controls cannot also be the only one who judges whether they work.

Where does compliance management sit in the Kantyra model?

Like risk management, compliance management cannot be captured in a single phase of the Kantyra model: it is the cycle of the model, applied to requirements instead of risks. The five steps divide across the four phases as follows.

The requirements register and the applicability analysis are the assess phase: you determine which frameworks and requirements apply to you and where you stand, for instance with the Cbw self-assessment. The translation into controls is the resolve phase: one set of controls covering all frameworks. Monitoring and measuring is the detect phase: effectiveness tests, deviations and new laws and regulations feed the register. And the reporting and the evidence form the demonstrate phase: the evidence per requirement and per control, the progress per framework and the picture for the board and the auditor.

Where risk management moves through the cycle with the question "what could go wrong", compliance management does so with the question "what must we comply with, and can we show it". Both processes share the same registers, the same controls and the same rhythm, and that is exactly why they belong in one environment.

Connecting to other processes

Like risk management, compliance management only functions when it is connected to the processes around it.

The most important connection is with risk management itself. Legal requirements form the floor of your risk treatment, because a risk that touches a legal obligation cannot simply be accepted. Conversely, the risk analysis provides the justification for filling in open standards. Where the law asks for "appropriate measures", your risk analysis determines what is appropriate in your context.

The second connection is the incident process, because the reporting duties stack up. You report a data breach to the Dutch Data Protection Authority within 72 hours, you report a significant incident under the Cbw with an early warning within 24 hours to the designated regulator, and contracts often carry their own notification deadlines towards customers. The incident process must know those routes and document the considerations, including when you decide that reporting is not necessary. In Kantyra you record per incident whether it concerns a data breach and whether it was reported, and the register guards the Cbw deadlines for the early warning, the notification and the final report. In the considerations field, you also record why you did or did not report.

The third connection is supplier management, because many compliance requirements carry through into the chain. Think of data processing agreements under the GDPR, supply chain security requirements under the Cbw and, before long, transparency requirements towards providers of AI systems. Procurement and contract management are thereby execution channels of your compliance process.

The fourth connection is awareness and training, because several frameworks set explicit requirements here. The Cbw makes training mandatory for the board, the GDPR assumes that employees know how to handle personal data, and the AI Act requires AI literacy of everyone who works with AI systems. A joint training programme that combines these requirements is more efficient and more credible than three separate mandatory modules.

Frequently asked questions about compliance management

What is the difference between compliance and security? Compliance is rule-driven: you satisfy requirements others have formulated. Security is risk-driven: you manage the threats that are relevant to your organisation. An organisation can be compliant and still vulnerable, or well secured and still unable to prove it. You need both processes, and they must feed each other.

What is a requirements register? One register in which all sources of requirements come together: laws and regulations, standards, contracts and internal policy, with the applicability and the main obligations per source. It prevents every framework getting its own list, with duplicated work and blind spots as a result.

Do I have to maintain separate controls for each framework? No, quite the opposite. The GDPR, the Cbw and ISO 27001 largely ask for the same controls. Maintain one set of controls and link every control to all the frameworks it covers; then a single piece of evidence demonstrates compliance towards several regulators and auditors.

What should I already be doing for the AI Act? Ensure AI literacy among employees who work with AI systems, because that obligation already applies. Also map which AI systems you use and which risk category they fall into, and include them in your processing register and your asset overview. The rest of the regulation will then grow into your existing process.

How do I avoid panic before an audit? By recording evidence at the moment it arises, attached to the requirement or the control it belongs to, and by continuously testing that controls work. Whoever does that never has to reconstruct anything for an audit.

In closing

Compliance management becomes manageable the moment you stop thinking in separate frameworks and start thinking in one requirements register, one set of controls and one evidence administration. The GDPR, the Cbw, ISO 27001 and before long the AI Act each ask their own questions, but the answer comes from the same set of controls. Whoever has that set in order and continuously records that it works never has to reconstruct anything for any audit or regulator. Whoever works this way no longer needs to organise demonstrability as a project: it arises by itself, every day.

Getting started with compliance management in Kantyra

Would you rather not manage your frameworks, requirements, controls and evidence in separate lists, but in one environment that connects to your risk management? In Kantyra's GRC platform you manage the compliance register with built-in and custom frameworks, link one set of controls to everything it covers, and attach the evidence to the requirement or the control itself. Request a demo and discover how demonstrability arises naturally from your daily work.

Kantyra is a Dutch ISMS and GRC platform that lets organisations manage their information security, risk management and continuity demonstrably, in line with ISO 27001, ISO 22301 and the Dutch Cyber Security Act.