A supplier can pass procurement, sign the contract and connect to critical systems before anyone asks the question that matters: what happens to our business if this provider is compromised? To assess third party cyber risk properly, security leaders need more than a questionnaire and a compliance certificate. They need a repeatable decision process tied to access, data, operational dependency and commercial consequence.
For Australian organisations managing Essential Eight uplift, ISO 27001, SOC 2 commitments or APRA-regulated obligations, third-party risk is no longer a side task for procurement. It is part of the operating security model. The challenge is doing it without turning every vendor engagement into a three-month audit.
Start with business exposure, not a generic score
A single vendor risk rating can be useful for reporting, but it is a poor basis for action on its own. A payroll platform with employee records, a managed service provider with privileged access, and a design agency with no production access should not face the same assessment depth.
Classify each supplier by the consequence of failure or compromise. Consider the data they hold or can access, the systems they connect to, whether they can act with privileged credentials, how easily they can be replaced, and the financial, regulatory and customer impact of an outage.
This creates a practical tiering model. Low-risk suppliers may need a short declaration and basic contractual controls. Medium-risk suppliers require evidence of core security practices. Critical suppliers need a detailed review before onboarding, followed by ongoing monitoring and contingency planning.
The point is proportionality. Over-assessing low-impact vendors wastes security and procurement time. Under-assessing a provider with access to production data creates an exposure that no polished contract can fix.
Define what “acceptable” looks like before procurement starts
Teams often begin collecting evidence before agreeing on their minimum requirements. That produces a stack of documents, inconsistent decisions and awkward exceptions late in the deal cycle.
Set a baseline that reflects the service being procured. For a supplier processing sensitive data, the baseline may include multi-factor authentication, encryption, vulnerability management, tested incident response, secure deletion processes and documented subprocessor controls. For a provider administering cloud infrastructure, privileged access management, logging, change control and recovery testing carry greater weight.
A useful baseline should answer three questions. Can the supplier prevent common compromise paths? Can it detect and contain an incident quickly? Can your organisation continue operating if the supplier is unavailable?
Do not confuse a certification with a complete answer. ISO 27001 and SOC 2 reports provide valuable assurance, but their scope, exclusions, control exceptions and reporting dates matter. A certificate may cover one product, one region or a limited set of operational processes. Review the evidence against the service you are actually buying.
Assess third party cyber risk across four control areas
An evidence-led review should focus on the controls that alter your real exposure, rather than asking every vendor the same 150 questions. Four areas usually provide the clearest view:
- Identity and access: How are staff, administrators and service accounts authenticated? Is multi-factor authentication enforced? Is privileged access limited, reviewed and removed promptly when roles change?
- Data and technology security: Where is data stored, how is it encrypted, and what integration points exist? Review cloud architecture, endpoint controls, vulnerability remediation and separation between customer environments where relevant.
- Security operations and resilience: Does the provider monitor for threats, manage incidents, test backups and run recovery exercises? Ask for actual test dates and outcomes, not simply a policy statement.
- Governance and supply chain: Who owns security accountability, how are staff screened and trained, and which subcontractors or offshore delivery partners support the service? The fourth party can be the weak point that never appeared in the original procurement pack.
Evidence should be specific. Policies show intent. Configuration records, audit reports, penetration test summaries, incident metrics, access review samples and disaster recovery test results show whether the controls operate in practice.
That does not mean demanding every confidential security artefact. Suppliers have legitimate reasons to protect internal documentation. Where direct evidence cannot be shared, use a controlled briefing, independent assurance report, redacted test result or contractual attestation. The goal is sufficient assurance for the risk, not unrestricted access to a vendor’s security programme.
Treat external ratings as a signal, not a verdict
Attack surface ratings and threat intelligence can quickly reveal exposed services, leaked credentials, poor domain hygiene or known vulnerabilities. They are useful, particularly when a supplier has not yet entered a formal review.
They also have limits. External tools can misattribute infrastructure, miss internal controls and penalise a provider for an issue that has already been remediated. A low rating should trigger investigation, not automatic rejection. Equally, a clean external profile does not prove that a supplier manages privileged access well or can recover from ransomware.
Combine external signals with supplier-provided evidence and your own architecture review. If a provider is connecting to your environment, assess the integration design as seriously as the provider itself. Least-privilege access, network segmentation, logging and a clean offboarding path can reduce residual risk materially.
Make residual risk a business decision
No supplier is risk-free. The decision is whether the remaining risk is understood, owned and commercially justified.
Document the gap, the likely impact, the agreed treatment and the accountable executive. Risk treatment may involve remediation before go-live, a time-bound exception, reduced access, additional monitoring, cyber insurance requirements or an alternative supplier. Critical gaps should not disappear into a spreadsheet because a project deadline is tight.
Contracts matter here, but they are not a substitute for security controls. Include clear security obligations, breach notification timeframes, audit and assurance rights, data handling requirements, subcontractor obligations, recovery expectations and exit assistance. The wording should reflect the risk tier and service model. A critical managed provider needs materially stronger obligations than a low-access SaaS tool.
For organisations subject to APRA CPS 234 or similar governance expectations, maintain a clear record of material supplier arrangements, risk assessments, exceptions and review dates. If an incident occurs, the ability to show how the supplier was assessed, approved and monitored is as important as the original decision.
Monitor the supplier after onboarding
The most common third-party risk failure is treating assessment as a gate rather than a lifecycle. Vendors change hosting providers, acquire companies, add subcontractors, release new integrations and experience security incidents. Your original assessment ages quickly.
Set review frequency by risk tier. Critical suppliers may require quarterly service and security discussions, annual evidence refreshes, notification of material changes and ongoing exposure monitoring. Lower-risk vendors can be reviewed less often, particularly where they have no sensitive data or system access.
Trigger an out-of-cycle review when there is a breach, material service change, acquisition, adverse threat intelligence, major control failure or expanded access request. This keeps attention on events that change exposure instead of forcing teams through performative annual reviews.
Offboarding deserves the same discipline. Confirm data return or deletion, disable accounts and integrations, rotate shared credentials, recover assets and retain the evidence. A former supplier with forgotten access is still part of your attack surface.
Build a process that security and procurement can run
Third-party assurance works when security, procurement, legal, IT and business owners have clear roles. Procurement should know which deals require escalation. Security should publish tier-based requirements and review service architecture. Business owners should accept operational impact and remain accountable for supplier performance. Legal should convert agreed controls into enforceable obligations.
Automation can reduce the administrative burden, especially for evidence collection, reminders, approval trails and compliance reporting. It cannot make the judgement call for you. A well-organised risk workflow still needs experienced people to interpret a control gap in the context of the service, the contract value and the organisation’s risk appetite.
For lean teams, the priority is not building a perfect vendor risk programme on day one. Start with a defensible intake process for high-risk suppliers, clear minimum controls, a documented exception path and scheduled reassessment. Then extend coverage as the supplier estate becomes visible.
Third-party cyber risk is a commercial control as much as a security control. The organisations that manage it well move faster because they know which vendors can be approved quickly, which need conditions, and which are not worth the exposure. If your current process cannot make those calls clearly, book a Discovery Call and map the workflow before the next critical supplier goes live.