Provisioning vs governance: where most teams lose control

Most access programs are really two programs wearing one name. One is about deciding who should have access and being able to prove those decisions later. The other is about making the access actually happen — correctly, across every system, every time something changes. Teams that treat these as a single problem tend to invest in one and quietly assume they have covered the other. The space between them is where control leaks out.

Two jobs that get treated as one

Governance is the decision layer. It answers who should have access to what, on what basis, approved by whom, and reviewed on what cadence — and it holds the evidence that those answers were real. Governance is where policy, ownership, approvals, and reviews live. Its output is not a change to a system; its output is a defensible decision and a durable record of it.

Provisioning is the execution layer. It takes a decision that has already been made and turns it into concrete state on real systems: an account created, an entitlement added, a title updated, access revoked. Provisioning is judged on reliability — did the intended change actually land, everywhere it was supposed to, without duplicates, drift, or half-finished operations.

The two blur together because a healthy access change touches both in the same breath: someone decides, and then something happens. But they fail in completely different ways. Governance fails quietly, as decisions no one can reconstruct and access no one can account for. Provisioning fails loudly, as broken onboarding, duplicate accounts, and revocations that never fully landed. A tool that is excellent at one is not automatically competent at the other, and most teams find out which half they were missing at the worst possible moment — usually an audit, or an incident.

Where teams lose control in the lifecycle

Walk the identity lifecycle — joiner, mover, leaver — and the seams show up in the same places for almost everyone.

Joining. A new hire needs a dozen systems on day one. If the request lives in a ticket queue and the approval lives in a chat thread, the decision and its rationale are already scattered before anything is provisioned. When fulfillment is a person copying settings by hand across systems, small inconsistencies creep in — the right group here, the wrong role there — and no one notices until something breaks or an auditor asks how that access was granted.

Moving. This is the stage most programs underserve. A title, department, or manager changes in the HR system and never reaches the downstream accounts that depend on it. Meanwhile access accumulates: people pick up entitlements with each new project and rarely shed the old ones. Nothing is obviously broken, so nothing gets fixed — and least privilege erodes one quiet grant at a time.

Leaving. Offboarding is where the two layers most visibly come apart. The decision is unambiguous — this person is gone — but the execution is spread across every system that was ever granted. A single missed revocation is a standing risk that no dashboard will surface on its own, and the person who would have caught it has already moved on to the next ticket.

Drift, underneath all three. External state diverges from intent constantly. Someone grants access directly in a downstream admin console. A retry half-applies a change. A system is restored from a backup that predates a revocation. Without something actively comparing reality against intent, drift stays invisible until an incident or an audit makes it visible the hard way.

The common thread is that control is lost at the seam between deciding and doing. A decision with no reliable execution is a good intention. Execution with no recorded decision is unaccountable change. Neither one, on its own, is control.

An ownership and accountability model

The fix starts by keeping two questions separate. “Should this happen?” is a governance question, and it belongs with the people who understand the business context — the resource owner, the requester’s manager, the security or compliance function. “Did it happen correctly, everywhere?” is an execution question, and it belongs with the platform or IT team that operates the plumbing. Blur the two and accountability blurs with them: when access is wrong, no one can say whether the decision was bad or the fulfillment was.

A workable model names owners on both sides:

• Every resource and entitlement has a named owner who is accountable for the decision to grant it.
• Approval logic is written down as policy, not improvised per request, so the same situation is decided the same way twice.
• Fulfillment reliability is owned as an operational concern, with clear signals when an operation fails or stalls, rather than assumed to have worked.
• Every exception has an owner and an expiry — not a permanent carve-out that outlives the reason it was granted.

This is also why sequencing matters. Start with the governance logic — who owns what, what gets approved by whom, what the review cadence is — and then automate fulfillment underneath it. Automating fulfillment first only makes it faster to grant access you cannot account for. Speed on top of an unclear decision model is just faster loss of control.

Decision paths and evidence capture

The most expensive audit is the one where the evidence has to be reconstructed after the fact — screenshots assembled, ticket histories exported, people asked to remember why someone was granted something eighteen months ago. Evidence should be a byproduct of the workflow, not a project you run every quarter.

For every access change, you want a durable answer to a short list of questions: who requested it, who approved it and on what basis, what policy applied, when it was fulfilled, what was actually applied to which system, and when it was later reviewed or revoked. If those facts are captured as the work happens — attached to the request, the approval, the operation, and the review — then audit readiness becomes a query instead of a scramble.

Two habits carry most of the weight.

Tie every lifecycle event to evidence. A grant, an attribute change, and a revocation should each leave a record that stands on its own. The goal is not a log for its own sake; it is that any single access fact can be traced back to the decision that produced it and the operation that applied it, without anyone having to remember.

Document exceptions instead of hiding them. Break-glass access and one-off grants are legitimate — pretending they do not happen is what makes them dangerous. Record the exception, give it an owner, and give it an expiry so it cannot quietly become permanent. A well-documented exception is stronger evidence of control than a policy that claims to have none, because it shows the process met reality and handled it on the record.

How Owlie closes the gaps

Owlie is built around exactly this separation: a decision layer and an execution layer that stay distinct but reference the same objects.

Everything resolves against one shared model — identities, resources, entitlements, and assignments — so a decision and its fulfillment are talking about the same thing rather than two disconnected inventories. A resource can be anything you grant: a SaaS app, a repository, a database role, a laptop order, a data room. Each carries its own request form, approval flow, and fulfillment path, so governance takes the shape of your business instead of forcing your business into a fixed set of screens.

The decision layer runs through requests, approval workflows, and access reviews. Approval steps can carry custom logic where a plain rule is not enough. Reviews turn existing grants into review work and produce audit-ready evidence as reviewers certify or revoke — evidence generated by the workflow, not compiled afterward.

The execution layer runs through intent-based, versioned provisioning. You describe the desired state; Owlie computes the minimal set of steps to reach it and drives them to a concrete end state on the target systems. Each assignment tracks a desired version and an applied version, so overlapping changes converge deterministically instead of racing, and recovering a stuck operation is a single safe retry rather than a manual reset. Manual fulfillment — a ticket to a person or team for the systems that cannot or should not be automated — runs through the same pipeline, with the same versioning, the same step-by-step journal, and the same audit trail as automated connector work. No second-class escape hatch for the systems that resist automation.

Sync closes the drift gap by verifying reality against intent rather than blindly importing inventory. When observed state and intended state diverge, that difference becomes a signal you can act on. And records that Owlie provisioned are marked stale rather than deleted when a sync run does not see them, so a sync gap does not silently wipe access Owlie was managing.

Evidence is a property of the engine, not a reporting add-on. Every provisioning attempt writes a per-step journal — what was tried, what succeeded, what failed and why — and records a snapshot of the applied state alongside the version that produced it. Specific attributes can be kept in sync to the downstream accounts as an identity changes, closing the mover gap for the fields you mark, and temporary access can carry an automatic expiry so it does not outlive the reason it was granted.

Because these are composable building blocks rather than one fixed workflow, the same primitives cover the decision and the execution without a suite rollout to stitch them together.

Where to start

If you take three things from this:

• Start with governance logic, then automate fulfillment. Decide who owns what, and what gets approved by whom, before you make granting faster.
• Keep every lifecycle event tied to evidence. Capture the decision and the applied change as the work happens, so audit readiness is a query rather than a reconstruction.
• Document exceptions instead of hiding them. Give each one an owner and an expiry; a recorded exception is a sign the process works, not that it failed.

Provisioning without governance is fast, unaccountable change. Governance without reliable provisioning is a policy no one can be sure was enforced. The teams that keep control are the ones that treat them as two connected jobs — and wire the connection so the evidence takes care of itself.