Building a Vendor and Third-Party Risk Management Program

Some of the most damaging breaches in recent years did not begin inside the victim’s own network. They began with a supplier: a software vendor, a managed service provider, a payroll processor or a small contractor with remote access. When you depend on third parties for systems, data and services, their security weaknesses become your exposure, and your customers and regulators will hold you accountable regardless of who actually failed.

A vendor and third-party risk management program turns that exposure from an unmanaged liability into something you understand and control. This guide sets out how to build one that is practical and proportionate rather than a paperwork exercise.

Start with a complete inventory

You cannot manage risk from suppliers you do not know you have. The foundation of any program is a current inventory of third parties, and most organisations are surprised by how long and how outdated theirs turns out to be. Shadow IT, departmental subscriptions and legacy contracts mean the real list is almost always larger than the official one.

Build the inventory from procurement records, finance and accounts payable data, identity and access systems showing who has logins, and input from business units. For each vendor, capture what they do, what data they handle, what access they have, and how critical they are to operations. This inventory is the spine of everything that follows.

Tier vendors by the risk they pose

The single most important decision in third-party risk management is not to treat every vendor the same. Sending a 200-question assessment to the company that supplies your office plants wastes everyone’s time and trains the business to see security as bureaucracy. Effort should follow risk.

Tier vendors using a small number of factors:

• Data sensitivity. Does the vendor handle personal information, financial data, health records or other sensitive material?
• System access. Do they have access to your network, applications or privileged accounts? Remote access is a recurring breach vector.
• Operational criticality. If this vendor failed or went offline, how badly would your operations be affected?
• Regulatory relevance. Does the relationship touch obligations you must meet, such as those under APRA CPS 234, which expects regulated entities to manage the information security capability of their service providers?

Use these to sort vendors into a few tiers, typically critical, important and low-risk. The tier then drives how deeply you assess them, what you require in contracts, and how often you reassess. This single step makes the whole program sustainable.

Due diligence proportionate to the tier

For critical vendors, due diligence should go beyond a self-assessment questionnaire. Ask for independent evidence: an ISO 27001 certificate with its statement of applicability, a SOC 2 report, penetration test summaries, and evidence of controls that matter most for the service they provide. Where the risk justifies it, validate claims rather than accepting them at face value.

For lower tiers, a focused questionnaire and basic checks are enough. The discipline is matching the depth of assessment to the tier, so that scarce assessment effort is spent where the genuine exposure lies. Map your expectations to a recognised baseline such as the Essential Eight so that vendors are measured against a consistent, defensible standard rather than ad hoc opinions.

Make security enforceable in the contract

Assessment tells you about a vendor’s security; the contract makes your expectations enforceable. Security obligations agreed verbally or assumed are worth little when something goes wrong. Depending on the tier, contracts should address:

• Security obligations referencing recognised standards and the controls relevant to the service.
• Breach notification with defined timeframes, so you are not the last to know about an incident affecting your data.
• Audit and evidence rights, allowing you to request proof that controls remain in place.
• Data handling, including location, use, return and secure destruction at the end of the relationship.
• Subcontractor management, requiring the vendor to govern and disclose their own critical suppliers.
• Liability and indemnity appropriate to the risk the vendor carries.

Involve legal and procurement early so security clauses are standard parts of your contract templates rather than last-minute additions that delay deals.

Monitor continuously, not just at onboarding

The biggest weakness in most programs is that they assess a vendor once, at onboarding, and never look again. A point-in-time assessment ages quickly; a vendor that was solid two years ago may have changed ownership, cut costs, suffered a breach or quietly degraded its controls.

Ongoing management should include periodic reassessment driven by tier, with critical vendors reviewed at least annually. Supplement scheduled reviews with trigger-based reassessment when something material changes, such as a reported breach, a change of ownership, a significant service change or a contract renewal. For your most critical vendors, continuous external monitoring of their security posture and threat intelligence can provide early warning between formal reviews.

Do not forget fourth parties

Your vendors have vendors. Your data may be processed by a subcontractor you have no direct relationship with, yet whose failure can still harm you. You cannot assess every party in the chain, but for critical relationships you should require vendors to govern their own supply chain, disclose the subcontractors who handle your data or support critical services, and flow your key requirements down to them. This is increasingly the difference between a program that looks good on paper and one that reflects real exposure.

Plan for vendor incidents and exits before they happen

A third-party risk program that only governs onboarding and renewals misses two of the moments when exposure is highest: when a vendor suffers an incident, and when a relationship ends. Both deserve planning in advance rather than improvisation in the moment.

For incidents, your own response plan should explicitly account for third parties. If a critical supplier is breached, who in your organisation is notified, how do you assess whether your data or systems are affected, and what actions can you take given that the systems are not yours to investigate? The answers are far easier to work out before an incident than during one. Your contracts should support this with notification obligations and cooperation requirements, but the operational plan to act on a vendor breach has to be yours.

For exits, the end of a relationship is a recurring source of orphaned access and stranded data. When a vendor is offboarded, access must be revoked promptly, data must be returned or securely destroyed with evidence, and any integrations must be decommissioned. Build an offboarding checklist tied to your inventory so that ending a relationship is as controlled as starting one, rather than something that quietly leaves a door open.

Avoid the common pitfalls

• Treating questionnaires as the goal. A completed questionnaire is evidence, not assurance. The value is in reviewing and acting on the answers, not collecting them.
• Assessing once and forgetting. Onboarding checks age quickly; without reassessment and monitoring, your view of a vendor becomes fiction within a year or two.
• Ignoring concentration risk. If many critical services depend on a single provider, that concentration is itself a risk worth governing, separate from the provider’s own security.
• Letting the business bypass the process. If onboarding is slow or bureaucratic, business units will sign vendors without it. Make the process proportionate so the easy path is also the governed one.

Governance and ownership

A third-party risk program needs a clear owner and a place in your governance structure, or it becomes a stack of completed questionnaires nobody acts on. Define who approves new critical vendors, who tracks remediation of findings, and how third-party risk is reported to the board alongside your other cyber risks. Findings outside tolerance need named owners and deadlines, just like internal risks.

Building and running this capability is a common reason organisations engage a virtual CISO, particularly where the supplier base is large and in-house security resources are stretched. CISO Advisory helps Australian government, financial services and enterprise clients design and operate vendor risk programs that are proportionate, defensible and genuinely reduce supply-chain exposure. To discuss your program, get in touch or call 07 2112 8502.