GV.RR-02 says roles, responsibilities and authorities related to cybersecurity risk management are established, communicated, understood and enforced. Everyone should know what they are expected to do, who decides, and who gets told.
What good looks like
Roles are written in policy and in job descriptions. A responsibility matrix shows who is responsible, accountable, consulted and informed for each key activity. People with security duties have performance goals that are measured. Operations, risk and internal audit each know their part and do not leave gaps between them.
How to implement it
- List the activities: access reviews, vulnerability fixes, incident response, vendor reviews, policy updates, training.
- Build a responsibility matrix. One accountable person per activity, and as many responsible, consulted and informed people as needed.
- Add security duties to job descriptions, including for managers and engineers, not only the security team.
- Set performance goals for people with risk responsibilities and measure them periodically.
- Describe authorities. Who may stop a release, approve an exception, or shut off an account in an emergency?
- Communicate the matrix at onboarding and when it changes. Check it is understood by asking a few people what they would do in a scenario.
Evidence to collect
- The responsibility matrix and policy sections that name roles.
- Job descriptions with security responsibilities.
- Performance goals and review notes for security roles.
- Records of communication, such as onboarding materials.
Common gaps
- Two people think the other owns the task, or nobody does.
- Authority is unclear, so an urgent shutdown waits on an email chain.
- Job descriptions never mention security for engineers or managers.
- The matrix is written once and never updated after reorganizations.
A small matrix example
For a company of thirty, "restore from backup" might have the infrastructure lead as accountable, two engineers as responsible, the head of operations as consulted and the CEO informed. "Approve a risk exception" has the head of security accountable below a set score and the CEO above it. Simple tables like this remove most confusion.
Writing authorities down
Authority is the part most companies leave vague. Decide and record who may take a production system offline in an emergency, who may revoke an employee's access without waiting for HR, who may approve a policy exception and up to what risk level, and who may speak to customers about an incident. Put the answers on one page where responders will look.
Quick check
Who should be accountable for each activity?
Exactly one person. If two people are accountable, in practice nobody is.
Do contractors need roles too?
Yes. Include them in the matrix and in access and onboarding processes, since they often hold real privileges.
Sources
- NIST Cybersecurity Framework 2.0 Reference Tool, subcategory GV.RR-02: https://csrc.nist.gov/projects/cybersecurity-framework/filters
- NIST Cybersecurity Framework overview: https://www.nist.gov/cyberframework
The CSF is voluntary guidance. There is no CSF certification, so this post describes how to work toward the outcome, not how to pass an audit.
