Identity and Access Management Governance

The Identity and Access Management (IAM) Governance requirement means you must run IAM under approved, documented policy and procedure, and tie IAM decisions to your enterprise risk management (ERM) program so access risks are identified, owned, tracked, and reported. Practically, auditors will expect clear ownership, review cadence, evidence of approvals, and proof the policy drives day-to-day access operations. ¹

Key takeaways:

• Document IAM governance (policy + procedures) with owners, approval history, and a defined review cadence. ¹
• Integrate IAM into ERM: include IAM risks in the risk register, align to risk appetite, and report metrics to the right governance forum. ¹
• Retain operating evidence that staff follow the governance, not just that the documents exist. ¹

IAM governance fails in predictable ways: a policy exists but is outdated, a tool is deployed but exceptions are unmanaged, or access reviews occur but nobody can explain how the results flow into risk decisions. C2M2 frames the requirement clearly: IAM activities must be guided by documented policies and integrated with the enterprise risk management program. ¹

For a CCO or GRC lead, the fastest path is to treat IAM governance as a control system with four moving parts: (1) a governing policy that sets mandatory rules and accountability, (2) procedures and standards that translate rules into repeatable operations, (3) ERM integration that turns IAM issues into owned risks with treatment plans, and (4) evidence that proves the system runs consistently.

This page gives requirement-level implementation guidance you can operationalize quickly: who needs to be involved, what to write, what to measure, what artifacts to retain, and what auditors commonly challenge. The emphasis is execution: how to show that IAM governance is real, current, and connected to business risk decisions. ¹

Regulatory text

Requirement (C2M2 ACCESS-2.F): “Identity and access management activities are guided by documented policies and integrated with the enterprise risk management program.” ¹

What the operator must do:

1. “Guided by documented policies” means IAM work (provisioning, deprovisioning, privileged access, third-party access, service accounts, access reviews, exceptions) must follow approved, written governance that tells teams what is required and who is accountable. ¹
2. “Integrated with the enterprise risk management program” means IAM is not only an IT process. IAM risks must be identified, assessed, recorded, owned, and reported through your ERM mechanisms (risk register, risk acceptance, KRIs/KPIs, governance committees). ¹

Plain-English interpretation

You need an IAM policy and supporting procedures that people actually follow, and you must be able to show how IAM issues become enterprise risks with owners and decisions. If your IAM governance is “security-owned” but never enters ERM reporting, you are not meeting the requirement. ¹

Who it applies to

Entity scope

This applies to organizations using C2M2 within the scoped business unit, function, or operational technology environment being assessed. It is commonly relevant for energy sector and critical infrastructure operators adopting C2M2 as a maturity benchmark. ¹

Operational context (where this breaks in practice)

IAM governance must cover:

• Enterprise IT (workforce identities, SaaS, core apps)
• Operational technology (OT) and plant/field environments where access paths differ but risk is high
• Third-party access (support vendors, integrators, contractors) as part of the overall access population (your governance should treat these identities explicitly)
• Privileged access (admins, engineering workstations, domain/tenant admins)
• Non-human identities (service accounts, API keys, shared accounts where they still exist)

If these areas run separate “local rules” without a common, approved governance layer, auditors will see fragmentation and inconsistent control operation.

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

Step 1: Set IAM governance ownership and decision rights

Create a simple accountability model and publish it in the IAM policy:

• Policy owner (often CISO, Head of Security, or CIO)
• Process owners for provisioning, access reviews, privileged access, and identity lifecycle
• Risk owner mapping for IAM risks (often business/system owners for application access risks; security for control design risks)
• Approvers (who can approve exceptions, risk acceptance, and compensating controls)

Practical tip: write down who decides when the business wants speed over control (for example, emergency access). That decision must be governed, not improvised.

Step 2: Write (or refresh) the IAM policy as an enforceable document

Minimum policy content auditors expect to see:

• Scope: workforce, third-party, privileged, non-human identities; IT and OT where applicable
• Access principles: least privilege, need-to-know, segregation of duties where relevant
• Identity lifecycle requirements: joiner/mover/leaver, timely removal, role changes
• Authentication requirements: password/MFA rules and where exceptions can exist
• Authorization requirements: approval workflow, system owner responsibility, role design expectations
• Logging/monitoring expectations for access administration and privileged activity
• Exception handling: how to request, approve, time-bound, and review exceptions
• Required reviews: access recertification, privileged access review, and policy review cadence
• Evidence requirements: what artifacts must be retained and where

Your policy must be approved and version-controlled. “Draft in SharePoint” does not count as governance.

Step 3: Build procedures and standards that translate policy into daily work

Policies set direction; procedures run the machine. At minimum, create procedures for:

• Provisioning/deprovisioning workflow (including emergency access)
• Access review execution (who runs, who attests, how removals are tracked)
• Privileged access management administration (vaulting, break-glass, approvals)
• Third-party access onboarding/offboarding and remote access controls
• Service account/API key issuance, rotation, ownership, and decommissioning
• Exception management (including compensating controls and expiry)

Keep procedures operator-friendly: checklists, screenshots, ticket fields, and decision trees.

Step 4: Integrate IAM governance with ERM (make it auditable)

This is the differentiator in ACCESS-2.F. You need explicit linkage between IAM and ERM:

• Define IAM risk categories (examples: excessive privilege, orphaned accounts, weak third-party access controls, unmanaged service accounts).
• Add IAM risks to the risk register with: risk statement, inherent/residual rating (use your ERM method), risk owner, treatment plan, target state, and due dates.
• Connect IAM exceptions to risk acceptance: exceptions should generate a risk entry or formally link to an existing one when they exceed defined tolerance.
• Report IAM governance metrics into your established risk forum (risk committee, security steering committee, ERM working group).

If you can’t show a clean trail from “IAM issue found” → “risk documented” → “decision made” → “treatment tracked,” auditors will call the ERM integration unproven. ¹

Step 5: Prove operating effectiveness with recurring rhythms

Set recurring governance activities and retain evidence:

• Policy review and re-approval
• KPI/KRI reporting (even a simple dashboard) presented to a governance group
• Exception review and expiry enforcement
• Control testing results feeding into ERM updates

Daydream can help here by turning IAM governance into a requirement-to-evidence workflow: map the IAM policy, procedures, and operational tickets to the requirement, then keep version history and recurring evidence in one place so audits are assembly, not archaeology.

Required evidence and artifacts to retain

Auditors typically ask for documents plus proof of use. Build an evidence folder (or system of record) with:

Governance documents

• IAM policy (approved, dated, version history, named owner) ¹
• IAM procedures/standards (same controls: owner, versioning)
• RACI or responsibility matrix for IAM decisions
• Exception/risk acceptance procedure and templates

ERM integration artifacts

• Risk register entries tied to IAM (screenshots/exports acceptable)
• Meeting minutes or agendas showing IAM risk discussed in ERM forums
• Risk acceptance approvals linked to IAM exceptions

Operating artifacts (day-to-day proof)

• Samples of access requests and approvals (tickets/workflows)
• Access review packages: population, reviewer attestation, remediation tracking
• Privileged access logs/reports and approvals for elevated access
• Third-party access onboarding/offboarding records
• Evidence of policy distribution and acknowledgments (if your program requires them)

C2M2 guidance emphasizes retaining version history, approvals, and operating artifacts that show IAM governance is used in day-to-day work. ¹

Common exam/audit questions and hangups

Use these as your pre-audit checklist.

1. “Show me the approved IAM policy and last review.” Hangup: policy exists but no approval record or outdated version.
2. “How do you ensure IAM work follows the policy?” Hangup: procedures aren’t mapped to policy requirements, so operations look ad hoc.
3. “Where is IAM represented in the enterprise risk register?” Hangup: IAM metrics exist, but no ERM linkage or risk ownership.
4. “How are IAM exceptions handled?” Hangup: exceptions live in email, have no expiry, and never become risk decisions.
5. “Who owns access risk: Security or the business?” Hangup: unclear accountability; system owners think IAM is “IT’s problem.”
6. “How do you govern third-party access?” Hangup: third parties bypass standard workflows, especially for emergency support.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails audits	Fix
Policy-only compliance	Document exists, but control operation is inconsistent	Pair policy with procedures, training, and evidence sampling (tickets, reviews).
ERM “checkbox” integration	IAM reported in security metrics but not in ERM	Create risk register entries for IAM themes; route exceptions into risk acceptance. 1
No version control	Can’t prove what standard applied at a point in time	Maintain approval history and versioning for policy and procedures. 1
Undefined exception path	Emergency access becomes permanent access	Require time-bound exceptions, compensating controls, and periodic review with documented approvals.
Ignoring non-human identities	Service accounts become unmanaged backdoors	Make ownership, rotation, and decommissioning explicit in governance procedures.
Third-party access treated as “procurement’s problem”	Offboarding gaps and unclear accountability	Define third-party identity lifecycle steps and evidence requirements under IAM governance.

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list regulator-specific enforcement actions.

Operationally, weak IAM governance creates predictable risk: inconsistent access provisioning, orphaned accounts, excessive privilege, and untracked exceptions. The business impact is usually felt first in incidents and in failed audits or customer due diligence, where you must show a defined operating standard and proof it is followed. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize governance and scope)

• Confirm scope for C2M2 assessment (business unit / OT environment / systems in scope). ¹
• Assign IAM policy owner and process owners; document decision rights.
• Inventory existing IAM documents and evidence sources (IAM tool, ticketing, GRC, PAM, HRIS).
• Draft or refresh IAM policy outline; identify gaps for third-party, privileged, and non-human access.

Days 31–60 (publish policy + wire to ERM)

• Finalize IAM policy and core procedures; route for approval and publish with version history. ¹
• Define IAM risk taxonomy and add initial IAM risks to the risk register with owners and treatment plans.
• Create exception workflow that triggers risk acceptance or risk linkage for material deviations.
• Stand up an IAM governance cadence (monthly metrics review, quarterly access governance review, or aligned to your ERM calendar).

Days 61–90 (prove it runs; prepare audit package)

• Run at least one complete cycle of key operations under the new governance: access review, exception review, and privileged access reporting.
• Collect operating artifacts into an audit-ready pack: policy approvals, procedure versions, sample tickets, review outcomes, ERM linkage.
• Identify control gaps from the first cycle and log them as remediation items tied to risk treatment in ERM.
• If you use Daydream, map IAM governance requirements to evidence requests and schedule recurring collections so the next audit is incremental.

Frequently Asked Questions

What counts as “documented policies” for IAM governance?

An approved IAM policy with scope, mandatory requirements, roles/responsibilities, and a review cadence, plus supporting procedures that teams follow in practice. You also need version history and approval records. ¹

How do I prove IAM is integrated with ERM without building a new risk program?

Use your existing ERM mechanisms: add IAM risks to the risk register, assign risk owners, and document decisions (treatment, acceptance, or transfer). Then show meeting artifacts or reporting that demonstrates IAM risks are reviewed through ERM governance. ¹

Does this requirement apply to third-party access?

Yes in practice, because third-party identities create access risk that must be governed under the same policy framework and lifecycle controls. Your governance should explicitly define onboarding, approvals, monitoring, and offboarding evidence for third parties.

What evidence do auditors usually request first?

The approved IAM policy (with approval history), the access review procedure, and a sample set of access requests showing approvals and removals. They often follow by asking where IAM risks appear in your ERM reporting. ¹

We have IAM tools, but governance is informal. What’s the fastest fix?

Write the policy to match how you operate today, then close the highest-risk gaps with targeted procedures (exceptions, privileged access, third-party access) and start retaining evidence. Tools support the control, but the requirement is governance plus ERM integration. ¹

How detailed should IAM procedures be for audit purposes?

Detailed enough that a new operator can execute them consistently and produce the expected artifacts (tickets, approvals, review outputs). If steps live only in tribal knowledge, audits will flag inconsistent operation.

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