Managing Third-Party Vendor Risk: A Practical Guide

Most businesses spend real money locking down their own firewalls, endpoints and email. Fewer stop to ask a harder question: what about everyone we've given a way in?

Your payroll provider, your accounting software, your marketing agency, your IT support desk, even the cleaning contractor with a building access card. Each one has some form of connection to your business, whether that's a login, an API key, a VPN account or simply your data sitting on their servers. If any of them is compromised, the attacker doesn't need to break into your systems at all. They just walk in through the door your vendor left open.

This is why third-party and supply chain risk has moved up the agenda, and it is still one of the easiest exposures to overlook when you're focused on your own environment. It is also one of the few security problems where the fix is mostly administrative rather than technical, which is good news for a business that doesn't have a security team.

What follows is a working method: build a list, rank it by damage, ask a small number of useful questions, put the answers in the contract, keep watching, and close the door properly at the end.

Why your vendors are part of your attack surface

A vendor relationship usually starts with a simple business decision: this company can do something faster or cheaper than we can in-house. Security rarely gets a seat at that table. The contract gets signed, an account gets created, and months later nobody in the business can say with confidence what that vendor can actually access, or whether they take security as seriously as you do.

Attackers understand this gap well. It's often easier to compromise a smaller supplier with weaker defences than to attack a well-protected target directly, then use that trusted connection to reach the real objective. The connection is the point. A vendor login is not treated as suspicious by your systems, because you authorised it. Traffic from a supplier's IP range doesn't trip an alert, because it never has before.

Three things make this worse in practice. Vendor access tends to be broad, because scoping it tightly takes effort at setup time. It tends to be permanent, because nobody owns the job of removing it. And it tends to be invisible, because vendor accounts often sit outside the joiner-mover-leaver process you apply to staff.

POPIA makes this your problem, not only theirs

This is the part South African businesses most often get wrong. Under the Protection of Personal Information Act, if you decide why and how personal information is processed, you are the responsible party. A vendor that processes that information on your behalf and under your instruction is an operator. Your payroll bureau, your cloud CRM, your outsourced call centre and your document storage provider are all likely operators.

Being the responsible party means the accountability stays with you. POPIA expects you to secure the integrity and confidentiality of personal information in your care, to have a written contract in place with any operator requiring them to maintain appropriate security safeguards, and to act when a security compromise occurs. An operator is required to tell you if personal information under their control has been accessed or acquired by an unauthorised person, and you are then the one who must notify the Information Regulator and the affected data subjects as soon as is reasonably possible.

Read that sequence again, because it has a practical consequence. Your notification obligation depends on a vendor telling you promptly. If your contract with them is silent on breach notification, you can be in the position of learning about your own reportable incident from a customer, or from the news. That is a contractual failure long before it is a technical one.

Regulated sectors have a second layer on top. Financial institutions in particular now face explicit supervisory expectations around oversight of third parties, which we cover in more detail in our look at South Africa's cyber rules for financial firms. Businesses serving customers in the UK or EU may pick up equivalent duties there under regimes such as the EU's Digital Operational Resilience Act, which is aimed at how financial entities oversee the ICT providers they depend on.

Step one: build the vendor inventory

You cannot manage a list you don't have, and it is easy to underestimate the length of yours. The list in someone's head is usually the ten vendors that send the biggest invoices. The real list is longer, and the risky entries are often small.

Don't start from memory. Start from records that already exist:

The accounts payable ledger and the company card statements. Every recurring payment is a supplier, including the small monthly SaaS subscription a department signed up for directly.
Your Microsoft 365 or Google Workspace admin console. Look at enterprise applications and OAuth consents. Any third-party app a user has approved may be reading mail, files or calendars right now.
Your DNS and mail records. MX, SPF and CNAME entries quietly reveal who hosts your website, sends your marketing mail and runs your booking system.
Firewall, VPN and remote-access accounts. Anything named after a company rather than a person is a vendor connection.
Your identity provider's sign-in logs. Look for accounts that only ever authenticate from outside the country or outside business hours.
Physical access records. Cleaning, security, maintenance and shredding contractors belong on the list too.

For each vendor, capture only what you will actually use: who owns the relationship internally, what data they hold or touch, what access they have, where that data sits, when the contract renews, and who you phone at 02:00 if something goes wrong. A spreadsheet is a perfectly respectable starting point. The register only becomes a burden if you try to make it exhaustive on day one.

Step two: tier vendors by what they can reach

A small bookkeeping firm with access to your banking details can be a bigger risk than a large software vendor that only sees anonymised data. Rank vendors by the damage they could do, not by how big, well known or expensive they are. That ranking is what lets you spend your limited attention where it matters, and it is also the thing an auditor or a major client will ask to see.

Judge each vendor on three questions: what personal or commercially sensitive data do they hold, what access do they have into your systems, and how quickly does your business stop working if they go down? The worst answers set the tier.

Tier	What they can reach	Due diligence	Review
1. Critical	Admin or network access to your systems, or large volumes of personal or financial data. Business stops without them.	Full question set, evidence requested, operator agreement, named contacts	Continuous monitoring plus a formal annual review
2. Important	Personal data or a business process you depend on, but no privileged access to your environment.	Short question set, key contract clauses confirmed	Annual review
3. Limited	Some business data, no personal data of consequence, replaceable within days.	Light check at onboarding and renewal	At renewal
4. Minimal	No data, no access, no operational dependency.	Note in the register	None beyond renewal

Two rules keep the tiering honest. First, tier on actual access rather than intended access, because "read only" reporting logins have a habit of quietly gaining write permissions. Second, re-tier whenever the scope of work changes. The agency that was Tier 3 while it redesigned your brochure becomes Tier 1 the day you give it access to your customer database for a mailing campaign.

Step three: due diligence a vendor will actually complete

Vendor risk management doesn't need to start with a 40-page questionnaire. Send one to a ten-person supplier and you will get silence, or worse, a set of confident ticks written by someone in sales who has never seen the server room. A short, specific question set that you actually read is worth more than a long one you file unread.

For a Tier 1 or Tier 2 vendor, this is a reasonable set to send:

What data of ours will you hold, and in which country will it be stored?
Is multi-factor authentication enforced on all of your staff accounts, including administrators and remote access?
How do your staff access our data or systems, and how is that access removed when someone leaves?
Is our data encrypted in transit and at rest, and who holds the keys?
Do you back up our data, and when did you last test a restore?
Which of your own suppliers or subcontractors will handle our data?
Have you had a security incident affecting client data in the last two years, and what changed as a result?
Who do we contact, and within what timeframe, if you suffer a security compromise involving our information?
Do you hold a recognised security certification or an independent audit report, and can we see the current one?
What happens to our data when we stop working together?

Ten questions fit on one page and can be answered quickly by someone who genuinely knows the answers. That last part is the real test. Judge the response as much as the answers: a vendor that replies quickly, admits what it doesn't do, and offers evidence is usually safer than one that ticks every box and provides nothing.

Be proportionate about evidence too. Asking a large cloud provider for its audit report is reasonable and they publish one. Asking a two-person bookkeeping practice for a formal certification is not, and you'll learn more by asking how they store your banking file and whether their laptops are encrypted.

Step four: write it into the contract

Answers in an email are useful. Obligations in a contract are enforceable. Under POPIA the operator agreement isn't optional for anyone processing personal information on your behalf, so use it to cover the things you would otherwise have to ask for as a favour later:

The purpose the vendor may process your information for, and a prohibition on anything else, including using your data to train models or improve their products.
A requirement to maintain appropriate, documented security safeguards, and to keep them current.
Notification to you of any security compromise without undue delay, with a defined contact and a defined timeframe, so that your own notification duty is achievable.
Prior written consent before appointing a subcontractor that will touch your data, and equivalent obligations flowed down to them.
Where the data will be stored and processed, and what happens if that changes or crosses a border.
Your right to request evidence of controls, whether that is an audit report, a scan result or a policy extract.
Return or secure deletion of your data on termination, with written confirmation.
Cooperation with you when a data subject exercises their rights, or when a regulator asks a question.

If you're building a broader compliance position at the same time, the same clauses feed straight into the wider programme described in our POPIA compliance checklist for South African businesses.

Step five: keep watching after the contract is signed

The biggest mistake in vendor risk management is treating it as a once-off check at onboarding. Security postures change. A vendor that was solid two years ago may since have been acquired, lost the key staff who cared about this, changed its hosting, or quietly let its defences slip. A questionnaire tells you what was true on the day someone filled it in, which is roughly as useful as last year's photograph of your car for insurance purposes.

Ongoing monitoring doesn't have to mean a new full-time job. In practice it means three habits:

External posture monitoring for your Tier 1 and Tier 2 vendors, so that expired certificates, exposed services, poor mail authentication and breach mentions surface on their own rather than waiting for the annual review. Platforms built for this, such as Panorays, which we use to run managed third-party risk programmes for clients, rate a vendor from the outside the way an attacker would see them and alert on changes.
A trigger list. Certain events should prompt a review regardless of the calendar: a vendor is acquired, suffers a publicised incident, changes the scope of work, moves your data to a new platform, or misses agreed service levels repeatedly.
A standing agenda item. Ten minutes in an existing monthly IT or operations meeting to work through anything that has changed is enough for most businesses.

The same discipline that keeps your own environment monitored applies here. If you already have continuous managed cybersecurity services covering your endpoints, identities and email, extending that mindset to your suppliers is a smaller step than starting from nothing.

Access should expire, not linger

One of the simplest, highest-impact changes any business can make is to stop granting standing access to vendors. A contractor who needed VPN access for a three-month project shouldn't still have it two years later. Give vendor accounts an end date at creation, review them on the same schedule you review staff accounts, and require multi-factor authentication on every one of them. Where the platform supports it, prefer time-bound, request-based access over a permanent login.

Fourth parties and concentration risk

Your vendors have their own vendors. Your cloud accounting platform relies on a hosting provider. Your marketing agency uses a scheduling tool that stores your customer list. Your payroll bureau may outsource its printing. You can't audit every link in that chain, but you can ask your Tier 1 suppliers a simple question: who do you depend on to deliver this service to us, and what happens to our data if they're compromised? A vendor that can answer immediately has thought about it. A vendor that cannot has told you something useful.

Concentration risk is the related problem and it is easy to miss when you look at vendors one at a time. Five suppliers that all host in the same cloud region, or a single connectivity provider carrying both your primary and your "backup" link, or one payment gateway with no alternative configured, all represent a single point of failure wearing five different logos. Map dependencies across the register, not just down each row, and note where you have no plan B for something the business cannot run without.

Offboarding: the step everyone skips

Ending a vendor relationship is the moment when risk is most often left behind. The invoices stop, the access does not. Work through the same list every time:

Disable and then delete all user accounts, service accounts, API keys and integration tokens belonging to that vendor.
Remove their entries from your identity provider, VPN, firewall rules and allow lists.
Revoke OAuth consents granted to their applications in Microsoft 365 or Google Workspace.
Retrieve an export of your data in a usable format before the account closes, not after.
Request written confirmation that your data has been returned or securely deleted, including from their backups, and record the date.
Collect physical items: access cards, keys, laptops, tokens.
Update your DNS, mail and monitoring configuration to remove anything pointing at their infrastructure.
Mark the vendor as terminated in the register rather than deleting the row, so you keep the history.

Building this into how you already work

None of this needs to become a full-time job. Folding vendor checks into your existing procurement and renewal processes, keeping a simple register of who has access to what, and reviewing it alongside your other IT housekeeping is usually enough for most businesses. A workable rhythm looks like a quarterly pass over vendor accounts and access, an annual review of Tier 1 and Tier 2 suppliers, a check at every contract renewal, and a triggered review whenever something material changes.

The goal isn't a perfect audit trail. It's knowing, in plain terms, who can reach your systems and data, and having a reasonable degree of confidence they're taking care of it. Vendor risk will never be fully eliminated, and that's fine. What matters is that it's a conscious decision rather than a blind spot. A short list of well-managed vendors is a far smaller risk than a long list nobody has looked at in years.

Frequently asked questions

How many vendors should we actually assess?

All of them belong in the register, but only Tier 1 and Tier 2 need a real assessment. For most small and mid-sized South African businesses that turns out to be a short list rather than a project, and it is manageable spread across a year. If everything looks like Tier 1, the tiering isn't working.

Does POPIA require a written agreement with every supplier?

It requires a written contract with any operator, meaning any party that processes personal information on your behalf and under your instruction. That covers most software platforms, outsourced services and professional firms handling staff or customer data. Suppliers who never touch personal information, such as a stationery wholesaler, don't need an operator agreement, though they may still belong in your register for other reasons.

What if a critical vendor refuses to answer our questions?

Treat the refusal as an answer and manage the relationship accordingly. Reduce the access they hold, restrict the data they receive, insist on stronger contractual protections, and note the gap in your register with a decision from someone senior enough to own it. Sometimes the commercial reality is that you cannot walk away, and that is acceptable as long as the risk is documented and accepted deliberately rather than ignored.

Is a security certification enough on its own?

It is good evidence, not a guarantee. A certification tells you a set of controls existed within a defined scope on the date of the audit. Check that the scope covers the service you're actually buying, check the date, and read the exceptions if a report is provided. Pair it with monitoring rather than treating it as the end of the conversation.

How do we start if we have no register at all?

Pull twelve months of supplier payments, list every company that appears, and mark the ones that hold personal data or have access to your systems. That first pass usually takes an afternoon and immediately shows you which handful of vendors deserve attention. Everything else in this article can be built out from there over the following few months.

This article is general information, not legal advice. POPIA decisions, correspondence with the Information Regulator and enforcement responses should be taken with a South African admitted attorney, and accountability rests with your Information Officer.