If an email is marked TLP:AMBER, check the sharing restrictions before forwarding it to a colleague or supplier. The Traffic Light Protocol gives the sender a way to state how far information may travel; the label needs to be understood before it is useful.
Traffic Light Protocol explained: what TLP is for, and what it isn't
TLP is a set of sharing restrictions, not a formal classification scheme. The source sets the label; recipients need the source's permission to share beyond those restrictions. It does not, by itself, describe how sensitive the information is in some absolute sense, and it is not a substitute for your organisation's information classification policy.
The protocol was built for threat intelligence and incident sharing between organisations — CERTs, ISACs, sector coordination groups — where a source needs to hand over something useful without losing control of who sees it next. It has since spread into general use inside single organisations, sharing internal security reporting, incident detail and vulnerability information, because the same problem exists there: people don't know if they're allowed to pass something on.
The four labels
The current version of the protocol, TLP 2.0, published by FIRST (the Forum of Incident Response and Security Teams) in 2022, defines four colours. AMBER also has a stricter variant.
| Label | What it permits | Typical use |
|---|---|---|
| TLP:RED | No further disclosure. Limited to the named recipients in the room or on the distribution, not to be shared more broadly even inside your own organisation. | A live incident detail discussed on a call, an active exploit against a named target |
| TLP:AMBER | Limited disclosure. Recipients may share with people in their own organisation, and with clients or constituents who need it to act, on a need-to-know basis. | A vulnerability bulletin sent to member organisations of an ISAC |
| TLP:AMBER+STRICT | Limited disclosure, restricted to the recipient's own organisation only — no onward sharing with clients or third parties at all. | The same bulletin, sent to an organisation the source doesn't want redistributing it downstream |
| TLP:GREEN | Limited disclosure, restricted to the community or sector the information was shared within. Not for public release. | A sector-wide threat trend briefing |
| TLP:CLEAR | No restriction on disclosure, subject to standard copyright rules. Replaced TLP:WHITE in the 2022 revision. | A public advisory once cleared for release |
TLP is not your document classification
Classification and TLP answer different questions. A classification scheme may describe sensitivity and handling requirements, including rules for review or reclassification. TLP communicates the source's sharing restrictions. Receiving information does not give the recipient authority to relabel it or widen its distribution.
A document can carry both. An internal incident report might sit at your organisation's "Confidential" classification, while a summary drawn from it is shared externally at TLP:AMBER for a single distribution. Treat the two as answering different questions — sensitivity, and permission to pass on — and the confusion mostly disappears.
Marking it correctly
- State the label before the content, not after. Subject line:
TLP:AMBER — <subject>. Verbally, at the start of a briefing: "everything from here is TLP:AMBER." - Mark every artefact independently. An email body, its attachment, and any extract copied into a ticket each need their own marking. A TLP:AMBER attachment inside an unmarked email is a common failure point.
- Never upgrade or downgrade a label you didn't originate without asking the source. If you need to share more broadly than the label allows, ask first.
- Carry the marking forward when you summarise or quote the source, even if you've reworded it. Paraphrasing doesn't strip the restriction.
- Default to the most restrictive plausible label when you're the originator and unsure. It's easier to loosen a label later with agreement than to claw back over-shared information.
Worked example
A three-site logistics firm receives a TLP:AMBER bulletin from its state ISAC describing a vulnerability in a fleet-tracking vendor's software. The security manager can:
- Forward it to the internal engineering team responsible for patching, on a need-to-know basis — permitted under AMBER.
- Include a summary in a risk note to executives who need it for protection or action — permitted on that need-to-know basis. The summary must retain the applicable restrictions; paraphrasing does not remove them.
She cannot:
- Post it to the company's general IT Slack channel where every staff member can read it — that exceeds "need-to-know."
- Forward it unmodified to the fleet-tracking vendor's competitor, even if the competitor asks nicely — that recipient is not automatically within AMBER's permitted organisation-and-client audience. Obtain the source's permission; GREEN would still require the recipient to belong to the intended community.
Adopting TLP inside a single organisation
TLP was built for information moving between organisations, but there's nothing stopping a single organisation adopting it for internal use, and many do — particularly for incident response communications and board or executive papers on live security matters. The value is the same one it was designed for: a shared, unambiguous instruction for how far something can travel, attached at the point it's created rather than worked out later by whoever happens to be holding it.
The risk in adopting it internally is over-formalising something that was meant to be lightweight. If every internal email ends up needing a TLP label and a sign-off before it can be sent, staff will route around it. Keep the scope narrow to start: incident response traffic, security committee papers, and anything currently being handled by informal rules like "don't forward this" that nobody has written down. Expand it only once people are using it correctly in that smaller scope, and make sure whoever introduces it also explains what it isn't — see the classification distinction above — so it doesn't get adopted as a replacement for an existing classification policy that still needs to exist alongside it.
Common mistakes
- Stamping everything TLP:AMBER by default. It becomes noise, and staff stop reading the label at all.
- Treating TLP as your classification policy. They answer different questions and need to coexist, not merge.
- Marking the email but not the attachment, or marking the slide deck but not the recording of the meeting where it was presented.
- Reclassifying received information without checking with the originator, particularly loosening a TLP:RED item because it feels like old news.
- Assuming TLP is only a document control. It applies to what you say out loud in a briefing just as much as to what's written down.
Check the source rules and give your team a reference
Use FIRST’s TLP definitions and usage guidance when applying or teaching the labels.
A label system only works if people can check it without asking. SRMBOK's free Traffic Light Protocol (TLP) Toolkit gives you an A3 wall chart for the operations centre, an A4 desk version, and a one-page practitioner guide covering marking, label selection, email and document handling, and the mistakes above — so the decision takes ten seconds, not a meeting. If insider handling of sensitive material is a live concern for your organisation, read Ten Questions That Reveal Whether You Have an Insider Threat Problem next. For where TLP fits into a broader assessment, see The 9 Steps of a Security Risk Assessment, In Order, and for the segmentation decisions that often sit behind who's "in the room" for TLP:RED material, see Security Enclaves: Explaining Segmentation to a Board in One Picture.