Threat Intelligence Sharing with ISO 27001 in 2026

At 07:40 on a Tuesday morning, Maria, the CISO of a fast-growing European payment platform, receives a high-confidence bulletin from a financial services ISAC. A credential theft campaign is targeting payment providers that use a specific identity provider integration. The advisory includes command-and-control domains, suspicious OAuth application names, user-agent strings, observed tactics, and a recommendation to rotate secrets for affected tenants.

Within minutes, the business starts asking the questions that define cyber threat intelligence sharing in 2026.

The SOC wants to push the indicators into the SIEM immediately. Legal asks whether the company can share its own telemetry back to the ISAC. The DPO asks whether IP addresses, usernames, ticket excerpts, authentication logs, or endpoint details include personal data. The COO wants to know whether customers must be warned. The CEO, fresh from NIS2 management training, forwards the alert with two words: “Our plan?”

Then the compliance manager asks the question that matters most: “If the supervisor asks next month, can we prove that our cyber threat intelligence sharing was lawful, approved, useful, and controlled?”

That is the new reality. DORA has moved from implementation deadline to supervisory scrutiny. NIS2 has moved from readiness projects to operational cooperation. GDPR still applies, even when the data is security telemetry. Threat intelligence sharing is no longer an informal Slack exchange between security teams. It is a governed activity involving confidentiality, personal-data minimisation, disclosure approvals, records, regulator expectations, and audit evidence.

For CISOs, compliance managers, auditors, and business owners, the issue is not whether to participate in cyber threat intelligence sharing arrangements. The real issue is how to share quickly enough to help defenders while preventing unlawful disclosure, customer confidentiality breaches, competitive leakage, unmanaged vulnerability publication, and weak evidence.

ISO/IEC 27001:2022 is the governance backbone that makes this possible. Not as a certificate on the wall, but as a management system that turns cyber threat intelligence sharing into a repeatable, defensible, GDPR-safe operating model.

Why cyber threat intelligence sharing changed in 2026

The first wave of DORA and NIS2 preparation focused on scope, incident reporting timelines, ICT third-party risk, board accountability, and gap assessments. That work was necessary, but regulators and customers are now asking more operational questions:

• Which ISACs, CERTs, CSIRTs, vendor forums, or trusted communities do you participate in?
• Who is authorized to represent the organization externally?
• How do you decide what can be shared?
• How do you prevent personal data, client secrets, vulnerability details, and sensitive architecture from being disclosed?
• How do threat intelligence inputs update monitoring rules, patch priorities, risk registers, incident playbooks, supplier reviews, and resilience tests?
• Where is the evidence?

DORA is especially direct for financial entities. It treats digital operational resilience as a board-owned ICT risk management system, not an IT checklist. DORA applies from 17 January 2025, so in 2026 many financial entities are being judged on whether their processes operate in practice.

DORA Article 45 permits cyber threat information and intelligence sharing among financial entities where the purpose is to enhance digital operational resilience. The sharing should occur within trusted communities and under arrangements that protect sensitive business information, personal data, confidentiality, intellectual property, and competition-law boundaries. In plain language, DORA does not mean “share everything.” It means “share safely, deliberately, and under controlled conditions.”

NIS2 creates similar pressure outside the financial sector. It applies to many essential and important entities across high-criticality and other critical sectors, including digital infrastructure, managed service providers, managed security service providers, cloud computing providers, data centre providers, online marketplaces, search engines, social networking platforms, banking, and financial market infrastructures. NIS2 Article 20 makes management bodies responsible for approving cybersecurity risk-management measures, overseeing implementation, and receiving training. Article 21 requires appropriate and proportionate technical, operational, and organisational measures, including risk analysis, incident handling, business continuity, supply chain security, vulnerability handling, effectiveness assessment, cyber hygiene, training, cryptography, HR security, access control, asset management, MFA, and secure communications. Article 23 requires staged reporting for significant incidents, including a 24-hour early warning, a 72-hour incident notification, and a final report no later than one month after the incident notification.

GDPR adds the privacy constraint. Personal data includes any information relating to an identified or identifiable natural person. Security logs, IP addresses, usernames, email addresses, endpoint names, authentication events, support tickets, malware samples, screenshots, and fraud investigation notes may all become personal data. GDPR requires lawful, fair, transparent, purpose-limited, data-minimised, accurate, storage-limited, and secure processing. It also requires accountability, meaning the organization must demonstrate compliance.

The result is a governance problem. Threat intelligence sharing must be fast enough to improve defence, controlled enough to satisfy supervisors, and disciplined enough to avoid privacy and confidentiality breaches.

ISO 27001 as the compliance hub for threat intelligence sharing

ISO/IEC 27001:2022 is well suited to this challenge because it starts with context, interested parties, scope, risk, leadership, operational control, monitoring, internal audit, management review, and continual improvement.

Clauses 4.1 to 4.4 require organizations to understand internal and external issues, identify interested parties and their requirements, define the ISMS scope, and maintain the management system. For a DORA or NIS2 organization, interested parties may include competent authorities, CSIRTs, customers, ICT providers, ISACs, sector groups, processors, controllers, insurers, internal audit, and the board.

Clauses 5.1 to 5.3 require leadership commitment, policy direction, accountability, resources, and assigned responsibilities. This matters because threat intelligence sharing fails when it is left to informal technical discretion. If the SOC analyst, legal counsel, DPO, CISO, PR lead, and business owner all apply different assumptions, the organization will either overshare, freeze, or respond too late.

Clauses 6.1.1 to 6.1.3 convert the regulatory issue into risk assessment, risk treatment, control selection, Statement of Applicability decisions, treatment plans, and residual risk acceptance. Typical threat intelligence sharing risks include:

• Personal data shared without a lawful basis or minimisation.
• Customer confidential information disclosed to a forum.
• Vulnerability details published before mitigation is available.
• Indicators consumed but never operationalised.
• ISAC participation not reflected in incident response, logging, vulnerability management, or supplier risk.
• Lack of evidence showing who approved disclosure and why.
• Competition-law risk from sharing commercially sensitive market information.
• Inconsistent regulatory and customer communications during a significant incident.

Clause 8.1 then requires planned processes to be implemented and controlled, with documented information sufficient to show that processes operated as planned. Clauses 9 and 10 require monitoring, measurement, internal audit, management review, nonconformity handling, corrective action, and continual improvement. In short, ISO/IEC 27001:2022 turns cyber threat intelligence sharing into an auditable operating model.

The two ISO controls that make sharing work

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint treats this topic as part of the Controls in Action phase, Step 22: Organizational controls. Two ISO/IEC 27002:2022 controls are central: 5.6, Contact with special interest groups, and 5.7, Threat intelligence.

The Zenith Blueprint is clear that ISAC participation is not symbolic networking:

Participation in such groups is not a symbolic gesture. It’s a strategic investment in intelligence, collaboration, and shared resilience.

For control 5.6, special interest groups may include national or sector-specific cyber threat intelligence networks, ISACs, regulatory forums, vendor security advisory groups, open-source communities, and academic working groups. But external sharing must be intentional, lawful, and cleared. The Zenith Blueprint adds the maturity expectation:

Mature ISMS implementations treat SIG participation as a governed activity, not an informal benefit.

That means keeping a register of joined groups and forums, designating official participants, capturing minutes or summaries, and integrating insights into internal reviews or control updates.

Control 5.7 turns external information into action. The Zenith Blueprint states:

An organization cannot defend against what it does not understand.

It also warns against confusing patch feeds with threat intelligence. Real intelligence includes threat actor profiling, tactics, techniques and procedures, indicators of compromise, sector-specific warnings, vulnerability context, and strategic business impact. Useful intelligence blends internal monitoring, external partnerships, CERT or ISAC relationships, commercial feeds, and open-source sources, but only when someone reviews, prioritises, and translates it into action.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls reinforces the cross-compliance value. It maps control 5.6 as preventive and corrective, supporting confidentiality, integrity, and availability, with governance as the primary operational capability. It ties 5.6 to 5.7 Threat intelligence, 5.5 Contact with authorities, 5.31 Legal, statutory, regulatory and contractual requirements, and 8.8 Management of technical vulnerabilities. It maps 5.7 as preventive, detective, and corrective, linked to Identify, Detect, and Respond, with operational capability in threat and vulnerability management.

The message is simple: a mature cyber threat intelligence sharing program has two halves. First, controlled relationships. Second, controlled use of what is received and shared.

A practical operating model for governed sharing

A defensible 2026 operating model should answer six questions before the first indicator is shared.

Clarysec typically implements this as a lightweight but formal workflow:

1. Intake and classify the intelligence.
2. Validate relevance to assets, suppliers, services, geographies, and customers.
3. Convert intelligence into action, such as monitoring rules, vulnerability tickets, user alerts, supplier queries, or risk updates.
4. Decide whether outbound sharing is necessary, lawful, safe, and permitted by membership rules.
5. Apply redaction, aggregation, pseudonymisation, or anonymisation.
6. Obtain required approvals.
7. Share through an approved channel.
8. Record what was shared, with whom, why, when, and under whose authority.
9. Review outcomes and update controls.

This prevents the two classic failures: the security team receives useful intelligence but nothing changes, or the security team shares useful intelligence but creates legal, contractual, or privacy exposure.

DORA Article 45: controlled sharing without losing confidentiality

For financial entities, DORA Article 45 should be translated into an internal cyber threat intelligence sharing standard. A practical interpretation includes five conditions.

First, the purpose must be resilience. Sharing should help prevent, detect, respond to, or recover from cyber threats. It should not drift into pricing, customer lists, market strategy, or commercially sensitive intelligence.

Second, the community must be trusted. This means clear membership rules, confidentiality obligations, secure channels, access controls, and limits on onward disclosure. ISO/IEC 27010:2015 supports secure information exchange in trust communities, including confidentiality rules, reciprocity, and trusted communication channels. ISO/IEC 27032:2023 supports cybersecurity information sharing and situational awareness. ISO/IEC 27035-2:2023 links information sharing to incident response planning, including participation in CERTs and industry groups.

Third, sensitive information must be protected. This includes business secrets, architecture diagrams, vulnerability details, credentials, customer identifiers, and personal data. Clarysec’s SME Data Classification and Labeling Policy Data Classification and Labeling Policy - SME states:

External sharing must be explicitly authorized and logged.

That sentence is the control principle behind a DORA Article 45 workflow. The organization must know what classification applies, who approved release, and where the record is kept.

Fourth, personal data must be minimised. The enterprise Data Protection and Privacy Policy Data Protection and Privacy Policy states:

Only data necessary for a specific, legitimate business purpose may be collected and processed.

The SME equivalent, Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME, states:

Only the minimum personal data necessary must be collected and retained

This matters because threat intelligence often tempts teams to copy raw logs into external channels. Instead, they should share only what the recipient needs, such as a malicious domain, a hash, a timestamp range, a general pattern, or a pseudonymised case reference.

Fifth, the organization must keep evidence. DORA is built around documented ICT risk management, incident classification, reporting, testing, third-party governance, and management accountability. If sharing influences incident response, a resilience test scenario, or a supplier risk decision, that should be visible in the ISMS records.

NIS2 cooperation: from legal scope to operational relationships

NIS2 expands the conversation beyond financial entities. It applies based on sector, size, and criticality, and can also apply regardless of size to certain entities, such as trust service providers, DNS service providers, TLD registries, critical entities, and domain name registration services.

For threat intelligence sharing, the key lesson is governance. Article 20 makes management bodies responsible for approving and overseeing cybersecurity risk-management measures. Article 21 requires appropriate and proportionate technical, operational, and organisational measures. Article 23 requires staged reporting for significant incidents.

Threat intelligence sharing intersects with all of these. If an ISAC advisory indicates that a supplier’s managed service is being exploited, Article 21 supply chain expectations become relevant. If intelligence indicates an ongoing significant incident, Article 23 reporting and customer communication workflows may be triggered. If a significant cyber threat may affect service recipients, the organization needs a controlled warning process.

The Zenith Blueprint addresses this in the ISMS Foundation and Leadership phase, Step 5, Communication, Awareness, and Competence. It recommends external communication planning that identifies customers, regulators, partners, and the public, then defines what is communicated, when, by whom, and with what approval. It gives the practical example of an incident communication procedure where the CISO drafts a notice, Legal reviews it, and the CEO approves it before sending.

The SME Incident Response Policy Incident Response Policy - SME states:

The General Manager (GM) is accountable for authorizing all incident escalation decisions, regulatory notifications, and external communications.

For larger organizations, the enterprise Incident Response Policy Incident Response Policy establishes the evidence baseline:

All incidents must be recorded in the Security Incident Management System (SIMS), including:

Where threat intelligence becomes an incident, customer warning, regulator notification, or external advisory, it must not live only in inboxes and chat threads. It belongs in the incident management system with classification, actions, approvals, evidence, and lessons learned.

GDPR-safe disclosure: sharing intelligence, not unnecessary personal data

GDPR allows security operations, but it does not create a free zone for uncontrolled telemetry sharing. Many threat intelligence artifacts may contain personal data:

• IP addresses connected to user activity.
• Email addresses used in phishing attempts.
• Usernames, device names, endpoint IDs, or customer tenant IDs.
• Authentication logs.
• Support tickets.
• Screenshots.
• Fraud investigation notes.
• Malware samples containing documents or personal files.
• Vulnerability reports that include customer data exposure.

In Clarysec’s model, every outbound sharing decision passes through a privacy and confidentiality filter.

In Zenith Controls, ISO/IEC 27002:2022 control 5.34, Privacy and protection of PII, is mapped as preventive and connected to classification, asset inventory, data masking, cloud security, information transfer, access control, identity management, and project or change review. It also maps to GDPR Articles 25 and 32 through privacy by design, security of processing, encryption, pseudonymisation, access control, and demonstrable governance. Supporting standards include ISO/IEC 27701:2021 for privacy information management, ISO/IEC 27018:2019 for protection of PII in public cloud processor environments, and ISO/IEC 29100:2011 for privacy principles.

For threat intelligence sharing, the DPO and security team should not meet for the first time during a crisis. They should pre-approve patterns, templates, redaction rules, and escalation thresholds.

Hands-on example: an ISAC alert becomes evidence-based resilience

Return to Maria’s payment platform. The ISAC advisory includes malicious domains, suspicious OAuth application names, user-agent strings, and a note that several members observed account takeover attempts against finance operations users. The company also finds three suspicious login attempts in its own logs.

Here is how Clarysec would operationalise the response using ISO/IEC 27001:2022, Zenith Blueprint, Zenith Controls, and the policy toolkit.

The outbound message originally includes timestamps, source IP addresses, target usernames, customer tenant IDs, and screenshots. After DPO and Legal review, it is reduced to:

• Time window in UTC.
• Attack pattern.
• Malicious domain observed.
• General affected role type, such as finance operations users.
• No usernames.
• No customer tenant IDs.
• No screenshots.
• No customer names.
• No raw logs unless requested through a controlled channel.

If the activity becomes an incident, the Incident Response Policy controls take over. If forensic artifacts are collected, the Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME applies:

Each item of digital evidence must be logged with:

The policy continues into evidence metadata requirements internally, but the audit principle is clear: every artifact used for investigation, sharing, regulator reporting, or customer communication needs traceability.

Vulnerability disclosure is not the same as threat intelligence sharing

One common mistake is treating vulnerability disclosure, incident notification, and threat intelligence sharing as the same process. They overlap, but they are not identical.

Threat intelligence sharing may involve indicators, tactics, sector warnings, adversary behaviour, mitigations, or observed attempts. Coordinated vulnerability disclosure involves a specific weakness in a product or service, often with a reporter, fix timeline, advisory, and public disclosure decision. Incident notification involves regulatory or contractual reporting about an event that affects services, data, or customers.

Clarysec separates these workflows while keeping them connected through the ISMS. The enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy states:

Coordination and Disclosure: The organization shall coordinate public disclosure with the reporter. By default, no vulnerability details shall be made public until a fix or mitigation is available or at least in progress. For critical issues where a fix cannot be delivered quickly, the organization may issue a security advisory with workaround guidance to warn users, in consultation with relevant authorities where required. The reporter is expected to refrain from public disclosure until the organization provides clearance or publishes an advisory. As a general rule, the organization aims to publish an advisory within 90 days of receipt of the report, or within another mutually agreed timeframe, in line with industry practice, including credit to the reporter where consent has been provided.

The same policy also states:

Confidentiality: Until public disclosure, all information relating to a reported vulnerability shall be treated as Highly Confidential. Details shall be shared internally only on a need-to-know basis with personnel required to validate or remediate the issue. The reporter’s identity shall be kept confidential where requested. All communications with the reporter should be encrypted, including through use of the organization’s PGP key, to protect sensitive vulnerability details.

This is crucial for DORA Article 45 and NIS2 cooperation. A trusted community may be the right place to share mitigations or high-level indicators, but not necessarily exploit details, customer-specific data, or unpatched vulnerability information.

External communications need the same discipline. The enterprise Social Media and External Communications Policy Social Media and External Communications Policy assigns review responsibility for content to ensure compliance with laws governing confidentiality, insider disclosures, intellectual property, and defamation. That matters when a technical advisory becomes a public statement, customer notice, website update, or regulator-facing message.

Cross-compliance mapping: one workflow, many obligations

A strong cyber threat intelligence sharing workflow should satisfy multiple frameworks without creating duplicate processes.

NIST CSF 2.0 is useful as a neutral organizing layer because its GOVERN function addresses stakeholders, legal obligations, dependencies, risk appetite, roles, policies, and oversight. Its DETECT and RESPOND functions expect monitoring, threat intelligence integration, incident declaration, evidence preservation, notification, and external communication.

COBIT 2019 adds management accountability. Practices such as DSS05.04 Manage security threats, APO12 Manage risk, MEA03 Managed compliance with external requirements, and APO13 Managed security help auditors test whether intelligence improves control performance and governance reporting.

How auditors will test your sharing program

An ISO/IEC 27001:2022 auditor will start with the management system. They will ask how legal, regulatory, contractual, and interested-party requirements were identified under clauses 4.1 and 4.2. They will check whether threat intelligence sharing is in scope, whether risks were assessed, whether controls 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15, and 8.16 are included or justified in the Statement of Applicability, and whether evidence shows the process operated as planned.

A DORA-focused auditor or supervisor will look for governance, board accountability, ICT risk integration, incident classification, resilience testing, third-party implications, and Article 45 conditions. They will ask whether participation in information-sharing arrangements is documented, whether sensitive and personal data are protected, whether intelligence updates the ICT risk management framework, and whether it influences testing scenarios.

A NIS2-oriented reviewer will focus on board oversight, Article 21 measures, incident handling, supplier dependencies, vulnerability handling, customer or service-recipient communications, and cooperation with CSIRTs or competent authorities. They will test whether threat intelligence is connected to significant incident assessment and staged reporting.

A privacy auditor will focus on GDPR principles. They will ask whether shared data was personal data, what lawful basis applied, whether minimisation was performed, whether pseudonymisation or redaction was possible, whether retention was controlled, and whether the organization can demonstrate accountability.

Good evidence includes:

• Approved ISAC or SIG register.
• Named participants and deputies.
• Membership terms and confidentiality obligations.
• Threat intelligence intake log.
• Triage and relevance assessments.
• Detection engineering tickets.
• Vulnerability prioritisation changes.
• Supplier risk escalations.
• Disclosure approval records.
• DPO or privacy review notes.
• Redacted outbound messages.
• Incident records in SIMS.
• Evidence chain-of-custody logs.
• Management review minutes.
• Internal audit findings and corrective actions.

Common pitfalls Clarysec sees in the field

The most common failure is informal participation. A security engineer joins a private forum, receives useful intelligence, and shares internal observations without formal authorization. The intent is good, but the evidence trail is weak and the confidentiality risk is high.

The second failure is passive consumption. The organization subscribes to feeds, attends ISAC calls, and forwards advisories, but no one can show how intelligence changed controls. Threat intelligence must update detection logic, patch priorities, playbooks, risk registers, supplier reviews, awareness campaigns, or resilience tests.

The third failure is raw log sharing. Teams send screenshots, SIEM exports, email headers, or packet captures externally without minimisation. This can expose personal data, customer identifiers, internal hostnames, tokens, or confidential architecture.

The fourth failure is confusing public relations with regulated communication. A LinkedIn post about an attack trend is not the same as a customer warning, regulator notification, CSIRT update, or coordinated advisory. Clarysec separates these channels, assigns approval owners, and requires records.

The fifth failure is ignoring suppliers. Many intelligence alerts concern third-party software, cloud platforms, managed service providers, or identity integrations. Under DORA, NIS2, NIST CSF, COBIT 2019, and ISO/IEC 27002:2022 supplier controls, threat intelligence must feed supplier risk management.

Build your 2026 threat intelligence sharing pack

Most organizations do not need a heavy standalone bureaucracy. They need a compact governance pack that works during a real incident. Clarysec recommends:

• Threat Intelligence Sharing Procedure.
• Approved Sharing Communities Register.
• Threat Intelligence Intake and Triage Form.
• Outbound Disclosure Approval Form.
• Privacy and Confidentiality Review Checklist.
• External Communication Matrix.
• ISAC Meeting Summary Template.
• Evidence and Incident Linkage Rules.
• Metrics Dashboard.
• Internal Audit Test Plan.

The procedure should reference ISO/IEC 27001:2022 risk management, communications, operational control, performance evaluation, internal audit, and continual improvement clauses. It should map to ISO/IEC 27002:2022 controls 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15, 8.16, and relevant supplier controls. It should also reference DORA Article 45, NIS2 cooperation and incident communication duties, and GDPR principles.

Most importantly, it must be usable under pressure. If the process requires a 12-person meeting before sharing a malicious domain with a trusted ISAC, it will fail. If it allows raw customer logs to be pasted into a community portal, it will also fail. The target is controlled speed.

Turn threat intelligence sharing into evidence-based resilience

Cyber threat intelligence sharing in 2026 is not just a security maturity badge. For financial entities, it is tied to DORA Article 45 and digital operational resilience. For essential and important entities, it supports NIS2 cooperation, incident handling, vulnerability response, supplier security, and service-recipient warning. For any organization processing EU personal data, it must be GDPR-safe by design.

Clarysec helps organizations build this operating model without slowing defenders down. We connect the Zenith Blueprint Zenith Blueprint, policy toolkit, and Zenith Controls Zenith Controls into a working ISMS process: approved communities, clear roles, privacy-safe disclosure, incident linkage, evidence records, audit readiness, and cross-framework mapping.

If your organization participates in an ISAC, receives cyber advisories, shares indicators with peers, reports to authorities, or handles vulnerability disclosures, now is the time to formalise the workflow. Start with a one-hour review of your current sharing arrangements, then map them to ISO/IEC 27001:2022, DORA Article 45, NIS2, and GDPR.

Clarysec can help you build the register, policy clauses, approval templates, audit evidence model, and management reporting pack needed to make cyber threat intelligence sharing fast, lawful, and defensible.