CIP-004-7 R3 Personnel risk assessment: requirements and evidence

What CIP-004-7 R3 personnel risk assessment requires before access is granted

A personnel risk assessment must be documented and complete before anyone receives authorized electronic or unescorted physical access to a BES Cyber System, except during CIP Exceptional Circumstances. CIP-004-7 Requirement R3 asks the entity to run a documented program that screens individuals before access is granted. Part 3.1 requires a process to confirm identity. Part 3.2 requires a seven-year criminal history records check covering the person's current residence and every other location where they lived for six consecutive months or more during the seven years before the check. Part 3.3 requires criteria or a process for evaluating what the check finds, so that decisions are consistent and can be explained to an auditor. Part 3.4 requires criteria or a process to verify that contractor or service vendor personnel risk assessments meet Parts 3.1 to 3.3. Part 3.5 requires that individuals with authorized access have a personnel risk assessment completed within the last seven years, which means the program must also repeat the assessment on that cycle. The risk being managed is simple: a person with a disqualifying history or a false identity should not be able to reach systems that can affect grid reliability.

The work is harder than the wording suggests. Residence history is the usual weak point, because the six-month rule means the program must reconstruct where a person lived across seven years, and gaps in that history have to be resolved or documented rather than ignored. Contractor paperwork adds a second problem: staff employed by a vendor may be screened under the vendor's own program, and the entity must still verify that the vendor's results meet Parts 3.1 to 3.3 before granting access. Evaluation criteria are the third problem, since a criminal record does not decide itself. Confirm with your Compliance Enforcement Authority and your legal counsel how your criteria were written, who applies them, and how each decision is recorded. NERC lists CIP-004-7 as mandatory and enforceable, and there is no CIP certificate. Compliance is judged by the Compliance Enforcement Authority, a Regional Entity or NERC, through audits, spot checks and self-reports, so the record of each assessment is the evidence that matters.

Which people, contractors and access types fall under the personnel risk assessment

CIP-004-7 R3 applies to anyone who gets authorized access before the access is granted, so scope is set by the access, not by job title. The cards below cover the three access types, the Exceptional Circumstances exception, contractor handling, and how the applicable system categories change the population.

Authorized electronic access

R3 reaches any individual who will receive authorized electronic access to applicable BES Cyber Systems and their associated systems. That covers administrator, operator and engineering accounts, and it also covers service accounts only if a person holds the credentials and can use them. Before you finalize the list, check each account against the access management records, not the org chart, because role-based accounts often have broader reach than the job title suggests.

Unescorted physical access

The same assessment applies to individuals who will have unescorted physical access into a Physical Security Perimeter that protects applicable Cyber Assets. Visitors who are always escorted fall outside this population, but staff with badges that open a PSP door without an escort are inside it. Confirm with the physical security team which badge groups grant unescorted entry, since badge provisioning often sits outside the IT access process.

Access to BES Cyber System Information

Access to BCSI is a separate trigger from access to the systems themselves. Individuals who can retrieve BCSI stored in a document repository, ticketing tool or cloud location need a personnel risk assessment even if they never log in to a Cyber Asset. Map every repository where BCSI lives, including off-premise and third-party storage, and confirm who holds access to each one.

CIP Exceptional Circumstances

R3 contains an exception for CIP Exceptional Circumstances, which lets an entity grant access before the assessment is finished in the situations the standard defines. The exception is narrow and does not waive the assessment; it defers the timing for that access. Document each use with the date, the reason and the approver, and confirm the definition in the standard text before you rely on it.

Employees and contractors alike

The assessment obligation does not depend on employment status. Contractors, integrators and service vendor staff who receive authorized access must have their assessment completed by you or verified by the vendor under Part 3.4 criteria. Ask each vendor in writing which checks it runs, how it confirms identity, and how it evaluates results, because you remain responsible for the outcome.

How applicable systems change the population

The population grows with the impact rating of the systems involved. High impact BES Cyber Systems, medium impact systems with External Routable Connectivity, and their associated EACMS, PACS and PCA all bring people into scope, and access to a PACS or EACMS can be as sensitive as access to the BCSI itself. Build the list from the applicable-systems tables in each CIP standard so that a system added to a control later does not leave its users outside the assessment.

How an assessor tests the personnel risk assessment program

This table sets out how an auditor typically tests each part of CIP-004-7 R3, from the documented program down to individual access records and contractor checks. Read each row as a test step paired with the evidence it produces. The main takeaway is that assessors sample people who hold access today, so every check date must trace back to a provisioned account.

Requirement part	What the assessor does	Evidence requested	Where it usually fails
R3 documented program	Reads the written personnel risk assessment program and confirms it applies before authorized electronic or unescorted physical access is granted	Current program document, approval record, and the list of roles it covers	Program exists but does not state when it runs relative to granting access
Part 3.1 identity confirmation	Selects sampled individuals and checks that the identity confirmation process was applied to each	Identity verification record per sampled person, with the method and the date completed	Identity confirmation is described in policy but no per-person record exists
Part 3.2 seven-year criminal history check	Checks that each sampled person has a check covering the seven years before the check, including every location of six or more consecutive months	Check report dates, scope statement, and the residence history used to define locations	Residence history is missing or incomplete for people who moved within the window
Part 3.3 evaluation criteria	Reviews the written criteria used to evaluate criminal history results and compares sample decisions against them	Documented criteria, reviewer sign-off, and a set of grant or denial decisions with rationale	Criteria are undocumented, or decisions were made without a recorded reason
Part 3.4 contractor and vendor verification	Samples contractor and service vendor personnel and confirms the vendor's assessment meets Parts 3.1 to 3.3	Vendor attestation or contract clause, verification notes, and the vendor's check dates	Vendor assessments are accepted without confirming they cover identity and the seven-year check
Part 3.5 seven-year currency	Compares each sampled person's check completion date with the access they hold today	Access list with grant dates, check completion dates, and a repeat schedule	Checks have lapsed for accounts that still provide authorized access
Access cross-check	Matches the population with access against the personnel risk assessment records to find gaps	Access provisioning export reconciled to the personnel risk assessment register	The access system and the HR or screening register are maintained separately and drift apart
Exception handling	Confirms any use of CIP Exceptional Circumstances was documented and limited in time	Exception record, approver, and the access it covered	Exceptions are used in practice without a record, or they remain open after the event

How to implement the personnel risk assessment program step by step

This sequence turns CIP-004-7 R3 into a working program: it fixes who needs a personnel risk assessment, defines how identity and criminal history are checked and judged, covers contractors, and produces a tracking record that shows every person with access has a current assessment.

Define scope from the access lists
Start by listing every individual who will hold authorized electronic access or unescorted physical access to applicable BES Cyber Systems, including their associated EACMS, PACS and PCA where the scope tables apply. Pull these names from the access lists your CIP-004 access management records already maintain, and include contractors, vendor staff and service accounts tied to a named person. The output is a scoped roster with each person's access type and the system categories they reach. You know this step is done when the roster reconciles against the current access lists with no unexplained names or gaps.
Write the documented program and evaluation criteria
The program must be written down before any checks run. Name the owner, describe when a personnel risk assessment is required (before authorized access is granted, except during CIP Exceptional Circumstances), and set the criteria your team will use to evaluate criminal history records. Have legal, HR and the CIP Senior Manager review the criteria so decisions on adverse results are consistent and defensible. The output is an approved program document with written evaluation criteria and a named decision maker. You know this step is done when a reviewer can follow the document from request to grant or denial without asking the author.
Set the identity confirmation process
Before any background check runs, confirm that the person is who they claim to be. Define which identity documents are accepted, who checks them, and how the check is recorded. Apply the same process to employees and to contractor staff so that identity is not assumed based on a company badge. The output is an identity confirmation procedure and a dated record for each individual showing the check was performed and by whom. You know this step is done when every name on the roster has a completed identity record that links to the person it describes.
Define residence history collection and the seven-year check method
The seven-year criminal history records check must cover current residence and every other location where the person lived for six consecutive months or more during the seven years before the check. Build a residence history form that asks for these locations and dates, then define how the check is requested for each jurisdiction and who orders it. Decide with counsel how gaps in residence history are handled and documented. The output is a standard residence form, a check request procedure, and a file showing which jurisdictions were searched for each person. You know this step is done when every person's file shows residence coverage that matches the form they signed.
Define contractor verification
When a contractor or service vendor performs the personnel risk assessment instead of your organization, you still need criteria or a process to verify that the vendor's assessment meets the identity confirmation, seven-year check and evaluation requirements. Write a verification step into your procurement and onboarding process. Ask vendors to supply the evidence that shows which checks were run, the coverage period and the results against your criteria, and confirm this before access is granted. The output is a vendor verification checklist and a signed attestation or evidence package from each vendor. You know this step is done when no contractor reaches authorized access without an accepted verification record. Confirm the exact evidence your auditor expects with the Regional Entity or your compliance advisor, since the standard sets the outcome rather than a specific form.
Build the tracking record with repeat dates
Create a single register with one line per person showing the date of identity confirmation, the date the criminal history records check was completed, the evaluation outcome, the access granted, and the date the personnel risk assessment must be repeated. The standard requires a personnel risk assessment to have been completed within the last seven years for each person with authorized access, so the register must make the repeat date visible and assign an owner to it. The output is a maintained register linked to the access management system. You know this step is done when the register can answer, for any individual, whether their assessment is current and when it expires.
Run a first population review
Once the program, verification process and register are in place, test them against the full roster. Pick every current access holder, confirm each has a completed and in-date assessment or a documented vendor verification, and resolve any gaps before the population is treated as compliant. Record the review date, the reviewer, the exceptions found and the corrective action for each. The output is a signed first review report that becomes baseline evidence for the audit file. You know this step is done when the review shows zero unexplained individuals with authorized access and every exception has a closed corrective action.

Evidence that satisfies CIP-004-7 R3 and how to keep it current

An auditor testing CIP-004-7 R3 looks for a documented program and a record for every person with authorized access, not a single clean check. The cards below cover the artifacts that prove the program ran, and the routine that keeps them accurate between Compliance Audits.

Written personnel risk assessment program

The program document states which personnel are covered, the identity confirmation method, the seven-year criminal history check, the evaluation criteria, and how contractor assessments are verified. It should name the owner and the approval date. Check that the document matches what staff actually do, because a program that exists only on paper is a common finding.

Identity confirmation records

Keep a dated record showing how each person's identity was confirmed before the assessment began, along with the identifier the check was run against. Store the verifier's name and the document type or method used. Confirm that the records can be tied to the specific criminal history check for the same individual.

Criminal history check results and residence coverage

For each check, record the date performed, the provider, the result category, and the locations covered. The residence history must show current residence and every other location where the person lived for six consecutive months or more during the prior seven years. Gaps in residence coverage are a frequent audit question, so record the reason where a location could not be checked.

Evaluation criteria and decision records

Documented criteria explain how the organization treats criminal history findings. Each decision should record who reviewed the result, the criteria applied, the outcome, and the date. Auditors test whether the same criteria were applied consistently across personnel, so a short rationale for each granted or denied access is worth keeping.

Contractor and vendor verification

When a contractor or service vendor performs the assessment, obtain written attestation that it meets the identity, check and evaluation requirements. Retain the verification record that the organization reviewed. Ask vendors to confirm the look-back period and residence coverage in writing, since those are the parts most often missing from vendor attestations.

Assessment tracking list

Maintain one list showing every person with authorized electronic or unescorted physical access, the date of the last completed assessment, and the date the next one falls due under the seven-year cycle. Reconcile it against the access management list each quarter so that no one holds access without a current assessment. Set a reminder well before the due date so renewals do not lapse.

What meeting CIP-004-7 R3 costs in money and effort

This table breaks down the money and staff time behind a CIP-004-7 R3 program, marking each component as one-time or recurring and naming who is paid for it. Use it to build a quote request and to see which costs grow with headcount, contractor turnover and the number of jurisdictions where people have lived. No dollar figures are given because none are supplied for this requirement; ask vendors and counsel for written estimates against your own roster.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Background check vendor fees per person	Screening vendor, billed per check	One-time for new hires, recurring at seven-year repeats	Number of covered individuals, number of jurisdictions searched, scope of each check
Identity confirmation	HR staff or screening vendor	One-time per person, repeated at each PRA cycle	Share of identity checks done in house versus by vendor, volume of new hires
Internal HR and security staff time	Employees who coordinate, review and file results	Recurring	Headcount in scope, contractor turnover, how many records are reviewed by hand
Legal review of evaluation criteria	Outside or in-house counsel	One-time to set criteria, then periodic review	Number of jurisdictions, changes in local law, how often criteria are revisited
Contractor verification effort	Staff who collect and check vendor PRA attestations, plus vendor contract changes	Recurring, tied to each contractor onboarding and renewal	Number of contracting firms, how many firms run their own checks, contract terms that require proof
Tracking tool work	Internal IT or an implementation partner configuring records and access links	One-time build, then recurring upkeep	Whether PRA status is linked to access provisioning, number of systems in scope
Auditor sampling time	Staff who pull records for the Regional Entity or auditor	Recurring at each audit or Spot Check	How well records are indexed, retention period, sample size set by the auditor

Tracking seven-year repeat dates across employees and contractors

The seven-year repeat under CIP-004-7 Part 3.5 is an operational problem, not a one-time check. Each person with authorized electronic or unescorted physical access needs a completed personnel risk assessment dated within the last seven years, so the program has to hold a date per individual and act before that date passes. A spreadsheet can work for a small population, but it depends on someone remembering to read it. The practical design is a record for every person that stores the completion date of each PRA component, the date the program will treat as expiry, and an owner who receives a reminder well ahead of that date. Confirm with your Regional Entity and internal audit how they expect you to evidence that dates were tracked, since the standard sets the outcome and leaves the method to you.

Identity and access management tooling can make that date operational by tying PRA status to the groups that grant access. The idea is to keep a group, for example one per CIP-protected system, that only contains people whose PRA is current and whose training and authorization are also valid. When a PRA record ages out, the account should leave the group, and the removal should flow to the target applications rather than depending on a manual ticket. Open-source options such as authentik's SCIM provider can push user and group changes to target applications over SCIM 2.0 and run a full sync every hour, which narrows the gap between a status change and the access change. Whether a given directory or application can express PRA status as an attribute, and how it behaves on a failed sync, are questions to test in your own environment before relying on them.

Transfers and departures are where repeat-date tracking usually breaks. A person who moves into a role that needs access must have a valid PRA before access is granted, and a person who leaves must lose access under the revocation timelines in CIP-004-7 Requirement R5. Contractors add a second path, because their PRA is performed by the vendor, and your program must verify that it meets Parts 3.1 to 3.3 and track its renewal date as well. Ask each vendor for the date of its last completed check and a contract term that requires notice before expiry. Document how you handle an expired record, including who is notified, how access is suspended, and how the exception is recorded if work cannot wait, since an unmanaged lapse is the kind of gap auditors tend to test first.

Who owns the personnel risk assessment and who can help

The registered entity owns the personnel risk assessment program. Under CIP-004-7 R3, the obligation to document the program, apply it before authorized access is granted, and keep each individual's assessment current sits with the entity, and so do the consequences if it fails. The entity must also decide how it evaluates criminal history records, which is where most of the judgment in this requirement lies.

Program ownership: A named owner approves the written program, its scope and its exceptions, and keeps it current.
Evaluation criteria: Leadership sets and signs the criteria used to evaluate criminal history records checks under Part 3.3, and records who applied them.
Contractor oversight: The entity sets the criteria or process it will use to verify that contractor and vendor assessments meet Parts 3.1 to 3.3 under Part 3.4.
Access decisions: Individuals are granted or denied access by the entity, based on the results of the assessment.
Evidence custody: The entity retains the records and produces them on request.

Before engaging anyone, confirm internally who signs the evaluation criteria and who answers to the Compliance Enforcement Authority for them.

Gaps that cause personnel risk assessment findings and how to close them

Most CIP-004-7 R3 findings are not missing background checks. They are gaps in the records, criteria and tracking that prove the checks were done correctly. The cards below cover the five gaps auditors most often find and the closing action for each.

Contractor PRAs accepted without verification

Vendors often send a completed PRA for their staff and the entity files it without checking it. Part 3.4 requires criteria or a process to verify that a contractor or service vendor's assessment meets Parts 3.1 to 3.3. Write down what you accept: identity confirmation method, a seven-year check, the evaluation criteria applied, and who signs off. Ask vendors to provide that evidence in the same form you would collect it yourself.

Residence history missing for the six-month rule

Part 3.2 extends the criminal history check to every location where the person lived for six consecutive months or more during the seven years before the check. Many records cover only the current address. Ask each individual to list all prior residences in the window, and record the locations checked for each one. A blank or incomplete residence history is a common and easily cited gap.

No documented evaluation criteria

Part 3.3 requires criteria or a process for evaluating what a criminal history records check finds. Organizations that run checks but cannot show how a result was judged leave auditors unable to test consistency. Write a short, approved standard that states which record types lead to denial, which lead to escalation, and who decides. Keep the decision record with each individual's file.

Seven-year dates not tracked

Part 3.5 requires that every individual with authorized access has a PRA completed within the last seven years. Checks done at hire are easy to forget once the initial access review closes. Store the completion date for each person in your identity or access records, and set a reminder well before the seven-year point. Confirm which system is the source of truth for that date before the audit, not during it.

Access not revoked when a PRA lapses

A PRA that passes its seven-year date is no longer valid for the access it supported, yet the account often stays active. Link the PRA expiry to your access workflow so that an expired record triggers removal of authorized electronic and unescorted physical access. Test this path with a sample account. Where your identity platform provisions to applications, confirm that a deprovisioning event reaches each target system, not only the directory.

Questions buyers and engineers ask about CIP-004-7 R3

What does a CIP-004-7 R3 personnel risk assessment program cost, and what drives it up?

The cost is driven mostly by headcount, the number of contractors and vendor staff who need access, and how many criminal history checks must be repeated over the seven-year cycle. Costs fall into two groups: the one-time work of documenting the program, defining evaluation criteria and setting up the identity and background check workflow, and the recurring work of running checks for new hires, contractors and renewals. Background check vendor fees are paid per check and vary by provider and jurisdiction, so ask for the per-check rate and the residence-history coverage in writing. Implementation fees depend on the written scope agreed before work starts. DeployOpen does not publish a price list, and a quote follows from that scope. Ask any provider to itemize one-time and recurring charges separately.

How long does a first CIP-004-7 R3 implementation take?

No fixed duration applies to every entity, so treat any single number you hear with caution. Timing depends on how many personnel records exist, whether an identity confirmation process already runs for employees, how many contractor firms supply staff, and whether the criteria for evaluating criminal history records need legal or HR review. The fastest path is usually an existing HR background check process that can be extended to cover the Part 3.2 residence rule and the contractor verification in Part 3.4. Ask the implementation partner to state the phases, dependencies and deliverables in the written scope, and confirm with your compliance lead which records the Regional Entity will expect to see during an audit.

Can an entity run its CIP-004-7 R3 program in-house?

Yes, a registered entity can run the program internally, because the obligation falls on the entity and not on any outside firm. In-house teams typically need HR, legal, security and compliance staff to agree on identity confirmation steps, the seven-year check scope, and the criteria used to evaluate results. Many entities use an outside background screening provider for the checks themselves and keep the decisions and records in-house. Outside help is most useful for building the documented program, mapping data flows and building evidence packages. DeployOpen prepares systems and evidence for assessments but does not issue audit findings. Confirm the approach with your Regional Entity's compliance staff before finalizing it.

What does the implementation partner need from our organization?

A partner needs named owners and access to the records that show who holds authorized electronic or unescorted physical access to BES Cyber Systems. Expect requests for your current access lists, HR onboarding and offboarding procedures, existing background check vendor contracts, contractor and service vendor agreements, and any legal guidance on criminal history evaluation. The partner also needs decision-makers who can approve evaluation criteria and sign off on the process. Missing or late inputs are the most common reason a fixed scope slips, so agree on the input list and the approvers before work starts. Ask for that list in the written scope.

How does contractor verification under CIP-004-7 Part 3.4 work?

Part 3.4 requires a process to verify that a contractor or service vendor has completed personnel risk assessments that meet Parts 3.1 to 3.3, so your organization must check the vendor's results rather than assume them. In practice, the entity defines the contract language, requests evidence that identity was confirmed, that a seven-year criminal history check with the residence coverage was run, and that the vendor applied documented evaluation criteria. Many entities record this in the contract and in a vendor register with dates and the verification method. Confirm with your vendor management and legal teams which evidence format is acceptable, and check the expectations with your Regional Entity.

How is the seven-year repeat cycle kept on schedule?

The standard requires that each person with authorized access has had a personnel risk assessment completed within the last seven years, so the program needs a tracking method that shows the completion date for every individual. Common approaches include a access register with a completion date and a calculated due date, automated reminders from the HR or identity system, and a documented step that removes access when a check has lapsed and no renewal is on file. Review the tracker at a fixed interval and keep the completion records available for audit. Ask your compliance lead to confirm how the Regional Entity will test this cycle during a Compliance Audit.

How self-hosted identity tools support PRA tracking and access revocation

Identity tools cannot run a personnel risk assessment, but they can keep the access decision tied to the PRA record so that access exists only while the record supports it. In practice, the entity's HR or security team decides whether an individual has completed the identity confirmation, the seven-year criminal history records check and the evaluation under Parts 3.1 to 3.3. Only after that decision is recorded should the individual be placed in the group that grants electronic or unescorted physical access to in-scope systems. An identity provider such as authentik can host the user record and group membership, and its SCIM provider can push user and group creations, changes and deletions to target applications over SCIM 2.0. Its documented hourly full sync and deprovisioning behavior mean that removing a person from the authorized group in the source system propagates to connected applications without a manual step. FreeIPA offers a similar role as a central directory built on 389 Directory Server, storing users, groups and hosts with centralized access control and delegated administration. Confirm which systems in your environment accept SCIM or LDAP-based provisioning, and test the revocation path end to end.

Several things remain outside the tools and must be planned as separate work. Neither authentik nor FreeIPA performs background checks, stores criminal history results as a determination, or decides whether a result meets your evaluation criteria, so the evaluation record must live in a controlled system with restricted access. Before relying on either product for PRA-linked access, confirm the license terms for your intended use and edition, including any features you need for provisioning or delegated administration, and check the current release notes against your configuration. Also confirm that the design fits your own environment, because the CIP audit will test whether the PRA date, the access grant and the revocation record agree. Ask the implementation partner to document how a PRA expiry or failed evaluation removes the individual from the authorized group, which target systems are covered, and how the removal is evidenced. The partner prepares these systems and records, while the organization owns the program and the Regional Entity assesses it.

How DeployOpen scopes and prepares CIP-004-7 R3 evidence

DeployOpen works on the systems and evidence behind CIP-004-7 R3 inside your own infrastructure, and it does not decide whether your program is compliant. We prepare the identity, access and record-keeping workflows that support your personnel risk assessment program, and an independent auditor or Regional Entity reviews the result.

How we scope

Engagements are fixed-scope, with the systems, Applicable Systems and personnel groups covered agreed in writing before work starts.
The written scope lists which identity sources, provisioning targets and contractor onboarding paths are in or out for R3.
Scope names your internal owner for the PRA program, since the organization owns its controls and the record of them.

How we build

We configure identity confirmation and access workflows so authorization waits on a completed, recorded personnel risk assessment.
We document how criminal history check results are recorded, retained and evaluated against your own written criteria.
We test the workflows against sample personnel records and confirm the evidence fields are complete before handover.

How we hand over

You receive configuration documentation, workflow diagrams and a map from each R3 part to the artifact that shows it.
Evidence exports are structured so your compliance team can produce records for a Regional Entity request without rebuilding them.
Handover includes a walkthrough of open items, such as contractor verification steps that still depend on vendor-held records.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing separately from the initial engagement.
A retainer can cover re-checking the seven-year refresh schedule and confirming that access tied to expired assessments is removed.
Ask any provider to confirm which R3 evidence they prepare and which decisions remain with your organization and your auditor.