06.03 Risk Review Cadence

Why this matters

A risk register that's submitted once and never revisited becomes wallpaper. The whole point of holding a register is that conditions change (a vendor's posture shifts, a control becomes ineffective, a new threat emerges, the program's risk appetite evolves), and the existing risks need to be reassessed against the new reality. Most programs handle this with a periodic review: every risk gets a fresh look on a cadence appropriate to its severity.

SimpleRisk's review-cadence configuration codifies that practice. Each risk level (Very High, High, Medium, Low, Insignificant) has an SLA — the number of days between reviews. When a risk is reviewed, the next review date is computed by adding the SLA to the review date. The Risks Pending Review queue surfaces risks whose next-review date has passed; reviewers work the queue.

The honest scope to know up front: the cadence is a calculated due date, not an enforced lockout. SimpleRisk doesn't lock you out of the application or auto-disposition risks that miss their review date; it surfaces them in the queue and lets the program work them on its own pace. The discipline of "actually doing the reviews" is operational, not system-enforced.

The other thing worth knowing: the cadence is configurable per level, not per risk. Every Very High risk has the same SLA; every Medium risk has the same SLA. Programs that want per-risk custom cadences (regulatory deadlines, contract-driven review schedules) handle the per-risk dates outside the standard cadence — typically by setting the next-review date manually after each review.

The third thing: the calculation can be based on inherent or residual risk. The setting next_review_date_uses controls which score determines the level used for the cadence calculation. Inherent (the default) uses the unmitigated score; residual uses the post-mitigation score. Programs with mature mitigation programs may prefer residual (a Critical-inherent risk that's been mitigated to Low residual deserves a Low cadence); programs that want to keep eyes on uncomfortable risks regardless of mitigation prefer inherent.

Before you start

Have these in hand:

Admin access to Configure → Settings → Risk Formula (where the SLA thresholds live).
A documented cadence policy. Don't pick numbers off the top of your head; map your program's review expectations (typically driven by regulatory or framework requirements — NIST RMF expects continuous monitoring with risk-tier-based cadences; ISO 27001 expects regular reviews) to the SLA settings.
Awareness of the inherent-vs-residual decision. The choice affects which risks land in the queue when. Pick before configuring; switching later changes the queue contents in ways that surprise reviewers.
A user with the management-review role for testing. Risk submitters can submit; only reviewers (users with the management-review permission) can complete reviews and reset the next-review date. Without a reviewer role, you can't validate the cadence end-to-end.

Step-by-step

1. Decide your per-level cadences

Common patterns:

Very High

Aggressive: 30 days
Moderate: 30 days
Light: 60 days

High

Aggressive: 60 days
Moderate: 60 days
Light: 90 days

Medium

Aggressive: 90 days
Moderate: 90 days
Light: 180 days

Low

Aggressive: 180 days
Moderate: 180 days
Light: 365 days

Insignificant

Aggressive: 180 days
Moderate: 365 days
Light: 365 days

The defaults SimpleRisk ships with (30/60/90/180/180) sit between aggressive and moderate. Adjust to match your program; programs with continuous-monitoring expectations or regulator-driven cadences may need shorter intervals; programs running risk reviews quarterly or twice-yearly may need longer.

2. Set the SLA thresholds

Sidebar: Configure → Settings → Risk Formula (the section may be labeled "SLA Thresholds" or "Review Cadence"). The settings:

sla_threshold_very_high — days for Very High risks (default 30).
sla_threshold_high — days for High risks (default 60).
sla_threshold_medium — days for Medium risks (default 90).
sla_threshold_low — days for Low risks (default 180).
sla_threshold_insignificant — days for Insignificant risks (default 180).

Range for each: 1–3650 days. Save the values.

3. Pick inherent vs residual for the cadence calculation

Same settings page. Find next_review_date_uses (or the equivalent labeled toggle):

Inherent — the cadence uses the inherent risk score (pre-mitigation). Appropriate when you want to keep reviewing risks that are dangerous in their unmitigated form, regardless of mitigation effectiveness.
Residual — the cadence uses the residual risk score (post-mitigation). Appropriate when mitigation effectiveness is the metric you trust and well-mitigated risks deserve a lighter cadence.

Most programs default to inherent; programs with mature mitigation tracking and confidence in their effectiveness scoring sometimes switch to residual. The choice isn't permanent — switching later just changes which score drives the next calculation.

4. Verify the cadence on existing risks

After setting the SLAs:

Open an existing risk at each level (Very High, High, Medium, Low, Insignificant).
Check the Next Review Date field on each.
Confirm the date matches last_review_date + sla_threshold_.

If the dates don't match, the risk's last_review_date may be stale (the SLA only applies after the next review, not retroactively). Either accept the existing dates or trigger a review on each risk to bring them into the new cadence.

5. Review and clear the Risks Pending Review queue

Once configured, the Risk Management → Review Risks Regularly view (or equivalent) shows risks whose next_review_date has passed. Reviewers work the queue:

Open a risk.
Read the current state (description, mitigation, prior reviews).
Make a review decision: Approve (no action), Consider for Mitigation (kicks back to mitigation planning), Submit New Risk (the situation has changed enough to warrant a new risk), Reject (close the risk as no longer relevant), etc.
The review action updates last_review_date = today; the next review date recomputes as today + SLA.

Programs with backlog typically see a wave of overdue risks the first time the queue is configured. Working through the wave is the program's catch-up step; subsequent reviews come due in stride.

6. Configure reminders (where supported)

The Notification Extra (see Email and the Notification Extra) can send reminder emails for overdue or upcoming reviews. Configure:

Who gets the reminder (risk owner, owner's manager, designated reviewer team).
How far in advance (e.g., "3 days before the review is due").
Whether to remind on the due date or only after.

Reminders increase compliance with cadence; don't over-do them — daily reminders for the next month produce reminder fatigue.

7. Plan for cadence changes

Tightening the cadence (e.g., Very High from 60 days to 30 days):

Existing risks keep their current next_review_date; the new SLA only applies after the next review.
The next-review date will compute against the tighter SLA going forward.
The first round under the new cadence may be a wave; communicate to reviewers.

Loosening the cadence (e.g., Medium from 90 days to 180 days):

Existing risks keep their current next_review_date; reviews already due remain due.
Going forward, the cadence is more relaxed.

Changes don't affect the historical dates; they apply to the next-cadence calculation after each review.

8. Coordinate with broader review programs

The risk-review cadence is one of several review processes a program runs. Consider how it interacts with:

Audit cadence — compliance audit reviews are separately scheduled; verify they don't double-count or conflict.
Control-test cadence — control testing has its own frequency; risks tied to specific controls may benefit from synchronized review.
Vendor risk reassessment cadence — vendors are typically reassessed annually or at contract renewal; risks tied to vendors should align if possible.
Quarterly business reviews — many programs review the top-N risks at QBRs; the cadence configuration shouldn't conflict with the QBR rhythm.

Document the program's overall review calendar; the SimpleRisk SLA settings codify one piece, not all of them.

Common pitfalls

A handful of patterns recur with risk review cadence.

Setting too-aggressive SLAs without the reviewer capacity. A 30-day cadence for everything Medium-or-above produces a never-ending queue if reviewers can't keep up. The result is a chronically-overdue queue that the program ignores. Match the cadence to actual reviewer capacity.
Setting too-loose SLAs without compensating discipline. A 365-day cadence for everything below High means most risks aren't actively maintained. Programs with regulatory monitoring requirements need tighter cadences regardless of operational convenience.
Switching from inherent to residual without re-baselining. The switch changes which level each risk is in for cadence purposes; risks that were Critical-inherent / Low-residual move from a 30-day to a 180-day cadence. Communicate the change so reviewers understand why their queue suddenly looks different.
Treating the queue as the sole signal that a risk needs review. Risks may need ad-hoc review before their scheduled date — incidents, threat-intelligence changes, organizational shifts. The cadence is a floor, not a ceiling.
Not setting next-review dates manually for special-cadence risks. A risk under a regulatory deadline (must be reviewed by a specific date) shouldn't rely on the standard cadence. Set the next-review date manually to the regulatory deadline; the cadence configuration applies to the following review.
Letting the queue grow without working it. A 200-risk-overdue queue that no one looks at is a worse posture than no queue at all — it normalizes "we don't actually review on schedule." Either commit to working the queue or adjust the cadence to a sustainable level.
Forgetting reminders. Without notifications, reviewers don't know risks have come due until they open the queue. The Notification Extra's reminders close that loop; configure them.
Setting sla_threshold_insignificant to 0 thinking it disables the cadence. A 0-day SLA means "review every day," which produces a permanent queue of every Insignificant risk. Use a long value (365+ days) for low-priority cadences.
Conflating risk review with risk closure. A review can result in closure ("this risk is no longer relevant"), but the default review action is to keep the risk and re-set the next-review date. Don't close risks just to clear the queue; close because the risk is genuinely no longer relevant.
Not training reviewers on the review actions. "Approve," "Consider for Mitigation," "Reject," "Submit New Risk" — these mean different things and have different downstream effects. Document the program's intended use of each.

Reference

Permission required: check_admin for SLA threshold configuration; governance (or the relevant management-review permission) for completing reviews on individual risks.
API endpoint(s): GET /api/v2/risks/pending_review (or equivalent) — paginated list of risks past due; POST /api/v2/risks/{id}/review — submit a review action.
Implementing files: simplerisk/admin/configure_risk_formula.php (the SLA threshold configuration UI); simplerisk/includes/functions.php (next_review($risk_level, $review_date) — adds the SLA days; next_review_by_score($score) — resolves score to level then to SLA days; recalculate_all_risk_scores() — bulk recalculation).
Database tables: risk_scoring (per-risk calculated_risk and residual_risk); mgmt_reviews (the per-risk review history including next_review date); review_levels (per-level review days, parallel to risk_levels).
config_settings keys: sla_threshold_very_high (default 30); sla_threshold_high (default 60); sla_threshold_medium (default 90); sla_threshold_low (default 180); sla_threshold_insignificant (default 180). All in days, range 1–3650. next_review_date_uses (inherent or residual).
External dependencies: None for the cadence itself; the Notification Extra for reminder emails.