Technology law in 2026: what startups and scale-ups really need to know

Technology law is no longer an afterthought

For many tech companies, technology is no longer at the edge of surgery, but at the heart of it. Products run on software, teams work with AI, processes are data-driven and services are digital. This also changes the legal playing field.

Where technology law used to be seen as a specialist corner of IT contracts and privacy, it is now touching on much broader issues. Think about how to use AI responsibly, how to get digitally signed, what data to share, how to deal with cyber incidents and who is liable if software or a digital product causes damage.

This is extra relevant for startups and scale-ups. Young growth companies in particular are moving fast, testing new technology early and often working with scalable digital products or services. Then it's important to know which rules not only exist on paper, but also really affect your product development, contracts, governance and risk management.

AI rules are getting more and more teeth

The AI Act has a risk-based approach. This means that not every AI system is treated in the same way. The severity of the obligations depends on the risk that a system poses to health, safety or fundamental rights.

Broadly speaking, we work with four categories: unacceptable risk, high risk, limited risk and low or minimal risk. That seems clear, but in practice, this layout quickly requires a sharp legal and operational assessment.

Banned AI is really prohibited

AI systems with an unacceptable risk are prohibited. These are applications that, according to the European legislator, are not compatible with fundamental values within the EU. Examples include systems that manipulate people subliminally, exploit vulnerabilities, collect untargeted facial images for recognition databases, social scoring, or real-time biometric identification in public spaces.

For startups, that may sound far from bed, but it's not always the case. A young company can also build or integrate functionalities that at first glance seem innovative, but are directly in the danger zone from a legal point of view. Especially when a product works with image, profiling, behavioral influence or synthetic content, a quick technical sprint is not enough. Then you first need to know whether the function is allowed at all.

In addition, organizations that use AI must also pay attention to AI literacy. In other words, it is expected that there is knowledge and awareness within an organization about the use of AI. For scale-ups that roll out AI widely within sales, HR, support or product teams, this is not a theoretical point, but a practical organizational issue.

High-risk AI requires serious compliance

The focus of the AI Act lies on high-risk systems. These are AI systems that can pose a significant risk to health, safety or fundamental rights. This can be the case, for example, when AI is part of regulated products, but also when AI is used in sensitive areas such as biometrics, education, personnel selection, creditworthiness, law enforcement or certain public services.

For startups and scale-ups, it is particularly important that qualification depends not only on the technology itself, but also on the context in which it is used. A tool that sorts resumes or reviews candidates can legally fall into a completely different regime than a generic productivity app. The same applies to AI solutions that are offered to parties in regulated sectors.

In addition, the AI Act distinguishes between different roles, such as the provider and the person responsible for use. This is important for companies that not only develop technology themselves, but also integrate third-party models, offer white-label solutions or market AI under their own brand. So in practice, the question is not just: what does the system do? But also: what role does your company operate in exactly?

For growth companies, this is relevant when it comes to investments, procurement and commercial contracts. Those who build or sell AI need to think early about documentation, responsibility sharing, product claims, and internal control. Those who primarily use AI should know what terms of use, instructions, and restrictions apply.

Transparency remains relevant even with lighter AI

Not all AI falls into the toughest categories. For systems with limited risk, transparency obligations mainly apply. For example, a user must be able to understand that they are interacting with an AI system. AI-generated content must also be recognisable as artificial.

This is particularly relevant for companies that use chatbots, generated texts, synthetic images or automated customer interaction. In practice, we see that this type of tooling is being rolled out quickly because it is commercially attractive and technically accessible. But even then, a useful feature is not automatically legally neutral.

Electronic signing remains practical, but not risk-free

Digital contract formation is often the standard for startups. Shareholder documentation, employment contracts, SaaS contracts and commercial deals are rarely sent around with a wet signature anymore. However, electronic signing does not mean that every form of digital consent automatically has the same legal position.

The rules distinguish between ordinary, advanced and qualified electronic signatures.

For example, a regular electronic signature can consist of a scanned signature or a typed name under an email. An advanced electronic signature must be more closely linked to the signer and set up in such a way that identification is possible and changes are visible afterwards. The qualified electronic signature is the heaviest variant and has the same legal effects as a handwritten signature in the EU.

The question is often not whether something is useful, but whether it is sufficiently reliable.

In the Netherlands, ordinary and advanced electronic signatures can have the same legal effects as a qualified signature, provided that the method used is sufficiently reliable considering the purpose and circumstances of the case.

That is exactly where the nuance lies in practice. Indeed, the law does not generally specify when that reliability test has been met. As a result, it is difficult to say by default that one tool or method is always enough.

For simple transactions, a lighter form is often more likely to suffice. As the stakes grow or the transaction is more complex, the importance of a stronger form of signing increases. For startups and scale-ups, this is relevant for investment rounds, governance documentation, IP transfers and other agreements that you want to be able to provide real proof of later.

If a discussion arises afterwards about the reliability of an electronic signature, this can directly affect the evidential value of the document. This is not only about whether an agreement was substantively desirable, but also whether you can still properly demonstrate that it was legally concluded.

Don't take evidence agreements too lightly

A practically relevant point is that parties can agree in advance about the level of reliability of a regular or advanced electronic signature. This can reduce ambiguity in evidence discussions.

For growing companies, this is not an unnecessary luxury. Especially when many contracts are concluded remotely and different teams have agreements signed independently, it pays to have a clear signing policy. Not every agreement requires the same level of security. But without an internal line, a patchwork of tools, processes and evidence risks quickly arises.

The European Digital Identity Wallet can change digital identification

The review of eIDAS laid the foundation for the European Digital Identity Wallet, often abbreviated as the EUDI Wallet. This digital wallet should make it possible to securely store and share identity data, login details and other attributes for online and offline authentication.

An important starting point is that the user himself has control over his personal data. At the same time, strict requirements apply to security and data processing.

For natural persons, this wallet must be available free of charge. Member States must offer at least one certified wallet by the end of 2026. In the Netherlands, work is underway on a public NL wallet.

What does that mean for tech companies?

This is particularly interesting for startups and scale-ups because digital identification and trust are becoming increasingly important in online services. Companies that work with onboarding, account access, digital verification, or signing may face new user expectations and possibly new technical integrations.

In addition, the wallet can also influence how electronic signatures are placed. Qualified electronic signatures are expected to become more accessible when they are more easily available via this type of infrastructure.

For tech companies, this does not mean that everything has to be different today. However, in product development and compliance, it is wise to already take into account a future where reliable digital identification will be standardized and more widely used. Especially for platforms, fintechs, HR-tech, healthtech and B2B software with identification processes, this is a development to follow closely.

DORA not only affects financial institutions, but also their tech suppliers

DORA has been applicable since January 2025. This regulation contains uniform rules for the digital operational resilience of financial institutions. The goal is to better manage ICT risks and to harmonize fragmented rules within Europe.

At first glance, DORA seems to be primarily a topic for banks, insurers and other financial institutions. But for startups and scale-ups, the indirect impact is often at least as great.

If you deliver to the financial sector, you will automatically come across DORA

Many young tech companies provide software, cloud solutions, data solutions or other digital services to parties in the financial sector. Once you're in that chain, DORA requirements often affect contract negotiations, due diligence, security questionnaires, audit rights, and operational obligations.

DORA includes rules on ICT risk management, incident reporting and outsourcing. In addition, there are delegated regulations that further specify topics, such as classification and reporting of incidents, issues for outsourcing policies, criteria for subcontracting and maintaining information registers about ICT contracts.

For suppliers, this means that customers in the financial sector often want to know in depth how you have set up security, continuity, governance and subcontracting. This requires mature contracts and processes. A startup that is technically strong but has not yet established much operationally can get stuck commercially.

The definition of ICT services is important

A relevant development is that it has been clarified when a service with ICT aspects is seen as an ICT service under DORA. If a service is primarily a regulated financial service and ICT is only supportive or inextricably intertwined, that service does not automatically fall under DORA's ICT service concept. If it concerns an independent service that meets the definition of ICT services, that may be different.

For tech suppliers, that distinction is important. It also determines what contractual expectations arise and how customers treat you as a relevant Dora supplier.

It is also important that certain ICT suppliers can be identified as critical. This underlines that European supervisors are increasingly taking chain dependency in digital services seriously.

The Data Act puts pressure on data access and exitability

The Data Act has been in force since September 2025 and introduces a new regime for data access and use. For many tech companies, this is one of the most practical digital rules, precisely because the regulation deeply interferes with products, services and contracts.

The regulation has roughly two main themes: data from connected products and related services, and rules for data processing services such as SaaS, IaaS and PaaS.

Data from smart products must be more accessible

With connected products, such as smart devices and other IoT solutions, users get the right to access data generated by their use. Ideally, this should be done directly. If that is not possible, the data holder must still make the data available.

In addition, users can request that that data be provided to third parties, except in case of abuse. At the same time, the regime also includes safeguards for data holders, for example concerning trade secrets, technical protection measures and the ban on using received data to develop competing products.

For startups that build or operate connected products, this means that data is no longer just an internal asset issue. The question of who gets access, in what form, under what conditions and with what protection also becomes legally relevant. Product architecture, API choices and contracts thus directly affect compliance.

Vendor lock-in is being addressed more emphatically

The second major theme is combating vendor lock-in in data processing services. Switching between providers must be realistically possible. This requires not only contractual space, but also technical provisions.

Providers should not hamper switching, be transparent about restrictions and maintain an online register of relevant data structures, data formats and interoperability specifications. Agreements must also include certain minimum elements, such as a maximum notice period of two months. From January 2027, switching costs may no longer be charged.

For SaaS companies and cloud-focused scale-ups, this is a strong message. Growth is often built on customer retention, but it should not be based on legal or technical friction that artificially complicates switching. The commercial reflex to retain customers for as long as possible must therefore be weighed against rules that actually aim to promote mobility and interoperability.

This requires a sharp contract review, but also product choices. How exportable is data? How transparent are you about restrictions? And how do you set up offboarding without pressuring the customer unnecessarily?

NIS2 puts the duty of cyber care and reporting higher on the agenda

The Netherlands is lagging behind in implementing NIS2. Implementation must take place via the Cybersecurity Act, but the core of the development is already clear: for many organizations, cyber resilience will be more firmly embedded in the legal framework.

NIS2 distinguishes between essential and important entities. This distinction is particularly relevant for supervision and enforcement. The range of applications depends largely on the sector in which a company operates.

Cybersecurity will be a governance and organizational theme

The core obligations under NIS2 are the duty of care and the duty to report. The duty of care means that appropriate and proportionate technical, operational and organizational measures must be taken to manage risks to network and information systems and to prevent incidents or limit their consequences.

For startups and scale-ups, this means that cybersecurity is less and less just an IT question. It affects governance, supplier choices, documentation and decision making. Especially for companies in digital infrastructure or ICT services, the content of those obligations can be further colored through European implementing rules.

One notable element is the apply-or-explain approach for certain entities. If, according to an organization, a measure is inappropriate, not applicable or not feasible, it must be documented in an understandable way. This shows that compliance is not just about doing things, it's also about being able to explain.

Incidents must be reported in phases

The reporting obligation under NIS2 is also practically relevant. Significant incidents must be reported in phases to the competent authority and the designated CSIRT. The notification therefore does not consist of one single message, but a process with an early warning and subsequent updates.

For companies that fall within the scope, this means that an incident response plan must not only work technically, but also legally and organizationally. After all, you must be able to assess in time whether an incident is significant, what consequences are visible, what measures have been taken and what the recovery forecast is.

This can be a vulnerable point, especially for fast-growing tech companies, where processes are sometimes still under development. Not because there are no good engineers, but because responsibilities, escalation lines and documentation are not yet tightly organized.

Software and digital services come into greater focus when it comes to product liability

One of the most drastic developments for tech companies is the renewal of the product liability regime. The new directive updates classic rules for a digital economy where software, AI and digital services are increasingly central.

Software is no longer a side issue

An important change is that software is explicitly classified as a product, regardless of the method of delivery. Digital manufacturing files and certain digital services that are necessary for the functioning of a product also fall within the scope.

This is fundamental for startups and scale-ups. Where product liability used to be mainly associated with physical products, software is now also coming into the picture much more emphatically. This is relevant for companies that develop apps, embedded software, cloud-controlled functionalities or software-driven devices.

At the same time, source code and free open source software are beyond the scope. This nuances the picture, but does not alter the fact that commercial software products and digital services are becoming legally much more visible in liability discussions.

More parties may be liable

Not only producers and importers can come into the picture. Other market participants, such as parties that radically change products, providers of associated digital services and, in certain cases, online platforms, can also be held liable.

This is important for the startup ecosystem. Many companies do not operate in one classic role. They develop, integrate, distribute, host, update, and scale via platforms or partners. As a result, the question of who is legally responsible can become more complex the more digital and multi-layered products are built.

The concept of deficiency has also been broadened to include digital aspects, such as cybersecurity regulations, product connectivity, the ability to keep learning and the absence of necessary security updates. This makes liability not only a matter of an error on delivery, but also of ongoing digital responsibility.

The position of injured parties is getting stronger

The new rules also strengthen the position of injured parties. The burden of proof is reduced by presumptions and there is more room to access relevant evidence, especially for technically complex products.

In addition, the concept of damage has been expanded. Not only personal damage and property damage in the private sphere count, but also loss or corruption of non-professionally used data.

For tech companies, this means that product safety, update policy, logging, documentation and internal decision-making are becoming even more important. Not only to prevent damage, but also to be able to explain later what choices were made and what safety measures were taken.

What founders and legal teams can already do with this today

All these developments have their own pace, scope and level of detail. However, there is a clear thread: European digital regulations are moving from abstract policy to concrete obligations that directly interfere with products, processes and contracts.

For startups and scale-ups, it is therefore wise not to think in silos by topic. In practice, AI, data, cyber resilience, digital identification and liability are often interrelated. An AI feature can touch on transparency, contracts, evidence, security and product responsibility at the same time.

At Startup-Recht, we regularly see that the biggest risks do not arise because a company does nothing at all, but because legal, technical and operational choices are made separately. A product team builds something new, sales conclude contracts there, operations takes care of the tooling and legal only joins if a customer or investor already asks. Then you'll be behind the facts more quickly.

A better approach is to determine early where your company is really affected. Do you use AI or provide AI solutions? Do you work with digital signatures in crucial processes? Are you building on data from connected products? Do you deliver to financial institutions? Are you potentially covered by NIS2? And are you developing software or digital services that may soon fall more explicitly under product liability?

Those who ask these questions in a timely manner are much better able to prioritize.

Conclusion: technology law is maturing, and your company must join

In 2026, technology law will no longer be a collection of separate specialist rules. It has become a mature legal playing field in which European legislation has an increasingly direct effect on how tech companies build, sell, secure and scale up.

For startups and scale-ups, the key message is clear: don't wait for compliance to become a brake. Use these developments to make your product, processes and contracts smarter and more future-proof. Companies that do this well not only reduce their legal risks, but also build more trust with customers, investors and partners.

‍