All Posts

When the Person You Trusted Most Isn't There Anymore

Most community banks and credit unions I talk with have IT support in place with a managed service provider, an internal IT contact, or some combination of both. On paper, they're covered.

The question I find myself asking, as someone who has spent years working alongside financial institutions, isn't whether they have someone. It's what their institution actually knows without that person.

Not the systems. But the context. The reasons. The relationships and processes built over years that exist primarily in one person's memory.

The person every institution has

In almost every community financial institution I've encountered, there's someone who has become the center of gravity for IT over time. They know why the network is configured the way it is. They remember the vendor decision made eight years ago and the reasoning behind it. They've built relationships with third-party providers that aren't documented anywhere. They've kept things running through staff changes, technology shifts, and regulatory updates, and they've done it pretty well.

That's not a problem. That's exactly what a trusted, long-tenured person does.

The quiet question is what happens to everything they know when they're no longer there to know it.

What key person risk looks like in community banking IT

Key person risk in community banking IT is the concentration of critical institutional knowledge, like vendor relationships, configuration decisions, undocumented processes, and operational history, in a single individual.

The risk isn't bad systems or weak security. It's the accumulated context that exists in one person's head rather than in documented, transferable processes. A bank can have excellent technology in place and still carry significant key person risk if the knowledge of how that technology was built, why decisions were made, and how relationships were established lives primarily with one person.

When that person transitions out, whether through retirement, a career change, or an unexpected departure, the institution discovers what it actually knew versus what it assumed it knew. The gap between those two things is often significant.

What typically surfaces:

Vendor relationships the incoming person has to rebuild from scratch.
Configuration decisions that made sense at the time but aren't documented anywhere.
Workarounds that exist for reasons nobody remembers.
Institutional history that the previous person carried without anyone realizing it.

None of this reflects poor planning. It reflects the natural accumulation of expertise in a trusted person over a long period of time. It happens at well-run institutions as consistently as anywhere else.

The coverage assumption

Here's where I find community banking leaders most often have a quiet question they haven't fully asked.

Having an MSP doesn't automatically close this gap. Having internal IT support doesn't close it either. What matters is whether the knowledge those people carry is documented, transferable, and genuinely understood by the institution — not just by the individual.

A president who believes their institution is covered because they have an IT provider may be right. But they also may be wrong. The question worth sitting with is whether that coverage is based on a real picture of what exists and why, or on trust in a person who carries that picture entirely in their head.

Both can look identical from the outside. They feel very different when a transition occurs.

The conversation worth having before it's forced

The community banks and credit unions that navigate IT leadership transitions most smoothly aren't the ones that prepared most frantically in the weeks before someone left. They're the ones that had a different kind of conversation earlier — a deliberate look at what the institution actually knew about its own IT environment, independent of any one person.

That's not a conversation about replacing anyone or questioning anyone's performance. It's a conversation about institutional resilience. About whether the knowledge that keeps things running is housed in a person or in a process.

The best time to have it is before a transition makes it urgent.

What we hear most often

What happens when an IT director retires at a community bank?

When a long-tenured IT director retires from a community bank or credit union, institutions frequently discover that critical knowledge like vendor relationships, configuration decisions, undocumented processes, and institutional history existed primarily in that person's memory rather than in transferable documentation. The transition period often reveals a gap between what the institution assumed it knew about its own IT environment and what was actually documented and accessible. The institutions that navigate this most smoothly are those that assessed this gap before the departure rather than after.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

What is key-person risk in community banking IT?

Key person risk in community banking IT refers to the concentration of critical institutional knowledge, vendor relationships, and operational decision-making in a single individual. When that person is unavailable, through retirement, illness, resignation, or unexpected departure, the institution may struggle to maintain continuity, answer examiner questions accurately, or make informed technology decisions without the context that person carried. It's distinct from having poor systems or weak security. An institution can be solid in both while still carrying significant key person risk.

Does having a managed IT provider eliminate key person risk?

Not automatically. An MSP should provide day-to-day IT management and strategic support, but key person risk often lives at the intersection of institutional knowledge and vendor relationships. A long-tenured internal contact carries the context about why decisions were made, what workarounds exist, and how the environment evolved over time. If that knowledge isn't documented and transferable, an MSP relationship doesn't replace it. The question worth asking is whether your institution's IT knowledge lives in a person or in a process.

How do community banks prepare for an IT leadership transition?

The community banks and credit unions that handle IT leadership transitions most effectively typically do three things before a transition occurs.

They conduct a structured assessment of what institutional IT knowledge exists and where it lives.
They ensure critical vendor relationships and configuration decisions are documented independently of any individual
They have a frank conversation at the leadership level about what the institution actually knows about its own IT environment versus what it assumes it knows. This conversation is most valuable and least disruptive when it happens proactively rather than in response to an announced departure.

If this raises a question worth exploring for your institution, the executive brief covers this and five other areas where community banking leaders often find they have more questions than they expected. It takes about ten minutes to read and is designed to leave you with better questions, not a list of problems.