Risk Register

A risk register is a living list of the things that could go wrong on a project, what we plan to do about each one, and who owns the watching. Every active project at Media Tech maintains one. The register lives in monday.com under the project's board, so it's visible to anyone with project access and is reviewed at the cadence the project's risk profile demands.

Risk management is not pessimism. It is the structured habit of asking "what would have to go wrong for this project to miss its goal?" while there is still time to do something about it. Risks that never become issues are a sign the system is working, not a sign the register was wasted effort.

What a risk is, and isn't

A risk is a future event with non-trivial probability that, if it occurred, would prevent the project from meeting its goal — its scope, schedule, budget, or quality. A risk is not an issue (issues are already happening). A risk is not a dependency (dependencies are known relationships). A risk is not a list of fears (probability and impact must both be non-trivial).

If you can't answer "what specifically would need to happen for this to materialise?" the entry isn't a risk yet — it's a worry.

The register entry

Every risk in the register has the following fields:

Field	Example
ID	RISK-Castline-014
Title	"OpenAI rate limit on AI Diary generation under launch-week load"
Description	Two-sentence specifics: the trigger, the consequence.
Likelihood	1 (Rare) — 2 (Unlikely) — 3 (Possible) — 4 (Likely) — 5 (Almost certain)
Impact	1 (Negligible) — 2 (Minor) — 3 (Moderate) — 4 (Major) — 5 (Severe)
Severity	Likelihood × Impact (1–25)
Owner	A single named individual.
Status	Open / Mitigating / Accepted / Closed
Mitigation	What we are doing to reduce likelihood or impact.
Contingency	What we will do if the risk materialises despite mitigation.
Review date	Next time this risk is re-evaluated.
Last updated	Date of the most recent change to any field.

Severity tiers and review cadence

Severity 16–25 — review weekly. Discussed at the project standup.
Severity 9–15 — review fortnightly. Discussed in the project review.
Severity 4–8 — review monthly.
Severity 1–3 — review quarterly, or when the project moves phase.

Review means actually looking at the entry, deciding whether likelihood or impact has changed, and updating the entry — not just scrolling past it.

Closing a risk

A risk closes when one of three things happens:

Avoided. The conditions that would have made it materialise are no longer present. Document why.
Mitigated. Likelihood or impact has fallen below the registration threshold (severity < 4). Document the mitigations applied.
Materialised. The risk became an issue. Move the entry to the issue log; reference the new issue ID. Run the post-incident review even if the impact was contained — the lesson is in the gap between expected and actual response.

Closed risks remain in the register for the life of the project as the historical record.

Castline-specific risk categories

Active categories on the Castline risk register:

Vendor concentration. OpenAI, Google, Pusher — single-point dependencies on third parties.
AI behaviour. Hallucination, content moderation gaps, latency variance under load, model deprecation.
Regulatory. EU AI Act classification drift, GDPR sub-processor changes, age-verification requirements in new markets.
Team capacity. Single-person dependencies on Ahmed Mahmood Khan, hiring slippage for Frontend/Backend/Designer.
Operational. Pusher outage, AWS region outage, App Store / Play Store review delay or rejection.
Commercial. Customer cohort concentration, churn signals, runway visibility.

Each category should typically have 2–6 active risks at any time. Fewer suggests we're not looking; more suggests we're not closing.

Owned by

Project Manager. The PM curates the register; each risk's owner is whoever has the most direct authority to act on the mitigation. Audited by the Master skill on a 30-day cadence.