Who Owns This Security Finding? Why Remediation Gets Stuck Between Teams
The finding has an assignee. Why is nobody moving it forward?
Security has reported the issue. Engineering has seen the ticket. The application team says the change belongs to the platform team. The platform team is waiting for more context.
Everyone knows about the finding. Nobody owns the next action.
- Separate application accountability from the next action.
- Make handoffs explicit and accepted.
- Escalate a blocker without confusing it with resolution.
A name in a field is only a starting point
An assignee field tells you where a ticket currently sits. It may not tell you whether that person understands the issue, has authority to make the change, or has accepted responsibility for doing it.
Consider an illustrative authorization finding in a Payments API. Fixing it might involve application code, a shared identity component, and a security retest.
Assigning the finding to “Engineering” leaves the difficult questions unanswered: which team, which change, and who acts first?
“It is with Engineering.”
A team name exists, but no accepted action, checkpoint or handoff is recorded.
“We know who acts next.”
A responsible person or team has accepted a specific action, with a checkpoint and a clear completion condition.
Separate the responsibilities
Ownership works better when it describes a responsibility rather than one person being expected to do everything.
- Application accountability
Who is accountable for the affected service and can resolve ownership disputes? - Remediation delivery
Who will implement the change and provide the fix context? - Security coordination
Who clarifies the finding, tracks progress and helps resolve blockers? - Verification
Who will independently check the reported fix and record the outcome?
A small team may combine some responsibilities. The record should still distinguish them, including how verification is performed and any limitations in independence. A role label alone does not prove an independent review happened.
Make every handoff answer three questions
Who acts next? Name the responsible person or team. If a team owns the work, make its point of contact clear.
What must they do? Describe a concrete action. “Investigate the ownership check in the invoice endpoint” is more useful than “look into this.”
When will progress be reviewed? Record the next checkpoint and the applicable remediation deadline. A progress update is not a replacement for that deadline.
The receiving team should confirm the handoff. Until it does, keep responsibility for coordinating the transition explicit rather than assuming a reassignment has solved the problem.
Shared work can involve many teams.
The next action should still be clear.
Multiple teams need coordinated work, not a moving target
When a finding spans teams, keep one coordinating owner for the overall finding and separate the contributing actions.
For the Payments API example, application engineering might implement the endpoint check, the identity team might confirm the shared authorization behaviour, and Security might retest the affected access paths.
Each action needs an owner and a completion condition. The overall record should show dependencies and identify which action is currently blocking progress.
This avoids repeatedly transferring the whole finding whenever another team needs to contribute.
Escalate the decision that is missing
An escalation should explain the blocker and the decision needed:
- Two teams disagree about who owns the affected component.
- The assigned team lacks authority or capacity to make the change.
- A dependency prevents remediation before the deadline.
- A risk decision requires an authorised approver.
Record who must decide, what they need to decide, and when the decision is needed.
Resolving the escalation does not close the finding. A decision may establish ownership, provide resources or approve a time-bound exception. Remediation and verification must still reach their appropriate outcomes.