There’s a line I find myself hearing more and more often, said almost as an aside while wrapping up a call and getting back to the “real” stuff: we only care about the go-live. Compliance is your problem.
It’s not always arrogance. Actually, it’s usually the opposite. It’s a line said with the natural ease of someone who thinks compliance is a technical detail, like choosing a framework or deciding whether the button goes on the right or the left.
Except that “detail” is changing shape. And it’s becoming—much faster than the market seems ready to admit—a matter of responsibility.
What the client buys and what the vendor sells
For years, in custom software, we understood each other through a fairly simple implicit pact. The client describes what they want, the vendor builds it, timelines and costs are agreed, and at delivery you test, go to production, close it out.
In this model, the “heavy” responsibility almost always ended up inside the project perimeter. If something went wrong, you talked about bugs, outages, maybe a penalty. Annoying, sure, but manageable.
The point is that in Europe, between 2025 and 2027, a shift in perspective is coming that makes that pact less stable. It’s not a single regulation you can ignore until the legal email arrives. It’s a set of rules that, taken together, push in a very specific direction: software is increasingly treated like a product.
And when something is a product, whoever “produces” it no longer answers only in contractual terms. They also answer for defects, a bit like what happens with an appliance that causes damage because it was designed or assembled badly.
The commercial misalignment that creates friction
This is where the real friction starts—the kind that then blows up in negotiations and quotes.
The client thinks in a linear way and, from their point of view, also correctly. They want a working platform, a portal, an app. They want it by a certain date, with a certain budget, with the features the business needs.
The vendor, however, finds themselves carrying a growing load of requirements that almost never show up in the brief. You don’t find them in user stories, you don’t see them in mockups, the product owner doesn’t ask you for them. And yet they’re things that, if missing, turn a “delivered” project into a “risky” project.
I’m talking about technical documentation done a certain way, component traceability, vulnerability management, transparency around certain algorithmic choices, accessibility. All activities that share one common trait: they cost time, skills, process.
And here comes the dilemma that, in my view, is becoming more and more toxic.
If you include them in the quote, you risk being more expensive than the competitor who doesn’t.
If you don’t include them, you absorb them into margin, work at a loss and, on top of that, take on a risk you never made explicit.
Neither path is sustainable for long.
Why “it’s always been this way” doesn’t hold up anymore
In Italian b2b we’ve spent years inside a “let’s do it, then we’ll see” culture. Light contracts, vague specs, lots of personal trust. Sometimes it worked pretty well too, I won’t deny it. Maybe because the context allowed it.
Now, though, three things are changing at once, and it’s the combination that’s scary.
The first is more “objective” liability. In some scenarios it’s no longer enough to say “we weren’t negligent.” The defect matters and the damage matters. And in certain cases the burden of proving there was no defect shifts to whoever produced or placed it on the market.
The second is the widening of the perimeter. Software isn’t only what you write. It’s also what you integrate: open source libraries, cloud services, third-party api, ai models. And when these things enter the final product, someone has to answer for how they were chosen, integrated, monitored.
The third is time. We’re not talking about a distant future. We’re talking about deadlines between 2026 and 2027. The code you’re writing right now will, in all likelihood, still be there when these rules are fully in force.
So I wonder whether it’s naive to keep treating compliance as a footnote.
The conversation nobody wants to have
The hardest part isn’t understanding the rule. It’s talking about it without blowing up the commercial table.
Try telling a client the quote goes up by 20% because you need to produce compliant technical documentation, implement a vulnerability management process, and keep an up-to-date inventory of components.
In the best case, they answer with a long silence.
In the worst case, they tell you someone else will do it without.
And this is where the market splits. Because that “without” rarely means “more efficient.” Often it means “compliance debt,” i.e., work and risk pushed into the future. A future in which, with the new rules, the bill could land on the vendor, the client, or both.
And yet almost nobody is having this conversation, at least not explicitly. It’s uncomfortable. It forces the client to accept that compliance has a real cost. And it forces the vendor to explain that cost without hiding behind words that sound like bureaucracy.
The cost of invisibility
There’s a paradox that makes everything more complicated. Compliance activities, when done well, are invisible.
A serious vulnerability management system is noticeable when nothing happens.
Technical documentation becomes valuable when something goes wrong.
A component inventory (like an up-to-date list of dependencies) is truly worth it on the day a critical vulnerability drops and you need to immediately understand whether you’re exposed.
The client sees the feature, sees the go-live, sees the interface. Everything that keeps that result standing over time stays under the floor.
So maybe the problem isn’t that the client “doesn’t want to pay.” It’s that they don’t perceive what they’re buying.
If you go to an entrepreneur and say “we need to implement a compliant software bill of materials,” you’ll probably lose their attention after a few words.
If instead you say “we need to be able, within 24 hours, to know whether a newly disclosed vulnerability puts your product—and therefore your liability—at risk,” you’re speaking the language of risk. Which is a much more universal language.
What changes, in practice, without turning everything into a nightmare
For vendors, the path is narrow but fairly clear. You need to stop treating compliance as a hidden cost and start treating it as an explicit service, with a value you can explain.
That means, for example, separating functional development from security and compliance maintenance. Not inside some indistinct “annual retainer,” but with a line item that says what it actually covers. Also because, if one day something ends up in dispute, ambiguity helps no one.
It means putting it in black and white, in contracts, who does what. Who updates dependencies? Who monitors vulnerabilities? Who produces and retains technical documentation? Who decides whether a library can be used or not? Who answers if a component turns out to be compromised?
Today, in many Italian contracts, these questions simply don’t exist. And when a question doesn’t exist, the answer always arrives at the worst possible moment.
It also means learning to sell these activities for what they are: risk reduction. Because the client doesn’t buy “compliance.” They buy the ability not to end up with an outlaw product, with a security incident handled badly, or with a dispute where they have no evidence and documents to defend themselves.
For clients, the mindset shift is the mirror image. Compliance is your problem is no longer a comfortable position, and maybe it never really was a safe one. If you place a digital product on the market, even if you had it developed by third parties, responsibility doesn’t evaporate.
At most you can seek contractual recourse against the vendor. But in the meantime the damage, reputation, incident handling, and commercial consequences are yours to deal with.
A question of market maturity
If you think about it, what’s happening looks like forced growth. The software market—especially custom work—is moving from an artisanal model, based on trust and implicit agreements, to a more industrial model, where responsibilities are defined, processes are documented, and quality isn’t just “it works on my phone.”
That’s not necessarily bad news.
For serious vendors it can become a way to stand out from those who compete only by cutting corners.
For more aware clients it can be a guarantee: knowing the software isn’t built just to go online, but to stay standing, withstand incidents, and not turn into a legal problem at the first jolt.
Maybe the right line today isn’t “compliance is your problem.” It’s something more honest and more useful: compliance is part of the product.
And then yes, it’s a structural cost of making software. The sooner you acknowledge it, the sooner you can manage it. And maybe, with a bit of courage, turn it into a competitive advantage too.
Key takeaways
Liability for a digital product on the market doesn’t evaporate by outsourcing development: it stays with whoever places it there.
Clients don’t buy compliance, they buy risk reduction — translating one into the other is the 2026 sales job.
The Italian b2b culture of light contracts, vague specs and personal trust is a debt someone will pay.
Compliance done well is invisible while it works; that’s why it isn’t seen, and why it must be sold.
Questions & answers
What does it mean that software becomes a product with legal liability?
The new EU Product Liability Directive (PLD, in force from December 9, 2026) and the Cyber Resilience Act treat software as an industrial good. Whoever puts it on the market is liable for defects — not just contractually, but strictly, the way an appliance or drug maker is. The burden of proving the product was compliant shifts to the producer.
If a client says "compliance is your problem," can the IT vendor just ignore it?
No, and neither should the client be saying it. Liability for a digital product placed on the market doesn’t disappear because you had a third party build it: at best you can claim contractually against the vendor, but meanwhile you handle the damage, the incident, and the reputational hit. For the vendor, absorbing it into margin without pricing it is unsustainable long-term.
How do you write a quote that includes compliance without losing to a competitor who doesn't?
Separate functional development from security and compliance maintenance as distinct contract line items, and translate compliance from bureaucratic language to risk language. Not “we implement a compliant SBOM” but “we know within 24 hours whether a newly published vulnerability puts your product at risk.” Clients buy risk reduction, not abstract compliance.
Why doesn't the traditional Italian contractual model hold anymore?
Because it relied on three assumptions that are collapsing together: liability limited to the contractual, perimeter restricted to code written in-house, and time to fix things afterwards. The new 2026-2027 EU rules push liability toward the objective, widen the perimeter to all dependencies (open source, cloud, APIs, AI models), and have deadlines already active. Lightweight contracts and vague specs that worked ten years ago are now a debt someone will pay.
The author
