In a secure SDLC, developers are responsible for building and fixing, the tech lead for technical standards, the product owner for priorities and risk acceptance, security for advice and verification, and operations for running and rollback. A RACI table writes this down so nobody guesses during a release.
What RACI means
RACI is a way to assign roles to a task. R is responsible, the one who does the work. A is accountable, the one who answers for the outcome and has the final say. C is consulted, giving input before a decision. I is informed, told after.
Keep one A per row. Two accountable people means nobody is.
Why write roles down
NIST's Secure Software Development Framework, in practice PO.2.1, asks organizations to define SDLC-related roles and responsibilities for everyone involved, to review them periodically and to confirm that people understand changes. Its examples name security staff, champions, project managers and leads, developers, testers, and operations and platform engineers.
A starter RACI
| Activity | Developer | Tech lead | Product owner | Security | Operations |
|---|---|---|---|---|---|
| Write security acceptance criteria | R | C | A | C | I |
| Decide if design review is needed | C | A | I | C | I |
| Design review | C | R | I | C | I |
| Peer code review | R | A | I | C | I |
| Fix a finding | R | A | I | C | I |
| Triage a finding | R | A | C | C | I |
| Accept a known risk | C | C | A | C | I |
| Define pipeline checks | C | A | I | R | C |
| Release go or no-go | C | R | A | C | C |
| Rollback | C | C | I | I | A |
| Post-release review | R | A | C | C | C |
| Root cause analysis of an incident | R | A | C | C | R |
Adjust the letters to match your team. Some teams make security responsible for pipeline checks and the tech lead accountable, as shown. Others prefer a platform team to own them.
How to use it
- Copy the table and edit it with the team in a short meeting.
- Check that each row has exactly one A.
- Replace role names with actual people where the team is small.
- Store it in the repository or the team's wiki.
- Review it twice a year, or when the team changes.
Common traps
- Security accountable for everything. This creates a bottleneck and teaches developers that security is someone else's job.
- No one accountable for risk acceptance. Known issues ship with no record.
- Operations left out. Rollback and runtime fixes land on them, so include them.
- Roles that do not match reality. If the table says the tech lead reviews every change but they do not, change one or the other.
Link roles to evidence
When an auditor or customer asks who approved a risk, the answer should be a name and a record, not a shrug. Pair the RACI with a simple log of approvals and exceptions in the team's tracker. NIST SSDF practice PO.4.1 includes recording security check approvals, rejections and exception requests in the workflow system.
Small teams
If one person holds several roles, name which hat they wear for each decision. A developer who also acts as the tech lead can still be responsible for a fix and accountable for the standard, but should not be the only approver of their own risk acceptance.
Safeguard offers compliance and evidence automation that can map controls to frameworks and keep records of approvals. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one control maps to several frameworks, then think about who on your team owns that control.
Quick check
Can two people be accountable for one task?
It is better not to. Two accountable people usually means no one is. Keep one A per row and use R and C for others.
How often should a RACI be reviewed?
At least twice a year and whenever the team structure changes. NIST SSDF suggests periodic review of roles and responsibilities.
Sources
Last reviewed: 19 October 2026.
