6.7 IAM Case Lab

Scenario: Meridian Health Analytics IAM Review

Meridian Health Analytics is a mid-sized company that processes clinical quality data for hospitals. It has 1,800 employees, 400 contractors, several SaaS platforms, a hybrid directory, and cloud analytics workloads. The company grew through two acquisitions, and access processes vary by business unit. Leadership asks for an IAM review after a contractor account was used to download sensitive reports two months after the contract ended.

The incident investigation finds several contributing causes. HR tracked employees but not all contractors. Application owners approved access by email, and those messages were not tied to expiration dates. Some SaaS applications used SSO, but others had local accounts. Cloud administrators shared a legacy emergency account during outages. Data warehouse roles were broad because analysts moved between projects quickly. Badge access was removed manually and sometimes lagged account disablement.

A narrow technical response would reset passwords and close the contractor account. That is not enough. The CISSP response is to identify control failures across the IAM lifecycle. Identity proofing was inconsistent for contractors. Authorization was too broad in the data warehouse. Accountability was weak for shared cloud administration. Deprovisioning was incomplete. Federation coverage was uneven. Access reviews were not evidence driven.

Initial Risk Register

The first recommendation is to establish an authoritative identity lifecycle. Employees come from HR. Contractors come from a vendor or sponsor system with named business sponsors, start dates, end dates, and required recertification. Workloads come from approved deployment pipelines or cloud inventory. Every identity must have an owner and a termination condition. This creates the foundation for provisioning, deprovisioning, and review.

The second recommendation is to redesign access around least privilege. Analysts should not receive broad access to all hospital data because projects change. A better design uses baseline analyst access plus project-specific access approved by data owners, with expiration aligned to the project. Sensitive exports require logging and possibly step-up authentication. Unused project access is removed during reviews.

The third recommendation is to expand federation and central session control. SaaS applications should be inventoried, assigned owners, and categorized by data sensitivity. High-risk SaaS applications should use SSO, MFA, role mapping, and automated deprovisioning where supported. Local accounts should be exceptions with compensating review and a remediation date. The team should test whether disabling a central identity actually blocks active sessions and downstream access.

The fourth recommendation is to implement privileged access management for administrators. Cloud admins should use unique privileged identities separate from daily accounts. Standing global administrator rights should be reduced. Elevation should be time limited, approved or policy driven, and logged. Break-glass access should remain available for outages but be protected, alerted, and reviewed after use. Shared emergency accounts should not be normal operating procedure.

The fifth recommendation is to connect physical and logical lifecycle steps. A leaver workflow should disable directory access, revoke sessions, remove SaaS access, collect devices, recover badges, terminate VPN, rotate exposed shared secrets, and preserve evidence. High-risk departures require coordination before notification. Routine contractor endings should be driven by end dates so access does not depend on someone remembering to file a ticket.

90-Day Remediation Plan

1. Build an application, identity, and entitlement inventory for the systems that store or process sensitive data.
2. Create a contractor identity source with sponsor ownership, end dates, and automated disablement triggers.
3. Move priority SaaS applications to SSO with MFA, owner-approved role mapping, and tested deprovisioning.
4. Replace shared cloud administration with unique privileged accounts, PAM workflows, and monitored break-glass access.
5. Redesign data warehouse roles around projects, data owner approval, expiration, and separation of duties.
6. Run a targeted access review for contractors, privileged users, broad analyst roles, and local SaaS accounts.
7. Report metrics to leadership: stale accounts removed, privileged accounts reduced, applications federated, and review remediation completed.

A good executive message avoids technical overload but keeps risk concrete. Meridian is not simply missing a tool. It lacks consistent lifecycle governance across human, contractor, cloud, SaaS, and physical access. The organization should invest first where the incident showed direct risk: contractor deprovisioning, sensitive data authorization, federation coverage, privileged access, and review evidence.

The case also shows why least privilege must be practical. If analysts genuinely move between projects quickly, the access process must be fast enough to support work. That may mean preapproved project roles, data owner workflows, and automated expiration. If the process is too slow, users will pressure managers into broad permanent access. Security governance should make the right path efficient and auditable.

Finally, Meridian should define residual risk and exceptions. Some legacy SaaS platforms may not support automated deprovisioning. Some emergency access may be required during identity provider outages. Some badge systems may need manual integration. Each exception should have an owner, expiration, compensating control, and remediation plan. A risk-aware IAM program does not pretend every issue is fixed immediately; it makes accepted risk explicit and managed.