What CIP-004-7 R4 asks an access management program to prove
Under CIP-004-7 R4, the compliance lead must show that every person with electronic access or unescorted physical access to in-scope systems was authorized on the basis of need, and that those authorizations stayed correct over time. Part 4.1 requires a documented process that authorizes electronic access and unescorted physical access into a Physical Security Perimeter, with the need determined by the entity, except during CIP Exceptional Circumstances. Part 4.2 requires a check at least once each calendar quarter that everyone with active access has a matching authorization record. Part 4.3 requires a review at least once every 15 calendar months that user accounts, account groups or role categories, and their privileges, are correct and necessary for electronic access. R4 governs authorization and verification. How quickly access must be removed after a termination or transfer sits in R5, and authorization for access to BCSI is handled separately in R6, so the evidence for those should not be substituted for R4 records.
The hard part is drift. Access accumulates across directories, applications, jump hosts, vendor accounts and badge systems faster than authorization records are updated, especially when a role change adds permissions and nobody removes the old ones. Confirm, before you design the program, which systems hold electronic access to your in-scope BES Cyber Systems and which of them can be fed from one authoritative identity source. Identity platforms such as FreeIPA and Keycloak can centralize accounts and group membership, but each downstream system still needs its own provisioning path or an entry in the quarterly comparison. Access certification tools such as midPoint's access certification help designated reviewers keep, change or revoke items on a set schedule, which supports the 15-month privilege review.
The exposure is real money. The Compliance Enforcement Authority can assess civil penalties for each violation, and each day can count as a separate violation. The maximum referenced in NERC's Sanction Guidelines is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 and shown in the eCFR text of 18 CFR 385.1602. Actual penalties depend on the facts, risk and mitigation, and that figure is a ceiling, not an expected outcome. Ask your compliance team which quarterly verification and 15-month review records a Regional Entity would request for your systems, and confirm the retention period in your own program documents.
Which systems, people and accounts fall under CIP-004-7 R4 access management
CIP-004-7 R4 applies wherever electronic or unescorted physical access reaches BES Cyber Systems, so the first job is deciding which systems and access paths are in scope. The cards below cover the Applicable Systems that drive the work and the account types that most often leave gaps in authorization records and the 15-month privilege review.
High impact BES Cyber Systems
The standard's Applicable Systems include high impact BES Cyber Systems, which CIP-002-5.1a categorizes using its bright-line criteria. Control Centers of Reliability Coordinators and qualifying Balancing Authority, Transmission Operator and Generator Operator Control Centers are the most common high impact examples. Confirm the categorization list with your CIP-002 record before scoping R4, because every access path to these systems must be authorized and verified.
Medium impact with External Routable Connectivity
Medium impact BES Cyber Systems are in scope for the access rules when they have External Routable Connectivity, a term defined in the NERC glossary that you should check against your own network design. Systems without that connectivity can still be covered by other parts of CIP-004, so verify the exact Applicable Systems rows for each requirement part rather than assuming one scope applies throughout.
Associated EACMS, PACS and PCA
Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets associated with in-scope BES Cyber Systems are frequently overlooked. Badge readers, domain controllers, jump hosts and remote access gateways can all carry privileged access into the perimeter. Inventory each of these components and record who can administer it, because those administrative accounts are where access reviews most often miss exposure.
Electronic versus unescorted physical access
Part 4.1 authorizes electronic access and unescorted physical access into a Physical Security Perimeter as separate decisions, and each needs its own authorization record and quarterly comparison. Someone who holds an authorized badge but no electronic account, or the reverse, must still appear correctly in both lists. Confirm with your physical security team how badge provisioning is recorded, since a badge system that is not linked to the authorization list is a common source of findings.
Contractor and vendor accounts
Contractor and vendor personnel with electronic or unescorted physical access are in scope in the same way as employees, and their accounts must be authorized on the same basis. Vendor remote access accounts are a frequent gap because they are created for a project and then left active after the work ends. Ask each vendor for its named user list, confirm an end date on each account, and include these accounts in the quarterly verification.
Shared, role and service accounts
Shared accounts, role accounts and service accounts are the accounts most likely to fail the 15-month review of user accounts, user account groups or role categories and their privileges. Each one needs a documented owner, a justified business need and a privilege set that the review can confirm is still necessary. Identify these accounts in your directory and application inventories early, because they often sit outside the normal joiner and leaver workflow.
How an auditor tests CIP-004-7 R4 access management
This table compares each test area of CIP-004-7 R4 (Parts 4.1 to 4.3 and CIP Exceptional Circumstances) against the test approach, the evidence an assessor usually requests, and the findings that appear most often. Use it to check whether your records would answer each question without reconstruction. Missing need determinations and skipped quarterly checks are the gaps most likely to appear in a Regional Entity review.
| Test area | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| Part 4.1 authorization records | Sample provisioned electronic and unescorted physical access and trace each grant back to a documented, need-based authorization | Dated authorization records showing the business need, approver and scope of access granted | Access granted without a documented need determination, or authorizations that do not match the granted scope |
| Part 4.2 quarterly verification | Confirm each calendar quarter in the audit period has a completed comparison of provisioned access against authorization records | Dated quarterly comparison reports and records of any corrections made after each comparison | Quarters with no comparison, comparisons that did not cover all active access, or discrepancies left open |
| Part 4.3 15-month privilege review | Check that every user account, group or role and its privileges was verified within 15 calendar months and that privileges remain necessary | Review documentation listing accounts and privileges reviewed, reviewer identity, date and decisions taken | Accounts or role categories not reviewed within the 15-month window, or reviews that confirmed access without checking necessity |
| CIP Exceptional Circumstances handling | Review any access granted during a declared CIP Exceptional Circumstance and confirm the exception was applied only as the definition allows | Records of the declaration, the access granted under it, and the timing of any follow-up authorization | Exceptional Circumstances invoked without a record, or access kept after the circumstance ended without authorization |
Implementing the CIP-004-7 R4 access management program in order
This sequence turns CIP-004-7 R4 from a written policy into working controls, each with a dated artifact an auditor can sample. The order matters because the quarterly comparison and the 15-month review both depend on authorization records that were created first and scoped correctly.
Define the need-based authorization process
Write the procedure that states how the entity determines need for electronic access and unescorted physical access into a Physical Security Perimeter, and name the roles that may request, approve and grant each type of access. Include the CIP Exceptional Circumstances handling and note that access to BCSI is governed separately under R6. The output is an approved, versioned procedure with named approvers and a documented approval date.
Inventory accounts and access paths in scope
Identify every system in scope for the applicable impact categories, then list the accounts, user account groups, role categories and access paths that reach them. Cover electronic access through interactive, remote and service channels, and map unescorted physical access to each Physical Security Perimeter. The output is a scoped inventory that shows which accounts can reach which Applicable Systems, and it becomes the baseline for every later comparison.
Create dated authorization records with approvers
For each person and role in the inventory, record the access granted, the business need, the approver, and the authorization date. Where the identity platform holds group or role assignments, decide whether the authorization record lives in that system or in a separate register, and keep one authoritative source. The output is a complete set of authorization records that an auditor can trace from a provisioned account back to a named decision.
Run the first quarterly comparison
Compare provisioned electronic access and unescorted physical access against the authorization records for every individual with active access, and document each mismatch. Each mismatch is either corrected by removing unauthorized access or resolved by adding a dated authorization. The output is a dated comparison record showing the population checked, the mismatches found, and how each was closed. Repeat this comparison at least once each calendar quarter.
Schedule the 15-month privilege review
Set up a recurring review, at least once every 15 calendar months, that confirms all user accounts, user account groups or role categories and their privileges are correct and necessary for electronic access. Assign a reviewer who does not administer the accounts under review, and agree the evidence format in advance. Access certification tools can route each review item to a designated reviewer for a keep, change or revoke decision, which leaves a decision trail. The output is a calendar entry and a review package for each cycle.
Complete the 15-month privilege review
Run the review against the current inventory, and record each reviewer decision with a date and a reason. Revoke any privilege that is not needed, correct group or role membership that has drifted, and feed changes back into the authorization records. The output is a signed review record that shows the accounts and privileges examined, the decisions taken, and the changes applied. Keep these records available for the audit period.
Document and track exceptions
Record every exception, such as an access grant made under CIP Exceptional Circumstances, an authorization that was delayed, or a mismatch that could not be closed within the quarter. For each one, state the cause, the approver, the compensating step, and the closure date. Review open exceptions at each quarterly comparison so none remain unexplained. The output is an exception log that links back to the affected authorization and review records.
Evidence that passes the CIP-004-7 R4 quarterly and 15-month checks
R4 is tested through records, not through the access itself. An auditor will look for three artifact sets: dated authorization records, dated quarterly comparisons, and the 15-month privilege review, each traceable to the same access list. The cards below cover what each artifact must show and how to keep it current between audits.
Dated authorization records
Each grant of electronic access or unescorted physical access into a Physical Security Perimeter needs a record showing who authorized it, the business need, the person granted access, the system or area, and the date. The record should exist before access is provisioned, and the authorizer should be someone with the authority to approve that need. Check that every active account in your identity provider or access system links back to a record, and that exception handling under CIP Exceptional Circumstances is documented separately. Keep BCSI access records under R6, which the entity handles separately.
Quarterly provisioned-to-authorized comparison
The quarterly check compares what the systems actually grant against the authorization records. Export the active electronic and unescorted physical access lists from each system, run the comparison, and record the date, the operator, the number of mismatches and the disposition of each one. An auditor will ask for four consecutive quarters, so the process must produce a dated output every quarter. Store the raw exports with the comparison so the result can be reproduced.
Proof the comparison ran on schedule
A dated report is only as credible as the schedule behind it. Keep a recurring calendar entry or ticket for each quarter, link the completed comparison to it, and log any slipped run with the reason and the corrective date. Automated jobs should write a run log with a timestamp, the source systems queried and the result count, and that log should be retained with the report. Confirm with your Compliance Enforcement Authority how they expect a late or missed run to be self-reported.
15-month privilege review sign-off
The review under Part 4.3 must confirm that each user account, user account group or role category and its privileges is correct and necessary. Produce a review package listing every account group and role with its members and privileges, then record the reviewer's decision on each item and the date. A named reviewer must sign off, and a change request should follow each removal or privilege reduction. Schedule the next review before the current one closes, because the window is 15 calendar months.
Retention and naming conventions
Auditors sample evidence from the full audit period, so retention must cover that period plus the time needed for review. Use a fixed naming pattern that includes the requirement, the system, the period and the date, for example CIP-004-R4_quarterly_<system>_<YYYY-QN>.csv. Keep original exports unaltered and record hashes or storage locations in an index. Confirm your retention period against the Regional Entity's audit notice and your internal records policy, because the required period is set by that process rather than by this card.
Reviewer decisions in an access certification tool
Running reviews in a tool such as midPoint, which supports access certification campaigns with designated reviewers who decide whether to keep, change or revoke each access item within a set timeframe, produces decision records by default. Those records give you reviewer identity, decision and date in one place. Before relying on it, confirm that the tool's campaign history and reports can be exported in a form an auditor can read, and that they cover the account groups and role categories in scope for Part 4.3.
Open-source tools that produce CIP-004-7 R4 evidence
midPoint is an open-source identity governance platform, licensed under EUPL-1.2+, that can run access certification campaigns. A campaign assigns designated reviewers who must decide, within a set timeframe, whether to keep, change or revoke each access item, such as a role assignment. For R4 Part 4.3, which calls for verifying at least once every 15 calendar months that user accounts, groups or role categories and their privileges are correct and necessary, this creates a dated, reviewer-attributed record of the decisions taken.
- Dated review records: Campaign start dates, reviewer decisions and completion timestamps can serve as the core of the 15-month privilege review file.
- Reviewer accountability: Each decision is tied to a named reviewer, which helps show who verified necessity for each privilege.
- Revocation trail: Items marked for removal can be tracked through to completion, supporting proof that unnecessary privileges were acted on.
- Segregation of duties context: Campaigns can surface accumulated roles that conflict with one another, which is useful for CIP-004 authorization decisions.
- Scope limits: Campaigns reflect what midPoint knows. Access granted in systems outside its connectors will not appear in the review.
Before relying on this tab, confirm with your implementation partner and your auditor that a midPoint campaign record fits your 15-month review design and the Part 4.2 quarterly comparison method, and that it covers all in-scope electronic and unescorted physical access.
authentik is an open-source identity provider licensed under MIT. Its 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. This helps move access changes from an authoritative source into downstream systems, which is where many R4 gaps appear: a grant that was approved but never provisioned, or a removal that was never applied.
- Automated push: Creations, changes and deletions flow to target applications without manual tickets for each change.
- Hourly full sync: The recurring full sync can help reconcile drift between the directory and target applications.
- Deprovisioning on loss of access: When a user loses access to an application, the target account can be removed, which supports the need-based model in Part 4.1.
- Provisioning logs: Sync activity can be exported as evidence that the provisioned state matches the authorization records during the Part 4.2 quarterly verification.
- Connector coverage: Only applications with SCIM support, or with a custom integration you build and maintain, can be automated.
Confirm that each in-scope target application supports SCIM 2.0 or has a supported integration path, and agree with your auditor how the hourly sync output will be compared with authorization records each calendar quarter.
FreeIPA is an open-source identity management system licensed under GPL-3.0-or-later. It uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects, with centralized access control and delegated administration through its web UI and command line tools. For R4, a central directory gives the organization one place to define who holds which group membership and to show that group-based access follows an approved authorization.
- Single source of group membership: Groups held in one directory make it easier to compare provisioned access with authorization records.
- Delegated administration: Administrative rights can be scoped, so each team changes only the groups it owns, and those changes are visible to reviewers.
- Host and service objects: Directory records can cover hosts and services, supporting clearer accountability for system-level access.
- Audit trail requirements: Confirm which change logs FreeIPA retains in your configuration, since they must be preserved for your audit period.
- Integration effort: Applications must authenticate against LDAP or Kerberos. Plan for that integration and its testing as part of the scope.
Confirm with your platform team how group membership in FreeIPA maps to the authorization records you will compare in Part 4.2, and document who may change group membership and how that is approved.
Keycloak is an open-source identity and access management product licensed under Apache-2.0. It provides single sign-on so users authenticate with Keycloak rather than separately with each application, supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can broker logins to existing OpenID Connect or SAML 2.0 identity providers. Centralizing sign-on means access to applications is decided at one point, which can simplify the evidence for who can reach which system and when access was withdrawn.
- One login point: Application access decisions made through Keycloak can be reviewed in one place.
- Protocol support: OpenID Connect, OAuth 2.0 and SAML 2.0 cover common application integrations.
- Brokering to existing providers: Keycloak can federate with an existing identity provider, so you may not need to migrate every user at once.
- Session and access revocation: Disabling a user in Keycloak can stop new logins to federated applications, supporting the timely removal required by R5 and the access controls in R4.
- Limits: Single sign-on does not remove local accounts or shared credentials inside applications. Inventory those separately.
Confirm that every in-scope application is integrated with Keycloak or has a documented exception, and verify how session lifetimes and disabled accounts behave in your environment before you cite Keycloak in your R4 evidence.
What meeting CIP-004-7 R4 costs in money and effort
This table breaks the cost of meeting CIP-004-7 R4 into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No prices are stated because none were supplied; use the questions in the last column to build a written quote that compares like with like.
| Cost component | One-time or recurring, and who is paid | What drives it up or down | What to ask for in a written quote |
|---|---|---|---|
| Tooling and licenses | Recurring for commercial identity or access governance products; open-source platforms such as FreeIPA, Keycloak, authentik and midPoint carry no license fee but still need hosting and staff. | Number of in-scope systems, number of user identities, and whether certification campaigns are needed or handled by hand. | Itemized license terms per year, hosting and storage estimates, support tier, and any per-user or per-connector charges. |
| Engineering to build authorization workflows and integrations | One-time, paid to the implementation partner or internal engineers to connect the directory, single sign-on and provisioning to each in-scope application. | Number of access paths (electronic, unescorted physical, remote), number of target applications, and how much existing authorization data is clean. | Fixed-scope deliverables list, named integrations, test plan, and the hours or fixed fee for each integration. |
| Quarterly comparison and evidence upkeep | Recurring, paid to internal compliance or operations staff, with optional partner support for scripts that compare provisioned access to authorization records each calendar quarter. | Number of people with active electronic or unescorted physical access, number of systems, and whether comparisons are automated and dated. | Who produces each quarterly comparison, what evidence format is delivered, and how long records are retained. |
| 15-month review by application owners | Recurring every 15 calendar months, paid in internal staff time for account, group and role-category reviews. | Number of accounts, groups and privileges per system, and whether role definitions are documented in advance. | Whether the review is part of the retainer, how reviewer assignments are recorded, and what sign-off evidence is produced. |
| External review or testing | Optional one-time or periodic, paid to an outside firm to test that the access controls work as described. | Number of in-scope systems, complexity of the access model, and whether testing covers only the workflow or also the technical enforcement. | Scope statement, test method, deliverable format, and whether retesting after fixes is included. |
| Auditor sampling and entity support | Recurring with each Compliance Audit or Spot Check, paid in internal staff time to pull samples and explain them. The Regional Entity, not the entity's vendor, decides the sample. | Audit schedule set by the Regional Entity, audit period length, and how clearly records are kept and indexed. | Confirm with the Regional Entity the evidence format it expects through its Evidence Request Tool and the retention period it applies. |
Who owns CIP-004-7 R4 and what an implementation partner can prepare
The registered entity owns CIP-004-7 R4 in full. It decides who needs electronic access and unescorted physical access to applicable BES Cyber Systems, approves each authorization, performs the quarterly verification of authorization records, and carries out the review of user accounts and privileges at least every 15 calendar months. Those decisions are attributed to people inside the organization, and an auditor will ask who made them and on what basis. A partner can support the work but cannot take over the decisions.
- Need determinations: Managers and system owners state the business need for each role, and the entity records that need before access is granted.
- Authorization sign-off: Named approvers accept or reject access requests, and their approvals are kept as dated records.
- Quarterly and 15-month reviews: Staff run the verifications, investigate exceptions and document the outcome.
- Program ownership: The entity keeps the written access management program current and assigns accountable owners.
- Staff time and tooling decisions: The entity funds its own reviewers and chooses which identity platform it operates.
Before engaging anyone, confirm which of these sign-offs your organization can staff internally and who holds final accountability for each one.
An implementation partner prepares the systems, integrations and documentation that make the entity's access decisions traceable and repeatable. DeployOpen works this way for self-hosted open-source platforms deployed in the client's own infrastructure. The partner does not approve access, does not sign verification records and does not represent the entity to a regulator. Its output is a set of working controls and evidence packages that the entity owns.
- Identity platform setup: Partners can configure directories and single sign-on, such as FreeIPA or Keycloak, so that access is granted through a documented workflow.
- Provisioning integrations: Partners can connect target applications so that changes in the directory flow to them, for example through SCIM provisioning.
- Comparison procedure: Partners can build a documented method for comparing provisioned access against authorization records each quarter.
- Evidence packages: Partners can assemble dated exports, configuration records and review templates for the entity's own staff to complete.
- Fixed-scope documentation: Partners can write procedures and runbooks under a written scope with agreed deliverables.
Ask any partner to state in writing which steps it performs and which remain with your staff.
Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC. It tests CIP-004-7 R4 through Compliance Audits, Spot Checks, Self-Certifications and Self-Reports, and it issues findings. There is no CIP certificate. The auditor or Regional Entity evaluates evidence the entity produces, and it must stay independent of the people who built the controls, so a partner should never design the audit approach or sign off on its own work as the test result.
- Testing and findings: The auditor samples authorizations, compares them to provisioned access and reviews the 15-month privilege review record.
- Evidence requests: The entity answers requests with records it already keeps, so evidence must exist before an audit is announced.
- Independence boundary: A partner can explain a control and show how it works, but it cannot grade the control or write the auditor's conclusion.
- Scope and period: The auditor decides which systems are in scope based on the entity's impact categorization.
- Enforcement: Findings can lead to mitigation plans and penalties under NERC's enforcement program.
Confirm with your Regional Entity which audit approach and evidence format it expects before you finalize the evidence packages.
Where CIP-004-7 R4 access programs usually fall short
Most access management programs under CIP-004-7 R4 have the right policy on paper but fail when an auditor compares dates, accounts and approvals. The gaps below cluster around timing of authorization, documented need, dated verification, and accounts that sit outside the normal provisioning path. Each one has a practical fix that an assessor can check.
Authorization recorded after access
Access is often granted during an urgent change and the authorization record is written days or weeks later, or never. Part 4.1 expects a process that authorizes electronic and unescorted physical access based on need before access is used. Check that each provisioning ticket carries an approval timestamp that precedes the account creation timestamp, and that exceptions are handled under the CIP Exceptional Circumstances definition with their own record.
No documented need determination
Authorization records often name a person and a system but do not show why that person needs that level of access. Part 4.1 leaves the need determination to the entity, so the entity must define it. Write down the criteria, such as job role, assigned BES Cyber System or facility, and the approver's authority, and require each authorization record to reference them. An assessor will test whether the stated need matches the access actually provisioned.
Quarterly checks done from memory
Teams often confirm the quarterly verification in a meeting instead of against exported data. Part 4.2 requires verifying at least once each calendar quarter that individuals with active electronic or unescorted physical access have authorization records. Export the provisioned access list from the identity provider and the directory, compare it to the authorization register, and keep the dated comparison and its sign-off as evidence. Ask the auditor what format they expect before the first cycle.
Shared and service accounts skipped
Reviews usually focus on named user accounts, while shared logins, service accounts and group accounts stay out of scope. Part 4.3 covers all user accounts, user account groups or role categories, and their privileges. Build an inventory of non-personal accounts with an owner, the systems they reach and the need for each, and include them in the 15-month review. A group that grants access to a BES Cyber System belongs in the review even if no one logs in with it directly.
Vendor accounts without authorization records
Contractor and vendor staff often receive access through a shared vendor account or a remote support tool that never reaches the internal authorization process. Those accounts still grant electronic access and must be covered by the same authorization and verification records. Require each vendor individual to be named, tied to a contract or work order, and recorded in the authorization register with an end date that drives removal. Confirm with the vendor how their remote sessions map to named people.
Privileges kept without necessity checks
A 15-month review that only confirms an account exists misses privilege creep, where roles accumulate as people move between jobs. Part 4.3 asks whether privileges are correct and necessary, not just present. Use an access certification step in which a designated reviewer decides to keep, change or revoke each role assignment, and record the decision. Periodic reviews of role membership in a tool such as midPoint can produce that decision trail, though its fit with your environment should be confirmed.
Questions buyers ask about CIP-004-7 R4 cost, time and effort
How much effort does CIP-004-7 R4 take for a small entity versus a large one?
Effort scales with the number of people, applications and systems that hold electronic or unescorted physical access to in-scope BES Cyber Systems, not with the size of the organization alone. A small entity with a few Applicable Systems and one access team can often run the quarterly reconciliation and the 15-month privilege review as part of existing duties. A large entity usually has more access paths, identity sources, contractors and vendor accounts, so each cycle takes more people hours and more tooling. The drivers to examine are the count of Applicable Systems, the number of identity stores, how often roles change, and whether access is granted through tickets or through a central identity system. Ask anyone quoting the work to show how they counted these drivers.
How long does a first CIP-004-7 R4 implementation take?
The first implementation depends on the written scope, which sets the systems, identity sources and evidence to be produced, so no duration can be fixed in advance. Work typically covers an inventory of access paths, a comparison of who holds access against authorization records, a need-based approval workflow, the quarterly verification and the 15-month review, and dated evidence from one complete cycle. Timing is driven by how clean existing records are, how many applications must connect to a central identity system, and how quickly application owners respond. Ask for milestones, the dependencies on your staff, and the date when evidence from a full quarter will exist. Remember that the controls must run for a period before an auditor can see them working.
Can our team implement CIP-004-7 R4 in-house?
Yes, many registered entities run R4 internally. The decision depends on capacity and skill, and no rule requires outside help. An internal team needs people who understand the CIP definitions, can extract access data from each system, can run the quarterly comparison reliably, and can keep dated records that an auditor will accept. Outside help is often considered where the team lacks identity engineering skills, where access is spread across many systems, or where the first cycle must be designed quickly. Whichever path you choose, your organization remains accountable for the controls. Estimate staff hours for each recurring activity, including the reviewer time for access decisions, before deciding.
What does CIP-004-7 R4 need from our application owners?
Application owners are the people who can confirm who should have access and why, so they carry a large share of the work. Expect requests for the list of accounts and roles in their system, the business reason each role exists, confirmation of which roles still need access, and dated approvals when access changes. They also support the 15-month review by confirming that user accounts, groups and privileges are correct and necessary for electronic access. Owners respond faster when they receive a clear extract, a fixed response window and one contact. Agree these responsibilities in writing, with a named person and a backup for each system in scope.
Can a partner prepare R4 evidence without issuing a compliance opinion?
Yes. An implementation partner can design the access workflow, configure identity tooling, produce the quarterly comparison and organize the evidence. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and the Compliance Enforcement Authority, which is a Regional Entity or NERC, decide whether your controls meet the standard, because there is no CIP certificate. Your organization owns the controls and must be able to explain them, run them and show them working over time. Confirm in the written scope that the deliverables are runbooks and evidence packages, not compliance statements.
Do open-source tools satisfy CIP-004-7 R4 on their own?
No. Open-source software can support R4 by holding identity, group and role data and by automating provisioning, but the requirement also needs a documented process, recorded decisions and dated evidence, which no tool supplies by itself. authentik's SCIM provider pushes user and group changes to target applications and runs a full sync every hour, which helps keep downstream accounts aligned with the source. FreeIPA stores users, groups and access control centrally, and Keycloak provides single sign-on across applications. Those tools still need authorization rules, reviewer decisions, quarterly comparisons and records of the 15-month review. A certification campaign tool such as midPoint can record reviewer decisions within a set timeframe. Confirm each tool's capabilities against your own environment.
What should we confirm before signing a fixed-scope CIP-004-7 R4 agreement?
Before signing a fixed-scope agreement, confirm the scope, deliverables and exclusions in writing. List the BES Cyber Systems, identity sources, applications and physical access systems in scope, and confirm how they map to your current CIP-002 categorization. Ask for each deliverable by name, such as the authorization workflow, the quarterly verification procedure, the 15-month review template and the evidence package. Confirm who performs each task across your staff, application owners and the partner. Agree the milestones, acceptance criteria, the process for changing scope, and the support terms after handover. Finally, ask your compliance lead whether the evidence format matches what your auditor expects.
How DeployOpen scopes and prepares CIP-004-7 R4 evidence
DeployOpen works on CIP-004-7 R4 by preparing the systems and records that show need-based authorization, quarterly verification and the 15-month privilege review. The organization keeps ownership of its controls and decides who needs access, while DeployOpen builds the open-source identity tooling and evidence trail around that decision.
How we scope
- Engagements are fixed-scope, with the systems, access paths and deliverables agreed in writing before work starts.
- Scope lists which electronic, unescorted physical and remote access paths fall under the Part 4.1 authorization process.
- Scope also confirms which user accounts, groups and role categories the 15-month privilege review will cover.
How we build
- We plan an identity source of truth that records the authorization basis for each user and role assignment.
- We configure provisioning and deprovisioning connectors so application access follows the authorization records.
- We test quarterly comparisons between provisioned access and authorization records before handing the process over.
How we hand over
- Documented procedures describe who authorizes access, who verifies it each quarter and how the 15-month review runs.
- Dated exports of authorization records and quarterly comparison outputs are delivered in a format your assessors can read.
- Your staff receive the runbooks needed to repeat the verification cycle without DeployOpen involvement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover upgrades to the identity platform and periodic checks that quarterly and 15-month records remain complete.
- Confirm with your compliance lead which evidence an independent auditor will accept, since DeployOpen prepares evidence but does not issue audit reports.
