all posts

compliance

NIS2 supplier-cascade — what observability vendors actually have to commit to

NIS2 has been in force since October 2024, with national transpositions through 2025. Most observability vendors are not directly regulated, but their customers are. The cascade obligations under Article 21(2)(d) and the 24-hour rule of Article 23 hit vendors via contract.

By Akshay Sarode· April 12, 2025· 14 min readnis2compliancesupplier-riskeu

NIS2 supplier-cascade — what observability vendors actually have to commit to

The single most common compliance question we field from customer security teams in 2026 is some variant of: "Our company is in scope of NIS2. Are you?" The answer is "no, we're not directly in scope, but here is everything we do that should make you treat the supplier-cascade element of your obligations as satisfied." This post is the long-form version of that conversation, with the actual articles cited and the actual contractual language we sign.

NIS2 — formally Directive (EU) 2022/2555 — entered into force on 16 January 2023. Member States were obliged to transpose it into national law by 17 October 2024. Most missed that deadline (Germany finalised its NIS2UmsuCG in 2025; the Netherlands, Spain, France, and Italy each took a similar trajectory through 2025). By early 2026, transposition is effectively complete across the EU-27 with national-flavour variations. The Commission published a list of essential and important entities for guidance, but the real work happens at member-state level.

Who is regulated, who is not

The directive's scope is set by Article 2 and Annex I/II. Annex I lists "essential entities" — energy, transport, banking, financial market infrastructure, health, drinking water, waste water, digital infrastructure (TLD registries, DNS providers, top-level cloud, data centres, content delivery networks, trust service providers, public electronic communications), ICT service management (B2B), public administrations, space. Annex II lists "important entities" — postal/courier, waste management, manufacture and distribution of chemicals, food production/distribution, manufacturing of medical devices/computers/electronics/machinery/motor vehicles/transport equipment, digital providers (online marketplaces, search engines, social networks), research.

A SaaS observability platform with a few hundred customers across Europe is not in either Annex as long as it stays below the relevant size thresholds (Article 2(1) — generally 50+ headcount or €10M turnover). Sutrace today is below those thresholds.

But — and this is the bit that matters — Article 21(2)(d) requires regulated entities to manage "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". That obligation cascades onto vendors via contract.

The four obligations that actually cascade

In practice, a regulated NIS2 customer cascades four things onto its observability vendor:

1. Documented "appropriate technical, operational and organisational measures" (Art. 21(2))

The directive's Article 21(2) lists ten categories of required measures. Customers will ask you to demonstrate each one. The categories are:

(a) policies on risk analysis and information system security (b) incident handling (c) business continuity, backup management, disaster recovery, crisis management (d) supply chain security (e) security in network and information system acquisition, development and maintenance (f) policies and procedures to assess effectiveness of cybersecurity risk-management measures (g) basic cyber hygiene practices and cybersecurity training (h) policies and procedures regarding the use of cryptography and, where appropriate, encryption (i) human resources security, access control policies and asset management (j) the use of multi-factor authentication or continuous authentication solutions, secured voice/video/text communications, and secured emergency communication systems within the entity, where appropriate

For each, your customer wants a document, a control test, and an evidence artefact. We map each one to a control statement in our SOC 2 Type II report and, where applicable, to a sub-section of our trust page. The standard package we send to NIS2-cascading customers is: SOC 2, ISO 27001 status, sub-processor list, DPA, the trust page URL, and a signed cover letter affirming Art. 21(2) compliance for the in-scope service.

2. The 24-hour early-warning regime (Art. 23)

Article 23 requires regulated entities to submit an "early warning" to their CSIRT (national computer security incident response team) within 24 hours of becoming aware of a "significant incident", followed by an "incident notification" within 72 hours, and a final report within one month. A "significant incident" is defined as one that has caused or is capable of causing severe operational disruption or financial loss, or has affected (or is capable of affecting) other natural or legal persons by causing considerable material or non-material damage.

The cascade: if your customer's security incident involves your service (data exposed, service disrupted, credentials compromised), they need their information from you within hours, not days. Otherwise they cannot meet their 24-hour obligation to their CSIRT.

What we sign: a contractual clause that we will notify a customer of any security event materially affecting their tenant within 24 hours of our awareness, with sufficient detail (event type, suspected cause, scope of affected data, ongoing mitigations) to populate their NIS2 early warning. This is non-negotiable on every paid plan.

We coordinate with national CSIRTs through the BSI Germany contact route for our europe-west3 data plane, since that's where the incidents would manifest in practice. Customers in other member states can route through their own national CSIRT.

3. Supply-chain security with our own sub-processors (Art. 21(2)(d))

This is recursive. The customer is asking about their suppliers' supply chain. We have to demonstrate that we are doing supply-chain due diligence on our sub-processors.

Our sub-processor list is on the DPA page and currently has four entries: Google Cloud (the underlying infrastructure for europe-west3), Cloudflare (CDN/edge for the marketing front end), Stripe (payment processing — not in scope of monitoring data), and PostHog EU (product analytics, customer-opt-in only). For each, we maintain: the contractual basis (DPA), the data-protection assessment, and the technical isolation evidence.

The Cloudflare and Stripe pieces are conventional. The Google Cloud piece is the one that matters for compliance discussions: GCP europe-west3 is in Frankfurt, Google has signed the EU SCCs for any tertiary processing, and the European Data Protection Board's 2023 guidance on cloud providers explicitly contemplates this architecture.

4. Multi-factor authentication and access controls (Art. 21(2)(j))

Customers will ask about: SSO support, MFA enforcement, session controls, role-based access, audit logging of administrative actions, key management. Our admin guard architecture documents this — the short version is: SSO via Firebase Identity Platform, MFA enforced for admin role accounts, immutable admin-action audit log, customer-side SSO via SAML or OIDC.

Where vendors get into trouble

The two failure modes we see most often:

Failure 1 — vendor claims to be "NIS2-compliant" without being in scope. This is meaningless. NIS2 doesn't certify vendors. It regulates entities. A vendor that claims to "be NIS2-compliant" is either (a) genuinely an essential/important entity who is meeting their own obligations, or (b) confused. Don't be confused. Our position is "we are not in scope; here is what we do to support cascading obligations."

Failure 2 — vendor refuses the 24-hour incident clause. This blows up procurement. If your customer's lawyer cannot get you to commit to a 24-hour notification, the customer cannot meet their Article 23 obligation, and the contract dies. We sign 24h on every paid plan, full stop.

A third, less common failure: vendors with US-resident data and no SCCs. Post-Schrems II, the Data Privacy Framework covers the gap, but a NIS2-cascading customer in a sensitive sector (energy, health, public administration) frequently has internal policy that requires EU residency regardless. Sutrace is EU-resident by default; this question doesn't arise.

DORA's parallel cascade (Art. 30)

If the customer is also a financial entity, DORA imposes a parallel cascade with more specific contractual requirements — notably Article 30 (audit rights, sub-contracting controls, exit strategies). DORA applies directly (it's a regulation, not a directive) and has been in force since 17 January 2025. The cascading clauses are mostly subsumed under DORA for financial entities, but NIS2 still applies as a baseline for non-DORA aspects.

The practical answer for vendors who sell into both: a single addendum that satisfies both. Our trust page has the addendum text and we counter-sign on request.

What the vendor questionnaire actually looks like

A real NIS2 supplier questionnaire (anonymised, energy-sector customer in DACH region, January 2026) had 87 questions across six sections:

  • Section A: Information security governance (12 questions)
  • Section B: Incident management (14 questions, including 24h notification)
  • Section C: Access control and identity (11 questions)
  • Section D: Data protection and residency (16 questions)
  • Section E: Sub-processor management (10 questions)
  • Section F: Business continuity and recovery (24 questions)

We answer all 87 with the standard package: SOC 2, ISO 27001 status, sub-processor list, DPA, trust page, compliance use-case page, 24h incident clause, EU-residency confirmation, MFA evidence. Turnaround time: 48 hours from receipt to filed-back response.

What we don't sign

We've had three customers attempt to push obligations far beyond NIS2's actual scope onto us. We refused, politely, and three times:

  • A customer's "right to inspect any sub-processor at any time." No — Art. 21(2)(d) requires us to manage supply chain risk, not to grant the customer free run of our suppliers. We provide our SOC 2 sub-service-organisation summary; customers can request specific evidence in writing.

  • A 4-hour incident notification window. No — NIS2 says 24 hours and our contract matches NIS2. Faster than that and you're paying for a CSIRT-grade SOC, which is a different product.

  • A "right to demand source code escrow." No — escrow is a sensible request for bespoke software but the wrong tool for a multi-tenant SaaS. The replacement is a documented exit strategy with full data export.

Where this is going in 2026-2027

Two things to watch.

First, the European Commission is preparing implementing acts under Art. 21(5) that will set out specific technical and methodological requirements. Drafts circulated through 2025 and final text is expected during 2026. The drafts cite ISO 27001 and IEC 62443 as reference frameworks — confirming what's already de facto practice.

Second, member-state enforcement is just starting. Germany's BfDI and BSI are already issuing supervisory letters under NIS2UmsuCG. The first round of fines is expected during 2026 and will set the tone for what "appropriate measures" actually means in practice. Vendors should expect customer questionnaires to get more specific and more demanding through 2026.

The observability-for-compliance use-case page is updated as the regime evolves.

External references