Access Review

Access reviews fail in predictable ways: the scope is unclear, the population is incomplete, or the review becomes a “rubber stamp” with no recorded decisions and no follow-through. C2M2’s access review requirement is simple on paper, but operationally it forces you to answer hard questions: What counts as an “asset” in scope? Which identities and accounts must be reviewed (human, service, vendor, break-glass)? Who is accountable for review decisions in OT environments where ownership is shared between engineering, operations, and IT?

C2M2 v2.1 frames this as a maturity practice: you define the frequency and prove you execute it. That makes the control design and the evidence just as important as the actual access changes. Your goal is to be able to show, for any in-scope IT or OT system, that access is periodically reviewed against current requirements, that inappropriate access is removed (or formally excepted), and that someone with authority attested to the outcome (Cybersecurity Capability Maturity Model v2.1).

This page gives requirement-level implementation guidance you can put into motion quickly: scope rules, review workflows, evidence to retain, and the exam questions that tend to derail teams.

Regulatory text

Requirement (C2M2 v2.1 ACCESS-2.E): “Access to IT and OT assets is reviewed at an organization-defined frequency to ensure access requirements are still met.” (Cybersecurity Capability Maturity Model v2.1)

What you must do as an operator:

1. Define a review frequency and apply it consistently to the IT and OT assets in scope.
2. Compare actual access (accounts, roles, entitlements) to current access requirements (job role, need-to-know, least privilege, contract status, training/authorization prerequisites where applicable).
3. Record decisions and complete remediation: remove, adjust, or document exceptions with approval and expiry.
4. Retain evidence that the review occurred, was performed by appropriate reviewers, and drove corrective action (Cybersecurity Capability Maturity Model v2.1).

Plain-English interpretation

An access review is a periodic “re-approval” of access. You produce a complete list of who has access to a system (or asset class), an appropriate reviewer confirms each access is still needed, and you take action on anything that is not justified. “Organization-defined frequency” means you choose the cadence, but you must be able to defend it based on system criticality and exposure, and then meet it consistently (Cybersecurity Capability Maturity Model v2.1).

Who it applies to

Entity types (typical C2M2 adopters):

• Energy sector organizations and critical infrastructure operators using C2M2 to assess and improve cybersecurity maturity (Cybersecurity Capability Maturity Model v2.1; DOE C2M2 program).

Operational context and scope triggers:

• Any environment with in-scope IT assets (enterprise apps, directory services, cloud platforms, VPNs, endpoints, databases).
• Any environment with in-scope OT assets (SCADA, DCS, PLC engineering workstations, historians, OT jump hosts, OT remote access, vendor maintenance paths).
• Any access path that can impact confidentiality, integrity, or availability of those assets, including third-party access and non-human accounts (service accounts, API keys), if those accounts grant system access that should be governed.

What you actually need to do (step-by-step)

Step 1: Define “access requirements” and review scope (write it down)

Create a short access review standard that answers:

• Assets in scope: define which IT and OT systems are included, and how you classify them (for example: critical OT, high-impact IT, supporting systems).
• Access types in scope: privileged roles, standard user roles, remote access, local accounts, shared accounts, service accounts, and third-party accounts.
• Reviewer model: line manager attestation, system owner attestation, or a split model (common in OT: system owner + operations/engineering sign-off).
• Decision outcomes: approve, revoke, modify (role change), or exception.

Deliverable: “Access Review Standard” (1–3 pages) mapped to your system inventory.

Step 2: Set the organization-defined frequency using a simple risk tiering rule

C2M2 does not prescribe a number; you must pick and consistently execute (Cybersecurity Capability Maturity Model v2.1). A practical approach is tiered frequency:

• Higher criticality / higher exposure systems reviewed more often (privileged access, remote access paths, OT control networks).
• Lower criticality systems reviewed less often.

Document the rule, not just dates. Auditors look for a rational basis plus evidence you met your own schedule.

Deliverable: Review cadence table by asset tier and access type.

Step 3: Build the authoritative “review population” (completeness is the make-or-break)

For each in-scope system, produce an export that includes:

• User/account identifier (human and non-human)
• Role/group/entitlement
• Privilege level (admin vs standard)
• Access method (local, directory, VPN, PAM, jump host)
• Account owner and manager (or accountable system owner for non-human)
• Last login / last use where available (helpful for decisions; not a substitute for review)

In OT, you may need multiple sources: local device accounts, domain groups, jump host access lists, vendor portals, and firewall rule owners. If the population is incomplete, the “review” is not defensible.

Deliverable: Dated access roster per system (or per asset class), with a population generation method.

Step 4: Run the review with accountable attestations

Use a workflow that forces explicit decisions:

1. Assign reviewers (manager, system owner, or both).
2. Provide context (role descriptions, access requirements, and what “approve” means).
3. Collect decisions for each account/entitlement:
   • Keep (still required)
   • Remove (no longer required)
   • Change (wrong role / too much privilege)
   • Exception (requires documented business/operational reason)

For OT, require reviewers to confirm operational necessity and safe change windows for removals or role changes.

Deliverable: Completed attestation records that tie reviewer identity to the decision set.

Step 5: Remediate and prove closure (reviews without action do not pass scrutiny)

Create remediation tickets from the review outcomes and track them to closure:

• Deprovision terminated/transfer users
• Remove dormant or duplicate accounts
• Reduce privilege (admin to standard; limit engineering tool access)
• Fix group membership drift
• Validate third-party accounts are current, sponsored, and time-bounded
• For exceptions: document approver, scope, compensating controls, and an expiry/next review trigger

Deliverable: Ticket list with closure evidence and timestamps, linked to the review cycle.

Step 6: Handle exceptions as a governed process

Define when exceptions are allowed and who can approve them. Minimum fields:

• Exception description and business reason
• Risk owner approval (system owner or designated authority)
• Compensating controls (monitoring, MFA, jump host restrictions)
• Expiry date or event-based expiration (contract end, project end)
• Revalidation requirement at the next review cycle

Deliverable: Exception register entries linked to the access review.

Step 7: Quality control and reporting

After each cycle:

• Confirm all in-scope systems were reviewed.
• Confirm all assigned reviewers completed attestations.
• Confirm remediation is closed or tracked with justified due dates.
• Record metrics that prove execution (counts are fine; do not over-engineer).

Deliverable: Access review completion report signed by control owner.

Where Daydream fits (practical, non-disruptive)

If you manage access reviews across many systems, Daydream can serve as the system of record for: review schedule, scoped populations, reviewer assignments, exception tracking, and evidence packaging for audits. The value is less “automation” and more consistency: one workflow, one evidence set, fewer missed systems.

Required evidence and artifacts to retain

Use this checklist to stay audit-ready:

Evidence item	What it proves	Common format
Access Review Standard (scope, cadence, roles)	The control is defined and repeatable	Policy/standard document
System/asset inventory in scope	Coverage across IT and OT	CMDB extract, asset list
Dated access rosters (populations)	Completeness of what was reviewed	CSV exports, screenshots, reports
Reviewer assignments	Right people performed the review	Workflow logs, emails, tickets
Attestations with decisions	The review occurred and had outcomes	GRC workflow, signed spreadsheet
Remediation tickets and closure evidence	Findings were fixed	ITSM tickets, change records
Exception approvals and expiry tracking	Risk decisions are governed	Exception register
Cycle completion sign-off	Management oversight	Memo, GRC sign-off

Retention period: follow your internal record retention standard; keep at least enough history to show consistent operation across multiple cycles.

Common exam/audit questions and hangups

Expect these questions from internal audit, customers, or assessors:

• “Show me your access review cadence and evidence you met it.” They will sample systems across IT and OT.
• “How do you know the access roster is complete?” Be ready to explain data sources and gaps.
• “Who is authorized to approve access and re-approve it?” They will test reviewer independence and authority.
• “What happens when someone leaves or changes roles between review cycles?” Your offboarding and change-of-role controls should align with review outcomes.
• “How do you control third-party and vendor access into OT?” They will look for sponsorship, time bounds, and review.
• “Show exceptions and who approved them.” Unowned exceptions are a repeat finding.

Frequent implementation mistakes (and how to avoid them)

1. Rubber-stamp reviews

• Mistake: reviewers click “approve all” with no accountability.
• Fix: require per-identity decisions for privileged access and remote access; sample-check approvals; require comments for high-risk approvals.

2. Incomplete populations

• Mistake: only reviewing Active Directory groups while OT local accounts and jump host access are ignored.
• Fix: define authoritative sources per system; include local accounts, shared accounts, and vendor paths.

3. No remediation linkage

• Mistake: findings are emailed, but there is no ticket trail.
• Fix: enforce “no finding without a ticket,” even if the ticket is a simple access removal request.

4. Exceptions that never expire

• Mistake: “temporary” access becomes permanent by default.
• Fix: require expiry or next-cycle revalidation; track exceptions in one register.

5. OT change constraints ignored

• Mistake: revocations scheduled during critical operations, then deferred without documentation.
• Fix: document safe windows and compensating controls; keep deferral approvals.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement. Practically, weak access reviews create two recurring failure modes: (1) inappropriate access persists after personnel changes, and (2) you cannot justify access decisions during control testing or customer diligence. C2M2 explicitly calls out the need to review access at a defined frequency and ensure requirements are still met, so the risk is both security exposure and maturity assessment gaps (Cybersecurity Capability Maturity Model v2.1).

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Confirm in-scope IT/OT systems for the C2M2 assessment boundary (Cybersecurity Capability Maturity Model v2.1).
• Publish the Access Review Standard: scope, roles, decision outcomes, exception rules.
• Define the cadence rule by system tier and access type.
• Identify authoritative sources for access rosters per system (IT + OT).

Days 31–60 (run the first cycle on a prioritized subset)

• Pilot access reviews on: remote access, privileged access, and highest-criticality OT systems.
• Train reviewers on decision criteria and what evidence they must record.
• Open remediation tickets for all removals/changes; stand up the exception register.
• Produce a completion report and capture lessons learned (population gaps, reviewer delays).

Days 61–90 (expand coverage and make it repeatable)

• Expand to remaining in-scope systems using the refined roster method.
• Add QA checks: completeness review, spot-check approvals, exception expiry tracking.
• Standardize evidence packaging for audits (one folder or GRC record per cycle).
• If tool support is needed, implement Daydream workflows to schedule reviews, collect attestations, and assemble evidence consistently.

Frequently Asked Questions

What does “organization-defined frequency” mean in practice?

You choose the cadence and document it, ideally using a tiering rule based on system criticality and exposure. Assessors will expect you to follow your own rule consistently and show evidence for each completed cycle (Cybersecurity Capability Maturity Model v2.1).

Do access reviews apply to OT systems even if they are “air-gapped”?

Yes if the OT assets are in scope for your C2M2 assessment. Even isolated environments have accounts, roles, and engineering workstations that require periodic validation (Cybersecurity Capability Maturity Model v2.1).

Are service accounts and shared accounts in scope for access review?

Treat them as in scope if they provide access to in-scope IT or OT assets. Review should confirm an accountable owner, a valid purpose, and appropriate privilege, then document the decision.

Who should perform the access review: IT security, managers, or system owners?

Use reviewers who can confirm business need and operational necessity: commonly line managers for end-user access and system owners for administrative and OT access. Security should oversee the process, enforce completion, and validate evidence quality.

What evidence is the fastest path to “audit-ready”?

Keep four things tied together: the access roster export, the reviewer’s attestation decisions, remediation tickets with closure proof, and an exception record for anything kept outside standard requirements (Cybersecurity Capability Maturity Model v2.1).

How do we handle access removal if OT uptime constraints delay changes?

Document the deferral decision, the approved change window, and compensating controls during the interim period. Then close the loop with a ticket showing the eventual removal and date of completion.