Red/Amber/Green (RAG) Map

What a RAG map does in security reporting

A Red/Amber/Green map compresses a status judgement into a fast visual signal, which is useful when leaders need to scan many controls, programmes, or risks at once. In security governance, its value is not precision, but speed, consistency, and a shared shorthand for whether something is blocked, at risk, or acceptable.

That simplicity is also its limitation: a RAG view can hide nuance, especially when different teams use different thresholds for the same colour. If the scoring rules are vague, the map becomes a communication aid rather than a reliable decision tool.

How to interpret red, amber, and green

In most security contexts, red means urgent concern, failure, or a blocker that needs attention before progress can continue. Amber usually means partial completion, elevated uncertainty, or a condition that is moving in the right direction but is not yet stable. Green indicates acceptable status against the agreed measure, not necessarily perfect security.

That distinction matters because the colours are relative to a defined control objective, milestone, or risk threshold. A green control can still have residual risk, and an amber item may be more important than several green ones if it sits on a critical dependency or has broad blast radius.

Because the map is only a summary, the underlying evidence should always be available elsewhere, such as a control test result, issue log, or risk register entry. Without that supporting detail, the colour can create confidence without explaining why the status was assigned.

Where RAG maps are used in governance

RAG maps are common in programme dashboards, control monitoring, audit tracking, incident recovery reporting, and executive summaries because they provide a compact view of status across many workstreams. They are especially helpful when the audience needs prioritisation rather than technical detail.

They also work well as a governance language between operational teams and leadership, as long as the organisation defines what each colour means, who assigns it, and when a status must be escalated. A RAG map with no decision rule is just presentation, not governance.

Used well, the map helps separate healthy progress from items that need intervention. Used poorly, it can flatten different kinds of risk into one colour and make serious problems look comparable to minor delays.

Common failure modes and best use

RAG maps fail when teams treat colour as an objective measurement rather than a judgement based on agreed criteria. They also fail when amber is overused as a safe default, when red is reserved so late that it loses meaning, or when green is awarded for activity rather than outcome.

They are most effective when paired with a clear legend, a short narrative explanation, and a consistent review cadence. That combination keeps the map useful as a management signal while preserving the detail needed for action.

If the subject is sensitive, high impact, or technically ambiguous, the map should be treated as a pointer into the real evidence set, not the evidence itself. The colour should start a conversation, not end it.

Related resources from NHI Mgmt Group

• Guide: Permission-Aware RAG Guide
• What should teams do when a host receives an amber or red authenticity result?
• What should teams do when an AI red team map reveals trust boundary violations?
• What is the difference between RAG access and MCP tool access?
• How should security teams govern RAG-powered IAM agents?