Observability for the EU compliance supplier-cascade

If you sell B2B software in Europe in 2026, you are not directly regulated by NIS2, DORA, the EU AI Act, or IEC 62443. Your customers are. That distinction matters less than it sounds, because every one of those frameworks pushes obligations down the supply chain through contract — and observability vendors, whose product is "see everything that happens in your stack," sit closer to the regulated activity than almost any other supplier category.

This page is for the team at a SaaS vendor (or an industrial integrator, or a managed-service provider) who is staring at a customer's vendor-risk-management questionnaire and wondering what they have to do to actually ship. We will tell you what we do, why we do it, and which sections of which regulation it maps to — because the alternative ("trust us, we're compliant") is not going to pass any procurement function reading this in 2026.

The four frameworks that matter for an observability vendor

NIS2 (Directive 2022/2555) entered into force October 2024 and was supposed to be transposed into national law across all 27 EU member states by 17 October 2024. Most member states blew that deadline; transposition was effectively complete during 2025. NIS2 expands the scope of "essential" and "important" entities far beyond the original 2016 NIS — it now covers manufacturers of critical products, food production, postal/courier services, and digital infrastructure. Read the directive: eur-lex 2022/2555. Article 21 mandates "appropriate and proportionate technical, operational and organisational measures" — including supply-chain security (Art. 21(2)(d)) — and Article 23 mandates 24-hour early warning notification of significant incidents.

DORA (Regulation 2022/2554) is in force since 17 January 2025. It applies directly (regulations don't need transposition) to financial entities and to their ICT third-party providers. The mechanism that matters for vendors is Article 28-30, which requires regulated financial entities to maintain a Register of Information of all ICT TPP arrangements, conduct due diligence before contracting, and include specific contractual provisions (audit rights, sub-contracting controls, exit strategies). Read it: eur-lex 2022/2554.

EU AI Act (Regulation 2024/1689) entered into force August 2024 with a staggered application calendar running through 2026 and into 2027. The pieces relevant to an observability vendor are Article 12 (mandatory logging for high-risk AI systems) and Article 14 (human oversight). Most observability vendors are neither providers nor deployers of "AI systems" as the Act defines them — but the moment you offer "AI agent observability" or "LLM monitoring" you start to look like a tool that helps a deployer meet Art. 12. Read it: eur-lex 2024/1689.

IEC 62443 is not EU law — it is an IEC industrial cybersecurity standard, but it gets cited contractually in industrial procurement specs across Europe and is referenced in NIS2 implementing acts as a source of "appropriate measures." 62443-3-3 (system security requirements) and 62443-4-2 (component security requirements) are what an industrial customer's procurement team will read in your security questionnaire.

What "supplier-cascade" actually means

The customer's regulator obliges them. The customer pushes that obligation onto vendors via contract. The vendor must demonstrably comply, or the customer can't contract with them, or has to disclose them as a "concentration risk."

For NIS2 — Article 21(2)(d) requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." In practice this is becoming standardised security questionnaires citing ISO 27001, SOC 2, or 62443 as the proof artefact. The NIS2 supplier-cascade post walks through the actual obligations word-by-word.

For DORA — Article 30 requires specific contractual provisions in every ICT TPP contract: descriptions of services, locations of data, audit-rights for the customer and the regulator, sub-contracting limitations, exit strategies. The DORA-for-observability post lays out the actual addendum.

For the AI Act — Article 12(1) requires high-risk AI systems to have logging that "ensures a level of traceability of the AI system's functioning throughout its lifecycle that is appropriate to the intended purpose of the system." That's a deployer's obligation. But if you're selling an AI-monitoring tool to that deployer, you're the implement they use. See the AI Act tooling post.

For IEC 62443 — section 3-3 SR (Security Requirements) cascade to the system integrator, who then cascades them to component suppliers. A monitoring vendor is a component supplier in this model.

What Sutrace actually does about it

We are an observability platform, not a compliance product. We do not certify your customers' compliance. What we do is build the architecture so that you, the vendor, can make the supplier-cascade representations honestly.

EU residency, default-on. Data plane is europe-west3 (Frankfurt). No US logging tier. No "support tooling that occasionally accesses customer data from California". The architecture is documented on the trust page.

SCCs, IDTA, Swiss overlay — we sign the 2021 EU Standard Contractual Clauses (Modules 2 and 3) on request, the UK ICO IDTA, and the Swiss FDPIC overlay. Walked through in the DPF-survival post.

DPA: a real signed Data Processing Agreement under GDPR Art. 28, with a sub-processor list, listed in the DPA. Not a click-wrap; a counter-signed document.

24-hour incident-notice clause in every customer contract, matching NIS2's "early warning" timeline (Art. 23). When a security event meaningfully affects your tenant, we tell you within 24 hours, with the information required to populate your own NIS2 / DORA notification.

Audit rights under DORA Art. 30(3) — for financial-entity customers, we agree to onsite audits (with reasonable notice and at the customer's cost), pen-test reports, and the right of regulators to inspect us as a "third party of a regulated entity." We do not negotiate this away.

Logging suitable for AI Act Art. 12 — when you use Sutrace to monitor an AI agent your team has deployed, the resulting logs are immutable, timestamped to within ±50 ms of UTC, retained per your configured retention policy, and exportable in a format suitable for evidencing under Art. 12. We do not interpret the logs for you — that's the deployer's call — but we make the logs admissible.

What this is not

We are not a "compliance platform". We don't generate SOC 2 reports for you. We don't write your DPIAs. We don't certify your AI systems as low/limited/high-risk. There are good products that do those things — Drata, Vanta, Secureframe — and you should still be using one. Sutrace is the infrastructure layer that those compliance frameworks treat as a sub-processor; we make sure that layer doesn't blow up your audit.

We are also not a CTPP under DORA — that designation is reserved by the ESAs for a small number of pan-European hyperscale TPPs (think AWS, Microsoft, Google). The CTPP regime is far above us. What we do is comply with the regular DORA TPP obligations that apply to any ICT vendor of a financial entity.

Pricing of compliance posture

The observability product itself is priced on the pricing page. The compliance commitments — DPA, SCCs, IDTA, custom 24-hour incident clause, audit cooperation — are included on every paid plan. We don't charge a "compliance tier". The infrastructure work to be EU-resident-by-default has already been done; charging for it would be charging twice.

For financial-entity customers under DORA we provide a counter-signed addendum at no charge. For NIS2 essential-or-important entities we provide the supplier-cascade questionnaire response in our standard format. For high-risk AI Act deployers we provide the Art. 12 logging configuration guidance. None of these conversations are gated.

FAQ

Are you NIS2-compliant? NIS2 doesn't certify vendors — it regulates the entities that use vendors. We are not a regulated entity under NIS2 ourselves (we're below the size thresholds and outside the listed sectors). What we do is produce evidence that your NIS2 supply-chain due diligence (Art. 21(2)(d)) finds satisfactory. The full position is in the NIS2 cascade post.

Are you DORA-compliant? DORA applies directly to ICT TPPs of regulated financial entities. If you are such an entity, we'll counter-sign the Art. 30 addendum and cooperate with audit requests. We are not a Critical TPP (CTPP) — that's a designation only the ESAs can apply, and it's reserved for hyperscale providers. See the DORA post.

Are you AI-Act-compliant? We are a tool, not an AI system as defined in Art. 3(1). We do not place AI systems on the market, and we do not deploy AI systems as a deployer. When our customers use Sutrace to monitor AI agents they have built, we make sure the logging satisfies Art. 12 traceability. The AI Act post explains why this distinction matters.

Where exactly is the data? europe-west3 (Frankfurt, Germany) for the data plane. Auth provider (Firebase Identity Platform) is configured for EU residency. Backups are within the EU. No data leaves the EU under normal operation. The DPF-survival post explains the legal architecture.

What are your sub-processors? Listed on the DPA page. Currently four. We notify customers via email at least 30 days before adding any sub-processor.

Do you sign individual customer DPAs? Yes — but our standard DPA is fine for 95% of customers and we encourage starting from it. Custom redlines are accepted from enterprise customers. SMB customers usually click-accept the standard DPA.

Will you let our regulator audit you? Yes. DORA Art. 30(3) audit-rights are non-negotiable for financial-entity customers. We extend the same right to NIS2 essential/important entities even though it's not strictly required, because it's cheaper than arguing about it.

What if a Schrems III decision invalidates the Data Privacy Framework? We don't rely on the DPF for EU-to-US transfers because we don't make EU-to-US transfers. The data plane is EU. The legal architecture is belt-and-braces and explained in the DPF-survival post. A Schrems III decision changes nothing about your data location.