GV.RR-02 Roles and responsibilities: evidence guide

What GV.RR-02 asks for: named owners for cybersecurity risk decisions

If a customer questionnaire, auditor or regulator asks who owns cybersecurity risk decisions in your organization, GV.RR-02 is the outcome you are being asked to demonstrate. In plain terms, it asks that cybersecurity risk management roles, responsibilities and authorities are set, communicated, understood and enforced. The risk it addresses is familiar: a patch cycle, a vendor review or an access recertification that nobody clearly owns, decisions that stall because no one knows who can approve them, and duties that vanish when a long-serving engineer changes teams or leaves. The CSF 2.0 Core is a framework, not a certification, so no one issues a GV.RR-02 badge. Your organization is assessed on its own evidence, and an independent assessor will look for proof that the assignments exist and are followed.

In practice the hard part is that roles often live in people's heads or in an informal org chart rather than in writing. The CISO may believe the head of infrastructure approves firewall changes, while the infrastructure lead assumes the change board does. Closing that gap means recording who is responsible, accountable, consulted and informed for each recurring risk activity, then carrying those assignments into the documents people actually use: the cybersecurity policy, position descriptions for the security and IT roles, and performance goals that measure whether the duty was performed. NIST's Implementation Examples for GV.RR-02 point to exactly these places, so start there and compare what you find against what people say they do.

Before you prepare evidence, run a short check. Pick five recurring activities, such as vulnerability triage, access reviews, supplier risk approvals and incident declaration, and ask three questions for each: is there a named owner in a written document, does that person's position description or goal reflect the duty, and can the owner name the decision they are authorized to make without escalation. Gaps you find become your remediation plan. Confirm with your assessor or your customer which documents and retention periods they expect, since NIST does not prescribe a format. Wiki platforms with version history, such as XWiki, and role-based permissions, such as those in BookStack, can keep these assignments dated and attributable, but the owners and their authority must come from your own governance decisions.

Which teams, roles and third parties GV.RR-02 covers

GV.RR-02 asks whether cybersecurity roles, responsibilities and authorities are set and enforced, and the answer depends on who is inside the scope. The cards below cover the scoping decisions that change the work most, and each one should be settled in writing before anyone drafts a responsibility matrix or position description.

Functions that hold cybersecurity duties

Decide which departments carry cybersecurity duties beyond IT security, including IT operations, engineering, legal, HR, finance and business owners of systems and data. Each function that owns a risk-relevant activity, such as approving access, signing vendor contracts or running onboarding and offboarding, needs a named responsibility. Check that no duty sits with a function that has no budget, tooling or authority to perform it.

Roles with authority to accept risk

Identify which roles may accept, reject or defer a cybersecurity risk, and state the limit of each authority, such as a dollar threshold, a system classification or a time limit. Acceptance authority that is implied rather than written down is a common gap an assessor finds during testing. Confirm that these roles are the same ones named in the risk register and the risk response records.

Managed service providers with delegated duties

Determine whether a managed service provider or managed security provider performs any duty on the organization's behalf, such as monitoring, patching or access reviews. Delegated duties still need an internal owner who is accountable for the outcome, and the contract should state what the provider does and what it must report back. Record the boundary between the provider's responsibilities and the organization's own.

Organizational Profile as the boundary

Use the Current and Target Organizational Profiles to set which business units, systems and suppliers fall inside the CSF scope. Roles that appear in the profile are in scope for GV.RR-02, and roles outside it need a documented reason for exclusion. Revisit the boundary whenever the profile changes, because a new business unit or system with no owner is a frequent source of accountability gaps.

Implementation Examples that apply

NIST publishes Implementation Examples covering policy wording, responsibility matrices, position descriptions, performance goals, and responsibilities in operations, risk and internal audit functions. Not every example fits every organization, so decide which apply and record the reason for each one you skip. The chosen set becomes the evidence list that an assessor will check against.

ISO/IEC 27001 mapping needs

The NIST CSF 2.0 Reference Tool lists informative mappings from GV.RR-02 to ISO/IEC 27001:2022 clause 7.2 and Annex A controls 5.2 and 5.3. If your organization is also working toward ISO/IEC 27001, the scope decisions above determine whether those mappings need to be reproduced in your own evidence. Confirm the mapping against the current Reference Tool export before relying on it in a client deliverable.

How an assessor tests GV.RR-02 audit readiness

This table lists the tests an independent assessor typically runs against GV.RR-02, the evidence each test asks for, and the gaps that most often surface. Use it to check your own records before an assessment, and note that conclusions about conformity come from the independent auditor or assessor, not from any implementation partner.

Test approach	Evidence requested	Common findings
Read the cybersecurity policy for named role assignments	Current approved policy with roles, owners and approval dates; version history showing when role text last changed	Policy names a role (for example, a risk owner) with no person or position assigned to it; approval date is older than the last organizational change
Sample the responsibility matrix against real decisions	Responsibility assignment matrix (responsible, accountable, consulted, informed) traced to sampled risk acceptances, incident decisions and exceptions	Decisions were signed off by someone not listed as accountable; matrix covers only the security team and omits business owners
Check position descriptions for security duties	Position descriptions for a sample of security, IT and business-owner roles, showing cybersecurity duties written into them	Roles named in policy are missing from job descriptions; duties exist only in verbal or chat-based instructions
Review performance goals for cybersecurity objectives	Goal-setting records or objectives for a sample of accountable roles, plus how progress was measured	Goals are generic, unmeasured or absent for accountable roles; no evidence that results were reviewed
Interview staff to confirm they know their duties	Interview notes with role holders and their managers, compared against the policy and matrix	Staff describe a different owner than the documented one; incident responders are unsure who has authority to isolate systems
Confirm that assigned owners are still in post	Current staff list or HR records matched to every named owner, with handover records for changes	Owners have left the organization and no successor was recorded; contractor-held roles have no end date or review
Check that authorities match responsibilities	Delegation of authority records and escalation paths tied to the sampled decisions	Responsible staff lack the authority to act; escalation paths in policy do not match how incidents were actually handled

How to implement GV.RR-02 in six steps

This sequence turns the GV.RR-02 outcome into a working record of who owns each cybersecurity risk activity, what that owner is expected to do, and how leadership and internal audit confirm the assignments hold up over time.

Inventory the cybersecurity activities that need an owner
List the recurring and one-off cybersecurity risk management activities your organization performs, such as approving risk acceptances, maintaining the asset inventory, reviewing access, running vulnerability management, and approving supplier exceptions. The security lead and the heads of IT, operations, legal and HR usually build this list together. The output is a single register of activities with a named business owner or a blank field. Each blank is a finding. Activities with no owner often reveal decisions that nobody has been asked to make, and those belong on the agenda for leadership before the matrix is drafted.
Draft a responsibility assignment matrix
For each activity, record who is responsible for doing the work, who is accountable for the outcome and holds the final decision, who is consulted before decisions are made, and who is informed afterward. Keep exactly one accountable party per activity so that the record answers the question of who is answerable when something goes wrong. Store the matrix in a version-controlled location so that changes are traceable. The output is an approved draft matrix that every named role has seen. Confirm the wording with the people who will hold each role, because a matrix that no one has read will not hold up in an incident.
Add cybersecurity duties to policy and position descriptions
Write the accountabilities from the matrix into the cybersecurity risk management policy and into the position descriptions of the affected roles. The policy states the principle and the governing bodies, while position descriptions state the duties each person performs. Compare the wording against the job families used by HR so that the duties are written in the terms the organization already uses. The output is an updated policy and a set of revised position descriptions, each approved by the people who own the policy and by HR. Where a role is shared across departments, state which part of the duty sits with each department.
Set and measure performance goals tied to duties
Translate each cybersecurity duty into one or more performance goals for the role holder, such as completing a scheduled access review or closing assigned risk treatments by an agreed date. Agree the measures with the manager and the role holder, then record how progress will be evidenced, for example through a ticket history or a signed review record. The output is a goal set for each affected role that the manager can review during the normal performance cycle. Goals should describe observable work, because a goal that cannot be checked cannot be enforced.
Confirm authority and escalation paths with leadership and internal audit
Walk leadership through the matrix to confirm that each accountable owner has the authority to make the decisions assigned to them, including the authority to stop or change work and to accept or refuse risk. Define the escalation path for disputes and for decisions above an owner's authority. Ask internal audit to review the matrix against the policy and position descriptions so that the assignments can be tested later. The output is a signed-off set of authorities and escalation paths, along with internal audit's written comments. Ask leadership to confirm that owners will be given the resources to perform their duties, since authority without resources is a common gap.
Communicate and review assignments on a set schedule
Publish the approved matrix, policy and position descriptions to the people who need them, and brief each role holder on their duties and goals. Set a review schedule that matches how often the organization changes staff, systems and suppliers, and record each review with the date, the reviewer and any changes made. Update the matrix whenever a role changes hands or a new activity appears, and keep the prior versions so that auditors can see how assignments changed. The output is a dated review log and a current matrix that matches the people who hold each role today.

GV.RR-02 evidence that passes an assessment

An assessor will not accept a statement that roles exist. The evidence has to show who holds each responsibility, how that assignment reaches daily work, and that owners have used their authority. The six artifacts below work together, and each should have a named owner and a review trigger so it stays accurate between assessments.

Approved policy naming roles

The cybersecurity risk management policy, or the section of it covering roles, names the accountable executive, the CISO or equivalent, risk owners and the functions that carry out controls. Check that the approval date, version and approver are recorded, and that the named roles match the organization chart. A policy that names a role nobody holds is the most common gap. Assign the policy owner and set a review trigger for reorganizations, new business lines and leadership changes.

Responsibility assignment matrix

A matrix maps each cybersecurity activity, such as risk acceptance, vendor approval, access review and incident communication, to who is responsible, accountable, consulted and informed. Each activity should have exactly one accountable party. Keep the matrix in a controlled location with its own version history, and record who maintains it so changes are traceable during an assessment.

Position descriptions with security duties

Position descriptions for roles that carry cybersecurity duties should state those duties in the job's own terms, such as approving access requests or owning a system's patching schedule. Assessors compare these descriptions with the matrix to find contradictions. Ask HR to record the review date for each description and to re-check it whenever a role's scope changes.

Performance goals and review records

Goals and completed reviews show that cybersecurity responsibilities are measured, not only written down. Look for objectives tied to specific duties, such as completing quarterly access reviews on time, and for review notes that record whether those objectives were met. Confirm with HR which review cycle applies, since the record must cover the period under assessment.

Role acknowledgments and communication records

Signed acknowledgments, training completions or briefing records show that role holders received and understood their assignments. Keep the acknowledgment date, the version of the document acknowledged and the person's role at that time. When an assignment changes, a new acknowledgment should follow, so the record matches the role as it stood on the assessed date.

Internal audit and management review minutes

Minutes from management reviews or internal audit findings confirm that owners act on their authority, for example by accepting a risk, approving an exception or ordering a remediation. This is the artifact that proves enforcement. Record the decision, the owner who made it and any follow-up action with its closure date. Set a recurring review of these minutes so gaps surface before the assessor finds them.

What GV.RR-02 costs in effort and money

This table lists the cost components of documenting roles and responsibilities under GV.RR-02, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for asking any quote to price each line separately, since no supplied figures exist for these items.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Drafting the responsibility matrix and policy text	Internal security or GRC staff, or an implementation partner under a written scope	One-time, then revised	Up with the number of business units and third parties holding duties; down when existing policy structure can be reused
Revising position descriptions and performance goals	HR and line managers, with security staff reviewing wording	One-time per role family, then recurring at each role change	Up with the number of distinct job families; down when job descriptions already follow a standard template
Legal review of assigned duties	Internal or external counsel, billed by the hour or as a fixed review	One-time, repeated when contracts or employment terms change	Up with jurisdictions, unionized staff or contracts that name security duties; ask whether review is in the quote
Keeping the matrix and evidence current	Policy owners and system administrators	Recurring, usually tied to reorganizations and annual reviews	Up with frequency of reorganization and number of systems of record; down with a single system of record
Version history and tooling	Platform or GRC administrators; open-source tools remove license spend but not staff time	One-time setup, recurring administration	Up when several tools hold responsibility records; down when one self-hosted wiki or GRC tool keeps the approved versions
Optional external review or auditor sampling	Independent auditors or assessors, who issue any report or opinion	Recurring at each assessment cycle	Up with sample size and number of roles tested; ask the assessor to confirm sampling approach before scoping
Training managers on accountability	Internal HR or security teams, or an external trainer	Recurring for new managers and at policy changes	Up with manager turnover and dispersed teams; down when training is folded into existing leadership programs

Open-source tools that keep role evidence current

Roles documentation for GV.RR-02 goes stale quickly unless its edits are tracked and its editors are controlled. The two tools below cover those needs, and each one still needs checking against your own audit trail requirements before you rely on it.

Versioned roles documentation with XWiki

XWiki is licensed under LGPL-2.1-or-later and keeps every change to a page under version control, recording what changed, when and by whom. Reviewers can compare any two versions and roll back to an earlier one. For GV.RR-02, this gives you a history of the policy statements and responsibility assignments that name who is responsible, accountable, consulted and informed. Confirm that the recorded history meets your audit trail requirements, including how long versions are kept and whether you need separate sign-off records. Your legal team should review the LGPL-2.1-or-later terms before you adopt it.

Scoped editing rights with BookStack

BookStack is licensed under MIT and derives each user's abilities from assigned roles. Permissions can be overridden per role at the shelf, book, chapter or page level. For GV.RR-02, you can let the security team edit the cybersecurity policy book while business owners only read it, or let a single function maintain its own responsibility pages. This limits who can change who is accountable for what. Confirm that role changes are logged in a form your auditors accept, and have your legal team review the MIT license terms for your deployment.

Who does what for GV.RR-02: your team, a partner and the auditor

Your organization owns GV.RR-02. Leadership must decide who is accountable for cybersecurity risk management activities and formally accept those duties, because no partner or auditor can assign authority on your behalf. HR owns the position descriptions and performance goals that make those duties part of everyday employment, and the CISO maintains the responsibility matrix and reports on whether the assignments are being followed.

Leadership decisions: Executives name the accountable owners for each risk management activity and approve the matrix in writing.
HR position descriptions: HR adds cybersecurity duties to job descriptions and confirms that new and changed roles carry them.
Performance goals: Managers set and review cybersecurity goals for staff who hold assigned responsibilities.
CISO reporting: The CISO keeps the matrix current after reorganizations and reports enforcement gaps to leadership.
Acceptance records: Each named owner signs or otherwise records acceptance of the duties.

Before engaging anyone, confirm that these decisions and signatures exist in your own records, since the auditor will ask to see them.

Where GV.RR-02 programs usually fall short

GV.RR-02 is met when people can point to a written assignment of cybersecurity responsibility and see it enforced in daily work. The gaps below share one pattern: the assignment exists on paper, but nothing connects it to position descriptions, reviews, handovers, third parties or audit testing.

Roles missing from position descriptions

The security policy names a role, such as the owner of access reviews, but the position description for the person filling it never mentions the duty. When the policy and the job description disagree, the assignment is hard to enforce and hard to defend. Check a sample of policy-named roles against current position descriptions and HR records. Where a duty is missing, add it to the position description and have the employee acknowledge the change.

Activities without a single accountable owner

A responsibility matrix lists several teams as responsible for a control, yet no one is marked accountable for the outcome. Work then stalls at handoffs, and an assessor asking who answers for the result gets several answers. For each cybersecurity activity, confirm one accountable owner, then check that the owner has the authority to approve, fund and escalate it. Record the change in the matrix with a date and approver.

Security goals absent from performance reviews

Staff are told to own security outcomes, but their performance goals never measure them. Without a goal, a manager has no basis to recognize good work or address missed duties, and the assignment stays theoretical. Review the goals of staff who hold named cybersecurity responsibilities and confirm that at least one goal reflects each duty. Ask managers to document how the goal was assessed at the end of the cycle.

Duties left with departed staff

When someone with security duties leaves, their recurring tasks such as certificate renewals, log reviews or vendor reassessments often go unowned until a failure exposes them. Offboarding checklists rarely list responsibilities, only accounts and equipment. Maintain a register of recurring security duties tied to named roles, and require a reassignment to be recorded before an accountable owner's last working day. Confirm the gap is closed by checking one recent departure.

Third parties holding delegated duties

A managed service provider monitors logs, a cloud partner patches the platform, or a consultant runs vulnerability scans, yet the internal responsibility record shows no trace of these delegations. The organization still owns the risk, but nobody can say who checks the provider's work. List each outsourced activity, the provider contact, and the internal person accountable for overseeing it. Confirm the contract and the responsibility matrix describe the same division of duties.

No audit testing of assignments

Responsibilities may be documented and still never be tested. Internal audit plans often cover controls but not whether the people named for them know their duties and perform them. Ask internal audit to include a check of role assignments in its plan, for example by sampling responsibility matrix entries against evidence of performance. Record findings and track them to closure so the gap is visible to leadership.

GV.RR-02 questions buyers ask before hiring help

Can NIST CSF 2.0 be certified?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans for a conformity assessment program. What you can get is either a self-assessment, where your own team records how well GV.RR-02 is met, or an independent assessment by an outside assessor who reviews your evidence and reports on it. Only the independent assessor issues a report. Ask any firm offering a CSF "certification" what body accredits it and what document you would receive, and treat vague answers as a warning. DeployOpen prepares roles, policies and evidence for assessment but does not issue reports or certificates.

How long does a RACI matrix and position description update take?

The duration depends mainly on how many roles, business units and position descriptions are in scope, how many people must review and approve each one, and whether the organization already has current documents to start from. Each of those drives effort up or down. Request a quote that lists each deliverable, the number of roles or position descriptions covered, the review rounds included, and the dates on which the organization must supply input. Also ask whether later revisions are included or billed separately. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote should follow from that written scope.

What does the organization have to provide for this work?

Most of the effort falls on the organization, not the partner. Expect the following inputs:

Named executives who will own the decisions about who is accountable for each cybersecurity risk management activity.
HR time to update position descriptions, performance goals and onboarding and offboarding steps.
Legal or contracts time to check that policy wording and delegated authority match employment terms, board charters and supplier agreements.
Business unit leads who confirm what their teams actually do.

If these people are not available or do not agree on accountability, no partner can settle it for them, so confirm their time commitments before signing.

Can our own staff define roles and responsibilities without a partner?

Yes. GV.RR-02 is about decisions that leadership must own, so an internal team can do the work if executives make the accountability choices and the team has time to document them. Internal teams often struggle with three things: getting people outside security to accept accountability, writing position descriptions that HR will approve, and keeping records current once the first version is done. An outside partner can help with drafting and structure, but the organization must still make and sign the decisions. Whichever route you choose, record who approved each assignment and when.

What does an auditor need compared with what a partner prepares?

An auditor or assessor tests whether the organization's roles are documented, approved, communicated and actually followed. They look for a policy that names responsibilities, a responsibility assignment record, position descriptions with cybersecurity duties, performance goals that include them, and evidence that people act on those duties. They do not write these documents for you. A partner prepares the systems and evidence: it drafts the policy text, builds the assignment matrix, updates templates and sets up the places where records live. The organization owns the controls and the approvals, and only the independent assessor issues any conclusion about them. Confirm the assessor's requirements before work starts so the evidence matches what they will request.

How do we keep role evidence current between assessments?

Treat roles as living records with named owners and review dates. Set a review trigger for each change in leadership, reorganization, new service or regulatory requirement, and record the date each assignment was last confirmed. Self-hosted wiki platforms can help here. For example, XWiki keeps every change under version control, recording what changed, when and by whom, and lets users compare versions and roll back. BookStack assigns abilities through roles and can override permissions per shelf, book, chapter or page, which helps limit who can edit approved responsibility records. Confirm how any platform you choose handles approval workflows, since version history alone does not prove a change was approved.

Which NIST references should we check when defining GV.RR-02 roles?

Start with the GV.RR-02 entry in the CSF 2.0 Core in NIST's publication, then review its Implementation Examples, which describe documenting roles in policy, recording responsible, accountable, consulted and informed parties, adding cybersecurity duties to position descriptions, and setting measurable goals. For a small organization, NIST's Small Business Quick-Start Guide cites GV.RR-02 when it asks who will develop and carry out the cybersecurity strategy. Use the informative references that map GV.RR-02 to other standards only as starting points, and confirm each mapping against the standard itself with your assessor, since the mappings are not a substitute for their text.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans and implements self-hosted open-source platforms inside the client's own infrastructure. For GV.RR-02, we help prepare the systems and documentation that show who is responsible and accountable for cybersecurity risk activities, while the organization owns its roles and an independent assessor reviews the evidence.

How we scope

We agree a written scope listing which roles, responsibility assignments and position descriptions are in scope for GV.RR-02.
We confirm which platforms will hold role records, such as the wiki, approval workflow or access system used for policy.
We ask the organization to name its accountable owners so the scope reflects its real decision makers and not an assumed structure.

How we build

We configure a self-hosted wiki or documentation platform with version history so role and policy changes are traceable.
We set up role-based permissions so documented responsibilities match who can edit and approve governance records.
We draft a responsibility matrix template recording who is responsible, accountable, consulted and informed for each activity.

How we hand over

We deliver the documented role records, permission configuration and change history as evidence for the organization's own review.
We provide a short runbook explaining how owners review role assignments, update them and record approvals over time.
We flag gaps where the organization still needs to decide roles, since those decisions and their sign-off remain its responsibility.

How we support

Fixed-scope engagements end with a written handover, and ongoing support is available as a retainer for changes to roles and platforms.
Retainers can cover periodic reviews of role records ahead of internal audits or independent assessments.
Questions about certification, scoring or assessor selection should go to the organization's chosen independent assessor, since DeployOpen does not issue reports or certificates.