Have you ever wondered why it is so difficult to sell in Europe?

You are close to an agreement with a new customer. The discussions have gone well, the solution is a good fit, and the commercial terms are almost settled.

Then the questions arrive.

How do you protect the customer's data? Who can access it? Which subcontractors do you use? What do you do if something goes wrong? And can you document your answers?

To a smaller company, it can feel as if the customer has suddenly made a straightforward deal unnecessarily complicated. To the customer, those same questions may be necessary before you can be approved as a supplier at all.

The difference is often not that one party takes security seriously and the other does not. They are simply looking at the requirement from opposite ends of the chain.

Requirements do not stop with the wording of the law

European rules such as the GDPR, NIS2, DORA, the AI Act and the Cyber Resilience Act have different purposes and scopes. They do not necessarily apply directly to every company.

But their impact does not stop with the organisations named in the legislation.

When a company is responsible for the security, data or resilience of its delivery, it also has to consider the suppliers on which that delivery depends. That responsibility is translated into procurement requirements, contract terms, security questionnaires and requests for documentation.

This is how European legislation can become a question in the inbox of a company that does not consider itself directly covered by the law.

For the security leader or management of the larger company, supplier requirements are therefore a way to understand and manage a real risk. If an important supplier loses data, suffers an attack or cannot deliver, the impact does not disappear simply because the incident occurred outside the company's own walls.

For the smaller supplier, this explains why the questions are being asked in the first place.

Requirements move from one company to the next

Imagine a small software company that wants to sell its solution to a bank, a municipality or a large industrial company.

The customer needs to know whether the solution can be used responsibly in its business. It therefore asks about access control, data processing, incident handling and the use of subcontractors.

The software company may not operate the infrastructure on which its solution is built. It may use a cloud platform, external development tools or other technical services. To answer the customer's requirements properly, the software company also needs to understand what those suppliers do.

The requirement has now travelled from European legislation or a business risk to the large company, on to the software supplier and perhaps from there to another subcontractor.

Eventually it reaches a management team that must make a decision: Can we already stand behind what the customer is asking for? Does something need clarification? Do we need to change anything? Or is the requirement so extensive that the deal no longer makes sense?

Not every customer requirement is a direct legal requirement. Some come from the customer's own risk assessment, internal policies or previous experience. It is therefore not enough simply to ask which law the requirement comes from.

What also matters is the outcome the customer is trying to achieve. A request for documentation may, for example, be the customer's way of making sure that a critical supplier can actually respond if something goes wrong.

Four questions before you do anything bigger

As a smaller company, you do not need to begin by mapping the entire European requirements landscape. The immediate need is usually much more concrete: understanding what the requirement you have received means for the business opportunity in front of you.

Start with four questions:

1. What exactly have we been asked to do or provide?
2. What will stop if we cannot answer?
3. What can we already stand behind honestly and document?
4. What clarification do we need from the customer before spending time or money?

These questions help you distinguish between what must be answered now, what you already have under control, and what requires a genuine decision. This helps you avoid both ignoring an important requirement and launching a large compliance project before you know whether it is necessary.

The same questions are relevant to the company setting the requirement. If you ask a supplier to invest time or money, you should be able to explain what you actually need, which decision depends on the answer, what evidence will be sufficient, and where the supplier can obtain clarification.

This does not make the requirements less serious. It makes them more useful.

The next step is therefore not to collect even more requirements. It is to understand what the specific requirement is actually meant to achieve.

Official sources

• The European Commission on NIS2
• The DORA regulation on EUR-Lex
• The European Commission on the Cyber Resilience Act
• The European Commission on the AI Act and its timeline
• The European Commission on GDPR principles and accountability

This article provides general information and is not legal advice. Whether a specific rule set applies to a company or a product requires an individual assessment.