From compliance to control

Authors: Remco Pabst, Business Consultant, and Shannon Breuer, Chief Information & Security Officer (CISO), both working at Pegamento.

Date: May 2026

From compliance to control

1. Executive summary

The cyber incident at Odido in February 2026 shows why security can no longer be treated exclusively as an IT issue. Odido reported that personal data had been hit from a used customer contact system, even though operational services had not been disrupted and there was no indication at the time that passwords, call data or billing information had been involved. Strategically, this is relevant because an organization does not have to completely shut down to still face tough questions about access management, logging, retention periods, customer trust and managerial control.

From Pegamento, we see that the central question in the market is shifting. The focus is no longer only on whether an organization has taken security measures, but mainly on whether it can show who had access, what actions were performed, what decisions were made, which measures demonstrably work and who is responsible for what. This shift aligns with broader developments in laws and regulations. In addition to integrity and confidentiality, the AVG also has the accountability principle. Organizations must therefore not only act compliantly, but also be able to convincingly substantiate this.

This same movement is visible outside the privacy domain. NIS2 places cybersecurity more explicitly in the boardroom, with governance, risk management, notification obligations, supply-chain security and management responsibility as recurring themes. For the financial sector, DORA has applied since Jan. 17, 2025, and concretely links digital operational resilience to monitoring, testing, third-party risk and incident management. In the Netherlands, the Cyber Security Act was not yet in effect on April 20, 2026, but preparing for it is already a real organizational issue.

Organizations that take this shift seriously are investing not just in tooling, but in governable cohesion between identity, logging, off-boarding, awareness, contract agreements, incident response and management accountability. That lowers risk, increases auditability and reinforces trust with customers, partners, regulators and directors.

2. Introduction: the shift everyone feels

Every market has tipping points: moments when an incident not only has technical or legal consequences, but raises a broader management question. The incident at Odido is such a moment. Not because one case would explain the entire market, but because events like this make visible how security issues arise in customer contact environments, process chains, supporting systems and governance choices – and thus not only in firewalls, networks or endpoints.

For many organizations, this shift already feels intuitively recognizable. Clients are asking different due-diligence questions. Procurement and legal teams want more substantiation. Auditors are asking not just for policy documents, but for evidence. Regulators are looking not just at whether measures exist, but whether an organization can reconstruct its choices, risk considerations and actions.

This white paper is written from that reality. Not as a product brochure, nor as incident analysis of one brand, but as strategic interpretation of a broader development Pegamento sees in practice: organizations become vulnerable when IT, Legal and Operations each approach security in part, but no one manages the whole.

3. Why this topic is relevant now

There are three reasons why this issue is especially urgent now. The first reason is the changing threat landscape. Cyber incidents affect not only the technical environment, but often directly customer processes, data flows and chain dependencies. Good log information and a practiced incident response are therefore no longer a luxury, but preconditions for administrative grip.

The second reason is the escalating impact of incidents. The IBM Cost of a Data Breach Report 2024 reported a global average data breach damage of USD 4.88 million. In addition, 70 percent of the organizations surveyed reported that their operations were significantly or at least noticeably disrupted. This underscores that cyber incidents are not just security problems, but business operations problems.

The third reason is the administrative and legal aggravation of the issue. NIS2 raises the European bar for cybersecurity in critical and important sectors and makes it clear that administrators and senior management cannot remain aloof. For the financial sector, this reality already applies concretely through DORA. The implication is clear: security is increasingly being judged on demonstrable mastery, not just technical intent.

4. Background and market context

For years, security was translated primarily into technology. Firewalls, endpoint protection, SIEM, IAM, segmentation, monitoring, patching and cloud hardening were all necessary, but rarely sufficient. This technical focus was explicable at a time when the dominant question was: can we prevent attacks or detect them faster?

Today, the bar has been raised. The question is no longer simply whether an organization has measures in place, but whether it can demonstrate their operation in conjunction with processes, responsibilities and decision-making. Accountability is thus not a semantic addition, but a fundamental change in the way organizations are judged.

In addition, digital chains have become more complex. Identities run through central identity providers and through local exceptions. Applications access data through APIs. Employees work hybrid. Suppliers manage parts of the stack. Customer contact platforms are connected to CRM, ticketing, analytics and knowledge bases. This creates risk not only in “the infrastructure,” but precisely in the transition between systems, roles, rights, management processes and contractual responsibilities.

5. What organizations often think security is and why that’s no longer enough

Many organizations still think of security primarily in terms of technology, tooling, certification and checkoff compliance. This easily leads to an appearance of maturity. There is an IAM solution, so access is regulated. There is logging, so reconstruction is possible. There is awareness training, so the people factor is covered. There is policy, so governance exists.

Practice shows a different picture. A central identity solution can coexist perfectly well with local exception accounts in applications. On paper, least privilege is set up, but in practice access persists after role changes or departures. Or there is logging on multiple layers, but the events are not correlated, timestamps are not harmonized and ownership for analysis is missing. Then there is data, but no evidence yet.

The difference between “having measures” and “having control” is almost always in consistency. Security often fails not because of lack of a tool, but because of lack of ownership, lifecycle management, review and explainability.

6. What customers, regulators and stakeholders really want to know today

The questions Pegamento sees in customer processes, audits and due diligence processes are rarely phrased in purely technical terms anymore. They usually revolve around control, demonstrability and accountability.

• Who has access to what data, on what basis and through what mechanism?
• Can you reconstruct which user performed which action, at what time and in which system?
• How are onboarding, job change and off-boarding set up, and what controls are in place for them?
• Who owns process, system, risk assessment and exception?
• How does the organization ensure safe behavior, reporting culture and escalation capability?

These questions are strategically relevant because they all test the same thing: not whether an organization is theoretically secure, but whether it can explain its security managerially and operationally. That is the real difference between a technical security approach and a mature organizational approach.

7. Where things go wrong in practice

7.1 Logging without context

Logging is essential, but logging without context provides a false sense of security. In many organizations, log data exists, but the connection between application, API, platform and identity is missing. This creates fragments of truth rather than a single manageable factual picture.

A useful logging strategy therefore does not start with “log more,” but with three design questions: what decisions or actions should we be able to reconstruct later, what sources are needed to do so, and who is responsible for quality, correlation, retention and interpretation?

7.2 Off-boarding as a weak link

Off-boarding is still too often seen as an HR afterthought rather than a security moment. That’s risky. The weakness is rarely just in the primary account, but rather in local applications, group memberships, tokens, administrator roles, API keys, mobile access and exception rights.

Organizations that approach off-boarding maturely make departure not a loose checklist at the end of a process, but a controlled chain with trigger, execution, verification and demonstrable closure.

7.3 Fragmented responsibility

Many organizations have expertise, but lack end-to-end ownership. IT manages systems. Legal sets requirements. Operations manages processes. HR processes personnel changes. Security monitors frameworks. But who is responsible for the demonstrable operation of the whole?

Exactly in that in-between space arise the questions on which audits, incidents and customer investigations get bogged down: who decided that an exception was acceptable, who verified that an account was actually closed, and who monitors the relationship between contract agreements, logging, retention periods and access?

7.4 Awareness as a one-time action

Awareness is necessary, but annual training does not make an organization resilient. Employees must not only recognize risks, but also know what to do when in doubt. Awareness only really works when it becomes part of process design: clear verification steps, recognizable communication, simple reporting routes, limited authority and consistent leadership.

8. The legal perspective: from compliance to accountability

From a legal perspective, the key shift is that being compliant on paper is no longer enough. Organizations must be able to show why their setup is appropriate, how measures were chosen, how exceptions are controlled and how actual operation matches what is described in policies, contracts and procedures.

That makes accountability a practical organizational principle. It is not just about privacy documentation, but directly about architecture, access management, logging, retention periods, incident logging, vendor steering and decision-making. The legal risks of weak demonstrability are broader than fines alone. They also touch reputation, contractual relationships, evidentiary position and managerial credibility.

This is precisely why the focus is shifting from “being compliant” to “being demonstrably compliant. Organizations must not only be secure, but be able to explain and prove that their measures are appropriate, current and governable.

9. The practice perspective: what security really looks like in systems, processes and chains

In theory, security sounds uncluttered. In practice, it is layered. A user action rarely touches a single system. An employee logs in through an identity provider, uses a customer contact application, accesses data through an API and leaves traces in monitoring, ticketing and management environments. If those sources don’t come together logically, a reconstruction problem arises.

The same is true for access management. The main identity may sit centrally, but rights also live in groups, application roles, local exceptions, vendor accounts, service identities and emergency accesses. As a result, “we have SSO” is not proof of control; at most, it is a part of it.

Procedurally, the reality is equally unruly. A role change in HR does not automatically mean that rights are adjusted in all chains. A supplier can perform management while the client remains legally responsible. A temporary exception can become structural. A project may demand speed, causing governance to be treated as a closing item. Thought leadership therefore does not start with denying trade-offs, but with making them governable.

10. Analysis: risks, bottlenecks and misunderstandings

The biggest misconception in the market is that security fails primarily because of too little technology. Much more often security fails because of lack of coherence. Logging is confused with proof. Compliance is confused with documentation. Awareness is confused with assurance. Governance is confused with designating one responsible function with no mandate over the whole.

A second misconception is that existing systems are obviously out of scope because they are legacy. In reality, legacy environments often actually increase the tension between speed, risk and demonstrability. Legacy systems do not require tolerance, but an explicit managerial consideration: mitigate, isolate, replace or phase out.

A third misconception is that security ownership can, in practice, be placed entirely with IT. Legislation, customer demands and regulatory requirements show that this is not tenable. Cyber resilience touches governance, compliance, operations, procurement and supplier management equally.

11. Analysis: opportunities, strategic options and organizational value

The positive flip side is that the same development also offers opportunities. Organizations that can demonstrate security not only strengthen their resilience, but also their market position. Clients, partners and auditors experience demonstrable control as a sign of maturity and reliability.

In addition, a mature security approach can increase operational agility. When identity lifecycle, logging, exception management and governance are well established, changes can occur faster and more securely. Security then becomes not a brake on innovation, but a condition for controlled acceleration.

Finally, the quality of decision-making increases. Those with visibility into access, chains, critical processes and third-party dependencies make better choices about sourcing, platform selection, retention, monitoring, contracting and crisis response. This is precisely why modern regulation places so much emphasis on resilience and managerial grip.

12. Practical applications and use cases

Use case 1 – customer contact platform under due diligence

An organization uses multiple systems for customer contact, CRM and knowledge management. After a market incident, a large customer asks additional questions. Not about firewalls or certificates, but about access, logging, vendor roles, processor agreements and off-boarding.

The organization with a mature model can show within a short time what roles exist, how access is granted, what administrator actions are logged, what exceptions exist, how long log data remains available, and what governance applies to role changes or departures. The organization without consistency is stuck with loose exports, policy documents and assumptions.

Use case 2 – employee leaves with broad operational access

Upon unexpected departure, a mature organization is not just disabling the primary account, but the entire identity lifecycle: SSO, local applications, administrator roles, group memberships, tokens, shared credentials, mobile access and physical access. The difference is in process discipline, automation and authentication.

Use case 3 – incident analysis without administrative confusion

When suspicious access to sensitive data is discovered, layered logging combined with clear team roles makes it possible to quickly determine which accounts were involved, which systems were affected, which notification pathways need to be activated and which communications are actually justified. Without that preparation, the exact opposite occurs: technical teams investigate, legal waits to be sure, operations wants to move on and management wants answers without a shared factual picture.

13. Pegamento vision: what organizations need to understand and do now

Pegamento’s vision is that organizations must redefine security. Not as a collection of tools, but as manageable cohesion between identities, rights, processes, logging, decision-making and chain responsibility.

• Shift from perimeter thinking to identity thinking. Those who control access, control risk – provided exceptions and lifecycle processes are in scope.
• Shift from logging as a technique to logging as evidence. Log only what can be interpreted, correlated and used later.
• Shift from compliance on paper to accountability in practice. Documentation is credible only when it matches actual system behavior and process execution.
• Shift from awareness as a campaign to awareness as a design principle. Build verification, reporting culture and safe defaults into processes.
• Shift from implicit collaboration to explicit ownership. IT, Legal and Operations should work together, but with clear mandate and governance.
• Shift from project-based improvements to structural governance. Resilience is not a temporary program but an ongoing governance task.

For organizations that want to act now, the most important practical question is not which tool to purchase first, but what evidence will be needed tomorrow to explain to the customer, auditor, regulator or board how the organization maintains control.

14. Conclusion

The lesson “after Odido” is not that organizations especially need more loose security measures. The real lesson is that modern security hinges on verifiable consistency.

Organizations get stuck when IT secures systems, establishes Legal frameworks and executes Operations processes, but no one is integrally responsible for demonstrable operation. Then the familiar gaps emerge: logging without usability, permissions without lifecycle, awareness without behavior, policy without proof and governance without ownership.

15. Sources and factual support

Incident context and current events

Odido – Cyber incident information page (2026). Used for factual information about the cyber incident, reference to a customer contact system and public indication that operational services had not been affected.

Odido Newsroom – Odido informs customers of cyber attack (Feb. 12, 2026). Used as primary source for initial public interpretation of incident.

Privacy, accountability and demonstrability

European Commission – Data protection explained. Used for AVG principles, including integrity, confidentiality and accountability.

European Data Protection Board – Accountability Tools. Used to explain that organizations must take appropriate technical and organizational measures and be able to demonstrate that processing is compliant.

European Data Protection Board – Data protection by design & by default: When to act and what to do (February 2026). Used for the ongoing duty to take appropriate action and focus on existing or obsolete systems.

Cyber regulation, governance and governance

European Commission – NIS2 Directive: securing network and information systems (Jan. 20, 2026). Used for scope, governance and management responsibility.

Digital Government – Cyber security law (March 5, 2026) and House of Representatives approves Cbw and Wwke (April 15, 2026). Used for Dutch status and expected implementation of the Cybersecurity Act.

De Nederlandsche Bank – DORA. Used for application date, content and supervisory dimension of DORA.

Logging, incident response and operational control

NCSC – The value of log information. Used for the need for log information to reconstruct events and user actions.

NCSC – Incident response plan, Incident response: where do I start? and Keep a grip on a cyber incident: use the Cyber Incident Log. Used for team roles, preparation and structured incident logging.

NIST – SP 800-92 Guide to Computer Security Log Management. Used as an authoritative source for log management as an enterprise-wide discipline.

Identity, awareness and operational discipline

idmanagement.gov – Identity Lifecycle Management Playbook. Used for provisioning, change management and immediate withdrawal of access on exit.

NIST – SP 800-53 Revision 5.1, AC-2 Account Management. Used for account management in relation to personnel termination, inactivity and auditing.

NCSC – Security awareness and related phishing/social engineering pages. Used for human factor, reporting behavior and securing cyber awareness.

Impact and business operations

IBM / Ponemon Institute – Cost of a Data Breach Report 2024 and IBM summary. Used for average global damage from a data breach and reported operational disruption.

16. Assumptions, limitations and concerns

The content of this white paper is time-sensitive with respect to the status of the Odido incident, public information about it, and the progress of any follow-up investigation. New facts or technical findings may change the interpretation.

The status of the Dutch Cyber Security Act is also time-sensitive. As of April 20, 2026, the law was not yet in force. Final obligations, further elaboration and implementation dates may change due to parliamentary consideration and lower regulations.

Some of the conclusions in this white paper depend on context, sector and architecture. Organizations in the financial sector are already dealing with DORA; other organizations will be assessed more heavily on AVG, contractual requirements, NIS2/Cybersecurity Act or industry-specific standards.

Finally, this document is a strategic and editorial white paper, not an individual legal advice or technical security audit. Where industry-specific interpretation or concrete compliance review is required, further assessment on an organization-by-organization basis remains necessary.