Team Workflow & Assignment is the layer that decides who fixes what. It turns validated findings into named work items, scores the best owner for each one against current workload and role, records individual assignment changes as history entries you can read back, and shows you where the queue is piling up. It sits between triage and remediation: triage says a finding is real, this module puts a person’s name on it.
The problem
Scanners are good at producing findings and bad at producing accountability. A week of scanning hands a security team a few thousand rows, and the distribution work happens in a spreadsheet: someone sorts by severity, guesses who has spare capacity, pastes ranges into a chat window, and hopes the handoff sticks.
The failure modes are always the same.
A senior engineer becomes the safe choice for every critical finding and becomes the bottleneck for the whole program.
It is assigned to nobody at all and simply ages.
Nobody can reconstruct who was asked to fix a given host in March, or when it moved off their plate, so when an auditor asks, the answer is a reconstruction rather than a record.
Because the spreadsheet has no notion of load, the team finds out someone was over capacity only when their items go past due.
How it works
- Every finding becomes a task record
Work is tracked on tasks, not on the raw vulnerability row. A task carries a title, description, priority, type, estimated hours, due date, creator, assignee list, and its own workflow state. When the assignment queue has no unassigned tasks left in it, the view looks for vulnerabilities that have no task attached and creates one for each, deriving the priority from the finding’s risk. A Critical finding becomes a critical task, High becomes high, everything else lands at medium. Tasks can also be created by hand for work that has no scanner behind it, such as a compliance review or a documentation job.
- The engine scores each candidate owner
For each unassigned task that is linked to a finding and has not been started yet, the system walks all active users and scores them on four weighted factors:
Available capacity, 40%Measured as current active tasks against a fixed ceiling of ten.
Role fit, 30%Favours pentest roles and matches technicians against web-class findings such as SQL injection or XSS.
Priority fit, 20%Steers critical work toward admin, manager and external pentest roles.
Track record, 10%Taken from that person’s completed-task count.
Only users with a free slot are eligible, so a saturated engineer stops being proposed. The engine returns the single highest scoring candidate for each task, with a numeric confidence score and a short reason string naming the factors that applied, such as the number of free slots, the matching role, and the count of completed tasks.
- A person confirms the assignment
Suggestions do not apply themselves. Each one opens a dialog pre-selecting the recommended owner, and you can accept it, swap in someone else, or add several people before confirming. A task supports multiple assignees with one designated primary owner, so pairing a technician with a reviewer is a first-class action rather than a comment. Confirming writes the assignee list, stamps who assigned it and when, and, for tasks linked to a vulnerability, raises an in-app notification for each newly added owner.
- Bulk actions for the long tail
The task inventory tab lists every task you are allowed to see, filterable by status, priority, assignee (including an explicit “unassigned” filter) and free-text search over title and description. Select any subset and assign them to one person, move them to a new status, or delete them in one call. Bulk endpoints check permission per item, so work you are not entitled to touch is skipped rather than silently applied, and the bulk assign and status responses name the skipped IDs.
- The task carries its own stage history
Each task moves through a fixed chain: detected, analysis, in progress, testing, completed. Advancing rebuilds the full chain cumulatively, so earlier stages are marked complete with the user and timestamp that closed them instead of being overwritten. Stages can be reverted when a fix fails verification, and any stage can be escalated with a written reason that is stored on the stage entry. The task’s own status and start/completion timestamps are kept in step with the stage.
What you can do
For every unassigned finding that has a task, with the score and the reasoning shown before you commit.
Assign one task to several people and nominate a primary owner.
Replace the owner list, adding and removing in the same action, both recorded.
Claim it for yourself, which is refused if someone already holds it.
Bulk-assign, bulk-restatus or bulk-delete, with permission checked on every item and unauthorised IDs reported back on the assign and status calls.
Who was added or removed, when, and by whom, recorded on the individual assign and claim actions, including the ones applied from a suggestion.
The tasks each member holds, how many they have completed, and a load percentage against the same ten-task reference, plus a team balance score derived from the spread between the busiest and lightest member.
Total tasks, assigned tasks, findings that still have no task at all, overdue tasks (past due date and not closed), average completion hours, completion rate, and velocity as tasks completed per day over the last seven days.
By status, priority, owner, type, due-date range and text search, with pagination.
Notes and attribution are preserved on each stage.
Who it is for
SOC leads and triage analysts use it as the distribution desk: the queue arrives validated, and the job is to place it well and spot the pile-ups. System administrators and technicians use it as their work list: the items genuinely assigned to them, with a start and complete action gated to the people actually on the task. Penetration testers pick up analysis and retest work and hand it back through the stage chain. Security managers and CISOs use the load view to answer the resourcing question. Whether the backlog is a staffing problem or a distribution problem. Compliance officers use the assignment history, because “we fixed it” is weaker evidence than “this named person was assigned it on this date by this manager, and closed it on that date.”
Why it matters
Distribution is where remediation programs leak time. Findings that sit unassigned are not being worked on by definition, and the dashboard counts the findings that still have no task at all, so that number is visible instead of implied. Suggestions cut the per-item decision from a judgement call to a confirmation, which is the difference between placing forty items and placing four hundred.
Capacity-first scoring also protects the people who are good at this. When the ranking treats free slots as the heaviest factor and drops saturated users from consideration entirely, work stops defaulting to whoever said yes last time. The balance score turns “the team feels swamped” into a figure you can show a budget holder.
Access is scoped by role. Admin and manager accounts see and act on everything; everyone else sees only tasks they created, own, or are assigned to. That scope is applied on the task list, on reading, updating and deleting a single task, on the assignment call and on the bulk endpoints, and starting or completing a task is limited to the people actually on it. Because the platform runs entirely inside your own infrastructure, none of this assignment data, who works on what, where you are weak, leaves your network.
Works with
- AI Triage, decides which findings are real and worth a task, so assignment is not spent on noise
- Task Management, the task record itself, its detail view, templates and stage controls
- User Management & RBAC, the roles and accounts the scoring and the permission checks both read from
- Notifications, tells a new owner in-app that something landed on their plate
Frequently asked questions
Does it assign work automatically, without a human?
No. The engine proposes the highest scoring owner; a person opens the suggestion and confirms, adjusts or replaces the proposed owner before anything is written. That is deliberate, an ownership decision that nobody signed off on is hard to defend later. If you want hands-off operation across the wider remediation flow, that lives in Autonomous Operations behind its own approval gates.
How does it know who is overloaded?
It counts. For each active user it queries their tasks in not-started or in-progress state, matching both the primary owner field and the multi-assignee list, and expresses that against a fixed ceiling of ten concurrent tasks, which is a built-in reference rather than a per-user setting. Users with no free slots are excluded from suggestions entirely. Nothing here is self-reported or estimated.
Can a regular analyst see the whole team’s work?
Only if their role allows it. Admin, manager and administrator roles have full scope. Every other role is filtered to tasks they created, are the primary owner of, or appear in the assignee list of: on the list view, on reading, updating and deleting a single task, on the assignment call, and on the bulk endpoints.
What happens when a fix does not hold?
The stage chain runs both ways. A task in testing can be reverted to an earlier stage with a note, and the earlier stage entries keep the user and timestamp that closed them, so the history reads as a real sequence of attempts rather than a single overwritten state. A stage can also be escalated with a written reason that is stored against it.
Assignment is the cheapest part of a remediation program to fix and the most expensive to leave broken.
An unowned finding is an open finding no matter how good the scanner was.
SITEY deploys in your own infrastructure with every module included; see pricing for the monthly and lifetime options.