MSP, Cloud, and DevOps Service Providers

You operate systems for your clients: private and public cloud, Kubernetes clusters, CI/CD pipelines, observability stacks, infrastructure-as-code environments, security tooling, and much more. You deliver a mix of operations, standard tools, and your own code: Terraform modules, Helm charts, Ansible playbooks, custom operators, glue code, runbooks.

Managed service providers and cloud service providers are in a particularly exposed regulatory position: you typically have operational responsibility plus access to your clients' systems plus your own code in the environment. This combination makes you the ideal target for supplier assessments under DORA and NIS2.

Typical services and their regulatory classification #

Managed cloud and managed Kubernetes #

Pure operations do not primarily fall under the CRA but directly under NIS2 supplier assessments (Art. 21(3) NIS2) and DORA third-party risk (Art. 28 DORA). Your client must include you in their DORA information register if they are a financial institution. This affects every MSP that has a banking, insurance, or asset management client.

Infrastructure-as-code and automation #

Terraform modules, Pulumi configurations, Helm charts, Ansible playbooks, Crossplane compositions — this is code that you write and deploy at clients. Errors in IaC lead directly to operational disruptions or data leaks. Art. 6(1)(c) of the Product Liability Directive covers such errors directly.

When you deliver modules as products to multiple clients, these modules become products with digital elements under the CRA.

CI/CD pipelines and DevSecOps tooling #

When you build pipelines for clients, the chain of runner, image registry, secrets handling, signing, and deployment is security-critical. Supply chain attacks target exactly this point. NIS2 and DORA assess such processes particularly closely.

Observability and security tooling #

Observability stacks (Grafana, Prometheus, Loki, ELK) and security tooling (SIEM, SOAR) process the most sensitive operational data. As operator of such stacks, you are a data processor and often a processor in the GDPR sense — with liability also for third-party libraries in these components.

Custom operators, controllers, glue code #

Self-written code in Kubernetes operators, Lambda functions, cloud functions, or glue scripts is independent product code under the CRA. It is introduced into your client's system landscape and is thus your delivered software.

Pen tests, hardening, incident response #

When you provide incident response or penetration testing for financial or NIS2 clients, you may be included in DORA's threat-led penetration testing regime (Art. 26 DORA). The requirements there are significant — with formalised roles, evidence, and authority involvement.

Which laws apply for which clients #

Two laws apply regardless of the client sector:

Product Liability Directive (Directive 2024/2853) covers any code you deploy at clients — Terraform modules, Helm charts, operators, Lambda functions, glue scripts. As developer, you are a manufacturer under Art. 8, data loss is a ground for liability (Art. 6(1)(c)), and liability is uncapped (Art. 12).
Cyber Resilience Act (Regulation (EU) 2024/2847) covers your reusable modules, custom operators, and tool bundles as "products with digital elements" (Art. 3 No. 1). Art. 13(5) requires due diligence for open source component integration — and base images, pipelines, and cloud tooling contain particularly many of these.

MSP and cloud clients are also often in regulated sectors — the regulatory breadth of your portfolio is correspondingly large:

Financial sector: DORA in full force. Every MSP working for a DORA-regulated client is an ICT third-party service provider. Depending on function, potentially "critical" under Art. 28(5) DORA.
Cloud hyperscaler resellers and integrators: You are part of the sub-outsourcing chain. DORA Art. 28 and the ITS information register regulation examine this chain closely.
Energy, utilities: NIS2 as essential entities. Cloud operations for municipal utilities immediately constitute supply chain under Art. 21(3).
Health, hospitals: NIS2 plus particularly high data protection requirements. Managed cloud for a hospital is highly regulated.
Public administration: NIS2 plus BSI requirements plus C5 requirements for cloud services. Particularly strict for federal and state authorities.
Digital infrastructure itself: NIS2 sector. Data centres, cloud providers, and hosting providers are essential entities under NIS2.
Automotive, industry, semiconductors: NIS2 as important entities. DevOps service providers in production networks are core suppliers.

Notable: MSPs are often the only external service providers with direct production access. Supplier audits are correspondingly rigorous.

Concrete consequences #

Legally at stake:

Unlimited liability under the Product Liability Directive for any deployed code — IaC modules, operators, glue scripts, images
Fines of up to EUR 15 million or 2.5% of annual turnover under CRA (Art. 64) for reusable modules and custom operators
Direct DORA supervision with fines of up to 1% of worldwide daily turnover (Art. 50 DORA), if you are classified as a critical ICT third-party service provider of a financial institution — this particularly affects large MSPs with a relevant financial portfolio
Loss of the financial and critical infrastructure segment if you fail the supplier due diligence. MSPs are particularly rigorously assessed because of their system access
Loss of certifications (ISO/IEC 27001, SOC 2, C5, TISAX) for documented security deficiencies — and thus immediate loss of entire client groups
24/72-hour reporting obligations under Art. 14 CRA, Art. 23 NIS2, Art. 19 DORA — often combined in a single incident
Personal liability of management in cases of gross negligence

Contractually, your clients will demand:

Documented security strategy and ISMS (ISO/IEC 27001 is becoming a standard requirement)
SBOM for deployed tools, images, charts, and custom modules
Supply chain evidence (signed images, SLSA, provenance)
Incident response with 24/7 availability for DORA clients
Exit scenario under Art. 28(8) DORA
Auditability and audit access for client auditors and supervisory authorities
Penetration tests and regular security reviews

Operationally, you must establish:

SBOM generation for all deployed container images and pipelines
Monitoring of all deployed open source components, including transitive dependencies in base images and Helm charts
Responsible disclosure channel and vulnerability handling under Art. 14 CRA
Patch strategy across all client systems with defined response times
Change management that auditors can follow
Continuous review of your own tool landscape for vulnerabilities

Financially, you face:

Ongoing certifications (ISO/IEC 27001, SOC 2, C5, TISAX depending on sector)
Building internal security capacity or procuring it as a service
Insurance requirements that are particularly high for MSPs
Unlimited liability risk under the new Product Liability Directive for custom code

Security is a competitive advantage even without obligation #

MSPs and cloud service providers compete fiercely for trust. Those who sit in clients' production systems are asked how their own supply chain is secured — and increasingly also where no regulation applies. Demonstrable security is a differentiator that works directly in the sales conversation.

Concretely, this brings: higher chances in tenders with security requirements, easier audits under ISO/IEC 27001, SOC 2, or C5, more favourable insurance premiums, stronger client retention, and clear differentiation from competitors who can only answer security questions on demand. What you invest in compliance simultaneously serves as a sales argument.

How OTTRIA supports MSPs and cloud service providers #

The open source share in modern cloud stacks is overwhelming: base images, Kubernetes, Helm charts, operators, observability tools, CI/CD tools, security tooling — almost everything is open source. The due diligence burden is correspondingly large. OTTRIA takes over this part:

SBOM analysis and maintenance for base images, Helm charts, CI/CD pipelines, and custom modules
Real-time vulnerability monitoring across all deployed components, including transitive ones
Silent fix detection in cloud-native projects through active observation of commit histories and security processes
Bug fixing directly in the open source project — for example in container runtimes, Kubernetes operators, observability stacks
Early warning through OTTRIA's steward role in critical open source projects — you learn about vulnerabilities before the CVE is published
Audit-ready documentation per client, per environment, per pipeline — presentable during DORA, NIS2, and C5 audits
Steward support for clients who want to deploy OTTRIA as steward for critical open source components
Responsible disclosure channel for your client environments and custom modules

You focus on operations, automation, and client advisory. OTTRIA delivers the open source due diligence part that no MSP can fully cover internally — and the audit-ready evidence that your clients must demand under DORA and NIS2.

Schedule initial consultation

Back to overview for software service providers