Sharing the load on vendor risk

When we partner with a software vendor to help with our algorithmic systems, we need to make sure that we’re managing our key outsourcing risks. This applies across the board, regardless of whether the system is for underwriting, claims, fraud, loans, or commissions, etc.

We know that it’s important for the stability of our business operations. It’s also increasingly being emphasised by regulators and supervisors.

We typically rely on a central governance process, e.g. a central security team that checks our vendor’s security posture. Assuming the central process works, we can probably rely on it to cover most of what we need to monitor.

But there are often gaps that we’re best placed to address, given that we’re closer to the action. These gaps sit closer to the work itself. That’s what this brief article is about.

Examples of key vendor risks that we can help manage

This is by no means a comprehensive set, but examples to illustrate how we can think about the potential gaps.

We’ll cover two here: security (naturally) and change (for errors in particular). In each case, it is likely that our central teams cover the usual paperwork: vendor questionnaires, assurance reports, etc.

Security – who has access to what

Imagine finding out that someone, added “temporarily” to fix something or look into something, still has some form of privileged access. They might be able to view unmasked customer data, or edit rules or scoring calculations. It’s a problem even if they don’t know they have this access, because they could easily change something by mistake.

A practical way to minimise the chances of this happening is to:

• Keep an approved list of people with such access, and sign off on any changes, including the duration of access.
• Ask for a regular list of users and their access privileges and check these. And not just active users, but anyone who has had access since the previous review. So, for example, if you do this quarterly, check who has access now and who has had access at any point in the last three months.

Note: Of course, this assumes that our contracts and internal processes let us see these access lists. If they don’t, that in itself is a useful finding to take back to our central vendor risk or procurement teams. Especially if we “own” either the system or the outcome. We probably own the outcome even if we don’t own the system, so we fight for the right to do what we need to, to manage our risk.

Change – especially the frequent small ones

Change risk isn’t just about big, planned changes. Often it’s the small tweaks and fixes (“oops” moments), which could happen when someone had access they shouldn’t have, or a change wasn’t properly tested.

Example 1: a vendor developer tweaks a rule to “fix” an edge case. It creates a spike in false positives for a small claim segment for a couple of days. They notice, roll it back, and move on. The effect on your team might be negligible.

Example 2: a key person is on leave, a junior developer tests a change narrowly, and this is released without proper QA. The key person notices something is off and fixes the bug. You might see an odd pattern in historic cases that you can’t quite explain.

Lots of ways to solve for this problem, the specifics will depend on the system and process etc. A simple starting point is a systematic log of all changes that we can review and question as needed. It’s not unusual; auditors do this all the time.

A housekeeping matter

While we’re on this, getting regularly updated documentation from the vendor is also useful. It’s a bit tangential to our risk discussion. But if we’re asking for things regularly anyway, we might as well use this opportunity to make sure we have the current documentation.

Keep it small, check it regularly

We may not have the capacity to do this for every vendor system, or to check everything every month. That’s fine. We could pick the high‑impact systems, choose a small number of checks that are worth the effort, and do those regularly.

The central team will typically handle broad third‑party risk and security reports. Our role is to make sure that a handful of very specific things are checked regularly, at least once or twice a year, often more frequently.

Disclaimer: The info in this article is not legal advice. It may not be relevant to your circumstances. It was written for specific contexts within banks and insurers, may not apply to other contexts, and may not be relevant to other types of organisations.