How it is created — QM-ORG-003 QM Role Matrix & Deputies

1. Why this artifact exists

Every security process names roles: the lead approves the threat model, the vulnerability manager decides triage, a second person authorises a signature. Each of those is one person attached to a deadline measured in hours.

In a large organisation this is invisible, because functions have depth. In a 45-person company most roles are one person, several roles sit on the same person, and the entire difference between a process that runs and one that stalls is whether a deputy was named before the holiday, the illness or the resignation. Naming one afterwards is not possible: the deadline is already running.

The matrix also does something no individual process document can. Each process states its own separation of duties — author cannot approve, developer cannot be sole verifier, requester cannot be approver. None of them can see the others. When a deputy is appointed, it is here and only here that you can check whether the appointment quietly breaks one of them.

2. Inputs

• Every process document that names a role. The matrix is derived from them; if a role appears in a process and not here, one of the two is wrong.
• The actual org chart, with the honest version of who does what — including the roles one person holds simultaneously.
• The separation-of-duty rules scattered across those processes, collected into one place.
• Your on-call arrangement, because the 24-hour regulatory window is the hardest reachability requirement you have.
• Competence expectations per role, and whatever training records already exist.

3. Steps

1. List roles, not people, in the first column — then name the holder by function. When the QA engineer changes, you update one cell rather than auditing every process document for their name.
2. Give every role a deputy, and name the deputy per decision type where the role spans several. A lead who approves both technical designs and risk acceptances may need one deputy for the first and the Managing Director for the second; a single deputy line hides that.
3. Record which documents each role acts in. This is what makes the matrix maintainable: when a process changes, you can see which roles it touches, and when a person leaves you can see what stops.
4. Collect the separation rules into one section. No self-approval, developer is not sole verifier, requester is not signing approver. Written once, they can be checked against every appointment; written five times in five documents, they cannot.
5. Add the rule that deputies are bound by the separations too. A deputy who did the work is not an eligible approver — this is the loophole that opens the moment the deputy is also the doer, which in a small team is often.
6. Say what happens when roles collide on one person for a specific decision: escalate one level. Not "proceed with one signature written twice", which is what happens by default when the document is silent.
7. Distinguish planned from unplanned absence. Planned means a written handover; unplanned means the deputy assumes the role on day one, and no decision waits for a return.
8. Make reachability testable. The on-call rota carries numbers and an escalation path, and the annual notification drill tests the phone numbers as much as it tests the templates. A rota nobody has ever called is a list.
9. Decide deliberately whether the Managing Director has a deputy, and write the reasoning. In a company this size, delegating approval to someone who reports to you makes the approval meaningless. The honest mitigation is reachability plus pre-filled decision templates — and a stated fallback for the case where they are genuinely unreachable inside the window, because a late notification is a breach while a notification submitted by the wrong person is a correction.
10. Handle vacancy explicitly. The Managing Director assumes an empty role until it is filled; a role listed as vacant with no interim holder blocks the release gate. Otherwise vacancies persist quietly, which is exactly what they do.
11. Retain superseded revisions. "Who was authorised to approve this in March 2026" has to stay answerable long after the person has left.

4. Done when

• Every role named in any process document appears here with a holder and a deputy.
• Deputies are differentiated by decision type where a role spans several.
• The separation rules are collected in one place and bind deputies.
• Role collisions on one person escalate rather than proceeding.
• Absence, vacancy and on-call reachability each have a written rule.
• Reachability is tested at least annually, with a record.
• Superseded revisions are retained.

5. Common mistakes

Naming people rather than roles, so every personnel change means editing a dozen documents. A single deputy for a role that makes several kinds of decision. Deputies who inherit the role but not the separation constraints. No rule for the case where one person holds both sides of a four-eyes requirement — the most common situation in a small team, and the one most documents leave silent. A rota with names and no numbers. And treating the matrix as an annual-review artifact when its whole value is being correct on the day someone is unreachable.

6. In TRA Studio

Assigning a requirement to an activity is only half the assignment; the other half is who performs it and who approves it. Where an activity's owner and approver would be the same person, the coverage is weaker than it looks, and that is invisible in a requirement view. Keep the role behind each activity explicit, and treat a role with no named deputy as a gap of the same kind as an unassigned requirement — because when it matters, it will behave like one.