Overview
Draft information sharing arrangements for exchanging cyber threat intelligence among financial entities per DORA Art. 45 (Regulation (EU) 2022/2554). Art. 45 encourages voluntary participation in trusted sharing communities — ISACs, national CERTs, and bilateral arrangements — to exchange indicators of compromise, TTPs, vulnerability intelligence, and anonymized incident summaries. Although participation is not mandatory, any entity that joins must comply with strict GDPR, business confidentiality, and competition law safeguards, and must notify both its management body and competent authority.
The skill walks you through an 8-step workflow: assess intelligence needs, identify sharing communities, draft the participation agreement, define data protection safeguards, establish operational procedures, set up governance, formalize notifications, and produce the complete arrangement document.
What It Covers
- Information sharing needs assessment — evaluate current threat intelligence gaps, map available sharing communities (EF-ISAC, national ISACs, ECB Cyber Resilience Hub, SWIFT ISAC), and prepare a join/do-not-join recommendation
- Participation agreement drafting — define scope of shared information (IoCs, TTPs, threat reports, vulnerability data, incident summaries), sharing protocols (TLP 2.0, STIX 2.1, TAXII 2.1, MISP), membership criteria, and roles
- Data protection safeguards — GDPR legal basis (legitimate interest), DPIA assessment, anonymization and pseudonymization procedures for IP addresses, email addresses, and entity identifiers, purpose limitation, and retention limits
- Business confidentiality and competition law — protections against revealing internal architecture, customer data, or commercially sensitive information; competition law compliance provisions per Art. 101 TFEU
- Operational procedures — platform selection, sharing frequency (real-time IoC feeds, periodic threat reports, ad-hoc urgent alerts), quality standards (confidence ratings, contextual enrichment), TLP handling matrix, feedback loops, and escalation for critical sector-wide threats
- Governance framework — internal authorization matrix by TLP level, annual effectiveness review (quantitative metrics and qualitative assessment), dispute resolution for TLP violations and quality issues, membership lifecycle management
- Notification obligations — management body awareness per Art. 45(3), competent authority notification with required content and timing, integration into ICT risk management framework documentation
- Cross-pillar integration — coordinates with DORA ICT risk management (Arts. 5-16), incident reporting (Arts. 17-23), resilience testing (Arts. 24-27), and third-party risk management (Arts. 28-44)
Output Documents
| Document | Purpose |
|---|---|
| Information Sharing Arrangement | Complete arrangement document with all sections per Art. 45 |
| Participation Agreement | Terms, scope, protocols, membership criteria, and roles |
| Data Protection Safeguards Annex | GDPR legal basis, DPIA summary, anonymization procedures |
| TLP Handling Matrix | Handling requirements and authorization levels per TLP designation |
| Sharing Community Assessment | Evaluation of candidate communities against selection criteria |
| Management Body Notification Record | Documentation of Art. 45(3) management body awareness |
| Competent Authority Notification | Formal notification to the supervisory authority |
| Operational Procedures Manual | Platform configuration, sharing frequency, quality standards, escalation |
Example Conversation
You: We’re a mid-sized European bank under ECB/SSM supervision. We want to establish a cyber threat information sharing arrangement per DORA Art. 45. We currently have no formal sharing participation — just ad-hoc email exchanges with our national CERT.
Agent: I’ll help you build a formal information sharing arrangement per DORA Art. 45. Let me start by assessing your sharing needs and mapping the relevant communities.
Information Sharing Needs Assessment:
Your current position shows a significant gap: ad-hoc email exchanges provide no structured intelligence, no TLP handling, no GDPR safeguards, and no audit trail. As an ECB-supervised entity, you’ll benefit from multiple sharing tiers.
Recommended sharing communities for your profile:
Community Relevance Intelligence Type Cost European Financial ISAC (EF-ISAC) High — pan-European banking focus IoC feeds, strategic threat reports Membership fee ECB Cyber Resilience Hub High — you’re SSM-supervised Strategic briefings, banking-specific alerts No cost (by invitation) National CERT (formalized) High — upgrade existing relationship National threat landscape, vulnerability alerts No cost FS-ISAC (global) Medium — broader coverage Extensive IoC feeds, cross-sector intelligence Membership fee I recommend joining the EF-ISAC and formalizing your national CERT relationship as the primary tier, with the ECB Cyber Resilience Hub as a supervisory channel. Shall I draft the participation agreement with these communities in scope?
You: Yes. We want to share IoCs and TTPs but we’re concerned about GDPR — our DPO flagged that IP addresses in IoC feeds are personal data under EU law.
Agent: Your DPO is correct — IP addresses are personal data under GDPR (CJEU ruling in Breyer v Germany, C-582/14). I’ll build the data protection safeguards into the arrangement from the start.
Data Protection Safeguards — Key decisions:
Element Recommended Approach Rationale Legal basis Art. 6(1)(f) — legitimate interest Cybersecurity protection is a recognized legitimate interest DPIA required? Yes — bulk IoC feeds with thousands of IP addresses Systematic, large-scale processing triggers Art. 35 IP anonymization Default: truncate to /24 subnet; full IP only for active C2 servers under TLP:AMBER Minimizes personal data while preserving detection value Email anonymization Default: domain-only sharing; hashed full address for cross-referencing Balances phishing detection with data minimization Entity identification Anonymous sharing by default; named sharing only with CISO approval Protects business confidentiality Retention IoCs: quarterly review, delete when not actionable; Reports: 24 months Aligns with purpose limitation I’ll include a balancing test documenting why cybersecurity interests outweigh individual data subject rights, with the safeguards above as mitigating measures. Now let me draft the TLP handling procedures and the authorization matrix…
Sharing Authorization Matrix:
TLP Level Authorized By Channel TLP:CLEAR SOC analyst (automatic) TAXII feed / MISP TLP:GREEN Threat intel team lead MISP / secure portal TLP:AMBER CISO or deputy MISP with restricted sharing group TLP:AMBER+STRICT CISO approval required Encrypted email / secure portal TLP:RED CISO + board member Verbal or secure messaging only You: This looks good. We also need to notify our competent authority and management body. Can you draft those notifications?
Agent: Absolutely. Art. 45(3) requires two distinct notifications. I’ll draft both.
For the competent authority notification, I’ll include: the communities you’re joining (EF-ISAC, national CERT formalized arrangement), types of information exchanged (IoCs, TTPs, threat reports), data protection safeguards summary, and the commencement date. This goes to the ECB/SSM as your direct supervisor.
For the management body awareness record, I’ll prepare a board presentation package covering: the rationale for participation, the communities selected, the risk assessment of sharing vs. not sharing, the data protection safeguards, the authorization matrix, and the annual review commitment.
I’ll also cross-reference the arrangement into your ICT risk management framework under Art. 13(4) for threat intelligence integration, and link it to your incident management process for sharing anonymized incident summaries after formal reporting under Art. 19 is complete.
Let me produce all the documents now.
Sample Output Excerpt
Below is a representative excerpt from the generated Information Sharing Arrangement document, showing the participation agreement terms and TLP handling matrix.
1. Purpose and Objectives
This Information Sharing Arrangement establishes the terms under which [Entity Name] participates in cyber threat intelligence sharing with trusted financial sector communities, in accordance with Article 45 of Regulation (EU) 2022/2554 (DORA).
Objectives:
- Enhance the entity’s capability to detect, prevent, and respond to cyber threats targeting the financial sector
- Contribute to the collective digital operational resilience of the European financial ecosystem
- Obtain timely intelligence on indicators of compromise, threat actor tactics, and vulnerabilities relevant to the entity’s ICT infrastructure
- Fulfill the entity’s responsibility under Art. 13(4) to integrate threat intelligence into its ICT risk management framework
2. Scope of Shared Information
| Information Type | Description | Default TLP | Sharing Frequency |
|---|---|---|---|
| Indicators of Compromise | IP addresses, domains, URLs, file hashes, certificates | TLP:AMBER | Real-time via TAXII 2.1 |
| Tactics, Techniques & Procedures | MITRE ATT&CK mappings, attack patterns, kill chain analysis | TLP:GREEN | Weekly digest + ad-hoc |
| Threat Reports (Strategic) | Sector threat landscape, geopolitical drivers, risk forecasts | TLP:GREEN | Monthly |
| Threat Reports (Tactical) | Active campaigns, exploitation trends, sector targeting | TLP:AMBER | As available |
| Vulnerability Intelligence | Zero-day disclosures, active exploitation, patch intelligence | TLP:AMBER+STRICT | As available |
| Incident Summaries | Anonymized lessons learned from ICT-related incidents | TLP:GREEN | Post-incident (after Art. 19 reporting) |
3. Data Protection Safeguards
Legal basis: Article 6(1)(f) GDPR — legitimate interest in protecting the entity and the financial sector from cyber threats.
Balancing test summary: The entity’s legitimate interest in timely cyber threat detection and prevention outweighs the interests of data subjects whose personal data (IP addresses, email addresses) may appear in threat intelligence, given the following safeguards:
| Safeguard | Implementation |
|---|---|
| Data minimization | Share only data elements necessary for threat detection; no contextual personal data |
| Anonymization (default) | IP addresses truncated to /24; email addresses reduced to domain only |
| Pseudonymization (exceptional) | Full IP/email shared only when detection requires it, under TLP:AMBER minimum |
| Purpose limitation | Shared data used exclusively for enhancing digital operational resilience |
| Retention limits | IoCs: quarterly review, deleted when not actionable; Reports: 24 months |
| Access restriction | TLP controls limit further dissemination; MISP sharing groups enforce technical access |
| DPIA | Conducted for bulk IoC feed processing; reviewed annually |
Entity identification: Anonymous sharing by default. The entity’s name, internal architecture, customer data, and proprietary detection mechanisms are never disclosed. Named sharing requires CISO authorization and is limited to TLP:RED communications with identified recipients.
4. TLP Handling Matrix
| TLP Level | Who May Receive | Further Sharing | Storage | Destruction |
|---|---|---|---|---|
| TLP:RED | Named recipients only | Prohibited | Encrypted, access-logged | Within 30 days or upon request |
| TLP:AMBER+STRICT | Recipient organization only | Within org, need-to-know | Encrypted, restricted folder | Quarterly review |
| TLP:AMBER | Recipient org + clients who need to act | Clients for protective action only | Standard secure storage | Quarterly review |
| TLP:GREEN | Community members | Within community, not public | Standard secure storage | Per retention policy |
| TLP:CLEAR | Unrestricted | No restrictions | No special requirements | Per retention policy |
5. Notification Records
5.1 Management Body Awareness — Art. 45(3)
| Field | Detail |
|---|---|
| Date presented | [Date] |
| Presented by | Chief Information Security Officer |
| Forum | Board Risk Committee meeting |
| Communities joined | EF-ISAC, [National CERT] formalized arrangement |
| Board acknowledgment | Recorded in meeting minutes ref. [Reference] |
| Next reporting date | [Date + 12 months] — annual update in ICT risk report |
5.2 Competent Authority Notification — Art. 45(3)
| Field | Detail |
|---|---|
| Competent authority | [ECB/SSM or national supervisor] |
| Date of notification | [Date] |
| Nature of arrangements | Multilateral (EF-ISAC), bilateral (national CERT) |
| Information types exchanged | IoCs, TTPs, threat reports, vulnerability intelligence, incident summaries |
| Data protection safeguards | GDPR Art. 6(1)(f) basis, DPIA completed, anonymization by default |
| Commencement date | [Date] |
Built-in Validation Tools
The dora_sharing_arrangement_checker validates the arrangement document against all Art. 45 requirements.
| Check | What It Validates | Severity |
|---|---|---|
| Entity profile | Name, type, competent authority, supervision level | ERROR |
| Needs assessment | Intelligence gaps, current participation, join/do-not-join recommendation | ERROR |
| Sharing communities | Community identification, type classification, relevance assessment | WARNING |
| Participation agreement | Purpose, information types, sharing protocols (TLP/STIX/TAXII), TLP defaults | ERROR |
| TLP default validation | Each default TLP marking is a valid TLP 2.0 level | WARNING |
| Data protection (Art. 45(2)) | GDPR legal basis, anonymization procedures, retention limits, DPIA status | ERROR |
| Confidentiality | Customer data prohibition, competition law safeguards, entity identification policy | WARNING |
| Operational procedures | Platforms, TLP handling matrix, sharing frequency, escalation process | ERROR |
| Governance | Authorization matrix, effectiveness review, dispute resolution, exit procedures | ERROR |
| Management body notification (Art. 45(3)) | Date, presenter, forum, acknowledgment record | ERROR |
| Competent authority notification (Art. 45(3)) | Authority, date, nature of arrangements, safeguards summary | ERROR |
| Cross-pillar references | Links to ICT risk framework, incident management, testing, third-party risk | WARNING |
Getting Started
Activate the Cyber Threat Information Sharing (DORA Art. 45) skill. This skill produces the information sharing arrangement as a standalone document, but it coordinates with other DORA skills for cross-pillar integration.
Related DORA skills (install these first if building a comprehensive DORA program):
- ICT Risk Management Framework — provides the risk management context into which threat intelligence integrates (Art. 13(4))
- Incident Classification — defines the incident reporting process that complements information sharing
- Third-Party Policy — third-party risk monitoring benefits from shared vulnerability and incident intelligence
- Resilience Testing — threat intelligence from sharing arrangements informs TLPT scenarios
Have this information ready:
- Your entity type, size, and supervisory authority (ECB/SSM or national supervisor)
- Current threat intelligence sources and sharing participation (formal or informal)
- Sharing communities you are considering joining (or already a member of)
- Your CISO or security team structure (who will authorize and manage sharing)
- Data protection officer’s position on sharing personal data in IoC feeds
- Any existing GDPR assessments or DPIAs related to cybersecurity processing
- Your ICT risk management framework documentation (for cross-referencing Art. 13(4))
- Prior cyber incidents or near-misses that illustrate the value of external intelligence
The agent guides you through the full 8-step workflow: needs assessment, community identification, participation agreement, data protection safeguards, operational procedures, governance, notification obligations, and final document production.