Access Granting and Revoking

The “Access Granting and Revoking” requirement means you must have defined, repeatable rules for how access to IT and OT assets is requested, approved, provisioned, changed, and removed—and you must be able to prove you followed those rules. Operationalize it by standardizing approvals, enforcing least privilege, triggering timely revocation, and retaining complete access decision evidence. ¹

Key takeaways:

• Define “who can approve what” and “what qualifies for access” for IT and OT, then route all access through that path. ¹
• Tie revocation to concrete triggers (termination, role change, contract end, incident response), not calendar reminders. ¹
• Treat evidence as part of the control: tickets, approvals, provisioning logs, deprovisioning confirmation, and exceptions must be retained and retrievable. ¹

Access failures rarely look like “hackers got in.” They show up as stale accounts, shared credentials, emergency access that never got closed, third-party remote access left enabled after a project ended, or an OT engineering workstation that quietly accumulated admin rights over years. The C2M2 ACCESS-2.B (MIL1) requirement is direct: access to IT and OT assets must be granted and revoked based on defined requirements. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to compliance is to make access decisions auditable. That means (1) documenting the minimum requirements for access (identity proofing, approvals, role/need, training, segmentation constraints), (2) enforcing the workflow so exceptions are visible, and (3) retaining the evidence that shows what you did and why.

This page gives you requirement-level implementation guidance you can drop into an access control standard, IAM operating procedure, and audit request binder. It also calls out OT realities (break-glass, vendor access, safety constraints) where “just use SSO” is not an option.

Regulatory text

C2M2 v2.1 ACCESS-2.B (MIL1) excerpt: “Access to IT and OT assets is granted and revoked based on defined requirements.” ¹

What the operator must do:
You must define the requirements that govern access decisions (grant, modify, revoke) for in-scope IT and OT assets, then operate consistently against those requirements. Your goal is simple: no access without authorization, and no continued access after the business need ends. ¹

Plain-English interpretation

• “Defined requirements” means written criteria and process steps, not tribal knowledge. The definition must cover approvals, provisioning steps, and revocation triggers, and it must apply to both IT and OT environments in scope. ¹
• “Granted and revoked” means the full lifecycle: new access, changes (role changes, privilege escalation), temporary access, emergency access, and removal. If you only do onboarding but not offboarding, you will fail this requirement in practice.
• Need-to-know / least privilege should be the default posture. The requirement’s implementation expectation aligns to granting only what’s required and removing it quickly when no longer justified. ¹

Who it applies to

Entity scope

This applies to organizations using C2M2 to assess cybersecurity capability within a defined scope, commonly energy sector organizations and critical infrastructure operators. ¹

Operational scope (what assets and situations)

Include all in-scope:

• IT assets: identity platforms, endpoints, servers, databases, cloud consoles, SaaS admin portals, code repos, ticketing systems, backup systems.
• OT assets: SCADA/DCS/HMI environments, engineering workstations, historians, OT domain controllers (if present), vendor remote access solutions, jump hosts, and network devices controlling segmentation.
• Third parties: vendors, integrators, OEMs, consultants, temporary labor, and managed service providers with logical or physical access paths.

If OT access is partially manual (local accounts, vendor service accounts), you still need defined requirements and evidence. The workflow may be different than IT, but it must be explicit and repeatable.

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

1) Define access requirements (write the rules people must follow)

Create a short “Access Granting & Revocation Standard” that answers these questions:

Decision point	Minimum requirement you define
Who can request access?	Employee, contractor, third party sponsor required, service accounts restricted
Who can approve?	System owner and/or data owner; OT asset owner for OT; security approval for privileged access
What is approved?	Specific role/group, asset scope, privilege level, duration (if temporary)
Preconditions	Identity verification, onboarding complete, required training, signed acceptable use/remote access terms
Time bounds	Default indefinite vs time-limited access rules; how extensions work
Revocation triggers	Termination, role change, contract end, access review finding, incident containment action
Exceptions	How to request, who approves, compensating controls, expiry date, logging requirement

This is the “defined requirements” auditors look for first. ¹

2) Build an approval workflow that matches your org chart (and OT reality)

Operationalize approvals through a system of record (ticketing, IAM tool, or GRC workflow). For each access type, define the required approvers:

• Standard user access: manager + asset owner (or a delegated approver).
• Privileged access: asset owner + security (and often IT/OT operations lead).
• Third-party remote access: internal sponsor + OT asset owner + security, with explicit time window.

Write a RACI for access decisions so approvals do not stall.

3) Provision access through controlled mechanisms (stop “side door” grants)

For each in-scope system, define the provisioning method:

• Preferred: IAM/JML automation (joiner/mover/leaver) tied to HR and role-based groups.
• Acceptable: ticket-based manual provisioning with a checklist and required screenshots/log extracts.
• Discouraged: ad hoc admin changes without a ticket. If you cannot eliminate this quickly in OT, require retroactive ticketing within your process and treat gaps as exceptions.

4) Make revocation trigger-based, not memory-based

Define and implement revocation triggers that automatically start deprovisioning work:

• HR termination feed creates deprovisioning tasks (IT and OT where applicable).
• Mover events (team/role change) force re-approval of entitlements; default-remove old entitlements.
• Third-party contract end disables remote access and accounts; close VPN, rotate shared secrets if any exist.
• Incident response can require immediate access suspension; document the authority and restoration steps.

Then define who executes revocation (IAM team, system admin, OT ops) and how completion is confirmed.

5) Require periodic revalidation (access reviews) for high-risk access

C2M2 ACCESS-2.B focuses on defined requirements for granting and revoking. In practice, most programs add access reviews as the safety net that finds drift and stale entitlements, and the provided best-practice guidance explicitly calls out retaining “review results.” ¹
Prioritize:

• Privileged groups (domain admins, cloud admins, OT admins)
• Remote access paths (VPN, jump hosts, vendor portals)
• Service accounts and shared accounts (reduce, justify, and control)

6) Instrument evidence collection (treat it as part of the control)

Decide upfront what “good evidence” looks like and make it easy to retrieve. If you plan for evidence after the audit request arrives, you will miss it.

Daydream (or your GRC system) fits well here as the control evidence hub: you can map each access pathway to required artifacts, assign owners, and track exceptions and expirations so “defined requirements” stays aligned with what’s really happening.

Required evidence and artifacts to retain

Retain evidence that ties request → approval → provisioning → verification → revocation:

Policy/standard artifacts

• Access granting & revocation standard (IT + OT scope statement) ¹
• Role/entitlement definitions (RBAC matrix or group catalog)
• Approval matrix (who approves what) and exception process

Operational records (samples are fine if volume is high)

• Access requests (tickets/forms) with business justification
• Approvals (system owner/manager/security) captured in-system
• Provisioning logs or screenshots showing changes applied
• Deprovisioning records tied to triggers (termination/mover/contract end)
• Access review outputs: reviewer attestations, remediation actions, exceptions ¹
• Exception register: rationale, compensating controls, owner, expiry, re-approval history ¹

OT-specific artifacts (commonly requested)

• Vendor access records (who, when, why, how long, via what path)
• Jump host logs, session recording confirmations (if available)
• Break-glass access logs and closure evidence

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Show me your defined requirements.” They want the standard, scope, and approval rules. ¹
2. “Pick 10 users: prove access was approved and appropriate.” You need traceability from entitlement to approval.
3. “Pick 10 terminations: prove access was removed.” If you cannot show revocation completion, you have an operating effectiveness gap.
4. “How do you handle OT accounts and vendor remote access?” Auditors probe the messy parts.
5. “What about exceptions and emergency access?” If you have break-glass without expiry and review, expect findings.

Hangups that cause findings:

• No single system of record for approvals
• Asset ownership is unclear, so approvals are rubber-stamped
• Revocation depends on emails or manager memory
• Third-party access is not time-bound or not reviewed

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Writing a policy that doesn’t match how OT work is done.
   Avoidance: define two pathways (IT standard, OT constrained) but keep the same principles: authorization, traceability, revocation triggers, evidence.

2. Mistake: Treating provisioning as the control and ignoring revocation.
   Avoidance: build “leaver” and “mover” workflows first; they prevent persistent inappropriate access.

3. Mistake: Shared accounts with no accountability.
   Avoidance: eliminate where possible; otherwise require named user check-out, logging, strict time bounds, and compensating controls documented as exceptions.

4. Mistake: Exceptions without expiry.
   Avoidance: every exception has an owner and a defined expiration event; re-approval requires a new rationale and proof compensating controls still work.

5. Mistake: Evidence stored in inboxes.
   Avoidance: force approvals into a system of record and export review artifacts into your evidence repository (Daydream or equivalent) with consistent naming and retention.

Risk implications (why this requirement gets attention)

Poor access granting and revoking creates two predictable failure modes:

• Unauthorized access (someone gets access they should not have) through weak approvals or privilege creep.
• Persistent access (someone keeps access after need ends) through weak offboarding and untracked third-party access.

C2M2 guidance flags the operational risk directly: if the process is poorly designed or not evidenced, inappropriate access may persist and access decisions become hard to justify during testing, audits, customer diligence, or regulator review. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish the access granting & revocation standard with scope (IT and OT) and the approval matrix. ¹
• Inventory your “systems that matter” for scope: identity stores, remote access paths, OT jump hosts, crown-jewel applications.
• Pick a system of record for access requests/approvals and enforce “no ticket, no access” for high-risk systems.
• Define revocation triggers and assign execution owners for each trigger type.

Days 31–60 (operate and collect evidence)

• Implement revocation workflows for termination and third-party contract end; test with real events and keep proof.
• Start privileged access review for the highest-risk groups and remote access paths; document remediation and exceptions. ¹
• Create an exception register with expiry and compensating controls, and require leadership sign-off for OT constraints.

Days 61–90 (scale and harden)

• Expand standard workflows to remaining systems; reduce manual provisioning pathways.
• Add mover-driven re-approval for role changes to cut privilege creep.
• Run an internal control test: sample access grants and revokes; verify evidence is complete and retrievable.
• Centralize artifacts (requests, approvals, review outputs, exceptions) in a single evidence library, mapped to the requirement. ¹

If you need this to move fast, Daydream can act as the control “spine”: define the requirement once, attach required artifacts, assign owners, and track exceptions to closure so audits stop turning into scavenger hunts.

Frequently Asked Questions

Does this requirement mandate least privilege even though the text is short?

The requirement focuses on granting and revoking access based on defined requirements, and the associated guidance frames it around need-to-know and least privilege. Write those principles into your access requirements and enforce them in approvals. ¹

How do we handle OT systems that can’t integrate with IAM or SSO?

Keep the same control logic: a documented request and approval, controlled provisioning steps, and defined revocation triggers with evidence. Where technical limits exist, document them as exceptions with compensating controls and an expiry condition.

What counts as “defined requirements” for an audit?

A written standard or procedure that specifies approval criteria, provisioning steps, review cadence expectations, and revocation triggers, plus proof you follow it. Auditors then test a sample of access events against that standard. ¹

Are access reviews required here?

The requirement is about granting and revoking based on defined requirements, but the provided implementation guidance explicitly calls out retaining “review results.” Use access reviews as your control to detect drift and force revocation when approvals no longer match need. ¹

How should we manage third-party remote access for break/fix support?

Require an internal sponsor, OT asset owner approval, time-bounded enablement, and a clear revocation step when work completes. Keep session logs or access logs and tie them back to the request record.

What evidence do we need to retain if access is automated?

Keep the request/approval record (even if embedded in HR/IAM workflows), the entitlement assigned, and system logs that show provisioning and removal occurred. Automation reduces manual steps but does not remove the evidence obligation. ¹

What you actually need to do

Use the cited implementation guidance when translating the requirement into day-to-day operating steps. ²

Footnotes

1. Cybersecurity Capability Maturity Model v2.1

2. DOE C2M2 program