Article 37: Mutual assistance

Article 37’s mutual assistance requirement means you must be ready for coordinated, cross-border supervision under NIS 2 when you operate in multiple EU Member States or when your systems are hosted in a different Member State than where you provide services. Operationalize it by mapping jurisdictions, naming authority-facing owners, and building a repeatable “regulator request” workflow with evidence packages. (Directive (EU) 2022/2555, Article 37)

Key takeaways:

• Build a cross-border supervision playbook: who responds, what you share, and how you track requests across authorities. (Directive (EU) 2022/2555, Article 37)
• Maintain a jurisdiction-aware obligation register so your incident reporting and security controls stay consistent across Member States. (Directive (EU) 2022/2555, Article 37)
• Keep exam-ready evidence that supports fast, accurate responses without oversharing or breaking confidentiality commitments. (Directive (EU) 2022/2555, Article 37)

Article 37 is not a “new control” you implement in your SOC. It is an operational readiness requirement for cross-border supervision. If your entity provides services in more than one Member State, or provides services in a Member State while your network and information systems sit in another, regulators can and will cooperate with each other and request assistance related to supervision. Your exposure is practical: parallel inquiries, conflicting timelines, duplicated evidence requests, and inconsistent answers across jurisdictions.

A CCO or GRC lead should treat this as a coordination problem: jurisdictions, authorities, internal owners, and evidence. If you already have incident triage and reporting workflows, Article 37 tests whether they work in a multi-authority context. If you run shared services, centralized IT, or cloud hosting that crosses borders, Article 37 is the reason you need clean system location mapping and third-party dependency records that you can provide quickly and consistently.

Done well, mutual assistance readiness reduces regulatory friction during incidents and routine supervision. Done poorly, it creates “avoidable noncompliance”: missed deadlines, contradictory statements, and incomplete evidence production. The goal is simple: one truth, many authorities, delivered through controlled processes. (Directive (EU) 2022/2555, Article 37)

Regulatory text

Excerpt (provided):
“Where an entity provides services in more than one Member State, or provides services in one or more Member States and its network and information systems are located in one or more other Member States, the competent authorities of the Member States concerned shall cooperate with and assist each other as necessary. That cooperation shall entail, at least, that:” (Directive (EU) 2022/2555, Article 37)

What the operator must do

Article 37 is directed at “competent authorities,” but it creates a concrete operational expectation for you: if you have cross-border operations, you must be able to support coordinated supervisory activity without confusion or delay. In practice, that means:

• You can identify which Member States are “concerned” for each service and supporting system. (Directive (EU) 2022/2555, Article 37)
• You can respond to information requests consistently across those Member States. (Directive (EU) 2022/2555, Article 37)
• Your incident handling and third-party dependency evidence is organized so you can produce it repeatedly and defensibly. (Directive (EU) 2022/2555, Article 37)

Use the full NIS 2 text to align terminology and your internal scope definitions. (Directive (EU) 2022/2555)

Plain-English interpretation (what Article 37 is really testing)

If you operate across borders, regulators will talk to each other. You do not get to treat each Member State inquiry as a brand-new, disconnected event. Article 37 effectively pressures you to have:

• A single internal narrative for scope, impact, and remediation during incidents.
• A consistent security control baseline that does not vary by “local preference” unless your obligation register documents why.
• A controlled method to share evidence, with review, approvals, and traceability.

This is where many organizations fail quietly: they have good security practices, but they cannot answer the same question twice the same way because ownership is unclear and evidence lives in too many places.

Who it applies to

Entity scope

This affects any regulated entity in NIS 2 scope that:

• Provides services in more than one Member State, or
• Provides services in one or more Member States while network and information systems are located in another Member State. (Directive (EU) 2022/2555, Article 37)

Operational contexts that trigger real work

Prioritize implementation if you have any of the following:

• Centralized EU IT/shared services supporting multiple Member States.
• Cloud hosting where workloads, logs, or security tooling are operated from another Member State.
• A group structure with local operating companies but central security operations.
• Material third parties (managed services, SaaS, telecom) with cross-border delivery or data processing locations that affect incident evidence.

What you actually need to do (step-by-step)

1) Build a jurisdiction and authority map (the “who can ask” list)

Create and maintain an authoritative mapping that ties:

• Legal entities and services offered
• Member States where services are provided
• Member States where supporting systems are located
• Competent authority touchpoints (as known through your regulatory tracking)
• Internal owners for each relationship (Regulatory, Legal, Security, IT Ops)

Output: “Cross-border supervision matrix” (table).
Exam value: Proves you know which Member States are “concerned.” (Directive (EU) 2022/2555, Article 37)

2) Maintain a NIS 2 obligation register with jurisdictional applicability notes

You need one place that answers: “What do we have to do, where, and who owns it?” This aligns directly with the practical risk that NIS 2 obligations drift across countries after national transposition.

Minimum fields:

• Requirement/topic (incident reporting, governance, third-party risk, evidence retention)
• Member State applicability
• Local deviations (if any) and rationale
• Control owner and backup owner
• Implementation status and milestones
• Evidence pointers (links to artifacts)

This can be managed in GRC tooling, a controlled spreadsheet, or Daydream if you want assignment, reminders, and evidence pointers in one workflow.

Output: obligation register with named owners and evidence links. (Directive (EU) 2022/2555, Article 37)

3) Codify your “mutual assistance ready” incident workflow

Article 37 becomes real during incidents. Tune your workflow so you can handle multiple authorities without losing coherence.

Add these decision points to your incident runbook:

• Jurisdiction trigger: Which Member States are implicated based on impacted services and system location? (Directive (EU) 2022/2555, Article 37)
• Single source of truth: Where is the authoritative incident timeline maintained (ticketing system, incident doc repository)?
• Regulator-response lane: A parallel workstream for handling authority questions, evidence packaging, and approvals.
• Consistency controls: A required cross-check so answers to Authority A match what Authority B receives, unless a documented reason exists (e.g., different scope question).

Output: incident triage/escalation/reporting workflow with timing triggers and evidence expectations. (Directive (EU) 2022/2555, Article 37)

4) Establish an “authority request intake and fulfillment” process

Treat regulator questions like high-risk tickets:

• Intake channel(s): dedicated mailbox and/or case management queue
• Logging: request date/time, requesting authority, request scope, deadline, internal assignee
• Triage: classify as incident-related, audit/supervision, or ad hoc inquiry
• Evidence collection: predefined evidence packs (see below)
• Review and approval: Legal + Security + Compliance sign-off criteria
• Delivery and confirmation: what was sent, when, to whom
• Post-mortem: what slowed you down, what evidence was missing

Output: regulator request SOP + tracker.

5) Integrate critical third-party dependencies into the evidence model

Cross-border environments often mean cross-border third parties. Your authority-response readiness improves dramatically when you can produce:

• Critical third party inventory tied to services/systems
• Contract pointers (SLAs, incident notification clauses)
• Assurance artifacts (SOC reports, ISO certificates if you collect them)
• Operational dependency mapping (what breaks if the third party fails)

Output: third-party dependency map connected to risk assessments and remediation tracking. (Directive (EU) 2022/2555, Article 37)

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with retention rules aligned to your broader compliance program:

Artifact	What it proves	Owner
Cross-border supervision matrix	You can identify “concerned” Member States and internal owners	Compliance / Legal
NIS 2 obligation register with jurisdiction notes	Consistent interpretation and accountable execution	GRC
Incident workflow with regulator-response lane	You can operate under multi-authority pressure	Security / IR
Authority request tracker (tickets/cases)	Traceability and timely response discipline	Compliance
Evidence packs (templates)	Repeatability, reduces ad hoc scrambling	Security / IT
Third-party dependency inventory tied to services	Supply-chain visibility for cross-border services	TPRM

Common exam/audit questions and hangups

Expect questions that test coordination and consistency:

• “Which Member States are relevant for this service, and why?” (Directive (EU) 2022/2555, Article 37)
• “Show how you ensure answers are consistent when multiple authorities request information.” (Directive (EU) 2022/2555, Article 37)
• “Who is authorized to communicate with competent authorities, and what is the approval path?”
• “Demonstrate evidence you can produce quickly: logs, incident timeline, containment actions, third-party involvement.”
• “How do you handle system location vs. service delivery location in your scoping?”

Hangup to plan for: Security teams often track incidents by system; regulators ask by service impact and jurisdiction. Your mapping must bridge both.

Frequent implementation mistakes (and how to avoid them)

1. No single owner for cross-border regulatory responses.
   Fix: assign a primary accountable owner (often Compliance) with a documented backup, and embed Security and Legal in the workflow.

2. Jurisdiction mapping exists only in someone’s head.
   Fix: publish the supervision matrix and tie it to your service catalog and system inventory.

3. Inconsistent narratives across authorities.
   Fix: maintain an incident “single source of truth” and require a consistency check before sending responses.

4. Third-party evidence scattered across procurement, security, and IT.
   Fix: centralize pointers (not necessarily documents) in your third-party inventory so you can assemble an evidence pack fast.

5. Over-sharing sensitive data without controls.
   Fix: define evidence redaction rules and approval steps. Keep a record of what was shared.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list cases. Your risk is still concrete: mutual assistance increases the likelihood that inconsistencies are detected because authorities can compare notes and requests across Member States. (Directive (EU) 2022/2555, Article 37)

Practical execution plan (30/60/90-day)

Exact timelines depend on your footprint and operating model, so treat this as a staged plan you can run as a project.

First 30 days (Immediate stabilization)

• Stand up the authority request intake process and a single tracker.
• Draft the cross-border supervision matrix from existing service catalog, CMDB, and legal entity chart.
• Name owners: regulatory response lead, incident comms lead, legal reviewer, security evidence lead.
• Create an initial evidence pack template: incident timeline, impacted services, affected systems, containment actions, third-party involvement.

Next 60 days (Operationalize and test)

• Build the NIS 2 obligation register with jurisdiction notes and control owners.
• Update the incident runbook to add the jurisdiction trigger and regulator-response lane.
• Run a tabletop exercise that includes two hypothetical competent authorities asking overlapping questions; test for consistency.

By 90 days (Make it repeatable)

• Connect third-party dependency mapping to your critical services and systems.
• Implement approval workflows and controlled repositories so evidence packs are reproducible.
• Decide where Daydream fits if you need structured obligation management, ownership assignment, and exam-ready evidence pointers across jurisdictions.

Frequently Asked Questions

Does Article 37 require us to contact competent authorities proactively?

Article 37 describes cooperation between competent authorities when cross-border conditions exist. Your operational takeaway is readiness: you must be able to support coordinated supervision and respond consistently when authorities engage. (Directive (EU) 2022/2555, Article 37)

We provide services in one Member State, but our cloud environment is hosted in another. Are we in scope for this requirement?

Yes, that operating model matches the scenario where services are provided in one or more Member States and network and information systems are located in another. Build jurisdiction mapping and an authority-response workflow. (Directive (EU) 2022/2555, Article 37)

What’s the minimum evidence we should have ready for cross-border authority requests?

Keep a jurisdiction/service/system mapping, a regulator request tracker, and incident evidence pack templates with clear owners and approvals. Those artifacts reduce response time and inconsistency risk. (Directive (EU) 2022/2555, Article 37)

How do we avoid giving different answers to different Member States?

Use a single incident record as the authoritative timeline and require a consistency check as part of the approval process for outgoing responses. Log every submission so you can reconcile discrepancies fast.

Where does third-party risk management fit into mutual assistance?

Cross-border incidents often involve shared infrastructure and third parties. If you cannot show which third parties support an impacted service and what evidence you have from them, you will struggle to answer authority follow-ups consistently. (Directive (EU) 2022/2555, Article 37)

Can our local country teams respond independently to their competent authority?

They can, but you need centralized coordination to prevent conflicting statements and duplicated work. A hub-and-spoke model works if you enforce shared evidence packs, approvals, and a single tracker.