In vulnerability remediation, product security should be accountable for triage and priority, the service owner responsible for the fix, platform responsible for shared images and pipelines, and compliance informed and responsible for the record. Write that split down once so nobody waits on a team that thinks the work is someone else's.
Why a vulnerability RACI is different from a general one
A general secure development RACI covers design, build and release. Remediation has one extra trait: the same finding touches three teams at once. Product security decides how urgent it is. The team that owns the service writes the fix. Platform controls the base image, the cluster or the pipeline the fix has to pass through. Compliance needs proof that the whole thing happened on time.
RACI stands for Responsible (does the work), Accountable (answers for the outcome, one person only), Consulted (gives input before) and Informed (told after). NIST SP 800-218, the Secure Software Development Framework, asks organizations to define roles for everyone involved in the life cycle, naming product owners and operations and platform engineers among them (task PO.2.1).
The table
| Step | Product security | Service owner | Platform | Compliance |
|---|---|---|---|---|
| Record the finding in the tracker | R | I | I | I |
| Analyze exploitability and impact | A/R | C | C | I |
| Choose the response: fix, mitigate, accept | A | R | C | C |
| Fix in application code or dependency | C | A/R | C | I |
| Fix in base image or shared pipeline | C | C | A/R | I |
| Approve a time limited exception | A | R (requests) | C | C |
| Verify the fix landed | A/R | C | C | I |
| Keep the record for audit | C | I | I | A/R |
One A per row is the rule. If you write two, you have a disagreement waiting to happen.
Where this goes wrong
Three patterns show up again and again.
First, product security is made accountable for fixing, not triaging. It cannot fix code it does not own, so findings age while it chases people. Keep fixes with the service owner and keep priority with security.
Second, platform is left out of the table. A vulnerable base image affects dozens of services, yet no single service team can fix it. Give platform an explicit row for shared components so the work does not bounce.
Third, compliance is treated as a reviewer at the end. SSDF task RV.2.1 gives the example of using the existing issue tracker to record each vulnerability. If the tracker is the record, compliance can read it directly instead of asking for screenshots later.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how one finding moves from detection to a tracked fix, and ask which team owns each step.
Making it stick
Review the table when a team changes shape, and at least once a year. The SSDF example for PO.2.1 includes an annual review of roles and responsibilities. Put the RACI next to your tracker, not in a slide deck nobody opens. If you use Safeguard, reachability analysis helps product security decide which findings need the fast lane, and fix pull requests (off by default, every category on Manual) give service owners a starting point. You can try a free scan to see what a finding looks like in your own code.
Quick check
Can two teams both be accountable for a fix?
No. Accountable means one named person or role answers for the outcome. Two accountable teams usually means neither acts first. Split the row instead, for example application fixes and base image fixes.
Where does the CISO or security leader fit?
Usually as accountable for the policy that sets timelines, and informed on exceptions above a threshold. Day to day triage stays with product security.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1, tasks PO.2.1 and RV.2.1.
Last reviewed: 19 October 2026.
