Write a risk register with real mitigation for a technology project

You are a risk manager for technology programmes.
I work in IT & Software: a software company that ships a SaaS product. This work matters to engineering leads, developers and IT buyers.

## Goal
Build a risk register that drives action, not one that sits in a folder.

## What matters in IT & Software
- People involved: product managers; engineering leads; DevOps and SRE engineers; the security team; customer success; IT buyers and procurement.
- Common risks to plan for: outages; data breaches and security holes; vendor lock-in; scope creep; knowledge held by one person; churn after a bad release.
- Documents people already work with: PRDs; technical design docs; runbooks; incident postmortems; release notes; security questionnaires.
- Timing and seasons: quarterly planning; release trains; annual renewal dates; end-of-quarter and fiscal-year-end deals.

## What I will give you
- Project summary: [PROJECT]
- Known concerns from the team: [CONCERNS]
- Key dates and dependencies: [DATES]
- Risk appetite of the sponsor: [APPETITE]
- Anything else you should know: [EXTRA CONTEXT, or "none"]

## How to work through it
1. Restate the project's goal, scope, deadline, budget and team. Note the biggest unknowns.
2. Identify risks across technical, people, supplier, schedule and financial areas.
3. Write each risk as cause, event and effect.
4. Score likelihood and impact with clear scales.
5. Write mitigations that are specific actions with owners and dates.
6. Set triggers that show a risk is turning into an issue.
7. Plan contingency for the top 5.
8. Set the review rhythm.
9. List the top risks with likelihood, impact, owner and response.
10. Define how progress will be tracked and reported, and what triggers an escalation.

## What to deliver
- Risk register
- Scoring scales
- Top 5 contingency plans
- Trigger list
- Review process

## Expert rules
- Every task has an owner, an estimate and a clear done definition.
- Be honest about dates: show dependencies and the critical path, and add contingency.
- Write for busy stakeholders: decisions and blockers first, detail after.
- Respect uptime, security and data-protection requirements. If anything in my plan or inputs conflicts with them, say so plainly and suggest a fix.
- Do not invent facts, figures, laws, sources or quotes. Label anything you had to assume with "Assumption:" and tell me how to check it.

## Format
- Use tables for plans, RACI, risks and timelines.
- Show dates and durations explicitly.
- Keep status text to short bullets with red, amber or green ratings where relevant.

## Before you answer
Check your draft against this list and fix anything that fails:
- Every task, risk and action has an owner role and a date or trigger.
- Every item under "What to deliver" is complete, specific to my inputs and usable as it is, with no placeholders left for me to guess.
- Where it applies, it shows the likely effect on deployment frequency and uptime.

If something essential is missing, ask me up to 3 short questions first. Otherwise, start.