IT System Houses and Integrators
You manage heterogeneous client landscapes: servers, networks, workstations, specialist applications. You integrate standard software, customise it, write interfaces, operate systems on commission or on-site at clients. Your clients come from all sectors — from mid-sized companies to municipal administration.
The regulatory classification of your work is more difficult than for pure agencies, because you rarely deliver a single "product" but rather a combination of standard software, customising, scripts, configuration, and operations. Precisely this mix is what places you in a regulatory exposed position.
Typical services and their regulatory classification #
Customising and custom developments on standard software #
When you adapt ERP, CRM, DMS, or specialist application systems — through plug-ins, modules, extensions, custom reports, or workflows — you deliver code that runs in production at the client. Under the new Product Liability Directive (Art. 4, Art. 8), you are thus a developer and hence a manufacturer. The CRA (Art. 3 No. 1) covers your developments as "products with digital elements" once they are placed on the market independently or as part of a product.
The common notion "it's just customising" does not hold legally. Once you deliver code, you deliver a product.
Interfaces and integrations #
Integration work — EDI, REST APIs, message brokers, ETL pipelines — is particularly sensitive. Interfaces often process financial, personnel, or health data. Errors in integrations are a common cause of data leaks. Art. 6(1)(c) of the new Product Liability Directive names data loss expressly as a ground for liability.
Infrastructure and operations #
Pure infrastructure services (hosting, managed hardware, network operations) do not directly fall under the CRA. But as soon as you install, configure, and operate software, you become an integrator — and are thereby embedded in your client's supply chain. For NIS2 clients, you are then a direct supplier under Art. 21(3).
On-premise installations of open source software #
When you install open source software (such as a Linux setup, a mail server, a wiki, a ticket system, a monitoring platform) at a client and maintain it, you are responsible for due diligence in the selection and maintenance of these components. The CRA requires in Art. 13(5) "due diligence" for FOSS integration. Those who install must know what they install.
Managed services and second/third-level support #
When you continuously patch, update, monitor, and fix systems, you are in ongoing product maintenance. This falls under the CRA's update obligations (Art. 13(8)) as well as the vulnerability handling obligations (Art. 14).
Which laws apply for which clients #
Two laws apply regardless of the client sector:
- Product Liability Directive (Directive 2024/2853) covers every custom development, every customising, every integration, once the code runs in production at a client. Developers are expressly manufacturers under Art. 8, data loss is a ground for liability (Art. 6(1)(c)), there is no liability cap (Art. 12).
- Cyber Resilience Act (Regulation (EU) 2024/2847) covers your custom developments, modules, interfaces, and installed open source components as "products with digital elements" (Art. 3 No. 1). Art. 13(5) requires "due diligence" for FOSS integration, Art. 14 the reporting and remediation of vulnerabilities.
System houses traditionally have particularly mixed client portfolios. Even a single client from a regulated sector draws the entire process landscape into additional DORA or NIS2 considerations:
- Banks, savings banks, cooperative banks, insurance companies bring DORA requirements from the client relationship. From the moment you have a single financial client, you become an ICT third-party service provider under Art. 2(1)(u) DORA.
- Municipal utilities, energy suppliers, grid operators, water utilities bring NIS2 requirements from the client relationship as essential entities.
- Hospitals, medical networks, care facilities, pharmaceutical companies bring NIS2 plus particularly high requirements for data protection and operational security.
- Municipalities, state authorities, government offices are public administration under NIS2 and are particularly sensitive in supplier assessments.
- Automotive, mechanical engineering, semiconductors are NIS2 sectors as important entities.
- Logistics, freight forwarders, public transport, airports are transport under NIS2.
- Data centres, cloud providers, telecoms companies are digital infrastructure under NIS2.
The breadth of your client portfolio thus becomes a risk: a single client due diligence that reveals weaknesses is enough to jeopardise the business with that client and their industry colleagues.
Concrete consequences #
Legally at stake:
- Unlimited liability under the new Product Liability Directive for every code you deliver and every custom development
- Fines of up to EUR 15 million or 2.5% of annual turnover under CRA (Art. 64), plus loss of EU market access for non-compliance
- Reporting obligations under Art. 14 CRA and Art. 23 NIS2 with deadlines between 24 and 72 hours
- Loss of regulated client segments (banks, insurance companies, energy, health, administration) if you fail the supplier assessment — with mixed system house portfolios, often the greatest economic damage
- Direct DORA supervision of up to 1% of worldwide daily turnover for critical ICT third-party service providers (Art. 50 DORA)
- Personal liability of management in cases of gross negligence
Contractually, your clients will demand:
- Documented security strategy and vulnerability management
- SBOM for deployed and developed software, including transitive dependencies
- Patch management processes with demonstrable response times
- Incident response availability, for DORA clients typically 24/7
- Exit scenario and handover plan (Art. 28(8) DORA)
- Audit access or audit support
- Liability insurance of relevant amount
Operationally, you must establish:
- SBOM creation and maintenance for all customisings and integrations
- Continuous vulnerability monitoring of all deployed components, including transitive ones
- Responsible disclosure channel for reports from the community
- Documented processes for patch rollout at your clients
- Traceability: which client runs which version of which component
Financially, you face:
- Costs for certifications (ISO/IEC 27001 is increasingly standard)
- Building internal security capacity or procuring it as a service
- Insurance premiums that rise significantly for undocumented processes
- Liability risk under the Product Liability Directive without cap
Security is a competitive advantage even without obligation #
System houses live on trust. Your clients give you access to their most important systems — those who can use this access responsibly and document it have a tangible competitive advantage. Even clients who do not fall under CRA, DORA, or NIS2 are increasingly asking for security evidence.
Concretely, this brings: better positioning in tenders, stronger client retention, higher day rates, less friction in audits and insurance, and a clear differentiator from competitors who still consider "we'll manage somehow" a business model.
How OTTRIA supports system houses #
OTTRIA works in the open source part of your supply chain — precisely where heterogeneous system houses have the biggest blind spots:
- SBOM analysis and maintenance across all deployed open source components of your customisings, integrations, and managed installations
- Vulnerability monitoring of all components, including the transitive dependencies that no scanner fully covers
- Silent fix detection through active code analysis — you learn about problems that are never captured as CVEs
- Bug fixing directly in the open source project for components you deploy and that nobody else maintains
- Coordinated response for vulnerabilities that affect multiple of your clients simultaneously
- Audit-ready documentation per client, presentable during supplier assessments under DORA and NIS2
- Steward role for components that are critical for multiple of your clients
You remain responsible for the installations at your clients. OTTRIA ensures that the deployed open source components are monitored, maintained, and documented — as CRA, DORA, and NIS2 require.
Back to overview for software service providers
Further reading