Risk heatmap
Click any cell to focus the register. Counts follow the active filters.
Impact
Likelihood
Low
Moderate
High
Severe
Projects, BAU teams, service change and operational work
Risk dashboard
Capture risks quickly, score likelihood and impact, track actions, keep dated notes, and produce a clear management view.
Overall risk shape
Average risk pressure across the strongest categories. Click a label to filter.
Risk bubble chart
Likelihood, impact and volume by category. Click a bubble to filter.
Common risk themes
Automated word cloud from risk text. Click a word to search.
Top risks
Click to editOverdue actions
Click to editRisk concentration
Click a row to filter the register.
By status
By project
By category
By owner
Recent activity
Risk changes, notes, imports and data actions recorded by this browser.
Editable register
Operational risk register
Edit directly in the table, add dated notes, or open the full form for risk wording, scoring guidance and history.
Filters
Hidden by default to keep the register focused. Open when you need a more specific view.
Risk register
0 risks shown.
Changes save after you leave a field, choose a score, add a note, or change a status.
| Notes | Actions |
|---|
Treatment work
Action workbench
Manage treatment actions as their own work items, with owner, due date, status and completion date.
Action workbench
Actions are shown separately from risks so follow-up work is easier to manage. Edit action owner, due date, status and completion date directly in this page.
Weekly risk review
Review workflow
Work through due, stale, ownerless, actionless, overdue and escalation risks. Each review decision is written into the risk history.
Review queues
Start with escalation and overdue items, then confirm stale risks, missing owners and missing actions. A short review note is enough.
Guided capture
New risk form
Build a clear IF, THEN, RESULTING IN risk statement and score it with visible guidance.
Management view
Management report
A plain-English summary of the current filtered view, grouped by project and designed for copying into reports.
Report mode
Use interactive mode inside TripTrap, or copy-ready mode for documents and status reports.
Administration
Settings
Adjust scoring labels, guidance, projects, categories, local data, and restore demo data.
Likelihood scale
Edit the five labels and guidance messages used in the form, table, heatmap and report.
Impact scale
Edit the five labels and guidance messages used when scoring seriousness.
Projects
Manage up to 25 projects or work areas. Projects behave like a simple category in the register, but the report groups risks by project.
Project count will appear here.
Risk categories
Adjust the category list used in forms, filters, dashboard breakdowns and the editable register. You can keep up to 25 categories.
Category count will appear here.
Data safety
Storage status will appear here.
TripTrap field guide
Risk practice wiki
A practical guide for using TripTrap in real project, BAU, service, cyber, data, vendor and operational change work. Start with quick instructions, then use the deeper reference sections when you need better questions, better judgement, or stronger reporting.
Working principle
Success is a useful discussion and a captured risk. Something visible today is better than a perfect risk statement written too late.
Basic use
Start here: the shortest useful process
TripTrap is for making risk conversations easier. It is not meant to create a perfect audit document. Use it to capture what the team is worried about, agree what will happen next, and keep the risk visible until it is closed, accepted, escalated, or becomes an issue.
1Add the concern
Record the thing that might go wrong. A rough title is enough to begin.
2Score it
Choose likelihood and impact using the guidance in the form. Do not debate the score for too long.
3Assign ownership
Name the person who will keep the risk live and bring updates back to the team.
4Add one next action
Write the next useful action, owner, due date and status.
5Review weekly
Add a dated note, update the score, and decide whether to watch, treat, escalate, accept or close.
Application help
How to use each part of TripTrap
Dashboard
Use the dashboard to start the conversation. Click the summary cards, heatmap cells, bubbles, word cloud terms, top risks, overdue actions and breakdown rows to focus the register.
Register
Use the register as the working list. Edit common fields directly in the table. Open the full form when you need better wording, more notes, action detail, history, or a related link.
Actions
Use the action workbench to follow up treatment work. Filter by overdue, due soon, blocked, open, completed, owner or project. Update action owner, due date, status and completion date here.
Review
Use weekly review mode to work through due, stale, no owner, no action, overdue and escalation queues. Each review decision writes history back to the risk.
Report
Use interactive mode inside TripTrap. Use copy-ready mode when pasting into a steering group pack, status report, board paper, sponsor update, email, or meeting notes.
Settings
Use settings to adjust likelihood, impact, project names and categories. Export a backup before changing lists if the data matters.
Risk basics
Risk, issue, dependency, assumption and decision
Many delivery teams mix these together. That is normal, but it helps to name the item correctly so the right action follows.
| Item | What it means | Typical TripTrap treatment |
|---|---|---|
| Risk | Something uncertain that could affect the work if it happens. | Score it, assign an owner, add actions, review until closed or accepted. |
| Issue | Something already happening. | Move it to the issue process if there is one. Keep a note if it still affects risk exposure. |
| Dependency | Something the team needs from another person, team, supplier, environment, decision or system. | Capture as a risk if the dependency may not arrive in time or may not be good enough. |
| Assumption | Something believed to be true for planning purposes. | Capture as a risk if the assumption could be wrong and would affect delivery or service. |
| Decision | A choice needed from an owner, sponsor, governance group, vendor or technical authority. | Capture as a risk if delay or the wrong choice could affect the work. |
Practical rule: if the team is uncertain and the outcome matters, capture it. The label can be improved later.
Risk wording
Writing useful risk statements
A useful risk statement makes the cause, event and impact clear enough for someone to decide what to do. TripTrap uses this pattern:
IF cause or condition
THEN event or consequence
RESULTING IN impact
Weak
Testing might be a problem.
Better
If the shared test environment remains unstable, then regression testing may not complete on time, resulting in delayed release approval and extra support effort.
Weak
Vendor risk.
Better
If the vendor does not confirm the integration design this week, then build work may continue on assumptions, resulting in rework and a missed migration checkpoint.
Weak
Security finding.
Better
If the critical security finding is not remediated before go-live, then production approval may be withheld, resulting in release delay or higher residual risk acceptance.
What to avoid
- Do not write only a symptom, such as “schedule risk”.
- Do not write only an action, such as “hold workshop”.
- Do not hide the real impact because it is uncomfortable.
- Do not turn every problem into a severe risk. Keep scoring honest.
Likelihood and impact
Scoring without making it painful
Scoring is a judgement tool. It helps the team decide what to discuss first. It is not meant to be mathematically perfect.
Likelihood
Likelihood asks how credible the risk is in the review period. Look at current evidence: backlog, defects, decision delays, staff availability, vendor responsiveness, incidents, unresolved findings and environment stability.
- Use lower scores for remote or weakly evidenced concerns.
- Use middle scores when the risk is credible but not yet trending badly.
- Use higher scores when delay, failure or exposure is already visible.
Impact
Impact asks how serious the effect would be if the risk happens. Consider delivery date, cost, service stability, security, compliance, user trust, operational load, reputation and leadership attention.
- Score the credible impact, not the worst imaginable story.
- Increase impact when customer, citizen, security, privacy or legal exposure is real.
- Record why the score changed in notes.
Watch for false comfort: a risk can have a low likelihood and still need attention if the impact would be severe.
Treatment and ownership
Actions, owners and response strategy
A risk without a next action is usually only a worry. The action does not need to solve the whole risk. It only needs to be the next useful movement.
Avoid
Change the plan so the risk no longer applies.
Reduce
Lower likelihood or impact through practical treatment actions.
Transfer
Move some responsibility, consequence or exposure through a supplier, contract, support arrangement or insurance.
Accept
Record that the risk is understood and no further action is planned for now.
Escalate
Raise the risk to someone who can decide, fund, prioritise, unblock or accept it.
Monitor
Keep watching when active treatment is not yet justified.
Risk owner and action owner
The risk owner is accountable for keeping the risk current. The action owner is responsible for a specific treatment action. They can be the same person, but they do not have to be.
Weekly operating rhythm
Running a useful weekly risk review
A weekly review should be short, specific and decision focused. The aim is to find movement, not read every field aloud.
30 minute review agenda
- 2 min: confirm the purpose and review period.
- 5 min: check severe, high and escalated risks.
- 6 min: check overdue and blocked actions.
- 6 min: review risks due this week or stale risks with no recent update.
- 5 min: add new risks from the week.
- 4 min: confirm decisions, escalations and owners.
- 2 min: export backup if the data matters.
Review questions that work
- What changed since the last review?
- Is the risk still real?
- Has likelihood or impact moved?
- Is the next action still the right action?
- Is the owner still the right owner?
- Does someone outside the team need to decide something?
- Should this be accepted, escalated, closed, or turned into an issue?
- What should be visible to sponsors this week?
Management reporting
How to report risk without making noise
A good risk report helps someone decide, support, challenge or unblock. It should not be a copy of the whole register.
Report this
- Severe and high risks.
- Decisions required.
- Actions overdue or blocked.
- Risks accepted by the team.
- Risks that need sponsor, vendor or portfolio help.
- What changed since last review.
Do not over-report this
- Closed risks with no current relevance.
- Low risks with no decision needed.
- Long wording that hides the real ask.
- Every note ever written.
- Internal debate about exact score where the action is clear.
Copy-ready mode: use the report page when pasting into project reports, steering packs, board summaries, sponsor updates or email.
Example library
Common IT and BAU risk examples
Cloud migration
If network firewall rule approvals remain queued behind operational work, then migration testing may not start on time, resulting in delayed cutover and longer parallel running.
Data migration
If source data quality issues are not resolved before migration rehearsal, then records may fail validation, resulting in manual remediation and loss of business confidence.
Cyber finding
If the critical vulnerability remains open at go-live, then release approval may be delayed or residual risk may need formal acceptance.
Service desk pressure
If service desk demand rises during rollout without extra support capacity, then incident response times may worsen, resulting in user frustration and reduced adoption.
Vendor delivery
If the supplier misses the design approval date, then build work may continue on assumptions, resulting in rework, dispute and schedule pressure.
Operational readiness
If support procedures are not agreed before go-live, then BAU teams may not be ready to manage incidents, resulting in slower recovery and unclear accountability.
Framework summary
Useful risk frameworks in plain English
Frameworks are useful when they sharpen thinking. They are not useful when they make the team avoid the conversation. Use this section as a guide to what each framework is good for.
ISO 31000
A broad international risk management standard. Good for principles, governance, context, risk identification, analysis, evaluation, treatment, monitoring and communication. Use it to shape the overall discipline.
IEC 31010
A companion risk assessment techniques standard. Good when you need structured tools such as bow tie analysis, scenario analysis, FMEA, business impact analysis, decision trees, checklists or root cause analysis.
PRINCE2 Risk Management
Useful for project, programme and portfolio delivery. It supports a managed approach to identifying, assessing and controlling risks in a delivery environment.
PMBOK and PMI practice guidance
Useful for project management discipline, planning, ownership, analysis, response planning, monitoring and reporting across portfolios, programmes and projects.
NIST Risk Management Framework
Useful for security and privacy risk in information systems. Stronger than TripTrap for control selection, implementation, assessment and ongoing authorisation.
NIST Cybersecurity Framework
Useful for cyber risk conversations across governance, identification, protection, detection, response and recovery. Good for boards, security teams and improvement roadmaps.
COSO ERM
Useful for enterprise risk and strategy. Good for senior leadership and organisational risk oversight, less useful for a small weekly delivery meeting.
FAIR
Useful for quantitative cyber and operational risk. Good when financial loss exposure matters and the organisation has enough data and maturity to model scenarios.
OWASP risk rating
Useful for application security risk discussions. Good for thinking about threat agents, vulnerability factors, technical impact and business impact.
CIS RAM
Useful for assessing cyber safeguards against business impact. Good for security teams using CIS Controls.
NZISM
Useful for New Zealand public sector information security risk. Good for agencies and suppliers working with NZ government security expectations.
NZ Digital Government guidance
Useful for New Zealand public sector risk assessment, information systems risk and digital assurance practice.
Reference links
Risk management frameworks and source links
These links open official or recognised sources. They are provided for deeper reading and comparison. Use them to support practice, not to make a lightweight risk process heavy.
ISO 31000:2018Risk management guidelines
IEC 31010:2019Risk assessment techniques
PRINCE2 Risk ManagementPeopleCert risk management framework page
PMBOK GuidePMI project management standard
PMI risk practice guideRisk management in portfolios, programmes and projects
NIST RMFRisk management for systems and organisations
NIST CSFCybersecurity Framework
COSO ERMEnterprise risk management framework
FAIR InstituteCyber and operational risk quantification
OWASP risk ratingApplication security risk rating method
CIS RAMRisk assessment method for CIS Controls
NZISM risk managementNew Zealand information security risk guidance
NZ Digital GovernmentRisk management guidance for public sector digital work