GV.RR-04 Cybersecurity in HR practices: requirements and evidence

What GV.RR-04 asks HR to do for cybersecurity

GV.RR-04 is the NIST CSF 2.0 Subcategory stating that human resources practices include cybersecurity. It sits in the Roles, Responsibilities, and Authorities Category of the GOVERN Function, and it is the point where an auditor, a customer questionnaire or an internal review will ask how HR supports security. The risk it addresses is familiar: a person who joins with more access than the job needs, keeps that access after moving teams, or leaves with credentials still active. Insider misuse and stale access are often not exotic attacks. They are gaps between the moment a person's employment changes and the moment the systems catch up. The Subcategory asks the organization to close that gap on purpose, with HR events driving security actions. The work is hard for a structural reason. HR runs the employee lifecycle in an HRIS or applicant tracking system, while security runs identity, access and logging in directory services and applications. These two processes rarely share an owner, a ticket queue or a definition of "joiner, mover, leaver." Evidence is therefore scattered: an offer letter in HR, a background check report with a vendor, a group membership in a directory, and a revoked session in an application log. Each piece may be correct, yet no single record shows that a change in employment led to a change in access within an agreed time.

Start by asking who owns each lifecycle event in writing, and which system is the source of truth for employment status. Confirm with your HR and security leads whether role changes trigger a documented access review, and whether terminations trigger deprovisioning that is logged and tested. The Subcategory's Implementation Examples describe these actions in general terms, so your own policy and procedures must make them specific. Assessors will generally test a sample of real joiners, movers and leavers and ask for the trail. Build that trail before the assessment, and confirm the expected timing and evidence format with your independent auditor.

Which people, roles and systems GV.RR-04 covers in practice

GV.RR-04 is only as complete as the population it reaches. The cards below separate the people, the systems that trigger access changes and the third parties that sit outside HR but still handle sensitive data. Each scoping choice decides who gets screened, who gets rechecked and whose access must be removed on time.

Employees and their lifecycle events

Employees are the baseline population: hires, transfers, promotions, leaves and departures. Each event should trigger a security step, such as confirming the access profile for a new role or removing access on the last working day. Check whether your HR system records these events with dates, and whether someone owns the step when a record changes. The gap to look for is an employee who changes role without any access review.

Contractors and temporary staff

Contractors and temporary staff often hold working access without appearing in the HR system. Decide early whether they enter through HR, through procurement, or through a sponsoring manager, because that choice sets who runs screening and who receives the offboarding notice. Confirm which team records their end dates. Without a named owner, contractor accounts tend to outlive their engagements.

Sensitive and privileged roles

Privileged administrators, staff with access to regulated data and roles that approve payments or change production systems form the sensitive tier. NIST's Implementation Examples expect background checks before onboarding to these roles, with periodic rechecks afterward. List these roles explicitly in a register, so screening rules apply by role rather than by job title alone. Confirm with legal counsel which checks the law allows in your jurisdiction.

HR systems and identity sources

The HR system of record and the directory that holds accounts are the two sources that drive access changes. When they disagree, access drifts. Map which system is authoritative for hires, role changes and terminations, and confirm how changes flow into the directory. Self-hosted identity platforms such as authentik can push user and group changes to target applications over SCIM 2.0, which removes manual copying between the two sources.

Directories that hold group membership

Group membership determines what an employee can reach, so directories that store users, groups and hosts need the same lifecycle rules as the HR system. FreeIPA, which uses 389 Directory Server, supports centralized access control and delegated administration. Check who can add people to privileged groups, and whether that delegation is itself recorded and reviewed. Delegated administrators are often overlooked in HR-linked scoping.

Third parties handling sensitive data

Outsourced providers such as payroll bureaus, background-check vendors, managed service providers and staffing agencies may handle personal data or hold accounts on your systems. Include them in scope when they touch sensitive information, and require them to notify you when their staff change roles or leave. Your contracts should state who screens their people and how quickly they report departures. Ask each provider to confirm these obligations in writing.

How an assessor tests GV.RR-04

This table sets out how an assessor would test each GV.RR-04 Implementation Example, the records requested for each, and the findings that commonly appear. Read each row as a test step: the procedure walked through, the sample drawn, and the proof that closes it. Because NIST does not certify assessments, the assessor here is the reader's own internal audit, a customer's reviewer or an independent auditor the organization chooses.

Test area	What the assessor does	Evidence requested	Common finding
Screening and onboarding procedure	Walks through the written screening and onboarding steps with HR and security, then compares them with what staff actually do	Current screening procedure, onboarding checklist, version history and approval date	Checklist exists but nobody can show it was used for a given hire
Joiner sample	Selects a sample of recent joiners across roles and checks each file against the procedure	Signed onboarding checklist, screening result, account creation ticket, security awareness completion	Screening step skipped for contractors or staff hired through agencies
Role change (movers)	Samples staff who changed roles in the period and checks that access was reviewed and adjusted	Role change notification, access before and after the move, manager approval of new access	Former access kept after a transfer because no one notified IT
Leaver sample and exit date	Samples leavers and compares the exit date with the date accounts were disabled in each system	HR termination record, identity provider deprovisioning log, application account status, device return record	Access not removed on the exit date, or disabled only in the directory and not in downstream applications
Background checks before sensitive access	Identifies sensitive roles, then checks that each check was completed before access was granted, and that periodic rechecks occurred	Sensitive role list, background check result dated before access grant, recheck schedule and records	Access granted before the check finished, or no list of which roles count as sensitive
Personnel acknowledgment of security policy	Checks that current staff and contractors signed or accepted the security policy and that acknowledgments were refreshed after policy changes	Signed or recorded acknowledgments with dates, policy version accepted, list of staff without acknowledgment	Acknowledgments on file for some staff only, with no follow-up for those missing
Screening documentation	Asks where screening results are stored, who can read them and how long they are kept, without reviewing the personal detail itself	Retention rule, access list for HR files, record of screening decisions	Screening performed but not documented, so the assessor cannot test it

Implementing GV.RR-04 step by step

This sequence turns HR events such as hiring, role changes and departures into named security actions with owners and evidence, so cybersecurity is built into people processes rather than handled ad hoc. Each step produces a document or record that an assessor can trace back to GV.RR-04.

Map HR lifecycle events to security actions
Start by listing every HR event that changes a person's access or obligations: candidate screening, offer acceptance, first day, transfer, promotion, leave, contractor extension and separation. HR and the security lead work through the list together and assign each event a security action, an accountable owner and a system of record. The output is a lifecycle matrix with one row per event. The step is complete when HR and security have both signed the matrix and every row names a control owner.
Define sensitive roles and background check scope
Identify which positions handle privileged access, regulated data, financial controls or safety-relevant systems, and record why each one is sensitive. Legal and HR confirm which screening steps local law permits for each role, including whether any recheck interval applies. The output is a sensitive-role list that states the screening level and recheck trigger for each role. Ask counsel to confirm the approach for each jurisdiction where you employ or engage people before the list is adopted.
Add security to onboarding and role change checklists
Extend the onboarding checklist with items that cover policy acknowledgment, security awareness training, least-privilege access requests and approval by the manager and a named security approver. Build a parallel checklist for role changes that removes prior access before new access is granted. The output is two versioned checklists stored in the HR system or a wiki with change history. The step is done when a sample of recent hires and movers can be traced through each checklist item to a completed record.
Set up policy acknowledgment and personnel obligations
Publish the security policies personnel must follow, then require each person to acknowledge them at hire, after material policy changes and at a cadence the policy sets. Include the obligations that matter most in your environment, such as handling of confidential data, acceptable use and incident reporting. The output is a set of acknowledgment records with date, version and identity. Confirm with legal how acknowledgments interact with employment terms and any consequences for non-compliance that HR will enforce.
Link HR events to identity lifecycle tooling
Connect the authoritative HR source to the identity provider so that joiners, movers and leavers drive account creation, group changes and removal automatically. In a self-hosted stack this often means an identity provider with a SCIM provider that pushes user and group changes to target applications, paired with a central directory for users and groups. Test each event type in a non-production environment and confirm that deprovisioning reaches every connected application. The output is a documented integration map and test results showing each event produced the expected change.
Write and test the offboarding runbook
Document the steps for separation, including account disablement, revocation of tokens and keys, return of devices, transfer of data ownership and the timing of the exit interview reminder of obligations. Run the runbook against a test account and a tabletop scenario for a sudden departure. The output is a tested offboarding runbook with a completion record template. The step is complete when the test shows that access was removed from every system in the integration map and that gaps found during the test are assigned and closed.
Retain evidence and review the process on a schedule
Decide where each record lives, how long it is kept under your retention rules and who can view it, then set a recurring review of samples across hires, movers and leavers. Use the review to update the lifecycle matrix, the sensitive-role list and the checklists when HR processes or systems change. The output is an evidence index that maps each GV.RR-04 claim to a record and a review log. Ask your auditor or assessor which sample sizes and records they expect before the first review cycle begins.

How identity lifecycle tooling carries HR events into access

An HR decision only protects systems when it reaches identity and application access. A hire, transfer or departure recorded in the HR system does nothing to GV.RR-04 until an account is created, changed or removed in every place the person can sign in. The pattern that makes this work is an authoritative identity source that feeds a directory, with provisioning pushed from that directory to each application. The HR system or a designated identity store is the record of truth, and every downstream account is derived from it rather than edited by hand.

authentik's SCIM provider illustrates the provisioning half of that pattern. According to its documentation, the SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. Those behaviors matter for offboarding: a removed role should lead to a removed account without a ticket. Confirm for each target application whether it supports SCIM 2.0 at all, whether group membership maps to the application's own roles, and how it handles accounts that were created locally before the integration existed. Applications without SCIM need a documented manual or scripted fallback with a named owner.

FreeIPA stores users, groups, hosts and other network objects in its 389 Directory Server, an LDAPv3 directory, and provides centralized access control with delegated administration through its web UI and command line tools. Its role is usually the directory of record for Linux hosts and LDAP-aware services, not the component that updates every SaaS or self-hosted application. Decide which system is authoritative for each population, document the direction of every sync, and test one leaver end to end, checking that the account is disabled in the directory, the provisioning target and any local accounts. Ask your vendors and integrators to show that trail in writing.

Evidence that passes GV.RR-04 and how to keep it current

GV.RR-04 is shown with records, not intentions. The cards below cover the artifacts an assessor typically asks to see, and the recurring checks that keep each one accurate between audits. Each card names one artifact and the question an assessor will put to it.

Signed HR security procedures

A written procedure for screening, onboarding, role changes and offboarding shows that cybersecurity is built into HR practice rather than handled ad hoc. Assessors look for a named owner, an approval date, and a version history that shows when the procedure last changed. Check that the procedure names the security steps explicitly, such as account provisioning, access reviews on transfer and removal of credentials at exit. Store it in a controlled document system and review it on a fixed schedule set by the procedure owner.

Background check records for sensitive roles

For roles with privileged or sensitive access, the file should show that screening happened before access was granted and that rechecks follow a defined schedule. Keep the role list, the check type applied to each role, the completion date and the approver, and limit the record to what the screening process needs. Confirm with counsel and your HR function which local laws govern screening and retention, because these rules vary by jurisdiction and affect what you may store.

Onboarding and offboarding checklists

Completed checklists are often the strongest evidence for this subcategory because they show the sequence actually happened. Pull a sample of recent joiners and leavers and confirm that each checklist is signed, dated and matched to the account records. A missing completion date on an offboarding task is the gap assessors most often find, so make the closing step a required field with a named reviewer.

Policy acknowledgments

Personnel obligations to follow security policy are demonstrated by signed or electronically recorded acknowledgments, collected at hire and again when the policy changes. Keep the policy version each person accepted, so you can show that a current version was acknowledged after an update. Run a recurring report that lists staff without a current acknowledgment and send it to managers for follow-up.

Role change notifications

When someone moves teams or takes on new responsibilities, the change should reach security and access owners so permissions can be reviewed. The evidence is the notification itself, the access review that followed, and the resulting entitlement change. Sample transfers each quarter and confirm each one produced a ticket or review record. Ask HR and IT to agree which system is the trigger, because a transfer that never reaches the access team leaves old permissions in place.

Deprovisioning logs

Deprovisioning logs show when access was removed from each system after a person left or lost a role. Compare the leaver list from HR with the account change records in each target application, and investigate any account still active after its end date. Retain the logs for the period your audit scope requires, and confirm that the identity provider and downstream applications write their change history to a location the reviewer can query.

What meeting GV.RR-04 costs in money and effort

This table breaks down the cost components of building cybersecurity into HR practices, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to shape a written scope and to ask suppliers and auditors for line-item quotes rather than a single lump sum.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
HR and legal time for screening and policy design	Internal HR, legal and security staff; outside employment counsel if engaged	One-time design, then recurring review	Number of jurisdictions, sensitivity of roles, and whether existing screening policy already covers security duties
Background check process for sensitive roles	Screening vendor or internal HR; candidates' consent workflow	Recurring per hire and per periodic recheck	Role count, recheck frequency set by policy, and local rules on what checks are lawful
Engineering time for lifecycle integration	Internal platform engineers or an implementation partner under a written scope	One-time build, then recurring maintenance	Number of target applications, whether an HR source of truth exists, and how many joiner, mover and leaver events are automated
Identity tooling setup	Implementation partner or internal engineers; open-source licenses carry no license fee	One-time setup, then recurring operations	Directory design, integration count and the effort to test provisioning and deprovisioning end to end
Evidence upkeep	Compliance lead, HR operations and system owners	Recurring	Frequency of joiner, mover and leaver sampling, how well records are kept in version control, and staff turnover
External review of HR and legal wording	Employment counsel or privacy specialist	One-time, then on policy change	Number of policy documents, national labor and data protection rules, and whether unions or works councils must be consulted
Auditor sampling and testing	Independent auditor or certification body, not DeployOpen	Recurring per assessment cycle	Sample sizes the auditor selects, population size of hires and leavers, and quality of ready-to-produce records
Ongoing support or retainer	Implementation partner, if engaged under a retainer	Recurring	Scope of changes to HR systems, upgrade cadence of the identity stack, and volume of access reviews

Who owns GV.RR-04 and what an implementation partner can take on

The organization owns GV.RR-04 in full. HR, legal, security and IT each hold decisions that no outside party can make on their behalf, because the screening standard, the employment terms and the access decisions are the organization's own commitments to its workforce and regulators. HR and legal decide what screening applies to which roles, what personnel must agree to in writing and how disciplinary action follows a breach of security policy. Security and IT owners decide which systems a role grants and how quickly access must end.

HR policy owner: Defines screening, background checks for sensitive roles, and the rules for rechecks where local law allows them.
Legal counsel: Confirms what can lawfully be checked, how consent is recorded and what the employment agreement says about security obligations.
Security owner: Sets the policy personnel must follow and the role-to-access rules that onboarding and offboarding enforce.
IT owner: Approves the identity lifecycle design and signs off on how joiner, mover and leaver events reach systems.

Ask each owner to show the signed decision, the date it was approved and the review cycle. Confirm that the same person is not both the requester and the approver of access changes.

Where GV.RR-04 programs usually fall short

GV.RR-04 is only as strong as the handoffs between HR, managers and identity systems. The gaps below tend to appear at the moments people join, move, or leave, and each one leaves an account or obligation that no one is watching. Work through them as a set, because a clean offboarding process does little if contractors sit outside it.

Contractors missing from offboarding

Contractors, temporary staff and vendor personnel often never appear in the HR system, so leaver checklists do not reach them. Their accounts can outlive the engagement by months. Check whether every non-employee identity has a named sponsor and an end date. Closure action: require a sponsor and expiry date on every contractor account, and tie removal to the contract end date.

Role changes that keep old access

When someone transfers, employees usually gain access for the new role and keep the old access. Over time this accumulates into excess privilege that no single review catches. Treat every internal move as a deprovisioning event as well as a provisioning event. Closure action: have the HR transfer trigger remove prior-role group memberships unless a manager re-approves them.

Background checks detached from access

Screening is often completed for every hire but never linked to which roles can reach sensitive systems. The check then has no effect on who receives privileged access. Confirm that the sensitive-role list drives both the screening requirement and the access approval. Closure action: block assignment of privileged groups until the background check for that role is recorded as complete, and schedule the periodic recheck the role requires.

Policy acknowledgments not refreshed

Staff sign the security policy at hire and rarely again, even after the policy changes or after a role takes on new duties. Personnel obligations then rest on a document few people remember agreeing to. Check when each person last acknowledged the current policy version. Closure action: re-issue acknowledgments on each material policy change and on role change, and keep the signed record in the HR file.

HR records unreconciled with directory

The HR system of record and the directory often drift apart, so an employee marked as departed can still hold an active account, or an active account has no HR record at all. Neither situation is visible without a comparison. Run a periodic comparison between HR status and directory accounts, and investigate every mismatch. Closure action: schedule the reconciliation, assign an owner for exceptions, and keep dated results as evidence.

Which open-source tools support GV.RR-04 evidence

authentik is an identity provider released under the MIT license. Its SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, so access follows the person's status in your identity source rather than a manual ticket. Per the vendor documentation, it runs a full sync every hour and deprovisions users from the target when they lose access to the application. That behavior is the kind of evidence an assessor looks for when checking that leavers and role changes are reflected in access.

Provisioning events: Creation, change and deletion events for users and groups can be reviewed against HR change records.
Scheduled full sync: The hourly full sync gives a recurring point where drift between the identity source and target applications would be corrected.
Deprovisioning on loss of access: Users removed from an application are deprovisioned there, which supports offboarding evidence.
Target coverage: Only applications that support SCIM 2.0 or have a configured connector are covered, so gaps must be listed.
Sync logs: Confirm the log retention period and export format with your own deployment before relying on them.

Confirm with your platform team that the SCIM targets, sync schedule and log retention match your HR joiner, mover and leaver workflow before you treat the output as evidence.

Questions buyers ask about GV.RR-04

Does NIST certify GV.RR-04 or any NIST CSF 2.0 implementation?

No. NIST does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program. GV.RR-04 is a Subcategory of the framework, so there is no certificate for it on its own. Organizations that need evidence usually show their alignment through a self-assessment or an independent assessment by a qualified assessor. Ask any firm offering a NIST CSF "certification" to explain what body issues it and what the document actually covers. NIST's CSF FAQs are the right starting point for that conversation.

How long does it take to build cybersecurity into HR practices?

The duration depends on how many HR processes already exist, how many systems they touch and how many roles need background checks. The work covers screening, onboarding, role changes, offboarding, sensitive-role checks and written personnel obligations, so it spans several HR workflows rather than one document. Ask any partner to break the timeline into those workflows and to state which ones depend on HR systems that the organization must change. No published duration applies to GV.RR-04 in general, so treat any single number you hear as an estimate to be tested against your own environment.

Can our HR team implement GV.RR-04 without outside help?

Often yes for the policy and process side, since HR already runs screening, onboarding and offboarding. The harder parts are technical: removing access when someone leaves, pushing role changes to downstream applications and keeping records that show it happened. Those depend on identity systems, which security or platform engineering usually owns. Outside help is most useful for integrating HR records with identity tooling and for producing evidence that an assessor can test. The organization still owns its controls, and an implementation partner prepares the systems and evidence.

What does GV.RR-04 require from HR and legal?

HR owns the hiring, onboarding, transfer and exit steps, so it must add cybersecurity checks to each one. Legal must review background check scope, notice and consent requirements under applicable employment and privacy law, and the wording of personnel obligations to follow security policy. Security sets which roles are sensitive and how often rechecks happen. Ask each group to sign off on its part in writing. Without that, the obligations and checks can drift apart over time.

Will an auditor test GV.RR-04?

An auditor may test it when the framework is part of the engagement, but the test depends on the assessment scope and on whatever standard or contract the organization is measured against. Assessors typically ask for the written procedures, a sample of onboarding and offboarding records, evidence of background checks for sensitive roles and signed personnel obligations. Ask your assessor early which samples they will draw and which records they expect to see. Only an independent assessor or certification body issues findings or reports.

How does GV.RR-04 relate to ISO 27001 Annex A 6 controls?

The NIST CSF 2.0 Reference Tool lists informative references that map GV.RR-04 to clause 7.3 and Annex A controls 6.1 through 6.8 of ISO/IEC 27001:2022. Those Annex A controls sit in the people theme, covering screening, terms of employment, awareness and responsibilities at termination or change. Treat the mapping as a starting point for shared evidence, not as proof that one framework satisfies the other. Confirm the mapping against the current reference tool and against your own certification scope before relying on it.

Which SP 800-53 controls also inform GV.RR-04?

The NIST CSF 2.0 Reference Tool lists PM-13, PS-1, PS-7 and PS-9 from SP 800-53 Rev. 5.2.0 as informative references for GV.RR-04. These cover the workforce security program, personnel screening, external personnel security and personnel transfer or termination. If your organization already uses SP 800-53 for federal or contractual work, these controls can share evidence with HR records. Check the reference tool for the current revision before you cite these identifiers in an assessment.

How DeployOpen prepares GV.RR-04 evidence

DeployOpen plans, implements and documents self-hosted open-source identity and wiki systems inside your own cloud accounts, data centers or air-gapped networks, and prepares the evidence that HR-linked cybersecurity practices are operating. DeployOpen does not issue audit reports, attestations or certifications. Your organization owns its HR policies, screening decisions and personnel obligations, and an independent auditor or certification body is the only party that reports on whether GV.RR-04 is met. In practice, the work covers the joiner, mover and leaver flows that GV.RR-04 points to, such as the directory and provisioning configuration, the wiki pages that hold the policy and role documents, and the logs and records that show each step ran.

Most engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and a quote follows from that written scope rather than from a published price list. For GV.RR-04, the scope discussion should settle which HR systems feed the identity platform, which roles count as sensitive and need background checks before onboarding, which policy documents must be acknowledged by staff, and who in HR and security approves each change. Ask for the deliverables list to name each artifact, such as a provisioning configuration export, a version-controlled onboarding and offboarding procedure, and a sample of access-removal records, so you know exactly what you will hold at the end. Ongoing support, upgrades and continuous testing are available as retainers, and they are quoted separately from the initial build.

Before engaging anyone, confirm with your HR and legal teams which screening and background check steps they run and which the law in your jurisdiction permits, and confirm with your auditor which evidence format they will accept. Those answers determine how much of GV.RR-04 a self-hosted platform can evidence directly and how much stays in HR records. Treat the implementation partner as the party that prepares systems and evidence, and keep ownership of the decisions with your own people, so the assessor sees a control owned and operated by your organization.

GV.RR-04 Cybersecurity in HR practices