The Last Mile of Identity Governance

About the Organization#

A multi-state regional bank in the United States, serving retail and commercial customers through several hundred local branches and a fleet of kiosk and off-premise ATMs. Supervised by federal and state banking regulators.

Industry: Banking

Employees: 11,500

3rd Party Identities: 17,300

Non-Human Identities: 28,500

Why This Matters in Financial Services#

Over a thousand applications sit in the CMDB and not in the governance platform. Until an application is onboarded it stays outside the reviews that platform runs, so the number that matters is not how many applications are governed. It is how many are still missing.

Each of those applications carries an application owner, a technical manager, and an executive owner. Thousands of production service accounts sit in Active Directory, spread across hundreds of owners. Application-local accounts live inside applications rather than the directory, with no inventory at all. Service accounts are already vaulted in the privileged access platform, with password rotation held back until the bank knows what each account touches.

Closing that gap is the last mile of identity governance, and it is not a technology problem. The platform is bought. The policy is written. The program is stalled because the data it runs on lives in the heads of several hundred people who have other jobs. This is the identity execution gap in its least glamorous form, and it is the gap Alex was brought in to close.

Four Core Problems#

1. The answer lives in someone else’s head. Onboarding an application to the governance platform starts with a template: what the application is, what risk tier it belongs to, what entitlements it carries, and what each of those entitlements actually means. No system in the stack holds that answer.

2. A process on paper, a chase in practice. The template goes out and nothing comes back. Someone follows up, then follows up again. Answers arrive partial, and the clarifying questions start a second round. The whole thing rests on one person’s persistence, and that person’s actual job is running the identity program.

3. Rotation blocked on unknown dependencies. Service accounts are vaulted, but rotation cannot be switched on until someone knows what each account runs, what it connects to, and what breaks when the password changes.

4. Ownership that decays. An account correlated to a person loses its owner when that person leaves. Application-local accounts cannot even be listed without asking every owner what they have.

The Solution#

How Alex Runs It#

1. Take the list and the questionnaire. The bank supplies the applications or service accounts, their owners, and the questionnaire it already uses. No connection to the governance platform is required to start.

2. Open the conversation. Alex starts a one to one Microsoft Teams conversation with each owner and asks for what the template needs.

3. Validate in the conversation. Alex checks answers as they arrive and re-asks what is missing, rather than accepting an incomplete form and handing the gap back to the identity team.

4. Nudge, then escalate. Alex follows up on a cadence the bank sets and escalates to the owner’s manager when an owner goes quiet.

5. Hand back structure. Alex returns the completed information in the agreed format, with a status view of which owners are done and which are outstanding.

The Bank Stayed in Control#

The bank’s security team never asked whether to allow this. It asked how tightly it could be bounded. Four answers carried the review.

An explicit allow list. Alex talks only to named owners. The restriction is enforced deterministically on Twine’s side rather than by the model, so Alex cannot message anyone outside the list even where the Teams app is deployed broadly.

Customer-hosted models. The language models run in the bank’s own cloud account. Twine consumes them as they are and never trains them on the bank’s data.

No write-back. Nothing is written to the governance or privileged access platform during the pilot. Alex collects and returns; the identity team reviews and enters.

Traceable by default. Every conversation and every piece of collected information is attributable to an owner and a request, so the output is reviewable rather than asserted.

Twine holds SOC 2 Type 2, ISO 27001:2022, and ISO 42001.

What It Did#

The bank set four questions before it started. Three of them now have numbers against them.

Do owners answer a digital employee in Teams? 87 percent of application owners responded to Alex.

Does onboarding throughput move? Applications went from one onboarded every six weeks to three a week.

Does it unblock the work downstream? Ownership was confirmed on 75 percent of service accounts, clearing the way for privileged access password rotation.

Does the pattern hold at full scale? Still open. The population runs past a thousand applications and roughly 300 application owners across the business units, and the bank is expanding scope from there.

Scope This in Your Own Environment#

Five questions. If you can answer them, you have a pilot.

1. Which collection is blocking you? Application onboarding, service account dependencies, local account inventory, entitlement descriptions, or ownership attestation. Pick one and count the owners involved.

2. Where is the list? You need the population and an owner for each. An export from the governance platform or the CMDB is enough. No integration is required to start.

3. What does answered mean? Write down the minimum fields you actually need to move. Most teams find it is four or five, not the forty on the template.

4. Who escalates to whom? Escalation only works if you can supply each owner’s manager. If you cannot, fix that first; it is the step that breaks the silence.

5. What is the allow list? Name the owners in scope. That list is the boundary the pilot runs inside, and it is the first thing your security team will ask for.