Begin with team capabilities
List the recurring work the organisation needs: threat modelling, cloud review, detection development, incident command, risk assessment, identity design and customer assurance.
Use common role language such as the NICE Framework, but tailor tasks to the environment. A generic catalogue should not replace local expectations.
- Outcome and task
- Required context and tools
- Frequency and criticality
- Primary and backup owner
Define observable levels
Use simple levels: learning, working with guidance, independent, and leading or designing. Describe what each level can do and when escalation is expected.
Avoid self-ratings without evidence. Pair reflection with manager observation, work products, simulations and peer feedback.
- Explain the task
- Perform in a safe environment
- Deliver independently
- Coach others and improve the system
Connect the matrix to work
Use the matrix for project assignment, on-call readiness, mentoring and recruitment. Identify single points of human dependency and create rotations.
Do not turn every gap into a training course. Some gaps need better documentation, automation, provider support or a change in architecture.
- Incident role readiness
- Architecture review participation
- Shadow and reverse-shadow assignments
- Cross-team practice
Build credible career paths
Offer technical and management growth. Senior individual contributors can lead architecture, incident learning or detection strategy without becoming people managers.
Review the matrix twice a year and after major environment changes. Keep it separate from a punitive scorecard so people report gaps honestly.
- Published role expectations
- Time for deliberate practice
- Mentoring responsibility
- Recognition for operational improvement
A practical 30-day field plan
Week one — Define work. Tasks and outcomes the team must deliver. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.
Week two — Describe skill. Knowledge, skill and level of responsibility. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.
Week three — Gather evidence. Projects, exercises, incidents and peer review. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.
Week four — Develop. Learning plan, mentoring and rotations. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.
Evidence worth keeping
Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.
- Outcome and task — owner, current state, last validation and any open exception
- Explain the task — owner, current state, last validation and any open exception
- Incident role readiness — owner, current state, last validation and any open exception
- Published role expectations — owner, current state, last validation and any open exception
- Decision log showing who approved residual risk and when it will be reviewed
- Test or exercise result with the actual outcome, not only a pass label
Questions for the leadership review
Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.
- Who is accountable for the security workforce outcome when teams disagree about delivery and risk?
- Which critical service or customer promise would be affected by a failure in this area?
- What evidence would tell us the design is working in production today?
- Which exception creates the largest concentration of access, dependency or recovery risk?
- What would the team contain first, and how would it restore a trustworthy service?
- Which improvement can be completed in the next 30 days without waiting for a large programme?
Common questions
Should certifications appear in the matrix?
They can be learning evidence, but demonstrated tasks and judgement should carry more weight.
How detailed should the matrix be?
Detailed enough to guide staffing and development; if it becomes hard to update, reduce it to the highest-value capabilities.