IT Regulation: Balancing Security and Cost
When the DORA Regulation was published, my colleagues Christian, Roman, and Florian locked themselves away in our conference room for a week. Their goal: to understand the regulatory requirements, contextualize them, and derive concrete areas of action for our clients.
I was very impressed by the three of their work ethic, but above all, it made it clear to me just how much technical work is required before legal requirements can be translated into concrete measures for IT, governance, and risk management.
And DORA is by no means the only set of regulations. NIS2, the Cyber Resilience Act (CRA), the AI Act, data protection requirements, industry-specific guidelines, and standards such as ISO 27001 or the BSI IT-Grundschutz are fundamentally changing the requirements placed on companies and their IT systems.
At the same time, geopolitical tensions, state-sponsored cyber activities, ransomware, and the growing dependence on digital infrastructure and IT service providers are constantly changing the risk landscape. The pressure on companies to make their IT more resilient remains correspondingly high. However, with every new regulatory requirement, the effort required to implement it also grows
The crucial question, therefore, is not whether regulation is fundamentally sensible. It is: How much regulation is needed to achieve greater security—and at what point does the regulatory burden exceed the additional benefits?
Why IT Regulation Is Necessary
The increase in regulation is no coincidence. Today, companies depend on functioning IT to an extent that would have been almost unimaginable just a few decades ago.
Regulatory requirements are intended to ensure a minimum level of security and resilience.
DORA requires financial institutions and relevant third-party IT service providers to systematically manage digital operational resilience. NIS2 raises the requirements for cybersecurity, risk management, and reporting processes for affected organizations. The Cyber Resilience Act places greater responsibility on manufacturers and Vendors of products with digital elements. The AI Act establishes a risk-based framework for certain AI systems and their use.
All of these regulatory frameworks address real risks. They ensure that topics such as information security, emergency preparedness, supplier management, and vulnerability management are not permanently sidelined in favor of short-term business interests.
Regulation Creates Obligations
Information security, business continuity, and third-party risk management almost always compete with other investments within companies.
A regulatory requirement changes this discussion. It shifts from “We should improve this at some point” to “We must demonstrably master this.”
This can help secure budgets, define clear responsibilities, and garner the necessary attention from management. Especially in areas where security measures have previously been viewed primarily as a cost factor, regulation can provide a significant impetus.
Good compliance also improves operational processes
Regulatory requirements do not automatically have to mean just more bureaucracy.
Those who clearly define processes, responsibilities, controls, and information flows ideally create structures that go far beyond simply passing an audit.
Robust asset management not only helps with audits but also makes it possible to reliably identify critical systems and dependencies in the first place. An established third-party risk management framework not only strengthens the company’s regulatory position but also improves oversight of key service providers. Clearly defined incident response processes not only help with reporting requirements but are especially crucial when a security incident actually occurs.
Modern engineering practices also benefit. Security by design, automated security testing, documented vulnerability management, and software bills of materials are increasingly mandated by new requirements. Companies that have already embedded these practices can, in some cases, use compliance as proof of existing quality.
Regulation can thus contribute to the long-term professionalization of governance and IT.
The problem: The regulatory stack is growing
The reality, however, is more complex than the simple formula “more rules, more security.”
Before an organization can meet a requirement, it must first understand what it specifically means for its own business model, IT landscape, and existing controls.
And while companies are still working on implementing one set of regulations, the next one is often already on the horizon.
The challenge, therefore, increasingly lies not in a single regulation, but in the interplay of many requirements. DORA, NIS2, CRA, the AI Act, the GDPR, national laws, and industry-specific requirements do not exist in isolation from one another.
They overlap, sometimes use different terminology, and require similar controls or evidence in different contexts.
When Compliance Displaces Operational Security
Every new requirement ties up resources. Employees analyze requirements, draft guidelines, maintain control catalogs, gather evidence, answer audit questions, and prepare for audits.
These resources are not unlimited.
This creates a paradoxical effect: regulation is intended to increase security, but at the same time it can tie up capacity that is then lacking for operational security measures. This is particularly challenging for small and medium-sized enterprises that cannot maintain large compliance, risk, or information security departments.
The danger is that companies will increasingly focus on demonstrating that controls are in place rather than on improving their actual effectiveness.
A company can be very well documented and yet still be poorly protected. Policies may be complete, controls in the GRC system may be marked as implemented, and evidence may be available for the audit.
The crucial question, however, remains:
Do these controls actually work when they’re really needed?
When an incident occurs, a critical service provider goes down, or a vulnerability is actively exploited, a green checklist won’t help. What matters then are robust processes, clear responsibilities, up-to-date technical measures, and people who know what to do.
Regulation must not unnecessarily hinder innovation
Another aspect is often underestimated: regulatory uncertainty influences investment decisions.
If companies cannot reliably assess which requirements will apply in the future to cloud models, AI applications, or digital products, they initially evaluate new technologies through the lens of compliance. The focus is no longer solely on the question, “What benefits does this solution provide?” but also on: “What additional effort for documentation and implementation does it entail?”
This does not mean that innovation should take place without guidelines. Clear rules are necessary, especially for technologies with significant impacts on security, privacy, or fundamental rights. However, these rules should be as transparent, technology-neutral, and proportionate as possible.
We don’t need less regulation; we need better governance
These problems do not automatically lead to a call for less regulation.
Cyberattacks, inadequately managed IT service providers, a lack of emergency preparedness, insecure software, and uncontrolled AI systems will not disappear simply because companies have fewer compliance requirements to meet.
The better question is:
How can we create regulations that actually reduce risks without overburdening companies with compliance administration? To achieve this, three things are essential.
- Greater harmonization of requirements: Comparable requirements from different regulatory frameworks should not have to be repeatedly reinterpreted, implemented, and verified. Greater uniformity would reduce duplication of effort and free up resources for actual implementation.
- Focus on risks rather than checklists: The scope and depth of controls should be guided more by criticality, protection needs, and actual risk. The decisive factor should be which risk a measure actually reduces.
- Prioritize effectiveness over formalism: Documentation and evidence are necessary, but they must not become the actual goal of compliance. A control that is formally compliant and neatly documented adds little value if it doesn’t work when it really matters. What matters is whether processes, responsibilities, and measures actually work in practice.
When I think back today on my three colleagues and their intensive DORA week, I see both sides of modern IT regulation.
On the one hand, there are experts who interpret complex requirements and use them to develop better governance, greater resilience, and concrete protective measures. On the other hand, there is the considerable investment of time, knowledge, and resources required to even gain a solid understanding of regulatory expectations.
Perhaps we should therefore focus less on how much regulation we can still tolerate, and more on how much of it actually reaches where it’s supposed to have an impact: in reducing real risks.
This is precisely the kind of translation we’ve honed through numerous regulatory projects: categorizing requirements, mapping them to existing governance structures, and embedding them in such a way that they are not only formally met but also become effective in practice. If you’re facing this challenge, we’d be happy to support you with our expertise.
Author: Eric Loewenstein