Risk Register

A risk register is a project artifact that catalogs identified engagement risks by probability, impact, mitigation strategy, and named owner.

A risk register is a project artifact that catalogs identified risks to an engagement, each with a probability rating, impact rating, mitigation strategy, contingency plan, and named owner. It is the formal record of delivery risk and the basis for prioritization when resources are constrained.

What every risk entry must include

  • Description: a plain-language statement of what could go wrong, specific enough to act on (not “resource risk” but “key architect may leave before integration phase”)
  • Category: schedule, scope, financial, resource, or client relationship
  • Probability: low, medium, or high (or a 1-to-5 scale)
  • Impact: low, medium, or high
  • Risk score: probability multiplied by impact, used to rank and prioritize
  • Mitigation: what the team is doing now to reduce probability or impact
  • Contingency: what the team will do if the risk materializes
  • Owner: a named person accountable for tracking and acting on this risk
  • Status: open, mitigated, closed, or escalated

Risk categories in professional services

The five categories that appear most frequently in services engagements are: scope growth and uncontrolled requirements expansion, key-person dependency on either side of the client relationship, third-party integration delays, budget overrun from underestimated effort, and executive sponsorship loss on the client side.

Risk register versus RAID log

A risk register is a focused document covering threats only. A RAID log is broader, bundling risks alongside assumptions, active issues, and dependencies in one tracker. Use a standalone risk register when a governance artifact is required for a steering committee. Use a RAID log when the delivery team needs a single source of truth for all delivery constraints. When a risk materializes, it moves to the issue log.

Keeping it alive

A risk register reviewed less than weekly becomes a compliance artifact rather than a management tool. Assign a single owner per risk, review the register at every status meeting, and escalate any risk that has moved to high probability or high impact since the last review. The delivery lead is typically responsible for maintaining the register and presenting it to stakeholders. When a risk is closed, document whether the mitigation worked; that record informs how similar risks are handled in future engagements.

From concept to workflow

Servantium helps services teams turn these operating concepts into repeatable workflows.

See how Servantium works