What is third-party risk management (TPRM)?

Third-party risk management is the work of knowing who you depend on outside your own organisation, what each of them can reach, and what you decided about the risk each one brings. Its rulebook changed three times in the last ten months. The Basel Committee on Banking Supervision published final principles for third-party risk on 10 December 2025. APRA's re-made CPS 230 commenced in Australia on 1 July 2026. On 18 September 2026 the European Banking Authority published final guidelines on the management of third-party risk, replacing its 2019 outsourcing guidelines. Alongside them, NIST released a due diligence quick-start guide in July 2026, and ASD's September 2026 Information security manual added two controls on how a service provider may reach into your systems.

The term has many synonyms because every document uses its own word: supplier for NIST and ISO, third-party relationship for the US banking agencies, ICT third-party service provider for the EU's Digital Operational Resilience Act (DORA), service provider for CPS 230, processor for the GDPR. Vendor risk management usually means the narrower set of parties you buy from. This guide says third party and means the wide set: the US agencies define a third-party relationship as "any business arrangement between a banking organization and another entity, by contract or otherwise".

Why third-party risk management matters

Third parties now sit inside nearly half of all breaches. Verizon's 2026 Data Breach Investigations Report (DBIR), covering incidents from 1 November 2024 to 31 October 2025, found third-party involvement in 48% of the breaches it analysed, up from 30% the year before: in Verizon's words, "a 60% increase, after already doubling the year before". It counts three ways a third party can be involved.

The first kind includes an exploited flaw in a product you run yourself, so the 48% is broader than "a supplier was breached". The third kind does the most damage per relationship, because the attacker arrives with access you granted on purpose. The worked example below deals with it.

Not every third-party failure has an attacker in it. On 19 July 2024 a faulty CrowdStrike update took Windows machines down around the world, and Microsoft estimated it "affected 8.5 million Windows devices, or less than one percent of all Windows machines". One provider and one update produced a worldwide outage. That is concentration risk, and no questionnaire answer would have predicted it.

The risk also reaches past the party you contracted. The CL0P ransomware group began exploiting CVE-2023-34362, an SQL injection flaw in Progress Software's MOVEit Transfer, on 27 May 2023, according to CISA and FBI advisory AA23-158A. On 6 June 2023 Zellis, a UK payroll provider that used MOVEit, confirmed that some of its customers had been affected; British Airways, the BBC, Boots and Aer Lingus were among them. For British Airways, Zellis was the third party and MOVEit the fourth.

Every regime that touches the subject agrees that the organisation relying on the third party keeps the responsibility.

In Australia, a breach at your payroll provider is your breach too. The Office of the Australian Information Commissioner (OAIC) treats personal information a provider holds for you as held jointly: a breach at one entity is a breach of every entity holding the information, only one of them needs to assess and notify for the group, and the OAIC suggests the one with the most direct relationship with the affected people.

That responsibility is why several readers ask about your third parties, and each reads a different clause: an ISO/IEC 27001 auditor reads Annex A 5.19 to 5.23, a SOC 2 auditor reads criterion CC9.2, APRA reads CPS 230 and CPS 234, and an EU supervisor reads DORA Articles 28 to 30. One record has to answer all of them.

How third-party risk management works, step by step

Third-party risk management is a lifecycle with an artefact at every step, and the artefacts sit on two sides of a line. On one side is what you hold: the register entry, the tier, the decision. On the other is what you can only see through the provider's evidence and the contract. Three things cross the line, and most of the work is about them.

The US banking agencies publish a five-stage lifecycle: planning; due diligence and third-party selection; contract negotiation; ongoing monitoring; and termination. It comes from the Federal Reserve, the FDIC and the OCC, in their Interagency Guidance on Third-Party Relationships: Risk Management of June 2023, and oversight and accountability, independent reviews, and documentation and reporting run across all five. Vendor guides publish four to nine stages (IBM eight, Mitratech seven, NAVEX six, Bitsight four), and the work underneath is the same.

NIST's Cybersecurity Framework 2.0 (February 2024) files the same work under Govern, as category GV.SC, with ten outcomes running from an agreed program and policies (GV.SC-01) through "Suppliers are known and prioritized by criticality" (GV.SC-04) to provisions for "activities that occur after the conclusion of a partnership or service agreement" (GV.SC-10). ID.AM-04 adds an inventory of supplier services, and ID.RA-10 asks that "Critical suppliers are assessed prior to acquisition". The ten steps below cover all of them.

NIST also ranks the work. SP 800-161 Rev. 1 Update 1 makes criticality and prioritised supplier assessment foundational, puts surveys, site visits, certifications and contract language among its sustaining practices, and leaves automation for "once sustaining practices have been broadly implemented".

How a tier is set

A tier decides how hard you look, so it has to come from the exposure rather than the invoice. Four questions carry it, each with a source. The first is the data the party holds: CPS 234 paragraph 16 scales the assessment of a third party to "the potential consequences of an information security incident affecting those assets", and the ISM's service registers record the data's sensitivity. The second is the access it has into your systems, the same test applied to systems. The third is what stops if it fails: GV.SC-04's criticality, and the US agencies' critical activities, which each organisation identifies for itself. The fourth is how hard the party would be to replace, which DORA Article 29(1) asks before any contract. The figure carries the answers from the worked example.

The weights and the number of tiers are each organisation's own; none of these regimes prescribes them. Depth follows the tier. At the lowest, desk research and the evidence on file may be enough. At the highest, due diligence reads the independent evidence in full, asks for the subcontractor list and examines how the provider will reach your systems. NIST SP 1326 (July 2026) names five components of due diligence on ICT suppliers: foreign ownership, control or influence; provenance; resilience; foundational cyber practices; and supply chain tiers. For APRA-regulated entities, CPS 234 paragraphs 16, 22 and 28 add the security half: assess the third party's capability, evaluate the design of its controls, and check any control testing you rely on.

How to read a SOC 2 report

Every guide says to collect a SOC 2 report; reading it is the work. The AICPA's description criteria require the system description to disclose any subservice organisation, meaning the provider's own providers, by one of two methods. Under the inclusive method its controls are disclosed and tested. Under the carve-out method only the types of controls assumed there are disclosed, and nothing is tested. The report must also list complementary user entity controls: the controls the provider assumes its customer runs.

So a carved-out subservice organisation is a fourth party the auditor did not test, and a complementary user entity control is one you must run yourself for the report's assurance to hold. Read those, then the scope, the period and the exceptions.

Fourth parties and concentration

A fourth party is "a party a service provider relies on in delivering services to the entity", in CPS 230's definition. NIST asks criticality analysis to reach "fourth- and fifth-party suppliers", and names the case that matters most: "third-party suppliers receiving critical input or services from a common fourth-party supplier". That is concentration through a shared fourth party.

The simpler form is one provider doing several jobs, which the US agencies list as "dependency on a single provider for multiple activities". DORA Article 29 requires a concentration assessment before contracting: whether the provider is easily substitutable, and whether the entity would hold several arrangements with the same or closely connected providers. CPS 230 paragraph 47(c) brings the fourth parties behind material service providers into policy, and the CPS 230 guide covers those paragraphs in full.

The clauses that carry the controls

A finding the provider agrees to fix belongs in the contract, or it stays a promise. The US agencies list sixteen contract topics, from the scope of the arrangement to default and termination. DORA Article 30(2) sets terms for every ICT contract, and Article 30(3) adds more for critical or important functions, including exit strategies with a mandatory transition period. The ISM writes each clause as its own control, and GDPR Article 28 bars a processor from engaging another without the controller's prior written authorisation.

The access row is the newest. ISM-1073 says a provider does not access or administer your systems without a contractual arrangement. ISM-2124, new in September 2026, restricts that access "to remote management tools, source network addresses and time windows explicitly approved by the organisation". ISM-2125, also new, requires it to be "independently logged by the organisation in a manner that the service provider cannot modify or delete". ASD calls these "additional safeguards rather than ... substitutes" for the measures that apply to any privileged user, such as individually attributable accounts and multi-factor authentication.

Deciding, monitoring and exit

The decision is approve, approve with conditions, or reject, and the risk that remains is accepted by a named person at the level the tier demands. The ISM says it plainly for cloud: an organisation "will still need to decide whether a particular outsourced cloud service represents an acceptable security risk". The risk register guide covers the mechanics of an acceptance; none of them change when the risk sits with a supplier.

Monitoring runs on two clocks: the review date the tier sets, and triggers that bring it forward. The US agencies list the triggers: "material or repeat audit findings, deterioration in financial condition, security breaches, data loss, service interruptions, compliance lapses, or other indicators of increased risk". Monitoring "may be conducted on a periodic or continuous basis", more often where the relationship supports higher-risk activities. Several vendor pages make continuous monitoring a stage; the regulator leaves the choice to you.

Exit is planned at the start. GV.SC-10, the agencies' termination stage, DORA Article 28(8) and CPS 230 paragraph 55(d) all ask for it, and the ISM writes the mechanics into the contract: portable data that allows migration "without any loss of data" (ISM-1574) and one month's notice before the service ends (ISM-1575).

A worked example: a logistics company hands its IT operations to a managed service provider

Harbourline Logistics is a freight and warehousing company of 1,800 people, with its head office in Brisbane and eleven distribution centres. It is certified to ISO/IEC 27001:2022, with a surveillance audit due in March 2027. It is not regulated by APRA, which is the point: third-party risk management is not a banking discipline. All names and figures here are fictional.

The intake. On 22 June 2026 the Chief Information Officer, Andrew Kerr, files an intake to hand day-to-day IT operations to Corvane Managed Services from 1 September 2026: the service desk, server and endpoint management, patching and backups, including administration of the warehouse management system. It records the four answers the tier needs. Corvane will handle employee records and customer shipment data, classified Confidential, with privileged access to every server. Warehouse dispatch stops if it fails, and replacing it would take about a year.

The tier. On 24 June the analyst, Lena Vos, tiers Corvane Critical: privileged access to every server, supporting warehouse dispatch. The Chief Information Security Officer (CISO), Nadia Haddad, approves the intake on 25 June, so neither the requester nor the analyst approves their own work.

Due diligence. The questionnaire goes out on 29 June and comes back on 17 July. Corvane's SOC 2 Type 2 report, covering 1 April 2025 to 31 March 2026, and its ISO/IEC 27001 certificate arrive on 3 July. Lena Vos reads the report in five places.

Three of the five matter more than the clean opinion. The exception concerns the very access Harbourline is about to grant. The user entity control, a quarterly review of the Corvane accounts that can reach the customer's systems, is now Harbourline's, and nobody runs it yet. The two carve-outs are fourth parties the auditor never tested.

Fourth parties. Lena Vos asks for the subcontractor list on 14 July and receives it on 21 July. It names an after-hours service desk in Manila, with remote access to customer systems, that appears in neither the SOC 2 report nor the proposal. It also shows Corvane's backup storage with the same cloud provider, in the same region, as Harbourline's warehouse management software: one regional outage would take the system and its backups together.

The findings. The assessment closes on 29 July with five.

1. F-1 is rated High. One shared administrator account reaches every server through Corvane's management agent, from any address, at any time, and it must close before go-live.
2. F-2 is rated High. The Manila desk has remote access and is not under contract, and the fix names it as a subcontractor, states its regions, requires one month's notice of change (ISM-1794, ISM-1572) and puts it inside the audit right.
3. F-3 is rated Medium and records the SOC 2 exception. The fix is evidence that the two later quarters were clean, plus Harbourline's own quarterly account review.
4. F-4 is rated Medium. Production and backups run through one tool, and the backups share a region with the warehouse system. That is the US agencies' single provider for multiple activities and NIST's common fourth party in one finding.
5. F-5 is rated Low, because the proposal has no exit terms. The fix is the return of configuration, credentials and documentation, a data export in a documented format, a deletion record and one month's notice of cessation (ISM-1574, ISM-1575).

Four of the five are about how Corvane reaches Harbourline's systems and what it holds when it does.

The contract. The security schedule is agreed on 12 August, closing F-2 and F-5, and the contract is signed on 21 August 2026. It requires notice of any incident as soon as possible and within 24 hours of discovery, a figure Harbourline set on top of ISM-0141's "as soon as possible". It treats unauthorised access by Corvane as a cyber security incident, notified to Harbourline immediately (ISM-1576), adds an audit right exercised each year (ISM-1571, ISM-1738), names the subcontractors, states where data is held, and carries the access terms, the exit terms and a break clause for failing security requirements (ISM-1804). F-3 closes on 18 August.

The decision. On 19 August the Chief Operating Officer, Rosa Delgado, as business owner of warehouse operations, accepts the residual risk of one provider holding privileged access to production and to the primary backups. Her three conditions: F-1 closed before go-live; Corvane's privileged sessions reviewed weekly until an immutable backup copy is live; and that copy live by 30 September. The acceptance expires on 31 March 2027. The person who owns the operation that stops if Corvane fails is the person who carries the risk.

Into Harbourline's own plans. F-1 closes on 28 August, and Corvane goes live on 1 September 2026. It is on the incident response contact list, and the continuity plan for warehouse dispatch names Corvane as a dependency with the restore path from the immutable copy, which goes live on 30 September and treats F-4. The next full reassessment is 1 March 2027, sooner on a change notice from Corvane, a breach at Corvane or a listed subcontractor, a new SOC 2 report with exceptions, or a change to the services.

The audit walk, March 2027. The ISO 27001 auditor walks Annex A 5.19 to 5.23. Control 5.19 gets the policy and the tier, 5.20 the security schedule, 5.21 the subcontractor list and F-2, and 5.22 the review date, the change-notice clause and the weekly session reviews. Control 5.23 covers cloud services Harbourline uses directly, so the warehouse management software's own record answers it. What Harbourline holds is short: one tier with a reason, one SOC 2 report read to its carve-outs, five findings closed against dates, one signed schedule and one acceptance with an owner and an expiry.

Common mistakes

Eight failure modes share one root: the vendor file records that a review happened, and leaves out what it found and who decided. Here is Corvane written both ways.

1. Tiering by spend or by the provider's size. A cheap tool with administrator access outranks an expensive supplier that never touches your data. Tier on data, access, what stops and how hard the party is to replace.
2. Sending every provider the same long questionnaire and treating the answers as evidence. A questionnaire records what the provider says about itself. Set the depth by tier, and corroborate with independent evidence; NIST lists surveys, on-site visits and certifications together as confidence-building mechanisms.
3. Filing "SOC 2: yes". Read the scope, the period, the exceptions, the user entity controls and the carve-outs, and adopt the user entity controls as your own.
4. Signing before the review finishes. After signature the provider has no reason to accept new controls. Start at intake, as GV.SC-06 asks, and turn each finding into a clause.
5. Stopping at the third party. Ask for the subcontractor list, require notice of any change to it (ISM-1794, and GDPR Article 28(2) for processors), and look for shared providers and for one provider doing several jobs.
6. Reviewing once, at signing. Set the next review date from the tier, and write down the triggers that bring it forward.
7. Leaving the residual risk accepted by nobody, or by procurement, with no expiry. A named person at the level the tier demands accepts it, with conditions and a date it comes back.
8. Having no exit plan. Write the exit terms into the contract, and walk through the exit for a critical provider on paper before you need it.

Third-party risk management compared with its neighbours

Five names cover overlapping work. They differ in what they examine, the product you acquire or the relationship you depend on, and in which risks they count. Security questionnaires and security ratings are tools used inside the program, never a substitute for it.

Standards and references

Most of what is published on this subject is out of date. The EBA's 2019 outsourcing guidelines, OCC Bulletin 2013-29 and the CPS 230 that commenced in July 2025 have each been replaced, and the edition of NIST SP 800-161 to cite is Rev. 1 Update 1.

US interagency guidance (Federal Reserve, FDIC and OCC, June 2023). Published at 88 FR 37920 on 9 June 2023. Section IV.C holds the five stages, the contract topics (a) to (p) and the monitoring triggers. It replaced the agencies' earlier guidance, including OCC Bulletins 2013-29 and 2020-10.

DORA, Regulation (EU) 2022/2554 (December 2022, applying from 17 January 2025). Articles 28 to 30, with the register templates in Implementing Regulation (EU) 2024/2956 of 29 November 2024; the first critical ICT third-party providers were designated on 18 November 2025. EUR-Lex refused automated reads, so the wording quoted here came from a text mirror and should be checked against EUR-Lex.

EBA Guidelines on the management of third-party risk (18 September 2026). They replace the 2019 outsourcing guidelines, cover the full lifecycle, align with DORA and carry a two-year transition, applying once published in all EU languages. Cited from the EBA's press release.

Basel Committee, Principles for the sound management of third-party risk (10 December 2025). A common baseline for banks and supervisors, superseding the 2005 Joint Forum paper Outsourcing in financial services for banks. Cited from the release, since the full text refused automated download.

NIST CSF 2.0 (February 2024), SP 800-161 Rev. 1 Update 1 (1 November 2024) and SP 1326 (July 2026). GV.SC, ID.AM-04 and ID.RA-10; the three tiers of practice and Appendix C on criticality; the due diligence components, read from the abstract only.

ISO/IEC 27036 and ISO/IEC 27001:2022 Annex A 5.19 to 5.23. ISO/IEC 27036 covers supplier relationships in four parts, including Part 3:2023 on hardware, software and services supply chain security; Part 2:2022 sets requirements but is not intended for certification. Annex A 5.19 to 5.23 are the supplier controls an auditor reads. ISO sells its standards, so these summaries come from dated secondary sources; check them against a licensed copy.

APRA CPS 230 (1 July 2026) and CPS 234 (1 July 2019). CPS 234 paragraphs 16, 22, 28 and 34 apply to every information asset a third party manages. The CPS 230 guide explains the service provider paragraphs.

ASD Information security manual, September 2026. The guidelines for procurement and outsourcing, including the service registers and ISM-2124 and ISM-2125. The ISM becomes an obligation through the Protective Security Policy Framework, a contract, a state policy or a direction.

GDPR Article 28, NIS2 Article 21(2)(d), and SOC 2 criterion CC9.2. The SOC 2 wording and the description criteria come from auditor explainers, chiefly Linford & Co (February 2021); check them against the AICPA's text.

How Alvor helps

With Alvor, an organisation can run third-party risk as the lifecycle this guide describes, with the separation of duties and the dates enforced by the product.

Every relationship starts as an intake filed before the vendor is engaged. The requester records why the vendor is needed, the services, a contact and a plain profile of data, access and dependence. Someone other than the requester triages and approves it, and the person who accepts the residual risk cannot be the analyst who assessed the vendor. Triage picks desk research, a vendor questionnaire, or both. Intake opens the vendor record at an intake stage; approval opens the first due diligence assessment and moves the vendor into due diligence in one step.

The tier is derived from the intake profile (the data the vendor will hold, its access, how critical the service is and how hard it would be to replace), with a one-line rationale an analyst can override. The tier sets how often the vendor is reassessed, and when a review date passes the next assessment is already waiting in draft.

The vendor answers one structured questionnaire, weighted across risk domains, in a hardened external portal with a rotating link, an emailed code, autosave and evidence upload, and needs no Alvor account. Every submission writes to the hash-chained audit log, and an analyst override keeps the vendor's original answer beside it.

The vendor record holds contacts, contracts, certifications, the scored assessment and its findings. Certifications and contracts are tracked for expiry, and each contract records its incident-notification window in hours and whether its protective clauses are present: right to audit, notice of subcontracting, return and destruction of data, data location, termination rights and the rest. Sub-processors are recorded with their country and grouped across vendors, so a provider behind several Critical or High vendors shows up as a concentration. Findings carry severity deadlines, and a daily sweep flags breaches of them.

Residual risk is accepted only by the person named to accept it, typed Business Owner, System Owner or CISO, with conditions, a scope and an expiry; the residual score is snapshotted at the decision, and the expiry is enforced on schedule. Offboarding runs as a checklist: revoke access, get the data back, obtain the destruction certificate, terminate the contract, confirm the sub-processors are informed, and repoint the dependent business processes. The register and findings export to CSV.

In Business Continuity, a business process declares the vendors it depends on, each with its own criticality, so the plan for warehouse dispatch would know it relies on Corvane. The AI Assistant is bring-your-own-model: it reads vendors, findings and assessments, answers questions such as which vendors support a Tier 1 process, and proposes any finding or status change as an approval card a person accepts. No model approves a vendor or accepts a risk.

Alvor Advisory runs a Third-Party Risk Assessment, which inventories and tiers the vendor estate by the access and data each vendor holds, and a Managed Third-Party Risk engagement that runs the program as a standing service.

Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers, or air-gapped. Third-Party Risk Management covers the module in full.