The board accountability gap

With DORA and NIS2, digital resilience is no longer only a technical or compliance topic. It is becoming a board-level responsibility. These regulations make leadership more directly accountable for how organizations manage cybersecurity, IT risk and operational resilience. When something goes wrong, the question is not only which system failed. It is also whether the organization had the right governance, controls and oversight in place.

At Framna, we have noticed a familiar pattern. DORA only started appearing on many agendas in the final weeks before the deadline. Not months before. Just weeks. That says something about how security is still often treated. Not as part of how the organization operates, but as something to solve when external pressure increases.

Security decisions get made early; in the design phase, before the architecture is drawn, or they get made poorly later, under pressure, when something has already gone wrong.

Least privilege is a good example. Systems and users should only have the access they need to do their job. It sounds straightforward, but it is one of the most common gaps we encounter in practice. We regularly see system connections that expose more data or functionality than the task requires; risks that are avoidable when the right questions are asked at the right time.

When ownership is unclear, the gaps show up slowly and usually at the worst possible moment. What we see in the organizations that handle this well is clearer ownership at the top rather than a more sophisticated security team. Security is a standing item in leadership discussions, not a quarterly report. And when AI is part of how products are built, which it increasingly is, human review remains a non-negotiable step before anything goes live. At Framna, that is a firm rule, not a guideline.

Security is sometimes framed as expensive, something that slows teams down or adds friction to delivery. The consequences of that thinking often become visible much later. Systems that were built quickly, without security as a design consideration, can require significant time and cost to correct. Not because the original problem was complex, but because it had time to become structural. Retrofitting security into a live product means working around decisions that were never designed to be undone.

Downtime, reputational damage, regulatory scrutiny, legal exposure and a loss of client trust that can take years to rebuild. That is what the alternative actually costs.

Policies, controls and development guidelines matter. But once a product is live, the question shifts from what you designed to what is actually happening.

In practice, that means paying attention to how integrations are being used, whether systems are behaving as expected and where usage patterns deviate from the original design. Most incidents do not announce themselves. They show up as small anomalies that only look significant in hindsight. The organizations that catch them early have invested in the infrastructure to do so.

The organizations that get this right are not waiting for the next deadline. They know what data they process, where it moves, who can access it and how their systems behave under pressure. That knowledge builds a track record that is genuinely difficult to replicate.

Everyone says they take security seriously. The organizations that get this right do not treat security as a separate workstream. They build it into how products are designed, delivered and operated.

The growing importance of cybersecurity at board level is a shift we recently explored in Het Financieele Dagblad with our AI Transformation Director, looking at how regulations such as DORA and NIS2 are moving accountability for digital resilience closer to executive leadership.