How We Stood Up Audit-Ready Identity Governance for a Healthcare Organization Without an Enterprise IAM Platform

The situation

A mid-market healthcare organization needed governance over user access across roughly a dozen business applications. Compliance obligations required documented, auditable joiner, mover, and leaver (JML) processes, and an audit was already on the calendar.

Internal budget could not absorb the per-seat licensing and implementation cost of an enterprise IAM platform such as SailPoint, Saviynt, or Okta Identity Governance. The choice on the table looked binary: write a check the organization could not afford, or keep limping along with a binder-driven manual process that would no longer survive an auditor's questions.

ExeQut was asked to find a third path. Deliver a defensible governance posture now, without locking the client into a custom-built dead end.

Compliance pressure does not respect budget cycles.

The challenge

The team had to solve five problems in parallel:

1. JML workflows lived in email threads and ad hoc ticket requests, with no consistent system of record.
2. Approvals were often verbal, and rarely captured in a form an auditor would accept.
3. Terminated employees occasionally retained access for days or weeks after departure.
4. Role definitions lived in spreadsheets that drifted from operational reality.
5. The upcoming audit required documented evidence of approvals, segregation of duties, and timely deprovisioning, none of which were available.

The approach

ExeQut proposed a two-phase strategy rather than a forced enterprise purchase. Phase one: build a custom, role-based JML application sized to the client's budget that would deliver governance and audit posture immediately. Phase two: design that application as a stepping stone, deliberately capturing the role catalog, approval workflows, integration map, and audit data needed to onboard an enterprise IAM platform cleanly when budget allowed.

That framing protected two things at once: the client's near-term audit posture, and the future investment in automated IGA whenever the budget arrived.

The operating model

A 3.5-FTE senior delivery team ran the engagement over six months to production. An ExeQut engagement lead owned client-facing delivery and governance. A tech lead and architect owned the technical direction. An IAM and security SME owned role catalog design, segregation-of-duties policy, and audit evidence requirements. A full-stack engineer built against a tightly scoped backlog.

Cadence was deliberately simple. Weekly working sessions with the client's compliance lead, HR, and IT operations kept the workflow tied to real organizational behavior, not theoretical access policy. Decisions, scope changes, and policy interpretations were captured in a decision log that doubled as audit-ready documentation later.

The technical architecture call

The team chose a React single-page application backed by a Spring Boot REST service and an append-only audit data model. The architecture was kept deliberately small: small enough to reason about, small enough to harden, and small enough to operate without a dedicated platform team.

The most consequential architectural decision was treating the audit log as a first-class output of every business workflow, not a side effect. Every request, approval, denial, comment, and downstream close-out is written as an immutable, timestamped row inside the same transaction as the underlying state change. There is no "reconstruction" path, because there is nothing to reconstruct.

Every approval was named. Every action was timestamped. Every change was reviewable.

Key infrastructure decisions

The application runs entirely in the client's existing AWS footprint, with no per-seat licensing on the governance layer itself.

• SPA hosting: The React front end is served from Amazon S3 behind Amazon CloudFront, with TLS terminated at the edge.
• Application tier: The Spring Boot REST service runs on Amazon ECS with Fargate, behind an Application Load Balancer. Stateless containers, autoscaling on CPU and request volume, no servers to patch.
• Data tier: Amazon RDS for PostgreSQL holds the role catalog, workflow state, and the append-only audit tables. Storage and snapshots are encrypted at rest with AWS KMS, with automated backups and point-in-time recovery enabled.
• Identity: The application federates to the client's existing identity provider over OpenID Connect, so end users sign in with the same credentials and MFA posture they already use. The JML application itself never owns a password.
• Observability: Application and load balancer logs land in Amazon CloudWatch, with audit-grade events also persisted to immutable database tables that auditors can query directly.

Workflow design

Each JML workflow was modeled against how the organization actually operates, not how a generic IGA template would expect it to operate.

• Joiner. A hiring manager initiates a request, selects roles from the catalog, and the system routes approvers automatically based on the role definition. Once approved, structured downstream tasks are generated for each affected system owner.
• Mover. Role change requests display a diff of access added and removed before any approver clicks accept. Dual approval is enforced where policy requires it, particularly for segregation-of-duties sensitive combinations.
• Leaver. HR triggers a termination flow that generates time-bound deprovisioning tasks for every system the employee touched, and requires named attestation of completion from each system owner.
• Downstream tasks. Each provisioning action produces a ticket to the relevant system owner (helpdesk queue or shared inbox) for execution, with completion logged back into the application. Where automation was not yet possible, the application made the manual work visible, measurable, and auditable.
• Access reviews. Scheduled certification campaigns surface each direct report's current access to their manager for confirm or revoke decisions, with full audit history retained.
• Internal RBAC. The application's own access model separates requesters, approvers, system owners, and administrators, so the governance tool is itself governed.

Deployment and release

The application is delivered through an automated pipeline. Code changes flow through review, unit and integration tests, container image builds, and infrastructure-as-code deployments to a staging environment before any production rollout. Releases are small, frequent, and reversible. Database schema changes are managed with forward-only migrations, so the audit history is never rewritten.

The application is a bridge, not a destination.

The outcome

The application shipped, the audit was met, and the client's compliance posture moved from "we will get to it" to "we can prove it."

The headline results:

• Zero audit findings on JML evidence.
• Leaver deprovisioning SLA collapsed from days to same day.
• 100% of access changes carry a named approver and a timestamp.
• Six figures avoided in enterprise IGA licensing in year one.

Beyond the numbers, the application is now the system of record for who has access to what, and why. ExeQut continues to support the platform under a steady-state engagement, with the role catalog and integration map maturing in step with the organization's operations.

Designed to graduate

By design, the application produces exactly the inputs that a future enterprise IAM platform investment needs to succeed:

• A clean, versioned role catalog ready to import into SailPoint, Saviynt, or Okta Identity Governance.
• Documented approval workflows that map cleanly to standard IGA constructs.
• A catalog of target systems with integration points, ownership, and provisioning patterns.
• Historical audit data that demonstrates baseline behavior and supports policy tuning at go-live.
• Quantified manual provisioning effort that builds an evidence-backed ROI case for automation.

When budget allows, the client can move from manual downstream tasks to automated connectors with continuity of policy, role definitions, and audit history intact. The work done today compounds into the platform tomorrow.

What we took from it

A few lessons from this engagement that travel well to other regulated, budget-constrained environments:

1. Audit posture is a product feature, not a reporting afterthought. Writing the audit log inside the same transaction as the business action is the difference between evidence and best-effort reconstruction.
2. Right-size the platform to the organization, not the category. A small, well-designed application can deliver real governance long before an enterprise platform is affordable, provided it is built to graduate cleanly.
3. Make the manual work visible before you try to automate it. Quantifying the volume and shape of manual provisioning is the cheapest way to build the ROI case for a future IGA investment.
4. Treat the role catalog as the durable artifact. Code and infrastructure get replaced; a clean, owned, versioned role catalog is what carries forward into whatever platform comes next.
5. Put compliance and engineering in the same room. Weekly working sessions with the compliance lead, HR, and IT operations kept the workflow honest, and produced documentation auditors actually accepted.