TLP 2.0: Share Threat Intelligence Without Leaking Data

TLP 2.0 describes who may receive information through further sharing. For a threat intelligence team, the label becomes useful when it stays attached to reports, indicators, and copies sent to recipients. A label lost in an export can leave an analyst treating restricted intelligence as public information.

A September 11, 2026 discussion about starting a CTI role asks what services the analyst should provide to different teams. This guide extends that practical question to distribution. The thread does not specifically discuss TLP, so it is not evidence of a recent increase in interest in the standard.

The working objective is to prepare a useful copy for the correct recipient, preserve its sharing conditions, and retain the ability to correct it. The workflow below supplements the standard with explicit organizational choices.

Understand TLP 2.0 sharing boundaries

The FIRST standard defines these boundaries:

• TLP:RED: individual recipients only; no redistribution.
• TLP:AMBER: organization and clients, on a need-to-know basis.
• TLP:AMBER+STRICT: the same, excluding clients outside the organization.
• TLP:GREEN: the relevant community; no public distribution.
• TLP:CLEAR: unrestricted disclosure, subject to copyright.

Labels remain untranslated. TLP does not define licensing, encryption, or legal classification. Wider sharing requires source permission. Documents retain applicable labels and restrictions on every page.

The NCSC Netherlands guidance also explains where markings appear in messages and documents. In your workflow, review the exported copy rather than assuming the editing screen shows everything recipients will see.

This distinction matters when designing a workflow. Your document system should handle permitted recipients, file protection, and usage rights separately. A report can travel over an encrypted channel to someone who should not receive it. Public information can still require attribution or a separate check before its illustrations are reused.

Make the distinction visible in internal guidance. Staff should not have to guess whether a red icon describes urgency, severity, access control, or the actual TLP label. Use a dedicated field with its written value and an explanation available where sharing happens.

Distinguish the source, the recipient, and its supplier

A security supplier does not automatically become part of its customer's organization. The direction of the relationship matters. A CSIRT providing services to a company has that company as a client; the company receiving a report cannot treat all of its own vendors as its clients.

The FIRST use cases explain that sending AMBER or AMBER+STRICT information to an outside service provider requires source permission. That permission can come through a standing agreement, a response to a request, or accompanying instructions. The cases also describe separating shareable portions from more restricted material, with the overall document retaining its most restrictive marking.

Avoid discovering these relationships during an investigation. Create a sharing relationship record covering internal teams, separate legal entities, incident response providers, and existing agreements. Have the appropriate owners resolve ambiguous cases before automating them.

A multinational team can use similar email addresses without having an obvious organizational boundary. A collaboration space can include guests, consultants, and subsidiaries. Check who can read the destination at the time of sharing instead of inferring permission from the channel's name.

Record changes in these relationships. A supplier contract can end while a guest account remains active. A support team can add a subcontractor. Periodic channel review is therefore part of maintaining your chosen workflow, even when the document and its label have not changed.

Keep three separate objects in the case file

The proposed workflow maintains a received copy, an analysis record, and a distribution copy. They serve different purposes and should remain connected through a case identifier.

The received copy preserves the source text, attachments, date, and instructions. It allows the team to revisit the exact wording when a restriction is challenged or the source corrects its information. Access to that copy should follow the organization's internal policy.

The analysis record connects the intelligence with local observations. It can become more sensitive than the original report because analysts add system names, users, log excerpts, and investigation results. Do not assume that a public source's status automatically applies to those additions.

The distribution copy answers the recipient's actual need. It might include only a contextualized indicator and a verification task. Preparing it avoids forwarding a complete investigation thread to ask a narrow question about a domain. The guide to threat intelligence sharing communities discusses potential partners; this separation governs what those partners actually receive.

Give each distribution copy a version. If an indicator is corrected later, a versioned object lets you identify exactly which recipients received the affected material. A filename such as “latest report” provides much weaker support for that task.

Minimize data without removing necessary context

Minimization removes information that is unnecessary for the intended action. It must also preserve the context that prevents misinterpretation. A domain alone can be insufficient if the observation concerns a particular URL path or a historical period.

Start with the recipient's task: search for a connection, verify a setting, examine an attachment, or confirm an observation. For each field, ask whether it helps that task and whether a less specific version would work.

An internal account identifier might become a generic role. A log excerpt can be limited to required fields. A timestamp can sometimes lose unnecessary precision, but that transformation should be disclosed if it affects correlation. The original remains available to authorized reviewers.

Look for indirect disclosures: an internal domain inside a URL, a case number in a screenshot, an employee's address in a filename, or hidden comments in a document. Inspect the final exported copy because the export tool can include data that was not visible in the editing view.

These steps do not guarantee anonymity or replace permission. NIST SP 800-150 places threat information sharing within a broader arrangement of objectives, scope, publication rules, and relationships. A label works better when those decisions already exist.

Keep a short transformation note when removal changes the meaning of evidence. A recipient should know that an account was replaced with a role or that timestamps were rounded. Otherwise, they may interpret an editorial change as a property of the original observation.

Worked example: requesting assistance without forwarding everything

The following scenario is fictional. A team receives an AMBER+STRICT report about a suspicious external service. It has an incident response contract, but its sharing agreement with the source does not mention that provider.

The analyst first defines the question: whether internal events match the reported period and behavior. They identify the portion of the report the provider would need and separate information belonging to their own organization.

A request to the source could use this structure:

Intelligence reference: SOURCE-42, version 2
Requested use: assistance examining internal logs
Proposed recipient: named company and response team
Required content: indicators and observation period
Excluded content: source identity and contextual appendices
Proposed conditions: access limited to the assigned team
Question: do you permit this transfer, and under what conditions?

This is a proposed request template, not normative standard language. Preserve the source's answer with the version it covers. When permission applies to limited information, prepare a copy within that scope; do not simply change the label on the complete original report.

Authorized internal work can continue while the request is pending. The customer may also describe a generic support need that does not disclose the restricted intelligence, after checking that the details do not reconstruct it. Urgency should trigger the escalation path established in the agreements, rather than an invented automatic exception.

The final case record should show the content that actually left the organization. Retaining only the approval request is insufficient if the attachment changed between review and transmission.

Preserve instructions across tools and exports

Information can lose its conditions at every transformation: report to ticket, ticket to chat, platform object to CSV, and CSV to a detection system. List those transitions before building automatic distribution rules.

A local record could associate each observation with these fields:

source_reference
source_version
received_marking
additional_restrictions
permission_reference
validated_recipients
verification_date
distributed_copy_and_version
sharing_owner

These are illustrative field names, not an official TLP schema. Their purpose is to preserve the information needed when content changes format. An integration that cannot carry restrictions should flag that loss before further distribution.

For STIX and TAXII pipelines, test imports and exports with synthetic objects carrying different restrictions. Examine the copy received by the final system, including comments and attachments. A marking field in the original platform does not establish that a connector preserves it.

Avoid an implementation that turns every unknown value into public information. A connector update, empty field, or malformed value should create a review case. Your system can retain an item for permitted internal analysis while suspending its redistribution.

Test correction paths too. If a source replaces an attachment, determine whether downstream tools update it, retain both copies, or silently keep the original. The answer affects what your sharing owner must do manually.

Review the actual copy before sending

A lightweight review works when it examines the real file and its destination. For repetitive exchanges, document an agreed pathway with the responsible owners and escalate exceptions. For a new partner or more sensitive material, add a targeted second review.

The reviewer should answer concrete questions. Does the copy respect the received instructions? Were attachments examined? Does the destination include guests? Has local information been added since approval? Can another analyst find the source and permission without searching several conversations?

Assign distinct responsibilities. The case owner determines necessary content, the channel owner knows its members, and the agreement owner confirms the sharing scope. An anonymous “approved” checkbox cannot resolve a disagreement between those concerns.

The CTI analyst OPSEC guide to private URL scanning examines this boundary for online investigation tools.

Also consider the request itself. Asking an outside service to enrich an indicator can disclose that the indicator is under investigation. The confidentiality review should cover queries and automated submissions, not only polished reports and attachments.

Respond when an incorrect copy has circulated

Prepare the procedure before an incident occurs. Identify the version, destination, actual recipients, and automations that might have created further copies. Stop affected distribution while the team verifies the scope.

Notify the appropriate owners and the source according to applicable agreements. Describe what was transmitted, without assuming a deleted message was never read. Ask recipients to replace or remove the affected copy and check their own onward distribution.

Record confirmations and known limits: a local copy that cannot be recalled, an export into another platform, or guest access during a particular interval. Removing content from your interface does not establish deletion everywhere. That distinction supports a proportionate response.

After correction, replay the pathway using test material. Was the cause an incorrect channel permission, an overlooked attachment, a connector, or ambiguous instructions? Fix the point that enabled the disclosure and inspect the result. A new universal approval step is not useful if it delays ordinary exchanges without addressing that cause.

The guide to preserving and reusing report evidence can support the version trail. Retain enough information to explain the correction without redistributing the sensitive material inside the correction notice itself.

Validate the workflow on a routine exchange

Choose a common pathway, such as an incoming report that becomes a request to an external SOC provider. Follow the copy from beginning to end and note where instructions disappear. Test a source correction as well: can the final recipient identify the replacement version?

When a shareable indicator needs reputation context, the IOC enrichment workflow explains how that context can support analysis. Check what the lookup sends to the external service first. A useful sharing workflow preserves the analytical context, the permitted audience, and the ability to correct distributed copies.