Organisations often join a sharing community, read the occasional bulletin and never share anything back, so they pay for membership and still learn about attacks on their sector from the news. Information Sharing and Analysis Centers (ISACs), Information Sharing and Analysis Organizations (ISAOs), government programmes and informal trust groups exist so that defenders in the same sector see the same threats sooner. This guide explains the main types of community, how to choose one, what sharing agreements and the Traffic Light Protocol govern, which legal frameworks support sharing in the US and EU, how to build an internal process that both consumes and contributes, and how to measure the return. It is for CTI leads, CISOs and legal or compliance staff who approve sharing. It complements the Threat Intelligence Guide.
Key takeaways
- Sector first: the community that sees the attacks aimed at your industry, such as FS-ISAC, Health-ISAC or the Automotive ISAC, usually gives the most relevant intelligence per hour spent.
- Sharing needs a policy: pre-approve what analysts may share, at which TLP level and through which channel, or legal review will stall every contribution during an incident.
- TLP 2.0 is the common language: CLEAR, GREEN, AMBER, AMBER+STRICT and RED, authoritative from August 2022, govern onward disclosure in almost every community.
- Legal frameworks help but do not cover everything: the US Cybersecurity Information Sharing Act of 2015 and NIS2's information-sharing provisions support sharing, but personal data, contractual confidentiality and competition rules still apply.
- Measure what you act on: count shared items that produced a block, hunt, patch decision or detection, not the number of emails received.
Types of sharing community
The National Council of ISACs describes ISACs as trusted entities established by critical infrastructure owners and operators, typically non-profit, that collect, analyse and distribute threat information to members, and in most cases offer 24/7 threat warning and incident reporting. The concept was introduced by US Presidential Decision Directive 63, signed on 22 May 1998, which asked each critical infrastructure sector to create a sector-specific sharing organisation; some ISACs formed as early as 1999.
| Type | Examples | Typical members | Strengths | Limits |
|---|---|---|---|---|
| Sector ISAC | FS-ISAC, Health-ISAC, E-ISAC, Auto-ISAC, Aviation ISAC, RH-ISAC, WaterISAC, Space ISAC | Owners and operators in one sector | Sector-specific threats, peer trust, analyst staff, exercises | Fees, eligibility rules, mostly US-founded though several operate globally |
| Government-sector ISAC | MS-ISAC for US state, local, tribal and territorial government; EI-ISAC for elections | Public bodies | Services such as monitoring and domain blocking | Funding models change; MS-ISAC moved to a member-funded model in 2025 |
| ISAO | Regional, cross-sector or community-of-interest groups | Any group sharing a common interest | Flexible, can form around a region, supply chain or technology | Quality varies widely; check capacity before relying on one |
| Government programmes | National CSIRT and cyber agency partnership schemes | Critical sectors, registered organisations | Authoritative advisories, sometimes classified briefings | One-way flow is common; eligibility criteria |
| Technical communities | MISP communities, vendor user groups, closed analyst trust groups | Practitioners | Fast, machine-readable indicators | Informal, membership by vouching, less governance |
The National Council of ISACs lists 26 members, from the Automotive ISAC and E-ISAC (electricity) through FS-ISAC, Health-ISAC, IT-ISAC, K12 SIX, MS-ISAC, ND-ISAC and REN-ISAC to the Space ISAC, Tribal-ISAC and WaterISAC. ISAOs grew from US Executive Order 13691 (2015); the ISAO Standards Organization, selected by DHS in October 2015 and led by the University of Texas at San Antonio, publishes voluntary guidance including ISAO 100-1 Introduction to ISAOs, ISAO 100-2 Guidelines for Establishing an ISAO, ISAO 300-1 Introduction to Information Sharing, ISAO 300-2 Automated Cyber Threat Intelligence Sharing and ISAO SP 4000 Protecting Consumer Privacy in Cybersecurity Information Sharing.
In Europe, sector ISACs are commonly organised at national or EU level, and NIS2 (Directive (EU) 2022/2555) explicitly encourages voluntary cybersecurity information-sharing arrangements between entities. Its recitals note that uncertainty about competition and liability rules has held back intelligence sharing, call for voluntary sharing arrangements at Union level, and state that such sharing may rely on legitimate interests under the GDPR.
Choosing which community to join
- Relevance: does the community see attacks on organisations like yours? Ask for anonymised examples of recent sector alerts and how fast they were issued.
- Two-way culture: what proportion of members contribute? A community where a handful share and everyone else reads will decline.
- Formats: are indicators available machine-readably (STIX and TAXII, MISP) as well as in reports? See the STIX and TAXII Guide.
- Analyst capacity: does the community have its own analysts who validate and enrich, or is it a mailing list?
- Services: exercises, working groups, incident response coordination and vendor or vulnerability coordination often matter more than the feed.
- Governance: membership vetting, a written sharing agreement, data handling rules and a clear process for dealing with leaks.
- Cost and eligibility: tiered fees by organisation size are common; some government-sector ISACs offer free or subsidised tiers, but funding models change, as MS-ISAC's 2025 move to member funding shows.
Small and large organisations
A small organisation should join one sector ISAC or ISAO, take its high-confidence indicators into existing controls and attend its briefings; contributing a few well-described incidents a year is enough to build standing. A large organisation should hold memberships in its main sector ISAC, any cross-sector or regional group where its suppliers sit, and the relevant government programme, and should assign named analysts to working groups. Multinationals also need to check which communities their subsidiaries can join and whether sharing crosses data transfer rules.
Sharing agreements and the Traffic Light Protocol
Most communities require members to sign a membership or sharing agreement before access. Review it with legal and the CISO, and look for the following.
| Clause | What to check |
|---|---|
| Permitted use | Whether shared information may be used only for defence, or also passed to service providers such as an MSSP |
| Attribution and anonymisation | Whether the community will strip your name before onward sharing, and on what request |
| Handling markings | Which TLP version applies and how breaches of markings are handled |
| Personal data | Who is controller, the legal basis for processing, and minimisation rules |
| Government sharing | Whether and how the community passes information to government agencies |
| Liability and confidentiality | Disclaimers on accuracy, confidentiality duties, and what happens on exit |
TLP version 2.0, published by FIRST and authoritative since August 2022 (version 1.0 is deprecated), defines five labels.
| Label | Who may receive it onward |
|---|---|
| TLP:CLEAR | Anyone; may be published, subject to copyright |
| TLP:GREEN | The recipient's wider community, peers and partners, but not public channels |
| TLP:AMBER | On a need-to-know basis within the recipient's organisation and its clients |
| TLP:AMBER+STRICT | Within the recipient's organisation only, not clients |
| TLP:RED | Named individual recipients only; in a meeting, those present |
Configure your threat intelligence platform and ticketing tools to carry TLP markings with the data, and make sure automated exports, for example from MISP to a SIEM or a managed service provider, respect AMBER and AMBER+STRICT. See the Traffic Light Protocol Guide.
Legal protections and constraints
- United States: the Cybersecurity Information Sharing Act of 2015 gives protections, including from liability, to private entities that share cyber threat indicators and defensive measures in accordance with the Act, and requires sharers to remove personal information not directly related to a threat. The Act has a sunset clause (6 U.S.C. 1510); Public Law 119-75 extended it to 30 September 2026, and whether it has been extended again should be checked. Confirm its current status with counsel before relying on its protections.
- European Union: NIS2 encourages voluntary information-sharing arrangements and voluntary notification of threats and near misses; national transpositions set out how this works in each Member State. Personal data in indicators (IP addresses, email addresses, usernames) remains subject to the GDPR, and NIS2's recitals point to legitimate interests as a possible basis.
- Competition law: sharing between competitors should be limited to security information. Keep commercial topics such as pricing and supplier terms out of sharing channels.
- Contracts and regulators: customer contracts, non-disclosure agreements and regulatory notification duties still apply. Sharing in an ISAC never replaces a mandatory regulatory report.
- Privilege: incident details shared externally may affect legal privilege over investigation material. Agree with counsel what is shared during active incidents. See the Legal Privilege in Incident Response Guide.
This section is a summary of frameworks that change; it is not legal advice.
Building an internal sharing process
- Write a sharing policy: define categories that are pre-approved (indicators from confirmed incidents, phishing samples, vulnerability exploitation observations), categories that need CISO approval, and categories that need legal approval (incident narratives naming third parties).
- Name the roles: a primary and deputy liaison per community, an approver for each category, and a legal contact available during incidents.
- Set up the plumbing: a threat intelligence platform or MISP instance that ingests community feeds, tags source and TLP, and exports to your controls. See the MISP Threat Sharing Guide.
- Grade what you receive: assign source reliability and information credibility before acting, so a community rumour does not trigger a production block. See the Intelligence Confidence and Source Reliability Guide.
- Sanitise what you send: remove internal hostnames, customer names, employee data and anything that identifies a victim, unless agreed.
- Pilot: share three to five items over a quarter, review the feedback and adjust the policy before scaling.
- Review and roll back: if an item was over-shared, use the community's process to recall or correct it, and update the policy.
Where identity fits
Much of the most useful sector intelligence concerns credentials: leaked API keys and tokens, malicious OAuth applications, compromised SaaS integrations and infostealer logs. Make sure the sharing policy covers how to share these safely, never sharing a live secret, only its type, prefix pattern, affected service and revocation status. Machine accounts used to pull TAXII or MISP feeds are themselves non-human identities with owners, scopes and rotation dates. See the Threat Intelligence for Identity and NHI Guide.
What a good contribution contains
Communities value short, specific, timely submissions more than polished reports. A useful contribution after a confirmed incident or blocked campaign usually includes the following.
| Element | Example content | Why it helps |
|---|---|---|
| Summary and TLP | Two sentences on what happened, marked TLP:AMBER or TLP:GREEN | Readers triage in seconds and know how far it may travel |
| Observables | Sender domains, URLs, file hashes, IP addresses, user agent strings, with first and last seen times | Peers can block or hunt immediately |
| Behaviour | ATT&CK techniques observed, for example T1566 phishing leading to T1078 valid account use | Lasts longer than indicators that the attacker rotates |
| Targeting | Which roles, systems or business processes were targeted, without naming victims | Helps peers judge relevance |
| Detection and mitigation | What caught it, what stopped it, and any rule logic you can share | Turns a warning into a defence |
| Confidence | Source grade and analytic confidence for any judgement, such as attribution | Stops speculation spreading as fact |
Share early with an "initial" label and update later, rather than waiting for a full investigation. Many communities accept anonymous submissions through their own analysts, which lowers the approval bar for sensitive cases.
Running the membership day to day
- Daily: the liaison or an automated pipeline reviews new community items, grades them and routes high-confidence indicators to controls and the rest to hunting queues.
- Weekly: the CTI lead reviews which items led to action and which contributions are pending approval.
- Monthly: attend the community briefing or working group, and report actionable items and contributions to the security leadership team.
- Annually: review each membership against the metrics below, renew or exit, and refresh the sharing policy and approver list.
Measuring value
- Actionable rate: percentage of received items that led to a block, hunt, detection, patch prioritisation or awareness action.
- Lead time: days between a community alert and the same threat appearing in public reporting or your own telemetry.
- Contribution count: items shared per quarter, and the share of your confirmed incidents that produced a contribution.
- Time to share: hours from incident confirmation to a sanitised contribution.
- Engagement: briefings attended, working group participation and exercises joined.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-02 Cyber threat intelligence is received from information sharing forums and sources | Membership and ingestion |
| NIST CSF 2.0 | RS.CO-03 Information is shared with designated internal and external stakeholders | Contribution during incidents |
| NIST SP 800-53 Rev. 5 | PM-15 Security and Privacy Groups and Associations | Formal contact with sharing communities |
| NIST SP 800-53 Rev. 5 | PM-16 Threat Awareness Program; SI-5 Security Alerts, Advisories, and Directives | Receiving and acting on advisories |
| ISO/IEC 27001:2022 Annex A | A.5.6 Contact with special interest groups; A.5.7 Threat intelligence | Memberships and intelligence process |
| NIS2 | Voluntary information-sharing arrangements and voluntary notification | EU basis for sector sharing |
Common failure patterns
- Read-only membership: never contributing means fewer personal contacts and lower trust when you need help during an incident.
- No pre-approval: every contribution waits for legal review, so intelligence arrives after it is useful.
- TLP ignored by tooling: AMBER data flows automatically to an MSSP portal or a public block list.
- Ungraded ingestion: community indicators go straight into blocking, causing outages and loss of confidence in the feed.
- Over-sharing personal data: full email headers with employee names and phishing victims' addresses shared without minimisation.
- Single point of contact: the one analyst who held the community relationships leaves, the credentials to the portal and TAXII feed go with them, and the membership quietly lapses. Name a deputy and hold feed credentials in a shared secrets store.
- Waiting for certainty: nothing is shared until the investigation closes weeks later, by which point peers have already been hit by the same campaign.
- Too many memberships: five communities and nobody reading any of them; one well-used membership beats several ignored ones.
Practitioner checklist
- Identify your sector ISAC and any regional or supply chain ISAO relevant to you.
- Review the sharing agreement with legal before joining.
- Write a sharing policy with pre-approved categories and named approvers.
- Configure tooling to carry TLP 2.0 markings and enforce them on export.
- Grade received intelligence before automated use.
- Sanitise contributions and never share live secrets.
- Confirm the current status of applicable legal protections with counsel.
- Track actionable rate, lead time and contributions each quarter.
Standards and references
- National Council of ISACs: About ISACs
- National Council of ISACs: Member ISACs
- ISAO Standards Organization: Published documents
- FIRST: Traffic Light Protocol (TLP) version 2.0
- Cornell LII: 6 U.S. Code 1510, Effective period
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- Center for Internet Security: MS-ISAC
- FS-ISAC: Who we are
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Threat Intelligence Guide · MISP Threat Sharing Guide · Traffic Light Protocol Guide · Threat Intelligence Feed Evaluation Guide. This guide summarises information sharing frameworks and legal protections and is not legal advice.