Control 2-2-4 of the Essential Cybersecurity Controls (ECC – 2 : 2024) requires organizations to perform periodic reviews of identity and access management (IAM) entitlements and to demonstrate those reviews through measurable metrics; integrating those metrics into your security program turns a checklist exercise into an operational risk-control that can be tracked, reported, and improved over time.
Key metrics to collect and why they matter
Start by defining a small, measurable set of IAM review metrics tied directly to risk and auditability: percentage of accounts reviewed (by category), percentage of privileged accounts with multi-factor authentication (MFA), number of orphaned or stale accounts, entitlement creep rate (percentage change in high-risk entitlements over time), percent of reviews completed on time, average remediation time for access removals or adjustments, and number of approved exceptions. These metrics give you both coverage (who was reviewed) and quality (how fast issues were fixed and whether controls like MFA are enforced).
Implementation steps specific to Compliance Framework
Under the Compliance Framework practice model, translate Control 2-2-4 into an executable process: (1) define scope and owner (business owners for each application/service), (2) classify accounts (privileged, service, user, contractor), (3) set review cadence based on classification (monthly for privileged, quarterly for service-critical, annual for low-risk), (4) automate evidence collection from identity sources, (5) run reviews and capture attestations, (6) track remediation tickets and SLAs, and (7) push metrics to your security metrics register and risk dashboard. Document each step in your control library and attach evidence links (review artifacts, screenshots, ticket IDs) to meet audit expectations.
Real-world small-business scenario
Example — a 50-employee SaaS startup using Microsoft 365, AWS, and a single AD/Okta instance: classify 4 executives and 3 cloud admins as privileged (monthly review), all full-time employees as standard (quarterly), and contractors (90-day cadence). Use Okta reports and the Azure AD sign-in logs to generate membership and last-login lists. Route review results to the relevant team lead; create remediation tickets in a shared Jira project with SLA tags (critical: 7 days, normal: 30 days). For the small shop, aim initially for 100% of privileged accounts reviewed monthly and 90% of standard accounts quarterly; track percent complete and average remediation time to show progress against ECC 2-2-4.
Technical examples and automation recipes
Practical automation reduces manual effort and strengthens evidence. Examples: for AWS, generate and retrieve a credential report with "aws iam generate-credential-report" and "aws iam get-credential-report --query 'Content' --output text | base64 -d > credential-report.csv" to find unused console keys, access keys older than 90 days, and service account status. For on-prem AD, a PowerShell query to find last logon inactivity: Get-ADUser -Filter {Enabled -eq $true} -Properties LastLogonTimeStamp | Where-Object {([DateTime]::FromFileTime($_.LastLogonTimeStamp) -lt (Get-Date).AddDays(-90))} | Select SamAccountName,LastLogonTimeStamp. For Azure AD via MS Graph/PowerShell you can use Get-AzureADAuditSignInLogs and Get-AzureADUser to compute last sign-in and then feed results to a review workflow. Build a small script to produce CSVs that are attached to review tickets; store them in immutable evidence buckets (S3 with WORM or SharePoint with versioning) to satisfy auditors.
Dashboards, thresholds, and remediation SLAs
Create a dashboard (Grafana, Kibana, or your GRC tool) showing: % of required reviews completed this period, % privileged accounts with MFA, number of orphaned accounts, mean time to remediate, and backlog of exceptions. Set targets that are realistic and risk-based: privileged review completion 100% monthly, MFA on privileged 100%, orphaned accounts 0, average remediation < 7 days for critical fixes. Use these thresholds in your risk register so that metric breaches automatically trigger escalation paths (security manager review, CISO briefing, or board reporting depending on severity).
Risks of not implementing IAM periodic review metrics
Without measurable periodic IAM reviews you increase the risk of credential misuse, privilege escalation, undetected orphaned accounts, and non-compliance findings in an audit. For a small business, this often translates to a single compromised but over-entitled account leading to a data breach, business disruption, or regulatory fines. Auditors and assessors will ask for evidence of periodic review; lacking metrics reduces your ability to prove control effectiveness and prolongs remediation cycles.
Compliance tips and best practices
Keep these practical tips in your Compliance Framework playbook: tie account lifecycle to HR events for automated deprovisioning; require business-owner attestation rather than security-only approval; implement temporary (time-bound) access for elevated roles; use PAM/just-in-time access for administrators; maintain an exceptions log with expiration and re-review; automate evidence capture (CSV exports, tickets, attestation confirmations) and store hashes of reports for tamper evidence; and incorporate IAM metrics into your quarterly compliance reporting. For small teams, start with scripted exports and simple dashboards before investing in full IGA tools.
Summary: Integrating IAM periodic review metrics into your security program for ECC 2-2-4 means defining risk-based review cadences, automating evidence collection, tracking a focused set of KPIs (coverage, quality, remediation), and embedding those KPIs into your Compliance Framework workflows and dashboards. By doing so you turn periodic access reviews from a checkbox into a demonstrable, auditable control that materially reduces access risk and proves compliance during assessments.
