When Risk Processes Depend Too Much on Key People

This is a common form of operational risk. The company believes it has a process, but in reality it has a group of experienced people compensating for missing structure. Their knowledge acts as an invisible layer between formal procedures and actual decisions.

The objective of process design is not to eliminate professional judgement. Risk management will always require judgement. The objective is to make sure that critical decisions do not depend on information that exists only in one person’s memory.

Key-person dependency is different from expertise

Experienced employees are valuable precisely because they recognise patterns, understand context and know how to deal with unusual situations. The problem is not that some people know more than others. The problem begins when the organisation cannot reproduce an important decision without them.

There is a practical difference between expertise and dependency. Expertise improves a controlled process. Dependency replaces it.

A mature process should allow a trained colleague to understand what needs to happen, which evidence matters, what authority is required and when the case should be escalated. The colleague may still reach a different professional judgement, but the structure around that judgement should remain stable.

Six signs that the process depends too much on individuals

Informal knowledge usually develops for understandable reasons

Key-person dependency rarely appears because a company deliberately chooses weak governance. It usually develops gradually.

A startup begins with a small team. Everyone communicates directly. A few experienced people make most decisions. Writing detailed procedures feels unnecessary because the same people sit next to each other and can resolve questions immediately.

Then the company grows. Volumes increase, new products are launched and more employees join. The original employees continue answering difficult questions, so the hidden dependency remains invisible. Instead of redesigning the process, the company keeps adding people around the existing informal structure.

Eventually the organisation reaches a point where informal knowledge no longer scales. The number of cases grows faster than the number of people who understand the exceptions.

Procedures often describe what should happen, not how decisions are made

A company can have many procedures and still depend heavily on individual knowledge.

The problem is often the level of detail. A procedure may say that high-risk cases must be escalated, but not define what makes a case high risk. It may require additional verification without explaining which evidence is sufficient. It may state that exceptions require management approval without identifying which manager, what information must be provided or how the approval should be recorded.

This creates a gap between policy and operation. Employees know the formal requirement but still need to ask an experienced colleague what it means in practice.

Good operational documentation should therefore capture decision logic, not just process stages.

Decision points should be documented before routine steps

When companies try to improve documentation, they often begin by writing every operational step in great detail. That can create long procedures while leaving the important questions unresolved.

The highest priority should be the points where the process can move in different directions. What evidence is enough to approve a merchant? When does a transaction require manual review? Who can accept an exception? What triggers escalation? Which cases require a second reviewer? When can a temporary limit be removed?

These are the places where inconsistent judgement creates risk.

Our guide to operational documentation in payment risk management explains how documentation can support repeatable risk decisions rather than simply record administrative steps.

Build the process around decisions, ownership and evidence

A practical risk process needs more than a sequence of tasks. Each important stage should make three things clear: who owns the decision, what evidence is required and what happens next.

The second model does not remove judgement. It gives judgement a controlled structure. An experienced analyst can still recognise unusual circumstances, but the organisation no longer depends on undocumented knowledge to know what should happen next.

Exceptions are where hidden dependency becomes most dangerous

Standard cases are usually easy to document. Exceptions are more difficult because they sit outside normal logic. That is also where key-person dependency grows fastest.

A team may have several unofficial exceptions that everybody experienced understands. A merchant type may receive a different review. A high-value customer may have special limits. Certain transactions may be approved after verbal confirmation. A particular country may require additional evidence that is not mentioned in the standard procedure.

Over time, these exceptions become a parallel operating model.

A controlled process should record why the exception exists, who can approve it, what evidence is required, whether it is permanent or temporary, and what conditions should cause it to be reviewed again.

Ownership must survive organisational changes

Many risk processes describe activities without clearly defining ownership. This works while the original team structure remains stable. It becomes difficult when teams are reorganised.

A process should assign responsibility to a role rather than to a person wherever possible. “Senior Fraud Analyst” is more durable than “Alex.” “Head of Risk approval” is more durable than the name of the current manager.

Role-based ownership also helps during hiring, absence and internal transfers. The organisation knows which responsibility must be covered even when the individual changes.

This is one of the areas where Riskscenter can support companies through a structured review of their risk processes and operational documentation, including ownership, decision logic, escalation and exception management.

Handover quality is a practical test of documentation

A procedure should not be judged only by whether it exists. A better test is whether another trained employee can use it.

Handover exercises are useful because they expose undocumented assumptions. Ask an employee who did not design the process to take a real case and follow the documentation. Record every point where they need to ask another person what to do.

Those questions reveal the actual documentation gaps.

If the employee understands the steps but cannot decide whether evidence is sufficient, decision standards are missing. If they know the decision but do not know who can approve it, ownership is missing. If they understand both but cannot find the previous case history, the problem is information access rather than procedure design.

Turn tribal knowledge into a controlled operating model

The transition should not begin by asking experienced employees to “write down everything they know.” That usually produces either overly long documents or incomplete notes.

A more effective approach is to observe where their judgement changes the process.

This approach preserves expertise while reducing dependency. The experienced employee remains valuable because of judgement and pattern recognition, but routine process continuity no longer depends on personal memory.

Documentation should support change, not freeze the process

One reason teams avoid documentation is the fear that procedures will quickly become outdated. That concern is legitimate. Risk environments change continuously.

The solution is not to avoid documentation. It is to design documentation that can be maintained.

Documents should have clear owners, version history and review triggers. A major product change, new payment method, repeated exception, regulatory change or significant loss event should be capable of triggering a process review.

The company should also distinguish stable elements from dynamic ones. Roles, approval structure and evidence standards may change slowly. Thresholds, country lists and specific control parameters may change more often and can be maintained separately.

Do not document every detail at the same level

Not every risk activity requires a fifty-page procedure. Documentation should reflect the importance and complexity of the decision.

A useful hierarchy can separate policy, process, procedure, decision guide and checklist.

This structure helps avoid two extremes: procedures that are too vague to guide real decisions and documents that are so detailed that nobody uses them.

Metrics can reveal hidden process dependency

Key-person risk is not always visible through standard operational reporting, but several indicators can expose it.

• Case handling time increases sharply when specific employees are absent.
• Escalation rates differ materially between analysts handling similar cases.
• One employee receives a disproportionate number of internal questions or approvals.
• Rework increases after handover to another team or shift.
• Exception decisions cannot be reconstructed from the case record.
• New employees require extensive verbal guidance despite completed training.
• Backlogs concentrate around activities owned informally by one person.

These indicators do not automatically prove poor process design, but they show where management should investigate further.

Process resilience should be tested before a key employee leaves

Companies often discover dependency during resignation, prolonged absence or organisational change. That is the worst time to redesign a critical process.

A simple resilience test is to ask whether a trained replacement could perform the process tomorrow using the available documentation, systems and authority model. If not, management should identify exactly what information is missing.

The same test can be applied to escalation, merchant review, fraud investigation, chargeback handling, AML cases, payment release and exception approval.

The objective is continuity. The company should not need the same individual forever in order to preserve the same standard of control.

Good processes make expertise more valuable

Reducing key-person dependency does not mean reducing the role of experienced specialists. The opposite is usually true.

When routine knowledge is captured in a controlled process, senior employees spend less time answering repetitive questions. They can focus on genuinely difficult cases, emerging risks, process improvement and training.

The organisation also becomes better at learning from them. Instead of expertise disappearing when someone leaves, important decision logic becomes part of the operating model.