A Security Triage Workflow for Teams Without a Security Engineer

Nobody abandons a security backlog on purpose. It happens because the queue has no owner, every item looks equally urgent, and there is nowhere to put "we are not fixing this."

Fix those three things and triage takes twenty minutes a week. Leave them and you get the familiar shape: a dashboard with a four-figure number on it that everyone has agreed not to look at.

This is a workflow for a team of three to fifteen engineers with no dedicated security person.

Rotate one triage owner per week

Not a committee, not "whoever notices". One name, one week, in a rotation everyone takes a turn in.

The rotation matters more than the role. A permanent security owner on a small team becomes a bottleneck, then a single point of knowledge, then a leaver. A rotation spreads the context, and — this is the underrated part — it makes everyone briefly responsible for the noise they would otherwise ignore, which is the fastest route to tuning the scanner properly.

The triage owner's job is not to fix anything. It is to make sure every new finding leaves the queue in one of four states within the week:

• Assigned, with a name and a deadline.
• Excepted, with a reason, an approver and a review date.
• Duplicate of something already tracked.
• False positive, with the rule tuned so it does not come back.

That last state is the one teams skip, and it is why queues grow. Closing a false positive without changing the rule guarantees you will triage the same thing next month.

Sort by exposure first, severity second

Severity alone is a bad sort order for a small team, because it answers "how bad if exploited" and ignores "how reachable is it."

Sort on two axes:

A medium-severity issue on an unauthenticated production endpoint outranks a high-severity one behind an admin login four people hold. Every experienced responder does this intuitively; writing it down is what lets a rotating owner do it without the experience.

Two findings jump the table entirely:

• A live exposed credential. Rotate now, measured in hours. Not a queue item.
• Publicly readable customer data. A database table answering to the public key, a storage bucket listing, an unauthenticated endpoint returning records. Same urgency.

Give every finding one of five states

More states than these and the board becomes an argument about process.

1. New — seen, not yet decided. The triage owner's inbox.
2. Accepted — real, has an owner, has a deadline.
3. Excepted — real, deliberately not scheduled. Reason, approver, review date.
4. Fixed — remediated and confirmed gone by a subsequent scan.
5. Not applicable — false positive, with the rule tuned.

The distinction that carries weight is Excepted versus overdue. A queue with fifteen documented exceptions and zero undocumented overdue items is a functioning process. A queue with zero exceptions and forty overdue items is the same team, worse informed — and it is the version that produces audit findings, because the overdue count has stopped meaning anything and nobody reads it.

An exception needs four fields: why, who approved, when, and when it is reviewed again. Always a date, never "indefinitely". A quarterly pass over expired exceptions takes ten minutes and stops the exception list becoming its own graveyard.

Where the queue should live

Findings belong where the work already is. If your team plans in Linear and triages security in a separate dashboard, one of the two will be abandoned within a month, and it will be the one that is not attached to anyone's sprint.

Two ways to do that honestly:

Sync to the tracker. Findings become issues in Jira or Linear, statuses flow both ways, and closing the issue closes the finding. The detail that decides whether this works: map on the status category — to do, in progress, done — never on the status name, because names are per-project free text and two teams in the same company will not match. Also give the sync an echo guard, or your own push comes back as a foreign change and the two systems fight.

Keep one queue and link out. Triage in the security tool, link the tracker issue on the finding, and let the deadline live in one place. Simpler, and better if only a subset of findings ever become sprint work.

What does not work is maintaining both by hand. One of them is always lying, and it is usually the one you would show a buyer.

Start the clock at detection

The measurement that decides whether any of this is real: the deadline runs from when the finding was first detected, not from when someone triaged it.

If triage starts the clock, a week of ignoring the queue is free, and your on-time rate measures your triage habits rather than your remediation. Materialise the due date on first sight and never recompute it — a deadline that moves when you edit the policy silently rewrites every number you have already reported. Remediation SLAs goes through the mechanics.

The weekly twenty minutes

A shape that survives a busy sprint:

1. New findings since last week (10 min). Each one leaves as assigned, excepted, duplicate or false positive.
2. Overdue, excluding exceptions (5 min). Two questions per item: is it still real, and does it need a different owner.
3. Exceptions past their review date (3 min). Renew with a new date, or move to accepted.
4. Reopens (2 min). Findings marked fixed that came back. A high reopen rate means "fixed" is being used to mean "closed the ticket", which is worth catching early.

Then post the four numbers where the team sees them: on-time closure rate by severity, median time to remediate, count overdue excluding exceptions, and mean time to triage. That last one is the leading indicator — when it climbs, breaches follow.

Cut the noise before you scale the process

A team drowning in triage usually has a tuning problem, not a capacity problem. Before adding process:

• Turn off rules that have never produced a real finding. Ruthlessly. A rule with a 100% false-positive rate over three months is not conservative, it is a tax.
• Deduplicate by fingerprint, not by title. Findings whose identity includes a version number produce a fresh row on every patch bump, and a single misconfiguration across forty crawled pages should be one item, not forty.
• Separate the deployed-app queue from the repository queue. They have different owners, different fix shapes and different cadences.
• Route pre-existing findings out of pull requests. A PR bot commenting on the repository's history rather than the branch's diff teaches everyone to scroll past it. See security review in pull requests.

What CheckVibe provides

For the parts of this that are product rather than process:

• Shared triage on both team tiers — assignment, comments and an activity trail, with every row resolving through the account rather than the acting user. (An early version of ours got this wrong in an instructive way: rows were keyed to whoever was looking, so a five-seat team had five private queues that each looked empty to everyone else.)
• client_viewer as a read-only seat, for a stakeholder who should see the queue and change nothing in it.
• SLA policies with due dates materialised at first detection and never recomputed.
• Slack, Microsoft Teams and signed webhooks for assignment and breach alerts, addressed to a person rather than a room.
• Two-way Jira and Linear sync on Team Advanced, mapping on status category with an echo guard.
• An append-only audit log the database refuses to update — 180 days on Team Basic, a year on Team Advanced.

Team plans start at $25 per seat per month with a five-seat minimum. The pricing page has the full split.

Frequently Asked Questions

Who should triage security findings on a team with no security engineer?

A rotating weekly owner, one engineer at a time, taken from the whole team. A permanent owner on a small team becomes a bottleneck and then a single point of knowledge; a rotation spreads context and makes everyone briefly responsible for the noise they would otherwise ignore, which is what gets the scanner tuned. The owner decides and assigns — they do not do the fixing.

How do you stop a security backlog from growing?

Three things, in order: give the queue one named owner per week, sort by exposure before severity so the list has a real top, and provide a documented exception path so items you have deliberately chosen not to fix leave the overdue count. Backlogs grow when every item looks equally urgent and there is nowhere to record a decision not to act.

Should security findings live in Jira or in a separate tool?

Wherever the team already plans, or synced to it. A separate dashboard that is not attached to anyone's sprint gets abandoned inside a month. If you sync, map on the status category — to do, in progress, done — rather than the status name, because names are per-project free text, and add an echo guard so your own writes do not come back as foreign changes.

What is the difference between an exception and an overdue finding?

An exception is a recorded decision — why it is accepted, who approved it, when, and when it gets reviewed again. An overdue finding is an absence of a decision. Auditors and enterprise buyers read a queue with documented exceptions and no undocumented overdue items as a working process; the reverse pattern is what generates findings, because the overdue count has stopped carrying information.

How often should a small team triage security findings?

Weekly, for about twenty minutes: new findings, overdue items excluding exceptions, exceptions past their review date, and reopens. Daily is unnecessary for anything except live exposed credentials and publicly readable customer data, which should page immediately rather than wait for a queue. Monthly is too slow — the backlog gets large enough between sessions that triage stops feeling finishable.

What does a high reopen rate mean?

That findings are being closed rather than fixed. If a subsequent scan finds the same issue again, either the fix did not address the cause, it was reverted, or someone marked it done to clear the board. Track it as its own number: it is the cheapest available check on whether your remediation metrics describe reality.

CheckVibe gives a team one shared queue with assignment, SLA deadlines from first detection, and an append-only audit trail. See what teams get, or run a free scan to see what would land in it today.