Guide 043 workflow

How to set a vulnerability review cadence your team can sustain

Set a sustainable vulnerability-review cadence with realistic capacity, evidence deadlines and escalation rules for missed reviews and urgent new information.

Use two clocks: an interrupt path for credible urgent exposure, and a predictable weekly block for ordinary claim review and fix checks. In the weekly block, make a disposition on a bounded number of items, reserve time to verify merged fixes, and leave every unresolved claim with a next fact, owner, and review date. Review the size and age of each state monthly. The right frequency is the one the team can actually staff; calling an unattended daily meeting a “daily review” does not reduce risk.

Change the schedule when your service exposure, release rate, or incident load changes. An actively exploited CVE in a deployed component can require action before the next meeting. CISA's Known Exploited Vulnerabilities catalog is a useful input for that prioritization, but catalog membership alone does not show that the affected component is present or reachable in your application. The weekly cadence still handles the ordinary work left behind by the urgent lane.

Separate four kinds of work

A single queue that mixes raw alerts, verified vulnerabilities, accepted risk, and completed fixes makes every meeting longer. At intake, preserve where a claim came from and the assessed revision. Then classify the work by the decision needed:

Work Decision and output Who must attend or provide facts
New claim Reject with counterevidence, investigate a specific missing fact, or record a supported finding; obtain independent challenge for consequential or disputed cases AppSec reviewer; service owner when deployment or controls are unclear
Verified open issue Decide business priority, fix owner, and target decision date Security lead and engineering owner; sponsor for tradeoffs
Proposed or merged fix Check the new revision and relevant behavior; record fixed, still present, or inconclusive Fix owner and independent reviewer
Expiring exception or unknown Renew with a justified owner and date, change the control, or escalate Named risk owner and security lead

OWASP SAMM's Defect Tracking practice calls for a view of known defects, a method to handle duplicates and false positives, access rules, and an explicit process when a timely fix is not feasible. A review cadence turns those expectations into recurring decisions. A raw scanner alert is a candidate for investigation, not automatically a verified defect.

Size the weekly meeting from capacity

Count the time to investigate, obtain owner context, write an actionable handoff, and verify a later change. If one engineer has six protected hours a week, spending all six on new alerts guarantees a growing fix-verification queue. Start with an allocation and revise it from observed time:

Illustrative weekly capacity, not a benchmark: One hour to screen new items and duplicates; two hours for one or two deeper investigations; one hour with engineering owners to decide accepted work; 90 minutes to reassess fixes; 30 minutes to update coverage, exceptions, and next checks.

This is a six-hour example. A calendar that allocates more time than a person has is a plan to accumulate debt. If an urgent allowance is funded separately, name it. In this six-hour plan there is no extra security capacity: interrupts must displace scheduled work, or the sponsor must explicitly add qualified time. If emergencies consume the week, say which ordinary work slipped and reschedule it. Do not quietly mark it reviewed.

Set a work-in-progress limit on active investigations and fixes, not a cap that hides inbound reports. For example, admit two new investigations only if two were resolved or deliberately paused with a named dependency. Keep the remaining alerts in an intake list with age and source. Give the sponsor a view of the oldest waiting credible item and the cause of delay. This is more honest than a dashboard that only counts the small worklist.

Reconcile four weeks against the same six hours

Constructed calendar, not observed team performance: Mariner Cloud has one AppSec lead with six protected hours each week. Service owners and the independent peer have separately agreed participation; their hours are not included in the lead's six. Monday's 24 scanner alerts start as intake, not 24 promised reviews. Two active investigations are the ordinary limit.

Week Intake Deep investigation Owner decisions Fix reassessment State updates Urgent response Total lead hours
1: ordinary flow 1 2 1 1.5 0.5 0 6
2: customer concern 1 0 1 1.5 0.5 2 6
3: deployment artifact late 0.5 2.5 1 1.5 0.5 0 6
4: fix awaiting closure 0.5 2 1 2 0.5 0 6

In week 1, intake links repeated reports and selects two questions. One obtains a technical disposition with the peer; the other waits for the billing route map. The remaining alerts retain an intake owner and age. The lead does not call them rejected because the investigation slots are full.

In week 2, a customer-reported account-boundary concern takes the two investigation hours. The incident owner handles the operational response under the incident plan; the lead preserves the allegation, requests the affected version and advises containment. The ordinary investigation does not advance. Its promised date moves with an explicit notification to the service owner. The 90-minute fix slot remains funded because an older material issue is awaiting closure. If the incident needs more than two lead hours, the sponsor must choose the next displacement; this table is a decision record, not a guarantee that emergencies fit.

Week 3 demonstrates why waiting is a state rather than a meeting. The route map is still absent. The lead pauses that investigation with a Friday evidence deadline and escalates the blocker to the manager. The freed active slot goes to an already selected, ready question. The 2.5 hours include its investigation and preparation for the peer; they do not include an imaginary review of the missing map. Intake is reduced by half an hour, so unscreened items are reported separately and retain urgent-report routing.

Week 4 moves half an hour from intake to reassessment. Assume the supplied exercise evidence shows the repaired invoice path now applies the account rule and the new release is mapped. The reviewer can close that scoped issue. A second merged fix remains inconclusive because its runtime control is unconfirmed; it stays in the next closure slot. Neither outcome depends on whether a scanner alert disappeared.

The four-week adjustment is modest: retain the six-hour calendar, ask the service owner to book a route-map handoff when admitting dependent investigations, while allowing bounded discovery for important unknown services, and keep two hours for next week's closure work. The manager sees the cost: slower ordinary intake until the closure queue falls. A cadence is sustainable when these substitutions are visible, not when the same overloaded calendar repeats every week.

Define what changes the schedule

Write down triggers so an engineer need not wait for permission to raise an urgent concern. Suitable triggers can include: credible evidence of exploitation in a deployed component; suspected cross-customer access; exposed secrets; a new production route with no accountable owner; or a fix that fails reassessment on a material asset. The list must be adapted to the business, incident plan, and on-call authority. CISA describes KEV as an input to prioritization, and NIST's SSDF includes responding to vulnerabilities as part of secure software development. Neither substitutes for checking your deployment and affected scope.

For each interrupt, record who accepted the alert, the provisional harmful action, the currently known exposure, the immediate containment decision, and the next verification step. Suspected exposure can be urgent without being confirmed. If the organization has an incident-response procedure, use it; the ordinary weekly review is not an incident command structure.

Plan for a missed review before it happens

A sustainable cadence needs a fallback for holidays, incidents and absent specialists. Name which decisions can use normal owner review, which require another qualified person and which must wait with a temporary response. This keeps the calendar from becoming either an absolute blocker or a permission to mark unreviewed work complete.

For Mariner, a missed fix-review slot should preserve the submitted revision, the expected security property and the next available reviewer. If the developer changes the patch while waiting, update the submitted revision so the eventual reviewer does not assess an obsolete artifact. If rollout happens under an authorized partial decision, keep the closure state pending rather than implying the review occurred.

The intake fallback matters as well. A reduced screening week must still leave a clear route for credible urgent reports. Tell service owners how to raise suspected customer-data exposure and who receives it. The ordinary queue may move more slowly, but its limitation should not make an urgent report depend on an unattended meeting.

Distinguish waiting time from review effort

A claim that spends a week waiting for a route map has not consumed a week of analysis. Track both elapsed age and reviewer time if the team is diagnosing capacity. The first identifies delayed risk decisions; the second shows where staffing is spent. Combining them into one average can lead to hiring more reviewers when the actual bottleneck is access to deployment evidence.

In week 3, Mariner's route-map delay is a service-owner dependency. The lead's useful action is to name the missing artifact, escalate the handoff and spend available analysis time on ready work. Repeatedly reopening the same source file would increase effort without changing the decision.

At the monthly check, examine a few old items by cause: evidence missing, ownership unclear, repair capacity unavailable or reassessment waiting. Choose one operating change for the dominant cause. A different meeting frequency helps only if it addresses that cause. More frequent meetings cannot supply a policy artifact that nobody owns, and fewer meetings cannot justify leaving a consequential claim unattended.

Review the cadence with honest denominators

At the monthly check, use a dated cohort rather than a single backlog total. For claims received during the month, count how many were accepted, rejected with counterevidence, still under investigation, or not yet reviewed. For fixes merged during the month, retain that fixed cohort and count how many are awaiting reassessment, positively verified, still vulnerable or inconclusive as of the reporting date. Report completed reviews of older fixes separately so throughput does not inflate this cohort's closure rate. Report age by state and the capacity used. A sudden fall in accepted findings may reflect reduced intake or review, not safer code.

Look at exceptions separately: owner, reason, compensating control, expiry, and next review. A missed meeting must not automatically extend an exception. If the team cannot keep its promised interval for several weeks, reduce new assessment intake, negotiate more owner time, or change the interval in the written policy. Do not relabel skipped reviews as complete.

The next action is to block one weekly review and one fix-check slot for four weeks, then measure what each actually finishes. Use the finding triage worked guide to define the disposition gate and the application security policy template to record who can make priority and exception decisions.