Identity and access management maturity

Identity and access management maturity (C2M2-06) requires you to progressively strengthen identity governance and access controls as your cybersecurity capability matures, and to be able to prove that progression with repeatable processes and evidence. Operationalize it by defining an IAM maturity target for your scope, closing governance gaps, tightening privileged access, and running recurring access reviews with audit-ready records. ¹

Key takeaways:

• Treat IAM maturity as a staged program: governance first, then repeatability, then measurable control performance. ¹
• Prioritize privileged access controls and access governance checkpoints; these create the clearest risk reduction and the strongest exam narrative. ¹
• Evidence matters as much as design: retain approvals, review logs, and exception handling so access decisions are defensible under scrutiny. ¹

C2M2 is a capability maturity model; it expects your identity and access management (IAM) to improve in rigor as your overall cybersecurity program matures. For a CCO or GRC lead, that means two things you can act on quickly: (1) your IAM controls must match the criticality of the environment in scope (often operational technology, industrial control systems, or other critical infrastructure), and (2) you must show a credible progression from ad hoc practices to governed, repeatable, and measurable controls. ¹

“IAM maturity” is not a single control. It’s the operating model behind access: who can approve access, how you decide what “appropriate” means, how you control privileged actions, how you remove access when conditions change, and how you prove it later. Weak maturity shows up as orphaned accounts, shared credentials, over-privileged roles, inconsistent approvals, and exceptions that become permanent. ¹

This page gives requirement-level guidance to stand up an IAM maturity track you can run: scope, target state, step-by-step execution, artifacts to retain, audit questions to prep for, and a practical execution plan that gets traction fast without waiting for a full IAM replatform.

Regulatory text

Requirement (C2M2-06): “Strengthen identity governance and access controls as capability maturity improves.” ¹

What the operator must do

You must build an IAM program that becomes more governed, consistent, and defensible over time. Practically, that means:

• Identity governance: clear ownership, defined approval authorities, documented standards (e.g., privileged access, service accounts, remote access), and recurring oversight. ¹
• Access controls that tighten with maturity: stronger privileged controls, better role/entitlement design, more consistent provisioning/deprovisioning, and regular access validation. ¹
• Evidence of progression: you can demonstrate that IAM is not static, and that you can measure and improve control performance within the defined scope. ¹

Plain-English interpretation

As your cybersecurity program grows up, your access program must grow up with it. You cannot rely on “we know who has access” or one-time cleanups. You need governance checkpoints (who approves, how often you review, how exceptions are handled) and strong privileged account controls because privileged access is where small process gaps become major incidents. ¹

Who it applies to (entity and operational context)

This requirement applies to organizations using C2M2 to assess a defined scope such as a business unit, function, or operational technology environment. It is especially relevant for critical infrastructure and energy sector organizations adopting C2M2 as their maturity benchmark. ¹

Operationally, expect the scope to include:

• Corporate IAM that grants access into OT management planes or engineering workstations
• Plant/field access paths (VPN, jump hosts, remote support tools)
• Privileged accounts in Windows domains, directory services, hypervisors, historian systems, EDR consoles, backup consoles, and network management systems
• Service accounts and shared accounts tied to automation, integrations, or legacy OT systems

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

Step 1: Define scope and maturity target (governance checkpoint #1)

1. Write a one-page IAM scope statement: systems, identity stores, user populations (employees, contractors, third parties), and privileged platforms in scope.
2. Name control owners for: joiner/mover/leaver, privileged access, service accounts, and access reviews.
3. Set a maturity objective for the next planning cycle: what will be standardized, what will be measured, what will be automated, and what will remain manual with controls.

Deliverable outcome: a scope-and-ownership baseline that makes later evidence coherent. ¹

Step 2: Establish access governance standards (governance checkpoint #2)

1. Document approval rules: who can approve what, and what “valid business justification” must include.
2. Create a role/entitlement model for key systems: at minimum define “standard user,” “power user,” and “administrator” patterns per system class.
3. Define an exception process: time-bound exceptions, explicit risk acceptance owner, compensating controls, and a re-approval trigger.

Keep it tight: you want enforceable rules, not a policy library. ¹

Step 3: Put privileged access under explicit control (highest-risk first)

Implement privileged account controls that reduce standing access:

1. Inventory privileged identities (named admin accounts, break-glass accounts, local admins, domain admins, cloud admins, OT application admins).
2. Separate admin from daily accounts (no admin rights on standard identities).
3. Limit and monitor privileged sessions: require strong authentication for privileged access paths; log privileged actions where the platform supports it.
4. Control emergency access (“break glass”): define who can use it, what triggers it, and what review happens after use.

If you do only one maturity improvement in the next cycle, do this one. It creates a clear story of risk reduction and control intent. ¹

Step 4: Standardize joiner/mover/leaver (JML) and third-party access

1. Joiners: access requests must map to roles/entitlements, with approvals recorded.
2. Movers: changes in job function must trigger access reevaluation, not additive access.
3. Leavers: disable accounts and remove access promptly, including remote access and SaaS consoles in scope.
4. Third parties/contractors: enforce sponsorship, time-bounded access, and a revalidation requirement tied to contract status or work orders.

Goal: provisioning becomes repeatable, not dependent on tribal knowledge. ¹

Step 5: Run recurring access governance checkpoints (access reviews that mean something)

1. Select review populations: privileged users first, then high-impact systems, then broader user groups.
2. Define review criteria: appropriate role, valid justification, no toxic combinations, no stale accounts.
3. Track outcomes: removals, changes, exceptions, and non-responses.
4. Close the loop: verify that removals actually executed in the target system.

Maturity shows up in repeatability: same cadence, same method, same evidence package. ¹

Step 6: Measure, report, and improve (maturity checkpoint #3)

1. Define IAM control health indicators you can consistently produce (qualitative is acceptable if measured data is not yet available): review completion status, exception counts, privileged inventory completeness, deprovisioning backlog themes.
2. Report to a governance forum (security steering committee, OT governance board, or risk committee) with decisions captured.
3. Build an improvement backlog: role cleanup, service account ownership, privileged session logging expansion, removal of shared accounts.

This is how you demonstrate “as capability maturity improves” in a way an assessor can follow. ¹

Required evidence and artifacts to retain

Retain artifacts that prove both governance and operation:

Governance artifacts

• IAM scope statement (systems, identity stores, populations)
• RACI / named control owners for IAM processes
• Access approval standard (what must be documented, who approves)
• Privileged access standard (separation of accounts, emergency access rules)
• Exception process and risk acceptance template

Operational artifacts

• Privileged account inventory (with owners and purpose)
• Samples of access requests with approvals and implemented entitlements
• JML records showing provisioning, modification, and deprovisioning outcomes
• Access review packages: reviewer list, evidence of completion, findings, remediation tickets, closure proof
• Break-glass usage logs and post-event reviews (even if “no events”)
• Evidence of governance checkpoint meetings where IAM metrics and exceptions were reviewed (minutes, action items)

Make the evidence “walkable”: an auditor should be able to pick a user and trace request → approval → provision → review → removal. ¹

Common exam/audit questions and hangups

What auditors ask	What they are testing	How to answer (and what to show)
“Who approves access and based on what?”	Governance and least privilege	Approval matrix, access request samples, role definitions 1
“How do you know ex-employees and contractors are removed?”	JML reliability	Offboarding evidence, deprovisioning report samples, ticket closure proof 1
“What controls exist over privileged access?”	Highest-risk access paths	Privileged inventory, admin separation, break-glass procedure, privileged logs 1
“Do you perform access reviews? What happens to findings?”	Control operation, not box-checking	Review package, remediation tickets, re-test evidence 1
“How does IAM improve over time?”	Maturity progression	Roadmap/backlog, governance minutes, before/after control coverage narrative 1

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating IAM maturity as an IAM tool purchase.
   Avoidance: Start with governance checkpoints, privileged inventory, and access review operation; tools can follow once the decision rights and data model are clear. ¹

2. Mistake: Doing one massive quarterly access review with low quality.
   Avoidance: Review privileged access and high-impact systems first with a consistent method; expand scope after the process stabilizes. ¹

3. Mistake: Exceptions without expiration.
   Avoidance: Require time bounds and re-approval triggers for every exception; tie exceptions to compensating controls and documented risk ownership. ¹

4. Mistake: No ownership for service accounts and shared accounts.
   Avoidance: Assign a human owner, define allowed use cases, and require periodic validation; remove or redesign shared access where feasible. ¹

5. Mistake: Evidence scattered across email and chat.
   Avoidance: Centralize evidence in a GRC workspace with standardized folders and naming conventions. Daydream can help by mapping IAM evidence requests to control expectations and keeping artifacts tied to the requirement narrative during assessments. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, weak IAM maturity increases the likelihood of inappropriate access persisting and makes access decisions hard to justify during internal control testing, audits, customer diligence, or regulator review. ¹

For critical infrastructure and OT-adjacent environments, the risk concentrates in:

• Privileged accounts that can change configurations, disable monitoring, or alter safety-related parameters
• Remote access pathways used by employees and third parties
• Service accounts that bypass human approvals and often have broad permissions

A practical 30/60/90-day execution plan

First 30 days (stabilize and create line of sight)

• Freeze the scope: document in-scope systems and identity stores.
• Create a privileged account inventory for in-scope platforms; assign owners.
• Publish an access approval standard and an exception template.
• Start a privileged access review on the highest-impact system(s) and track remediation to closure. ¹

Days 31–60 (make it repeatable)

• Implement admin/daily account separation where feasible; document exceptions.
• Standardize JML intake with required fields (requestor, justification, role/entitlement, approver).
• Run a second access governance checkpoint: review exception register, privileged inventory completeness, and remediation status; capture decisions and actions. ¹

Days 61–90 (prove maturity movement)

• Expand reviews to the next tier of systems and to third-party/contractor access.
• Add measurable reporting: review completion, remediation aging themes, exception counts, privileged population changes.
• Write an IAM maturity backlog for the next cycle (role redesign, service account governance, privileged session logging expansion) and get it approved in your governance forum. ¹

Frequently Asked Questions

Does C2M2-06 require a specific IAM technology (IGA/PAM/SSO)?

No specific technology is stated in the requirement text; it requires stronger governance and controls as maturity improves. You can start with defined decision rights, repeatable reviews, and privileged controls, then add tooling to scale. ¹

What should I prioritize if I have limited resources?

Prioritize privileged access controls and governance checkpoints (approvals, exceptions, reviews). These areas reduce high-impact risk and create strong, defensible evidence for maturity. ¹

How do I show “maturity improvement” to an assessor?

Show a baseline, a repeatable process, and governance records that demonstrate change over time (e.g., privileged inventory completeness improving, recurring access reviews with tracked remediation). Keep artifacts tied to the defined scope. ¹

How do third parties fit into IAM maturity?

Include third-party identities in scope when they have network or system access, especially remote or privileged access. Require sponsorship, time-bounded access, and periodic revalidation with recorded approvals. ¹

What evidence is most persuasive in audits?

Traceable samples: request → approval → provisioning → review → remediation, plus privileged inventory and break-glass governance. Meeting minutes showing oversight and decisions help connect controls to management accountability. ¹

Where does Daydream fit in operationalizing this requirement?

Daydream fits where teams struggle most: organizing evidence, standardizing review workflows, and keeping exceptions, approvals, and remediation tied to the IAM requirement narrative. That reduces scramble during assessments and makes maturity progression easier to demonstrate. ¹

What you actually need to do

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

Footnotes

1. DOE C2M2

2. DOE C2M2 program