Access Granting and Revoking

Access control failures remain a leading cause of security breaches and compliance violations. The C2M2 ACCESS-2.B requirement mandates that organizations implement structured processes for granting and revoking access to both IT and OT assets. This goes beyond basic user account creation—it requires you to establish defined criteria, approval workflows, and timely deprovisioning procedures.

Many organizations struggle with this requirement because access management spans multiple systems, involves various stakeholders, and requires coordination between HR, IT, and business units. Manual processes lead to orphaned accounts, excessive privileges, and audit findings. The key is building repeatable workflows that balance security with operational efficiency while maintaining complete documentation for compliance verification.

Regulatory text

The C2M2 v2.1 ACCESS-2.B requirement states: "Access to IT and OT assets is granted and revoked based on defined requirements."

This mandates that your organization cannot grant access arbitrarily or leave it to informal decisions. You must document specific criteria for who gets access to what systems, establish formal approval processes, and ensure access is removed when no longer needed. The requirement applies equally to information technology (IT) and operational technology (OT) environments.

Plain-English Interpretation

You need written rules about who can access your systems and data. When someone needs access, there must be a formal request and approval process. When they no longer need it—because they changed roles, left the company, or completed a project—you must remove that access promptly. Every access decision needs documentation showing the business reason.

This isn't just about creating user accounts. It covers all forms of access: network permissions, application privileges, database rights, physical access to server rooms, and remote connectivity. The emphasis on "defined requirements" means you can't make access decisions case-by-case without consistent criteria.

Who This Applies To

Entity Context:

• Energy sector organizations ¹
• Critical infrastructure operators
• Any organization with significant IT/OT integration
• Companies with regulatory compliance obligations requiring access control

Operational Context:

• IT administrators managing user accounts
• OT engineers controlling industrial system access
• Security teams overseeing access governance
• HR departments triggering joiners/movers/leavers processes
• Business managers approving access requests

Step-by-Step Implementation

1. Document Access Requirements

Create written policies defining:

• Job roles and their standard access needs
• Criteria for granting privileged access
• Requirements for temporary/contractor access
• Emergency access procedures
• Cross-system access dependencies

2. Design Request Workflows

Build formal processes for:

• New employee onboarding access
• Role change access modifications
• Project-based temporary access
• Privileged access elevation
• Third-party/vendor access requests

Each workflow needs:

• Request forms capturing business justification
• Defined approvers (manager + data owner minimum)
• SLA commitments for processing
• Escalation paths for urgent requests

3. Implement Approval Controls

• Two-person rule: Requester cannot self-approve
• Data owner approval: System/data owners must approve access to their resources
• Risk-based approval: Higher privileges require additional approvals
• Documented criteria: Approvers reference written requirements, not personal judgment

4. Automate Provisioning

Manual account creation leads to errors and delays. Implement:

• Identity management systems that provision based on approved requests
• Role-based access control (RBAC) for standard permissions
• Integration with HR systems for automated onboarding
• Self-service portals for common access requests

5. Establish Revocation Triggers

Access must be revoked when:

• Employment terminates (same day)
• Role changes eliminate need (within 24 hours)
• Project completes ²
• Policy violations occur (immediately)
• Periodic access reviews identify stale accounts

6. Create Audit Trails

Document every access decision:

• Request details and business justification
• Approver names and timestamps
• Provisioning completion confirmation
• Revocation actions and timing
• Any deviations from standard process

Required Evidence and Artifacts

Auditors will request:

Policies and Procedures:

• Access management policy with defined requirements
• Detailed workflows for granting/revoking access
• Approval matrices by system and privilege level
• Emergency access procedures

Operational Records:

• Access request forms/tickets for sample periods
• Approval documentation showing proper authorization
• Provisioning logs confirming access was granted as approved
• Deprovisioning evidence for terminated employees
• Access review reports and remediation actions

System Configurations:

• Identity management system settings
• RBAC role definitions and assignments
• Integration points with HR systems
• Automated deprovisioning rules

Metrics and Reporting:

• Time-to-provision metrics
• Orphaned account discovery reports
• Failed access review rates
• Policy exception tracking

Common Exam Questions and Hangups

Typical Auditor Questions:

1. "Show me your access granting criteria for privileged accounts"
2. "Provide evidence that all terminated employees from last quarter had access revoked timely"
3. "How do you ensure approvers understand what they're approving?"
4. "Walk me through a recent emergency access grant"

Common Findings:

• Generic justifications: "Needs access to do job" isn't specific enough
• Self-approval: Requesters approving their own access
• Delayed revocation: Access lingering days/weeks after termination
• Undocumented emergency access: Granting access first, documenting later
• Missing OT coverage: Focusing on IT while ignoring industrial systems

Examiner Focal Points:

• Termination to revocation timing (same-day expected)
• Privileged access approval rigor
• Consistency between policy and practice
• OT environments often have weaker controls

Implementation Mistakes to Avoid

1. Over-Relying on Manual Processes

Problem: Tracking access via spreadsheets and email approvals. Solution: Even basic ticketing systems provide better audit trails than email. Invest in identity management for organizations over 500 users.

2. Vague Access Requirements

Problem: Policies saying "appropriate access based on job needs." Solution: Define specific access profiles for each role. List exact systems, applications, and permission levels.

3. Ignoring Service Accounts

Problem: Focusing on human users while service accounts proliferate unchecked. Solution: Apply same rigor to non-human accounts. Document ownership, purpose, and review cycles.

4. Informal OT Access

Problem: Plant engineers sharing credentials or granting access verbally. Solution: OT access needs same formal workflows as IT. No shared accounts, no verbal approvals.

5. Retroactive Documentation

Problem: Granting emergency access first, creating paperwork later. Solution: Define true emergencies narrowly. Even emergency access needs same-day documentation.

Risk and Enforcement Context

While C2M2 itself isn't a regulation with monetary penalties, it's increasingly referenced in:

• NERC CIP compliance for bulk electric systems
• TSA Security Directives for pipeline operators
• State-level critical infrastructure requirements

Poor access control directly enables insider threats and external breaches. In OT environments, inappropriate access can lead to safety incidents beyond just data loss.

Organizations with mature access controls report:

• Fewer audit findings across all frameworks
• Reduced insider threat incidents
• Faster onboarding for new employees
• Lower IT support burden from access requests

30/60/90-Day Execution Plan

Immediate (Days 1-30)

• Document current access granting/revoking practices
• Identify all systems requiring access control
• Create inventory of approval authorities by system
• Review last 90 days of terminations for access removal evidence
• Draft access management policy if none exists

Near-term (Days 31-60)

• Design standardized request forms/workflows
• Define role-based access profiles for common positions
• Implement ticketing for access requests if using email
• Train approvers on new documentation requirements
• Begin daily termination-to-revocation reconciliation

Ongoing (Days 61-90)

• Deploy identity management tool or enhance existing
• Integrate HR system for automated triggers
• Conduct first quarterly access review
• Refine approval matrices based on operations
• Establish monthly access metrics reporting

Frequently Asked Questions

What's the difference between IT and OT access requirements under this control?

While the core requirement applies equally, OT environments often have unique constraints like shift-based access, safety-critical permissions, and legacy systems that don't integrate with identity management platforms. Document these differences but apply the same rigor.

How quickly must we revoke access after termination?

C2M2 doesn't specify exact timeframes, but industry standard is same-business-day for terminations and 24-48 hours for role changes. High-privilege accounts should be disabled immediately upon termination notice.

Can managers approve their own access requests if they're also the data owner?

No. Even if someone serves multiple roles, segregation of duties requires a different person to approve access. Establish a peer review or escalation process for these scenarios.

Do we need to document access for contractors differently than employees?

Yes. Contractor access typically needs additional fields like contract end date, sponsoring employee, and company affiliation. Many organizations require quarterly revalidation for all contractor access.

What if our legacy OT systems only support shared accounts?

Document this as a compensating control gap. Implement additional monitoring, logging, and physical access controls. Create a roadmap for migrating to systems supporting individual authentication.

How do we handle emergency access needs outside business hours?

Define true emergencies narrowly (system outages, safety events). Create on-call approval chains. Allow temporary access with next-business-day documentation. Log all emergency access for review.

Footnotes

1. C2M2 framework focus

2. Cybersecurity Capability Maturity Model v2.1