Agile risk management: integrating risk into agile boards

Risk management has a reputation problem in agile teams. The risk function turns up at the planning meeting with a 30-page risk register, and the team’s velocity drops by half for a sprint. Then the risk function disappears for a quarter, and the team builds something the regulator will find awkward.

The pattern that actually works: integrate risk into the agile cadence itself, at the smallest unit of work where it can usefully live.

The four levels

Every agile organisation has at least four levels at which risk discussions happen. Each gets a different cadence, a different format, and a different audience.

1. Story level (every story)

A story-level risk question is one that fits in the definition of done. Examples:

• “Does this change introduce a new third-party data flow?”
• “Does this change widen authorisation for an existing role?”
• “Does this change touch the cardholder data environment?”

If yes, a small mandatory checklist runs (often as a pull-request template) before the story can be merged. The checklist outputs a “this story raised a risk” signal that feeds the sprint-level review.

This is the level where risk has the highest impact and the lowest overhead.

2. Sprint level (every two weeks)

The sprint-level risk meeting is 15 minutes at the end of sprint review. Two questions:

• “What stories raised a risk signal this sprint?”
• “Are any of those signals a risk register entry, or do they all resolve at story level?”

The output is one of: nothing changed in the risk register; one or two existing entries got updated; one new entry got added. A rolling snapshot of “risks added vs closed per sprint” lives on the team dashboard alongside velocity.

3. Release / quarterly level (every 3 months)

The release-level risk meeting is 60 minutes. Two questions:

• “Has the cumulative effect of this quarter’s changes shifted the risk posture for any function the regulator cares about?”
• “Have any of the residual risks the board accepted last quarter become unacceptable?”

The output is a one-page board-ready summary. This is the artefact the CISO carries into the risk committee.

4. Annual level (once a year)

The annual risk-strategy meeting is a half-day. The question is:

• “Are we managing the right risks?”

This is where the risk register itself gets a structural review — not just the entries, but the categories. Has the firm changed enough that the categories from a year ago no longer fit?

Why these four (and not three, or five)

Story level catches what the team knows

The team writing the story knows things the risk function won’t see for weeks. The story-level checklist captures their knowledge while it’s fresh.

Sprint level translates code into risk language

Without sprint level, story-level signals pile up unattended. Sprint level is where the team’s language (“we changed the auth middleware”) gets translated to risk language (“the authorisation surface for role X changed”).

Quarterly level reaches the board

Boards don’t reason in sprints. Quarterly level is the cadence at which risk-management work is consumable by people who weren’t in the sprint review.

Annual level keeps the structure honest

Without annual level, the categories ossify. The risk register starts to look like a year ago, even when the firm doesn’t.

How this maps to DORA

EU Digital Operational Resilience Act (DORA, in force January 2025) requires every in-scope financial entity to maintain an ICT risk register, refresh it on a defined cadence, and link it to incident reporting and operational resilience testing. The four-level cadence above maps directly:

• Story level — feeds new entries (or updates) into the register
• Sprint level — the cadence at which the register actually changes
• Quarterly level — the artefact for the management body that DORA expects to be appraised regularly
• Annual level — the structural review DORA’s risk-management framework requires

If you’re running this cadence, your DORA evidence collection writes itself.

What goes wrong

Three failure modes I’ve seen across multiple engagements (anonymised):

Failure 1 — story level skipped

The team treats the checklist as ceremony and ticks every box without thinking. The signal becomes noise. Fix: make the checklist questions tighter and make “raised a risk” require a one-line justification.

Failure 2 — sprint level extends to 60 minutes

The risk discussion expands to fill the time. Fix: make the meeting a hard 15-minute timebox and move anything that doesn’t fit to the quarterly review. The agile cadence works because it’s tight.

Failure 3 — quarterly level becomes a slide deck

The output of the quarterly review is a 30-slide deck nobody reads. Fix: the output is one A4 page. Three risks, one paragraph each, one recommendation. Anything more is the risk function performing thoroughness.

What to do tomorrow morning

If your firm doesn’t yet have a story-level risk checklist:

1. Pick three questions that catch 80% of the risks your team actually generates (look at the last 12 months of incidents).
2. Add them to the pull-request template.
3. Track the signal for two sprints before adding any sprint-level ceremony. Most teams over-engineer step 4 before they’ve earned step 1.

By the end of two sprints you have data, not a process. Build the process from the data.

---

This article is part of our DORA readiness pillar. For hands-on help with your ICT risk programme, see our GRC and audit readiness service.