Since its entry into force in May 2018, the General Data Protection Regulation (GDPR) has been considered the central framework for handling personal data within the European Union. Its aim is to strengthen citizens’ rights in the digital space and to obligate companies to practice transparent and responsible data protection. Despite its pioneering status, the GDPR is frequently criticized—especially by small and medium-sized enterprises (SMEs)—as overly bureaucratic and difficult to implement. Now, a comprehensive reform is planned for 2025. With its proposals, the European Commission seeks to reduce existing hurdles and adapt the regulation to current technological developments such as artificial intelligence (AI) and big data—without compromising fundamental data protection rights. But can this balancing act succeed?

Why GDPR Reform Is Now on the Agenda

The proposed GDPR reform was officially introduced in spring 2024. Since then, additional proposals have emerged, all pursuing a central goal: making the regulation more practical and efficient. Two key objectives are in focus:

• Relief for SMEs by reducing excessive obligations
• Adapting the GDPR to technological innovation

While business associations such as Bitkom and the BDI welcome the reform, data protection advocates and civil society organizations like noyb warn of serious risks to EU citizens’ fundamental rights.

Reducing Bureaucracy for SMEs: Relief or Risky Exception?

A core element of the reform is the planned relief for small and medium-sized enterprises. Companies with fewer than 750 employees would be exempt from certain documentation requirements—such as processing records or data protection impact assessments—provided no high risk is involved.

The EU Commission justifies this step by citing the need to align the GDPR with business realities. The current “one-size-fits-all” approach places a disproportionate burden on SMEs with limited resources.

Surveys show that many companies are not fundamentally opposed to data protection—they simply struggle with the practical implementation of its requirements. A shift toward differentiated regulation could offer much-needed relief.

However, critics argue that this differentiation sets a precedent: data protection rights could be weighted differently depending on company size. This would contradict the European fundamental right to informational self-determination.

Jurisdictional Flexibility: Streamlining or Strategic Loophole?

Another significant aspect of the GDPR reform concerns the jurisdiction of data protection authorities. Currently, the principle is that in cases of cross-border processing, the authority at the company’s main establishment takes the lead.

In the future, this model is to be made more flexible to accelerate procedures and reduce legal uncertainty.

Yet practice already reveals weaknesses in the system: companies like Meta and Google benefit from the Irish Data Protection Authority being responsible for them—an authority repeatedly criticized for slow response times and weak enforcement.

Too much flexibility could allow corporations to strategically choose “data-friendly” authorities—clearly a setback for EU-wide harmonization of data protection oversight.

Technological Change: How AI and Big Data Challenge the GDPR

A major driver of the reform is technological progress. The GDPR was created at a time when automated decision-making, algorithmic profiling, and AI systems were still fringe topics. Today, they are central to digital business models.

Therefore, the Commission proposes:

• Clearer definitions of terms like “personal data” and “automated decision”
• Reassessment of pseudonymized or aggregated data
• Technology-neutral solutions that uphold data protection standards

Industry representatives welcome this move, hoping for legal clarity to support data-driven innovation. Companies want to better understand what compliant AI applications should look like.

But data protection advocates urge caution: in practice, pseudonymized data is often re-identifiable—especially when analyzed using AI across large datasets. A premature opening could foster misuse and undermine fundamental rights.

Civil Society Criticism: Lack of Transparency and Inclusion

It’s not just the content but also the legislative process itself that faces sharp criticism. Civil society organizations complain that economic interests dominated the drafting of the reform.

NGOs, data protection experts, academics, and civil rights groups were barely involved. This one-sidedness threatens the legitimacy of the entire legislative process and could erode trust in EU institutions.

Civil society therefore calls for a transparent debate, balanced representation of interests, and an independent impact assessment that also considers long-term risks to democracy and the rule of law.

Conclusion: GDPR Reform as a Balancing Act Between Innovation and Rights Protection

The planned GDPR reform of 2025 is undoubtedly necessary—not least to align regulation with the realities of modern data processing. Targeted relief could benefit especially small and medium-sized enterprises. Greater clarity is also needed in dealing with emerging technologies like AI and data analytics.

But modernization must not come at the expense of data protection and digital self-determination. The challenge lies in finding a fair, practical, and legally sound solution. One thing is clear: if data protection is weakened, Europe risks not only losing trust but also its leading role in global data law.

Germany’s NIS2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) is expected to come into force in spring 2025. This new regulation will have significant implications for service provider contracts and cybersecurity. Companies should not wait passively but actively prepare to comply with the legal requirements. This article outlines how NIS2 will affect future service provider contracts for regulated entities and what actions must be taken.

Urgency of NIS2 Implementation

In practice, the delay in Germany’s NIS2 law does not exempt regulated companies from preparing. Although penalties cannot be imposed before the law takes effect, cyber insurers may refuse coverage for incidents occurring after October 17, 2024, if NIS2 requirements are ignored.This deadline marked the end of the EU’s transposition period. For companies operating across borders, legal uncertainty arises: who is liable if an incident occurs in an EU country that has implemented NIS2, but the responsible company is based in unregulated Germany?

Who Needs to Prepare?

A simple rule applies: any company regulated under NIS2 must begin preparations immediately. In Germany, this affects up to 29,500 companies.However, due to NIS2’s supply chain security requirements, it’s unclear how many service providers and suppliers will also be impacted.

Supply Chain Security

NIS2 requires regulated companies to contractually ensure that all external partners comply with cybersecurity standards—whenever outsourcing, third-party services, or hardware/software products affect business-critical processes. In such cases, contractors must commit to meeting the same requirements as the regulated company itself.

Figure 1: NIS2 impact on service providers and suppliers

This is not entirely new for many providers. Companies pursuing ISO 27001 or BSI IT-Grundschutz certifications already face supplier audits and contractual requirements for resilience, integrity, and confidentiality. Data center operators, for example, are used to regular checks by clients with sensitive data needs.

Impacts on Service Providers

What’s new with NIS2 is that compliance is enforced indirectly—through contractual obligations from regulated clients. Paradoxically, suppliers may face compliance demands before their clients do. While regulated companies benefit from transition periods (up to three years for critical infrastructure operators), service providers do not. Many contracts are renewed every 2–4 years, and upcoming negotiations will require NIS2-compliant clauses.If a contract’s term overlaps with the law’s effective period, regulated companies must ensure their suppliers are compliant. Procurement teams will demand proof of cybersecurity measures during contract renewals. Risk management will only allow partnerships that meet legal standards.

Recommended Actions for Service Providers

Service providers should begin implementing the minimum security requirements listed in Article 21 of NIS2, such as security concepts and encryption. Most of these are not new, especially for platform operators, data centers, or software developers working with regulated clients.A useful benchmark is the questionnaires used by cyber insurers, which assess crisis management, network security, and user privileges. Clients will expect readiness for audits, penetration tests, and exercises. Additional cybersecurity clauses may be added to SLAs. Written declarations of compliance with IT-Grundschutz may become mandatory—already a requirement in public tenders.

Conclusion: NIS2 and the Supply Chain

Ignoring rising cybersecurity expectations is no longer an option—especially for service providers working with NIS2-regulated companies. Future contracts will only be awarded to those who can demonstrate an appropriate level of cybersecurity. NIS2 dramatically expands the scope of cybersecurity obligations. Thousands of companies must now meet their clients’ elevated expectations. Compliance may even become a competitive advantage, especially if high resilience and security are emphasized in marketing.

In today’s business world, IT service contracts are the critical foundation for collaboration between outsourcing companies and their service providers. A well-crafted contract can make the difference between smooth cooperation and constant conflict. Based on our experience from various outsourcing projects, we want to highlight 10 important aspects that should be regulated in an IT service contract to ensure effective provider management.

Scope

We do not aim for completeness: many other aspects should also be appropriately regulated in IT service contracts depending on the outsourcing situation. These include liability, warranties, payment terms, confidentiality, contract duration, termination conditions, knowledge and compliance management. So let’s focus on the aspects that, in our view, are particularly decisive for the success or failure of cooperation with service providers. Summarized for you: IT Service Contracts – 10 Key Aspects

Figure 1: 10 Aspekts

Ten Aspects

1. Clear Service Specification

The services to be provided must be defined as clearly and precisely as possible in the service contract. This includes the type and scope of services as well as the expected service quality. The latter is usually specified in the contract through service levels. The procedure for measuring compliance with service levels should also be regulated in the contract.

When specifying the expected external services, it is important to clearly define the client’s cooperation obligations. If other service providers are working for the outsourcing company, clear performance boundaries between all parties must be specified. The goal is to minimize gray areas between provider and client as well as between providers.

Additionally, the framework conditions under which the service provider is to deliver the services must be defined. These can include service times and location requirements.

Clear service specifications and measurable service levels help manage expectations on both sides and provide a basis for evaluating service quality.

2. Pricing and Billing Modalities

A transparent and fair pricing mechanism is essential to avoid misunderstandings and disputes. The contract should clearly specify which services are provided at what price and how billing is handled. Variable costs, such as for additional services or overtime, should also be clearly regulated.

3. Change Management

Changes to IT services are inevitable, whether due to technological advancements or changing business requirements on the client side. Effective change management in the contract ensures that changes are carried out in a structured and controlled manner. This includes defining processes for requesting, evaluating, commissioning, and implementing changes, as well as communication between the parties.

4. Risk Management

A good IT service contract should also include provisions for handling risks and emergencies. This involves identifying potential risks, developing action plans, and regularly reviewing and updating these plans. The goal is to proactively minimize the impact of disruptions and ensure continuity of business processes.

5. Reporting, Roles, and Communication

Regular reporting and open communication are crucial for successful provider management. The contract should specify what information (especially within SLA reporting) a provider must deliver and at what intervals, and how communication between the parties is organized. Appropriate roles and committees, along with their tasks and interactions, should be defined in the contract for regular exchanges and decision-making.

This enables continuous monitoring of service quality, early identification of problems, and appropriate service development.

6. Cooperation

The contract should also obligate the service provider to cooperative behavior. This applies not only to collaboration with the client but also with the client’s other service providers. Shared goals should be defined in the contract as a basis. Common values and rules can then be agreed upon to guide cooperative behavior.

7. Escalation Procedures

A clearly defined escalation procedure is important for resolving conflicts quickly and effectively. The contract should specify the steps to be taken when problems cannot be resolved at one level and who is then responsible for resolution. This helps avoid misunderstandings and ensures timely problem resolution.

8. Performance Reviews and Audits

Periodic performance reviews and audits help ensure compliance with contractually agreed standards. The contract should specify how often these reviews take place and what criteria are applied. This allows deviations to be identified early and countermeasures to be taken.

9. Continuous Improvement and Innovation

A good IT service contract should also include provisions to promote innovation and continuous improvement. This may include the provider’s obligation to regularly evaluate new technologies and best practices and to propose optimization measures for IT services. The contract should also define how improvement ideas are planned and implemented, especially when multiple service providers must collaborate to realize improvements.

10. Exit Strategy

A well-thought-out exit strategy is essential to ensure a smooth transition to a new provider or the reintegration of services into the company upon contract termination. The contract should include clear provisions for the handover process, data migration, and support from the previous provider.

Conclusion: IT Service Contracts – 10 Key Aspects

A well-crafted IT service contract is the foundation for successful collaboration between client companies and IT service providers. The ten aspects mentioned – clear service specification, pricing and billing modalities, change management, risk management, reporting and communication, cooperation, escalation procedures, audits, continuous improvement, and exit strategy – are crucial for effective provider management and minimizing conflicts.

As a provider manager, you should ensure that these points are clearly and precisely regulated in your contracts to enable smooth and successful collaboration. If you work with multiple service providers, it makes sense to agree on uniform contract provisions with all parties. This simplifies collaboration and provider management.

A good contract alone does not guarantee good service and smooth cooperation. But it provides the necessary foundation. Consistent expectation management and active relationship management are essential for long-term success in IT outsourcing.

After our first blog article (April 2024) on the new EU NIS2 Guidline dealt with the basics, differences to NIS1, and the legislative situation, we will this time focus on the following topics: What criteria are used to categorize companies that operate critical infrastructure? What sanctions are potentially possible? What measures, especially in the area of risk management, must be implemented by the companies affected? In the following article, we provide an overview of these topics.

NIS2 categorization of affected companies

With the NIS2 Directive coming into force, companies in 18 industrial sectors—instead of the previous 9—will have to implement specified minimum information security standards from 2024 onwards. The following two main criteria apply to determine whether a company is affected:

1. Criterion: Company size

Companies with at least 50 employees and an annual turnover of more than €10 million fall within the scope of the NIS 2 Guidline if criterion 2 is also met.

2. Criterion: The company sector

Whether an organization falls under NIS 2 also depends on whether it belongs to one of the 18 defined company sectors. The company sector is the second decisive criterion, in addition to the size of the company. If both criteria are met, an organization falls under the NIS 2 Guidline.

Special cases in categorization

There are special cases in the digital infrastructure sector. Some operators are to be regulated regardless of their size. For companies that offer domain name services or trust services with qualified signature management, for example, which are considered extremely critical under NIS2, the size of the company is irrelevant. Even small or micro-enterprises that offer such services are considered particularly important entities—with all the obligations that this entails. Figure 1 provides an overview of this.

Figure 1: Special cases for digital infrastructure companies

NIS2 Sanctions

NIS2 divides sectors into eleven “essential” sectors with high criticality and seven “important” sectors. The distinction between ‘essential’ and “important” also determines the scope of government oversight and the sanctions that can be imposed for non-compliance with and violations of NIS2 requirements.

For “essential entities,” sanctions can amount to up to ten million euros or two percent of global annual turnover, whichever is higher. For “important entities,” fines can amount to up to seven million euros or 1.4 percent of global annual turnover, also based on the higher amount.

A distinction is made between negligent and intentional fault, without differentiating between “essential” and “important” sectors. Even negligence can then lead, for example, to personal liability on the part of the managing director.

Companies exempt from NIS2

A company that should actually be affected may also be completely exempt from NIS2. The NIS2 Guidline does not apply to entities in the fields of defense or national security, public security, and law enforcement. The judiciary and parliaments are also excluded from the scope of application.

To avoid multiple regulation, the NIS2 Guidline provides an exemption for entities that must meet corresponding IT security requirements under other EU directives. For example, financial institutions subject to DORA only need to provide evidence of their information security and report incidents under DORA. They therefore already meet the relevant requirements.

Measures to be ensured

What measures must the affected companies now implement? The NIS2 Guidline requires them to implement a series of compliance measures. The following ten detailed requirements for risk management are taken directly from Article 21 of NIS2. They are crucial for full compliance with the Directive:

• established concepts for risk analysis and security for information systems,
• concepts for dealing with security incidents,
• concepts for maintaining operations, such as backup management and disaster recovery, as well as the corresponding crisis management,
• evidence of supply chain security, including security-related aspects of the relationships between individual institutions and their immediate suppliers or service providers,
• Security measures for the acquisition, development, and maintenance of network and information systems, including vulnerability management and disclosure,
• Concepts and procedures for assessing the effectiveness of risk management measures in the area of cybersecurity,
• Basic procedures in the area of cyber hygiene and training of employees in the area of cybersecurity,
• Concepts and procedures for the use of cryptography and, where appropriate, encryption,
• Staff security, concepts for access control and facility management (e.g., data centers),
• use of multi-factor authentication or continuous authentication solutions, secure voice, video, and text communications, and, where appropriate, secure emergency communications systems within your own facility.

Checklist for implementing necessary measures

But how can these requirements be implemented consistently? We recommend creating a checklist. In our opinion, the following recommendations should be included in this checklist:

1. Risk assessment and management:
   The first step should be to conduct a comprehensive assessment of current security risks. This involves identifying vulnerabilities in the IT infrastructure and then developing plans to address them.
2. Implementation of security measures:
   It must be ensured that security measures comply with the requirements of NIS2. These include advanced technologies for defending against cyber threats, regular updates and patches, and effective access controls.
3. Employee training:
   An essential part of compliance is raising awareness and training all employees. It must be ensured that they understand the importance of IT security and know how to respond to security incidents.
4. Incident reporting system and SIEM:
   Effective systems for detecting and reporting security incidents must be implemented. This should enable incidents to be detected, recorded, and reported quickly and efficiently.
5. Documentation and compliance review:
   Security processes and compliance measures must be carefully documented. Regular internal audits can help to review and ensure compliance with the NIS2 Guidline.
6. Cooperation and information exchange:
   Opportunities for cooperation with other companies affected by NIS2 and with authorities should be exploited in order to exchange best practices and continuously improve one’s own security strategy.

Conclusion

The NIS2 Guidline represents a significant step forward for European IT security. Its scope has been expanded to include additional sectors. The focus is on stricter security requirements as well as transparency and cooperation.

Companies now need to check in good time whether they are affected by NIS2. If this is the case, they must review their security strategies and adapt them to the new requirements. This includes a comprehensive risk assessment, the implementation of stronger security measures, employee training, the establishment of effective incident reporting systems, and clear documentation of all measures taken.

The new EU NIS2 Directive must be incorporated into German law by October 17, 2024. NIS2 stands for “Network and Information Security – Version 2.” The directive has been in force in the EU since January 2023. It aims to ensure that facilities classified as critical can supply the population in member states with essential goods and services. But how did the second version of NIS come about and how does it differ from NIS1? We will take a closer look at this and more in a series of blog articles. In the first article, we will discuss the origins and innovations of NIS2.

History of NIS1 and KRITIS

The European Union introduced its first cybersecurity directive in 2016. Today, this directive is known as NIS1. It was developed against the backdrop of an increasingly threatening situation and growing IT security requirements in Europe. The EU’s aim was to protect sectors and services that are important to society in its member states from IT attacks.

NIS1 contains binding requirements for the protection of systems belonging to companies that operate “critical infrastructures” (KRITIS). These KRITIS companies play a crucial role in society as they provide services in important areas such as energy supply, health, and transportation.

Emergence of NIS2

Advancing digitalization is also leading to a steady increase in threats. A higher level of protection is required to adequately mitigate the current risks at KRITIS companies. The EU therefore decided to revise the NIS1 Directive. After lengthy deliberations and discussions, NIS2 was the result. Following approval by the EU Parliament and the European Council, NIS2 was adopted as an updated version on December 14, 2022. After it comes into force on January 16, 2023, EU member states will have 21 months to transpose the new regulations into national law. Accordingly, affected companies should already be familiarizing themselves with the requirements of the NIS2 Directive so that they can plan and implement the necessary measures in good time.

Figure 1: Timeline of the Genesis of NIS2

At the same time as NIS2, the so-called CER Directive – “Critical Entities Resilience Directive” – also came into force. CER regulates physical protection against sabotage and other attacks for KRITIS companies, for example in terms of access policies for data centers. The security of information and communication technology, on the other hand, is the subject of NIS2. CER is not discussed in detail in this and the following NIS2 articles.

Status of German legislation

The drafts for the existing KRITIS umbrella law (KRITIS-DachG) on CER implementation and the somewhat cumbersome NIS 2 Implementation and Cybersecurity Strengthening Act (NIS2UmsuCG) are currently at different stages of the legislative process.

While the implementation of the KRITIS umbrella law has already been approved by the relevant ministries and the hearings with the federal states and associations for the second draft bill have been completed, there has been little progress on NIS2. An initial draft bill was already circulating unofficially in the summer of 2023. However, the Federal Ministry of the Interior and Homeland (BMI), which is in charge of the bill, has not yet published an official version. The schedule is now becoming increasingly tight. A concrete draft bill must first pass through the cabinet and then through parliament. Due to this complex procedure, it cannot be ruled out that the start date of NIS2 on October 18, 2024, will be missed.

Industries and sectors affected by NIS2

The scope has been significantly expanded and now covers a total of eighteen industrial sectors, from water to space. The previous nine sectors of the KRITIS Regulation are included in the new areas. NIS2 continues to distinguish between high-criticality sectors and other critical sectors. The CER Directive applies to the 11 sectors with high criticality. The table in Figure 2 provides an overview of the sectors affected.

Figure 2: Sectors affected by NIS2

Like NIS1, NIS2 imposes comprehensive requirements on risk management and cybersecurity.

New classification as an affected company

Another key element of the reform is a complete reclassification of the target group. In the previous understanding of critical infrastructures, the determination of their criticality was regulated in the KRITIS Regulation (KritisVO). In the future, this will be replaced by the Kritis-DachG (CER) and NIS2UmsuCG (NIS2).

The previous three-stage procedure defined sector affiliation, specific plant categories, and concrete thresholds. Exceeding these thresholds made an operator a KRITIS within the meaning of the regulation. The virtual benchmark for these thresholds was always a figure of 500,000 people who would be affected by a failure of the critical infrastructure.

After much back and forth, it was agreed in the negotiations on NIS2 (as well as CER) to redesign the classification of critical facilities and, in future, to classify them across Europe according to company size (50 employees and above), turnover figures (€10 million/year), and sector affiliation. This classification will be regulated in the aforementioned NIS2UmsuCG in the future.

According to estimates by the Federal Statistical Office, these changes will mean that ten times more companies than before will be legally obliged to comply with the provisions of the NIS2 and CER directives. Existing KRITIS companies will automatically continue to fall under the new directive.

New features in NIS2

What are the most important differences and new features in NIS2 compared to NIS1? There are four important changes:

More than twice as many sectors (18 instead of 7) than before are classified as critical.
Violations of NIS2 requirements will be punished according to a now uniform and significantly stricter catalog of fines, which is capped only by a percentage of global annual turnover – similar to the GDPR introduced in 2018. Previously, EU countries were able to determine the penalties themselves. In Germany, the maximum penalty was €20 million.
NIS2 introduces executive responsibility for the first time. In the future, executives will be personally liable if they violate their duties – including claims for damages that must be paid from their own assets.
The new directive revises the existing reporting requirements to the Federal Network Agency and the BSI in the event of security incidents. In future, there will be a three-stage process instead of a single stage: a preliminary report must be made within 24 hours if a critical service fails – even if there is no precise knowledge of what exactly has happened. After 72 hours at the latest, the respective national supervisory authorities (in Germany, the Federal Network Agency) expect a qualified report on the incident and how it is being dealt with.

Conclusion

The new classification system means that significantly more companies are now subject to KRITIS regulation. This results in many new tasks for these companies. Especially for smaller companies, the effort required for appropriate risk management can quickly become a major challenge. Companies already classified as KRITIS must review their existing concepts and adapt them if necessary. You can find out exactly what measures should be taken here, how the classification as a critical company works in detail, and further details in one of the next blog articles.

The EU Regulation DORA (Digital Operational Resilience Act) establishes a unified framework for the European financial sector to manage cybersecurity and ICT risks. Its goal is to strengthen the EU financial market by harmonizing requirements and standards in cybersecurity and ICT risk management, ensuring resilience and adaptability—operational resilience—of financial institutions during and after disruptions. Implementation is required by 2025, but how can this be achieved with manageable effort? This blog post provides an overview of DORA and offers practical tips for implementation.

 DORA Applies from Early 2025

The Digital Operational Resilience Act affects nearly all regulated institutions and companies in the European financial sector, including banks, insurance, and reinsurance firms. Companies must act now: the regulation came into force in January 2023 and will apply from January 17, 2025, after a two-year transition period.

In January 2024, the European Supervisory Authorities (ESAs)* published the first final drafts of technical regulatory and implementation standards—a set of standards to ensure consistent regulation of operational processes.

Figure 1 : EU Regulation DORA – Contents and implementation tips

*= The European Supervisory Authorities (ESAs) include:

EBA: European Banking Authority

ESMA: European Securities and Markets Authority

EIOPA: European Insurance and Occupational Pensions Authority

 What DORA Regulates

The EU Regulation DORA aims to strengthen resilience against cyberattacks and digital security. It sets requirements for cybersecurity, business continuity, and crisis management to ensure processes remain available during cyberattacks or technical failures. It focuses on ICT risk management and aligns with national and international best practices.

DORA covers six key areas:

Incident Reporting Framework

With regard to the implementation of DORA, uniformly regulated reporting processes for incidents in European financial companies are an important aspect. Parallels to the reporting obligation can also be found, for example, in the NIS2 Directive. Incidents are first reported to the competent national authority and assessed with the involvement of the European supervisory authorities. If relevant, they are then forwarded to other member states and other authorities. Figure 2 shows an incident in the DORA reporting process with BaFin as the central element in interaction with BSI and European supervisory authorities:

DORA regulatory and implementation standards

The above-mentioned drafts of technical regulatory and implementation standards (RTS and ITS) published by the ESAs are intended to support and facilitate implementation: The regulatory technical standards (RTS) contain detailed, specific rules and technical requirements, e.g. with regard to ICT risk management and security measures for IT systems, while the implementing technical standards (ITS) contain specific rules or procedures, e.g. instructions for conducting security tests or reporting security incidents.
The European Commission reviews these drafts to ensure that they are in line with European laws and policy objectives. They will become the binding standard for the implementation of DORA. As these standards specify the requirements of DORA in concrete terms, they also enable a better assessment of the implementation costs for companies.

Distinction from other regulatory requirements

DORA overlaps thematically with other current regulations and directives, such as the NIS2 Guidline, which aims to strengthen the overall level of cybersecurity in the EU, and TIBER (Threat Intelligence-based Ethical Red Teaming), which aims to promote resilience against cyberattacks through preventive testing. If a company also falls under the NIS2 Directive, the following applies: If the DORA requirement is more specific, it takes precedence.

For the banking sector, the European Banking Authority (EBA) published the EBA Guidelines on Outsourcing and Guidelines on ICT and Security Risk Management in 2019, defining risk management measures relating to information security and outsourcing requirements. However, these are recommendations or guidelines that only apply to the banking sector.

The DORA Regulation basically includes the content of these requirements and guidelines. DORA focuses on the consistent standardization of known regulations and requirements in the context of operational stability and business continuity. Unlike the EBA guidelines, it affects not only the EU banking sector, but the entire EU financial sector.

How does DORA integrate into German financial regulatory requirements?

Recommendations for action and tips for implementation

1. Requirements/processes/methods that have already been implemented or established, e.g., from the EBA guidelines, provide a good basis for implementation for financial companies.
2. Requirements for documentation and reporting obligations should be reviewed and processes adapted.
3. Existing service provider contracts must be reviewed and, if necessary, adjusted, for example, with regard to the support to be provided by the service provider in the event of incidents. (Adjustments can be extremely time-consuming!)
4. Existing tools for risk management/documentation/reporting can be used to provide support, e.g., tools for automatic detection and alerting of anomalies, or tools for encryption and management of cryptographic keys, or for implementing lifecycles for firewall rules to strengthen network security.
5. New tools for documenting service provider contracts and information registers on service providers required for reporting obligations must be established.
6. Findings or measures from the implementation of the Supply Chain Act can also be helpful for the risk assessment of service providers (despite the primary focus on social and environmental standards).
7. Overall, specific requirements must be aligned with the (technical and organizational) standards already in place within the company, and processes must be adapted and adjusted accordingly.

Conclusion

On November 27, 2023, following the European Parliament, the European Council also adopted the EU Data Act. The aim of this act is to reduce legal, economic, and technical barriers to the data economy. Access to and transfer of automatically generated data arising from the use of a wide variety of networked products and related services (Internet of Things, IoT) is to be simplified. Such products include fitness trackers and products such as Apple CarPlay. Furthermore, this regulation is intended to make it much easier to switch cloud service providers. This blog article examines the key content of the EU Data Act, in particular its significance for the use of cloud services and the history of its development.

History of its development

The first draft of the EU Commission’s Data Act dates from February 23, 2022. It is a comprehensive set of rules for fair access to and use of data. According to the EU Commission, a large proportion of machine-generated/industrial data – up to 80% – currently remains unused. The Data Act aims to unlock this treasure trove of data by removing the legal, economic, and technical barriers to its use, while at the same time improving the value creation associated with data.

After many readings and amendments, the European Parliament approved the regulation on November 9, 2023. Following its subsequent adoption by the European Council on November 27, 2023, the EU Data Act entered into force on January 11, 2024. There will now be a transition period of 20 months before the Data Act becomes applicable on September 11, 2025. It will then apply to all companies offering relevant products in the EU. Further obligations, such as compliance with the principle of “access by design,” i.e., access by state judicial and investigative authorities when necessary, will only become applicable after a further twelve months, i.e., probably in September 2026.

The EU Data Act was developed from the initial draft phase on February 23, 2022, to its implementation on January 11, 2024. This period includes the transition period until full applicability on September 11, 2026.

Figure 1: The EU Data Act – Implications for Cloud Service Providers

Overview – EU Data Act

But what exactly does this Data Act entail in terms of new developments?

The EU Data Act is intended to regulate the handling of data from the areas of IoT, Industrial Internet of Things (IIoT), and connected cars. It also addresses the use of virtual assistants, which are likely to be AI-based in the future, and assumes that they will become increasingly important.
It is intended to regulate the relationship between data owners and users. Users generate data that remains with data owners. The Data Act is intended to empower users to claim the data they have generated – and, if necessary, to trade it.
Switching between cloud service providers is to be made much easier. According to the EU Data Act, it is no longer permissible to prevent users from switching.

Key content aspects

Chapter 4 of the EU Data Act is dedicated specifically to switching between data processing services. This refers to what is known as “cloud switching.” According to this, a cloud service provider may not, for example, place technical, contractual, or organizational obstacles in the way of a customer who is about to switch. Specifically, this applies to, among other things, the termination of services, the conclusion of a new contract with a competitor, and the porting of data to a competitor or to one’s own on-premise infrastructure with the aim of obtaining similar services from a competitor or splitting services – also known as “unbundling.”

Chapter 4, Article 25 of the Data Act contains provisions on contractual agreements for data processing services such as cloud services. In addition, there are information requirements regarding the methods and formats for changing service providers. This includes, among other things, information about any restrictions and technical limitations. Service providers are required to maintain an up-to-date online register that provides information on data structures and formats as well as relevant standards and specifications for interoperability.

In Chapter 8, Article 33, the Data Act establishes comprehensive rules on the interoperability of data, mechanisms and services for data transfer and use in shared European data spaces. Data spaces refer, for example, to cloud environments such as AWS, Azure, or Google Cloud. The EU Commission may issue implementing regulations and request standards-setting organizations (e.g., ISO, DIN) to establish uniform standards in this area in order to achieve this interoperability. Providers must then implement these standards accordingly.

Monitoring the implementation of requirements

As is customary in comparable EU regulations, the EU sets out corresponding requirements for the implementation and enforcement of these rules in the Data Act. According to these requirements, the individual EU member states are to designate authorities responsible for enforcing the Data Act. For Germany, this is likely to be either the Ministry of the Interior or the BSI, which reports to it. However, this has not yet been decided. These authorities are to investigate complaints of violations of the EU Data Act, particularly in the area of trade secret protection, and generally monitor the application of the Data Act. In addition, they are to observe technological and economic developments in the area of data provision. Possible consequences would be an adjustment of regulations. An example of this would be a new product on the market that offers previously unknown possibilities for data collection and processing, for example in connection with AI. The member states will have to work out in the coming months what the EU-wide cooperation between the authorities should look like.

Similar to the GDPR, significant penalties are provided for violations of the EU Data Act. Fines can be up to €20,000,000 or up to 4 percent of the company’s global annual turnover. Such a penalty would be possible, for example, in the event of refusal to grant access to data.

Conclusion – EU Data Act

The EU Data Act is the first set of regulations of its kind worldwide. The processing of industrial data is moving closer to the processing of personal data (GDPR) in regulatory terms. However, no concrete statement has been made on the subject of “data ownership,” which has been criticized by data protection organizations. Furthermore, the Data Act represents a significant encroachment on the freedom of the parties concerned to draft data use agreements. Once the regulation finally comes into force, it will become clear what consequences this will have. Affected service and product providers should start implementing the requirements of the Data Act now at the latest, as it is clear that the Data Act will entail numerous obligations for digital companies, some of which can only be met through long-term and extensive process adjustments.

When having done IT-Outsourcing – measuring success correctly is not easy. In most companies, the success of IT outsourcing is measured by the cost savings realized. It must be ensured that the scope and quality of the service also meet the customer’s requirements. After outsourcing, internal IT checks this based on SLA reports from the service provider: it must ensure that the service provider’s performance is “correct”. However, the effort and efficiency of internal provider management is often not taken into account when determining outsourcing success. In the following, we show how a holistic measurement of success can look like. It not only takes into account the performance of the external service provider. It also considers the performance of the vendor management in the evaluation.

When measuring outsourcing success, most companies focus exclusively on the quality and costs of externally provided services. This means, focus is only on the performance and costs of service providers. Vendor management is often not included in this analysis: This has a significant influence on the performance of the services and also represents an additional cost component that must be taken into account when determining the total cost of ownership (TCO) of IT outsourcing.

In the following, we will first take a closer look at the dependencies between service provider performance and vendor management performance. We will then take a look at how to measure the success of IT outsourcing on the basis of key performance indicators (KPI), taking vendor management into account.

Dependence between provider and vendor management performance

Ideally, the service provider always provides its services at the service level agreed in the contract. Vendor management controls the provider with little effort. Additionally it ensures that the overall IT service for the company is always in line with customer requirements. Therefore it has to take appropriate measures to integrate all internal and external services (see figure 1).

Figure 1: Ideal scenario – high performance of the service provider and vendor management (VM)

In practice, things often look different: There are always situations in which a provider falls short of the agreed service level.That means, the performance of this provider is too low. Now vendor management must take appropriate additional control measures to ensure that the provider better meets its contractual commitments.

The vendor management effort (and thus the vendor management cost) increase (see figure 2).

Figure 2: low performance of the service provider – rising cost for vendor management

If things go badly with a provider for a longer period of time, the effort (and therefore the costs) in vendor management increase: Discussions increase, conflicts and escalations accumulate. This is particularly true if the vendor management is not set up efficiently. In this case its (low) performance is not sufficient to turn around the poor quality of the external service. In this situation, the performance of the provider may drop further (see figure 3).

Figure 3: low performance of the vendor management deteriorates service provider performance

Vendor management must therefore have sufficient performance of its own to bring the provider up to the agreed performance level. This can be done by using suitable control measures, especially in the event of service level deviations.

Measurement of outsourcing success

Let us now look at how the success of outsourcing can be measured. Usually KPIs are used for this purpose. The dependency between provider performance and vendor management performance/costs that has just been demonstrated makes it clear that outsourcing success cannot be depicted solely by measuring the performance of one party – i.e., only the service provider.

The “correct” set of KPIs must therefore reflect the performance of both parties. That is the basis to provide an accurate picture of the current situation. But which KPIs are the right ones to measure success? This depends on the outsourcing objectives, which are usually defined as part of the sourcing strategy: The KPIs and target values to be achieved are derived from these objectives. The set of KPIs should be manageable, but adequately reflect the objectives. Ideally, KPIs that reflect the performance of both parties are combined with those that only represent the performance of one party.

For example, if the following objectives are defined for a “Workplace Service” outsourcing measure:

• the reduction of cost of ownership (TCO) of the affected IT service
• maintaining the performance of the IT service after outsourcing.

Then these goals can be made measurable by the following KPIs, among others: 

(1) KPI TCO after outsourcing

The cost share of internal provider management attributable to the external services under consideration must be used here. If the quantification of the target is a 10% reduction in the TCO of the services compared with the TCO before outsourcing, the

target value (TCO _{external services}) = TCO _{services before outsourcing} * 0,9

(2) KPIs for performance after outsourcing

For example, one KPI of service quality after outsourcing that reflects the performance of both parties is the provisioning time for a new PC:

This KPI implicitly measures the performance of vendor management: Vendor management has end-to-end responsibility and must ensure that the internal and external providers each deliver the required performance and also work together smoothly to always meet the required provisioning time.

The quantification for this KPI is already included in the target definition, as the performance is to remain the same after outsourcing:

target value (PC deployment time _{external services}) = PC deployment time _{services before outsourcing}

This KPI, which maps the performance of both parties, can now be supplemented by others that only map the performance of one party. For example, this could be the duration of the initial provision of a client application on a PC if the service request is handled solely by the service provider.

Conclusion: IT-Outsourcing – Measuring Success Correctly

The success of IT outsourcing should be measured by the degree to which the sourcing goals are achieved. Internal IT has a significant influence on this success through vendor management: If service providers are managed efficiently and processes involving internal and external parties run smoothly, then the planned benefits for the company’s own IT customers can also be realized. That is why the performance of vendor management must be taken into account when determining the benefits of services. The degree to which sourcing goals are achieved can be measured using the “correct” set of KPIs. They adequately have to reflect the performance of the service provider and vendor management.

In the following, we show how to set up business relationship management in IT vendor management based on the ISO 44001 approach in order to lead to better IT services for your own company. Cooperation with IT service providers offers companies many advantages in today’s world: Cost savings, professional handling of service operations, rapid introduction of new technologies and services for their own core business. Nevertheless, companies pursuing a multi-sourcing strategy often find it difficult to create efficient collaboration between all parties involved. The reasons are essentially conflicting objectives of the parties. As a result, the quality of the externally provided services suffers and the goals set with outsourcing are increasingly missed over time. ISO 44001 (Collaborative Business Relationship Management System) can provide a remedy, enabling the active design of collaborative business relationships.

With this article we would like to give a short overview of the standard and provide hints on how to get started with Business Relationship Management in provider management.

The structure of the ISO 44001 standard

ISO 44001 is divided into two elements. The basis of the standard is the High-Level Structure (HLS), consisting of 10 sections (see Figure 1). This was introduced to harmonize various ISO management system standards and give them a uniform structure. Thus, the information security standard ISO 27001 (2013) was the first “heavyweight” standard to use this HLS standard (for more details, see also Annex SL).

Based on this, an eight-stage life cycle (see Figure 2) was developed that addresses the requirements specific to ISO 44001 for the development, introduction and management of business relationships – in particular, shared governance, required personnel skills and the design of joint collaboration. This is applied in the eighth phase (operation) of the High Level Structure.

In the following, the main sections of the HLS, divided into the following three phases (see also Figure 1) – will be briefly presented: Prerequisites (Sections 1-7), Operation (Section 8 in interaction with the eight phases of the life cycle), and Performance Monitoring (Sections 9 and 10).

Phase 1: Create conditions in the company

The first seven sections of the HLS describe how to create the right conditions in a company.

Section 4, Context of the Organization, is particularly important here. In this step, the needs and expectations of the various stakeholders are identified.  In addition, issues such as legal requirements are analyzed. Furthermore, the area in which Collaborative Business Relationship Management is applied is defined.

Section 5 Leadership describes the requirements – leadership, accountability and commitment with regard to the collaborative business relationship management system – for top management (C-level). Furthermore, the top level of management must ensure that the objectives of the management system are in line with the strategic direction of the company. Among other things, ISO 44001 requires the appointment of a Senior Executive Responsible (SER) and the introduction of governance structures. One core element here can be a code of conduct, along with others.

Section 6 Planning focuses on setting up risk and opportunity management and aligning it with the business objectives: The who, what, how, when of a business objective must be identified.

Section 7 Support deals with the selection and provision of all necessary resources. Here, it is particularly important to select competent personnel with the (soft) skills required for collaborative working. These can be honed in training courses if necessary. It is important that the people selected are aware of their important role in the introduction of the business relationship management system. However, support also means providing or maintaining all the necessary documentation.

Phase 2: collaborative work based on the ISO 44001 life cycle model

Section 8 Operation (Operation is the heart of ISO 44001). Here, the eight steps of the life cycle model are presented in detail. The following graphic provides a brief overview of the eight steps of the life cycle and their contents.

Phase 3: Performance monitoring

Section 9 Performance Evaluation states, among other things, that evaluation methods and criteria must be defined for evaluating the collaborative business relationship. Regular evaluations must then be carried out on the basis of this evaluation system.

In the last step – Section 10 Improvement – the aim is to make continuous improvements to the relationship and relevant processes and activities in order to respond to changing requirements, needs or goals. In addition, it is important to identify and correct deviations from one’s own concept that occur in practice.

Introduction – Business Relationship Management in IT Vendor Management

In order to introduce a collaborative business relationship management system in IT vendor management, the company’s own concept should first be tested and validated as part of a pilot with a service provider before it is introduced to other service providers.

The Choice of the Service Provider for the Pilot

First of all, it must be clarified for which service providers a minimum expected benefit can be achieved through the introduction of such a formalized management system. As a rule, these are the business relationships with strategic service providers. Their services are essential to the core business of their own company: if the relationship with the service provider deteriorates, the performance of the core business can quickly be impaired.

To identify strategic service providers, it makes sense to categorize all service providers. The following graphic shows examples of categories and criteria for category assignment. Once the strategic providers have been identified in this way, the most suitable one for the pilot must be selected from among them.

The piloting

Once the strategic provider has been selected, the business relationship management system is introduced together with him as part of a pilot project. Experience gained in the pilot can thus be incorporated into the system concept. After the pilot is completed, the results of this first pilot will serve as a blueprint for adapting the results to other service providers.

The persons auditing the implementation of business relationship management in vendor management must be familiar with the content of the standard and obtain management’s approval and support for the audit. Accordingly, the appropriate personnel and management for such an undertaking must also be selected in advance. In the next step, a gap and awareness analysis should be conducted in workshops. Other parameters must also be investigated or defined before a recommendation is made regarding the introduction:

• Impact and costs of pilot implementation
• expected benefits
• Scope of application
• …

Once management has approved the recommended rollout, nothing stands in the way of an initial rollout as part of the pilot. At the same time, however, an evaluation process must also be implemented. This is used in the pilot phase and later in regular operation to compare all activities and processes of the (pilot) project with the standard in order to identify gaps and deviations. From this, in turn, measures and action plans can be derived to better align the existing processes with the standard. After their implementation, a second evaluation of all processes follows.

Conclusion – Business Relationship Management in IT Vendor Management

ISO 44001 offers companies the opportunity to put their collaborative business relationships with their strategic service providers on a solid foundation. The standard takes a detailed look at various areas of collaboration, such as governance, personnel, skills and behavior. This creates a framework for actively shaping and developing relationships with strategic service providers and thus significantly increasing the benefits of the IT services that are most important for the company’s own core business.