Most UK organisations have an enterprise risk register somewhere in the governance structure. It rarely helps the comms team because it is written in risk-management language, updated quarterly at best, and does not connect to monitoring queries or escalation paths. A comms-specific reputation risk register bridges that gap: it takes the top risks that would require a communications response and links each one to a concrete monitoring trigger, an owner, and a response playbook.
What belongs in the register (and what does not)
A reputation risk register is not a list of everything that could go wrong. It is a curated set of 8-12 risks that would materially affect how stakeholders -- media, regulators, investors, customers, employees -- perceive the organisation.
Include:
- Regulatory enforcement or investigation (FCA, CMA, ICO, Ofcom, HSE)
- Product safety or service failure
- Data breach or cyber incident
- Executive misconduct or leadership crisis
- Environmental or sustainability controversy (greenwashing allegations, emissions data)
- Workforce issues (redundancies, strikes, working conditions)
- Litigation or legal action with public interest
- Political or policy exposure (lobbying disclosure, government contract scrutiny)
Exclude:
- Operational risks with no public-facing dimension (internal IT outage that does not affect customers)
- Financial risks that are already covered by investor relations without comms involvement
- Risks so remote they have never appeared in sector coverage (asteroid impact is not a comms risk)
Structure of each register entry
Each risk needs five fields to be operationally useful:
Risk description
One sentence. "FCA opens formal investigation into mis-selling of product X." Not "regulatory risk" -- that is too vague to act on.
Likelihood and impact rating
Use a simple 3x3 matrix (Low / Medium / High for both likelihood and impact). The rating should be reviewed quarterly and updated after any near-miss or actual incident.
Monitoring trigger
This is the field that makes the register operational rather than decorative. Translate the risk into a specific monitoring query or alert condition.
Example triggers:
| Risk | Monitoring trigger | Platform | |------|--------------------|----------| | FCA investigation | Brand name + ("FCA" OR "Financial Conduct Authority" OR "enforcement" OR "investigation") | Meltwater / Signal AI alert | | Data breach | Brand name + ("data breach" OR "ICO" OR "personal data" OR "hack") | Meltwater + Brandwatch social alert | | Executive misconduct | CEO/CFO name + ("resign" OR "misconduct" OR "investigation" OR "allegation") | Signal AI + Google Alerts | | Greenwashing | Brand name + ("greenwashing" OR "misleading" OR "ASA ruling" OR "net zero") in proximity to negative framing | Meltwater Boolean with sentiment filter |
Each trigger should be a live, tested query in your monitoring platform. A trigger that exists only in a document is not a trigger -- it is a wish.
Owner
One named individual, not a team. The owner is responsible for initial assessment within a defined timeframe (typically 1 hour during business hours, 4 hours outside). The owner does not need to manage the response -- they need to confirm the signal is real and escalate if it meets the threshold.
Response playbook reference
Link to the specific holding statement, Q&A document, or crisis protocol for that risk. If the playbook does not exist yet, the register has just identified a gap. Fix it.
Building the register in practice
Step 1: Start with the enterprise risk register. Pull the top 20 risks from the corporate register and filter to those with a public-facing or media dimension. This usually yields 8-15 risks.
Step 2: Workshop with comms and legal. A 90-minute session with the head of comms, a legal representative, and the monitoring analyst. Walk through each risk and define the trigger, owner, and playbook reference. Do not try to do this by email -- the discussion surfaces gaps.
Step 3: Build the queries. The monitoring analyst builds and tests each trigger query in Meltwater, Signal AI, or Cision. Run against 30 days of historical data to check for false positives. A query that fires 50 times a day on irrelevant content is worse than no query.
Step 4: Set alert routing. Each trigger should route to the owner via email, SMS, or platform notification. During business hours, email is fine. Outside hours, SMS or push notification for High-impact risks.
Step 5: Document and distribute. The register should be a single shared document (Google Sheet, SharePoint, or Confluence page) accessible to the comms team, legal, and the CEO's office. Do not bury it in a risk management portal nobody checks.
Quarterly review process
The register goes stale fast. A quarterly review should take 60 minutes and cover:
- New risks: Has the business entered a new market, launched a product, or taken on a new regulatory obligation? Add the corresponding risk and trigger.
- Retired risks: Has a risk been resolved (litigation settled, product withdrawn)? Remove it and archive the query.
- Trigger accuracy: Review false positive rates for each query. If a trigger fires more than 5 times per week on irrelevant content, refine the Boolean.
- Playbook freshness: Are the holding statements and Q&A documents still current? A holding statement that references last year's CEO is a liability, not a resource.
- Near-misses: Did any incident occur that was not on the register? If so, add it.
Tabletop testing
Once per year (minimum), run a tabletop exercise that tests the register end-to-end. Pick a risk, simulate the trigger firing, and walk through the escalation path in real time. Time each step.
What to measure:
- Time from trigger to owner acknowledgement (target: under 30 minutes during business hours)
- Time from acknowledgement to initial assessment (target: under 2 hours)
- Time from assessment to first external communication if needed (target: under 4 hours)
If any step takes longer than target, fix the process before the next real incident.
Common mistake: the register that nobody checks
A UK infrastructure company built a detailed 22-risk reputation register after a crisis in 2023. It was presented to the board, praised, and filed in SharePoint. Eighteen months later, when a HSE investigation generated BBC and Guardian coverage, the comms team scrambled from scratch. The register existed but had never been connected to live monitoring queries, and the named owners had changed roles.
A register is only as useful as its connection to live alerts and current owners. If the queries are not running and the owners are not current, you have a document, not a risk control.