The IIA’s Third-Party Topical Requirement takes effect on 15 September 2026. From that date, any assurance engagement whose subject is third-party management, or that identifies third-party management as a topic while doing something else, must assess seventeen named governance, risk management and control processes, must document which of the seventeen apply, and must record a rationale for any it leaves out. It was issued on 15 September 2025 with a user guide, after a public comment period in the spring of 2025, and it is the second of the mandatory topic-level requirements that now sit beside the Global Internal Audit Standards in the IPPF; the Topical Requirements explainer explains the mechanism, and the Cybersecurity Topical Requirement workbook is the model for what a conformant engagement file looks like.
This guide is the working version for the third-party requirement specifically. It defines what counts as a third party under the requirement (broader than “vendor”), sets out when the requirement binds, walks through all seventeen requirements in three workbook tables (what to assess, the evidence to expect, the gap most programs have), maps them to the frameworks and regulations a third-party program is usually built on (the 2023 US interagency guidance, DORA, NIST SP 800-161, ISO/IEC 27036, the EBA outsourcing guidelines), gives a gap assessment a function can run in a week, a conformance record template, a plan for the first ninety days after the effective date, and a worked example of a distributor’s function scoping its first engagement under the requirement.
This guide was rewritten in September 2026 from a shorter version published in August 2026. The requirement statements below are paraphrased from The IIA’s published Third-Party Topical Requirement (September 2025), read in full for this rewrite; the evidence examples and gap notes are practitioner commentary, not IIA text. It was extended on 25 September 2026 with test procedures for all seventeen requirements, a sampling approach across tiers and life-cycle events, a request list, guidance for immature programs and overlapping requirements, a reporting format and answers to common questions.
In this guide
- What counts as a third party, and why the definition is the first scoping decision
- When the requirement binds
- The Governance domain: four requirements
- The Risk Management domain: four requirements
- The Control Processes domain: nine requirements
- Testing the seventeen: procedures, populations and what fails
- How the seventeen map to the frameworks your program already uses
- What an existing program usually covers, and what it usually does not
- A gap assessment you can run in a week
- The conformance record: a template
- Sampling third parties across tiers and life-cycle events
- The request list for a third-party engagement
- When the program is immature, the regulation is stricter, or another requirement applies
- Reporting coverage and conclusions
- The first ninety days after 15 September 2026
- Worked example: scoping a first engagement under the requirement
- Questions about the requirement
- Related guides
What counts as a third party, and why the definition is the first scoping decision
The requirement defines a third party as an external individual, group or entity with which the organization (the primary organization, in the document’s phrase) establishes a business relationship to obtain products or services, whether or not the relationship is formalised by a contract. It then extends the concept to the third party’s own suppliers where they matter to the primary organization, which is the “further downstream” language that appears in the risk management requirements. That definition is wider than most vendor management programs: the requirement names vendors, suppliers, contractors, subcontractors, outsourced service providers, other agencies and consultants, which in practice reaches cloud and software providers, joint-venture and alliance partners where the relationship is one of obtaining products or services, and the subcontractors behind any of them. The requirement also says what it is not intended to address: indirect external relationships such as regulators, agents and trustees or board members, and internal relationships such as employees. Auditors are given flexibility to adapt the term to the organization’s own definition of a third party. It does not by itself reach customers, regulators or shareholders, and it does not turn every purchase into a third-party relationship; the requirement’s own governance domain expects the organization to have a way of deciding which relationships warrant which treatment.
The scoping consequence is immediate. An engagement titled “vendor management” that examines the procurement department’s supplier file has, under the requirement, given assurance on third-party management, and will be assessed against seventeen requirements that assume a life cycle from the decision to contract through to offboarding. The function either scopes to the full definition, or documents that its engagement covers a defined subset (procured suppliers of goods, say, and not IT service providers or outsourced functions) and excludes the requirements that the subset does not reach with a stated rationale. Either is conformant. Auditing the supplier file and calling it third-party assurance is not.
When the requirement binds
The rules are the same as for every Topical Requirement. It applies when third-party management is the subject of an engagement in the plan, when the topic is identified while performing an engagement, or when it is the subject of a requested engagement that was not on the plan. Conformance is mandatory for assurance services and recommended for advisory services. Evidence that each of the seventeen requirements was assessed for applicability must be documented and retained, and where requirements are excluded, a rationale must be documented and retained. Conformance will be evaluated during quality assessments. The second trigger is the one that will catch functions in the first year: the outsourced payroll provider inside a payroll audit, the cloud platform inside an IT audit, the logistics contractor inside an operations audit and the co-source firm inside the function’s own QAIP are all third parties, and the part of each engagement that gives assurance on how they are managed is within the requirement’s reach.
| Engagement | Does the Third-Party Topical Requirement apply? | How |
|---|---|---|
| Third-party or vendor risk management program audit | Yes, in full | All seventeen assessed; exclusions justified by scope |
| Audit of one outsourced function (payroll, claims processing, a managed security service) | Yes, to the relationship in scope | Governance and risk requirements at program level; control-process requirements for that relationship’s life cycle |
| IT audit in which a cloud provider or SaaS platform is material | Yes, for the provider-management part; the cybersecurity requirement also applies | Both applicability records; overlapping requirements evidenced once |
| Procurement or purchase-to-pay audit | Yes, where the engagement concludes on supplier selection, contracting or monitoring | Control-process requirements A to D and F typically in scope; governance and risk assessed or excluded with rationale |
| SOC 1 or SOC 2 report review supporting another engagement | Yes, for the monitoring requirement (Control Processes F) at minimum | Record that the review is the monitoring evidence for that provider (see the SOC 1 report review method) |
| DORA ICT third-party engagement at an EU financial entity | Yes; the two overlap substantially | Map DORA Articles 28 to 30 evidence to the requirement (see the DORA guide for internal auditors) |
| Advisory work on designing a TPRM program | Recommended | Use the seventeen as the design criteria; note the decision |
The Governance domain: four requirements
Governance is where most programs are weakest and most audits are thinnest, because the artifacts are documents and meetings rather than transactions. The four requirements ask whether the organization decides deliberately to use third parties, whether it has written down how it will manage them, whether the people involved know their roles and can perform them, and whether the right people hear about performance, risk and compliance in time to act.
| Requirement (paraphrased) | What to assess | Evidence to expect | The common gap |
|---|---|---|---|
| Governance A. A formal approach, implemented and periodically reviewed, for deciding whether to contract with a third party, with criteria for defining and assessing the resources needed and available to meet the objective | Is there a make-or-buy decision framework, is it used before relationships are entered, and has it been reviewed? | Sourcing policy or decision framework; business cases showing the criteria applied; evidence of periodic review of the approach | Decisions to outsource are made by budget holders with no framework; the “approach” exists only for IT |
| Governance B. Policies and procedures that define, assess and manage third-party relationships and risks across the life cycle, aligned with regulatory requirements and periodically reviewed and updated | Does the TPRM policy cover selection through offboarding, does it reflect the regulations the organization is subject to, and is it current? | Policy and procedures with version history; regulatory mapping; review approvals | A procurement policy standing in for a TPRM policy; no coverage of monitoring or exit; last reviewed years ago |
| Governance C. Defined roles and responsibilities for who selects, directs, manages, communicates with and monitors third parties and who must be informed, with a process ensuring the people assigned have the competence to perform them | Is there a RACI for third-party management, is it applied to real relationships, and are relationship owners trained or qualified? | RACI; relationship owner assignments in the inventory; training records or competency criteria for owners | Relationship ownership defaults to whoever signed the contract; owners have no training and no defined duties |
| Governance D. Protocols for communicating with stakeholders, including timely reporting on the performance, risks and compliance (specifically breaches of laws and regulations) of prioritized third parties | Does management and, for critical relationships, the board receive periodic reporting on third-party performance, risk and compliance, and are breaches escalated? | Reporting packs; escalation protocol; minutes showing discussion; breach notifications | Reporting exists only for IT vendors or only after an incident; the board hears about third parties when something fails |
The Risk Management domain: four requirements
The risk domain is where the requirement’s reach shows: it expects a standardized process that covers the key risk types relevant to the organization (the requirement lists strategic, reputational, ethical, operational, financial, compliance, cybersecurity, information technology, legal, sustainability and geopolitical risks as examples), assessment across the whole life cycle, prioritization that extends to downstream parties, responses matched to ranking, and an issue escalation route with accountability for outcomes.
| Requirement (paraphrased) | What to assess | Evidence to expect | The common gap |
|---|---|---|---|
| Risk Management A. Standardized, comprehensive processes for managing the risks of third parties and their services, with defined roles, addressing the key risk types relevant to the organization, with adherence monitored and deviations corrected | Is there one risk process applied to all relationship types, and does it cover more than information security? | Risk methodology; risk taxonomy for third parties; evidence the same process was applied to a supplier, a service provider and an outsourcer | Three processes (IT security, procurement, legal) that never meet; concentration, financial and compliance risk not assessed |
| Risk Management B. Risks identified and assessed regularly across the life cycle; the assessment used to rank and prioritize third parties, including those further downstream; risk responses ranked and prioritized too | Is every relationship risk-rated at onboarding and re-rated on a cycle, does the rating drive tiering, and are fourth parties considered for the highest tier? | Inherent and residual risk ratings in the inventory; tiering criteria; re-assessment dates; fourth-party information for critical relationships | Ratings assigned once and never refreshed; tiering by contract value rather than risk; no view of subcontractors |
| Risk Management C. Risk responses adequate and commensurate with ranking; implemented, reviewed, approved, monitored, evaluated and adjusted | Do the due diligence, contract terms and monitoring intensity actually differ by tier, and are responses tracked? | Tier-based requirements matrix; evidence that high-tier relationships received the higher-tier treatment; response tracking | Every relationship gets the same questionnaire; responses recorded and never revisited |
| Risk Management D. Processes to manage and escalate issues arising from third parties, ensuring accountability for outcomes and increasing the likelihood of meeting the terms of the relationship; where a third party does not respond to escalated concerns, management evaluates the relationship and pursues further action, remediation or termination | When a third party fails or causes an incident, is there a route that assigns an owner, tracks resolution and escalates? | Issue log with owners and dates; escalation criteria; examples of escalated issues and outcomes | Issues handled informally by the relationship owner; no log; nothing reaches management until the contract is up for renewal |
The Control Processes domain: nine requirements
The nine control-process requirements follow the life cycle in order: selection, contracting, contract approval, inventory, onboarding, monitoring, corrective action, renewal, offboarding. They are the requirements most audit programs already test in part; what the requirement adds is completeness (all nine, for all relationship types in scope) and the inventory requirement, which most programs fail and everything else depends on.
| Requirement (paraphrased) | What to assess | Evidence to expect | The common gap |
|---|---|---|---|
| Control Processes A. Due diligence for sourcing and selecting third parties, with a documented and approved business case or equivalent justifying the need | Was the need justified and approved, and was the due diligence proportionate to the tier? | Business cases; due diligence questionnaires and results; financial, security, compliance and reference checks by tier | Due diligence limited to a security questionnaire; business case absent for services that grew from a pilot |
| Control Processes B. Contracting and approval performed per policy, with collaboration among the relevant parts of the organization | Did legal, security, compliance, finance and the business all take part in contracting for in-scope relationships? | Contract review workflow; sign-offs by function; deviations approved | Contracts negotiated by the business alone; security and compliance see them after signature |
| Control Processes C. Final contracts reviewed and approved by all relevant stakeholders including legal and compliance, signed by authorised individuals from both parties, and stored securely | Are executed contracts complete, authorised, retrievable and containing the terms the policy requires (service levels, data handling, audit rights, termination)? | Contract repository; signature authority matrix; clause checklist results | Unsigned or expired contracts in force; missing audit and exit clauses; contracts stored in email |
| Control Processes D. An accurate, complete and current listing of all third-party relationships, such as a centralised contract management system | Does the inventory exist, is it complete against independent sources, and is it current? | The inventory; reconciliation to accounts payable, contracts, access records and expense data; ownership and tier fields populated | The most common finding under the requirement: the inventory understates relationships by a third or more against accounts payable |
| Control Processes E. Documented onboarding processes, established and followed, to set the foundation for the third party to meet the contract | Is there an onboarding procedure and was it followed for sampled relationships? | Onboarding checklist; access provisioning; data-sharing setup; kickoff records | Onboarding is “give them a login”; no confirmation the third party understands its obligations |
| Control Processes F. Ongoing monitoring of whether third parties perform to the contract and fulfill their obligations throughout the life cycle, including verifying the reliability of the information they provide and re-evaluating performance periodically and whenever the agreement changes | Is performance and risk monitored at a frequency matched to tier, and does monitoring cover the third party’s own controls (assurance reports, audits, attestations)? | Service-level reporting; assurance report reviews with complementary user entity controls addressed; periodic reassessments; site visits or audits for critical relationships | Monitoring equals invoice approval; SOC reports collected and not read; no reassessment after onboarding |
| Control Processes G. Protocols to initiate corrective actions when a third party fails expectations or poses increased or unexpected risk, including incident escalation based on severity, post-incident reviews and root-cause analysis of incidents | When monitoring finds a problem, is there a defined response and was it used? | Corrective action plans; incident escalation matrix; examples | Problems tolerated until renewal; incidents handled by IT without the relationship owner |
| Control Processes H. Contract expiration and renewal dates monitored, with renewal actions taken as necessary | Are expirations tracked and are renewals a decision rather than a default? | Expiry reporting from the inventory; renewal decisions with re-assessed risk | Auto-renewals; services continuing on expired terms |
| Control Processes I. A formalised offboarding plan, implemented and followed, addressing contract requirements on timing and expectations: termination, replacement where necessary, return or destruction of data, removal of access, transition | When a relationship ends, is there a plan, and was it executed for sampled exits? | Offboarding checklist; data return or destruction certificates; access removal evidence; transition records | Terminated providers retaining data and access; no exit plan for critical services |
Testing the seventeen: procedures, populations and what fails
The three domain tables above say what to assess. This one says how: the procedures that produce a conclusion on each requirement, the population they run on, and what a “does not meet” conclusion usually looks like in the file. The requirement’s own framing sets the population for the controls domain. The control-process requirements are assessed for the third parties prioritized by risk, and the evaluation has to include management’s processes for the ongoing assessment and monitoring of third parties. The inventory requirement is the exception, because completeness can only be judged against everything.
| Requirement | Procedures | Population and extent | What “does not meet” usually looks like |
|---|---|---|---|
| Governance A (decision to contract) | Inspect the sourcing or make-or-buy framework and its last review; trace relationships entered in the period to a decision record that applied the criteria | Every relationship entered in the period if there are few; otherwise a sample across tiers | Relationships entered with no decision record; the framework has never been reviewed |
| Governance B (policies and procedures) | Compare the policy set with the seventeen requirements and the life cycle; check the regulatory mapping and the review approvals | The whole policy set | Silent on monitoring, renewal or exit; not reviewed within its own cycle |
| Governance C (roles and competence) | Inspect the RACI; for each sampled relationship, find the named owner and test whether the owner performed the defined duties; inspect competency criteria or training for owners | Owners of every sampled relationship | Owners who do not know they own the relationship; no competency criteria at all |
| Governance D (communication and reporting) | Inspect four quarters of reporting on prioritized third parties’ performance, risk and compliance; trace two known incidents or breaches into that reporting and, for critical relationships, to the board | Four quarters of reporting | The board hears about third parties only after a failure; breaches of law not escalated |
| Risk Management A (standardized process) | Inspect the methodology and taxonomy against the risk types the requirement lists; check how adherence is monitored; re-perform the risk rating for five relationships | Methodology plus five re-performed ratings | Security-only assessment; no monitoring of adherence |
| Risk Management B (assessment and prioritization) | Use analytics to test that every inventory record has a current rating and tier; check refresh dates against policy; check that downstream parties are identified for the top tier | The full inventory | Stale ratings; tiering by spend rather than risk; no view of fourth parties |
| Risk Management C (responses by rank) | Compare the treatment the policy requires for each tier with what sampled relationships received; check responses are approved, monitored and adjusted | All tier-one and a sample of tier-two relationships | Tier-one relationships treated like tier three |
| Risk Management D (issues and escalation) | Trace issues from the log to an owner, a resolution and any escalation; test what happens when a third party ignores escalated concerns | Every logged issue in the period, or a sample if many | No log; unresponsive providers renewed without an evaluation |
| Control Processes A (due diligence and business case) | Inspect the business case and due diligence for new relationships, checking depth against tier | New relationships in the period, by tier | No business case; due diligence limited to a questionnaire |
| Control Processes B (contracting per policy) | Trace contracting through the approval workflow and confirm legal, security, compliance and finance took part as the policy requires | New and renewed contracts in the sample | The business negotiated and signed alone |
| Control Processes C (executed contracts) | Inspect executed contracts for approvals, authorised signatures on both sides, secure storage, required clauses and a named contract manager | Contracts of every sampled relationship | Unsigned or expired contracts in force; audit and exit clauses missing |
| Control Processes D (inventory) | Reconcile the inventory to twelve months of payments, the contract repository, external accounts in identity systems and card or expense spend; investigate every difference by count and value | Full populations, by analytics | The inventory understates the relationships the organization pays |
| Control Processes E (onboarding) | Test onboarding of relationships started in the period: access provisioning, data-sharing terms, kickoff, acknowledgement of obligations | New relationships in the sample | Onboarding consists of issuing a login |
| Control Processes F (ongoing monitoring) | Inspect performance reporting, assurance report reviews (exceptions, bridge letters, complementary user entity controls), periodic re-evaluation and re-evaluation after changes to the agreement; test the reliability of information the third party supplies | All tier-one and the tier-two sample | Reports collected but not read; no re-evaluation since onboarding |
| Control Processes G (corrective action and incidents) | Trace third-party incidents through escalation by severity, post-incident review and root-cause analysis | Every third-party incident in the period | Incidents closed without review; the same failure repeats |
| Control Processes H (expiry and renewal) | Use analytics to compare contract end dates with payments; test renewals in the period for a decision informed by re-assessed risk | Every expiry and renewal in the period | Payments continuing on expired contracts; automatic renewal with no review |
| Control Processes I (offboarding) | For relationships ended in the period, test the offboarding plan: termination, replacement where needed, return or destruction of data with certificates, and access revoked (matched to identity systems) | Every terminated relationship if there are few; a sample if many | Former providers with live accounts; no evidence data was returned or destroyed |
Two procedures carry more weight than the rest, and both are analytics. The inventory reconciliation under Control Processes D decides the population for everything else, and the identity-system match under Control Processes I finds the most embarrassing exposure a third-party program can have: people who no longer work for the organization’s providers still logged in to its systems. Run both in planning, not fieldwork, so that the engagement’s scope rests on the real population. The user access review guide covers the identity-system side of the match.
How the seventeen map to the frameworks your program already uses
The requirement is a scope floor, not a new framework, and it was written to sit over the guidance that third-party programs are usually built on. A function that already tests against one of the sources below can map its criteria to the seventeen requirements in an afternoon; the table shows where each source concentrates and where it leaves a requirement uncovered, which is where the function’s own criteria have to fill in.
| Source | Who it binds or guides | Strong coverage of | Thin on |
|---|---|---|---|
| US Interagency Guidance on Third-Party Relationships: Risk Management (Federal Reserve, FDIC, OCC; June 2023; OCC Bulletin 2023-17) | US banking organizations | The full life cycle (planning, due diligence, contract negotiation, ongoing monitoring, termination); governance; board oversight; critical activities | Nothing structurally; written for banks, so the proportionality language needs translation elsewhere |
| DORA, Regulation (EU) 2022/2554, Articles 28 to 30, with the register templates in Implementing Regulation 2024/2956 and the subcontracting rules in Delegated Regulation 2025/532 | EU financial entities, for ICT services | Inventory (the register of information), contractual provisions, concentration and subcontracting, exit strategies, critical providers | Non-ICT third parties; the make-or-buy decision; competence of relationship owners |
| NIST SP 800-161 Rev. 1 (May 2022), Cybersecurity Supply Chain Risk Management | US federal agencies; widely adopted elsewhere | Risk assessment across tiers, supplier criticality, downstream suppliers, monitoring of cyber risk in the supply chain | Commercial and financial risk types; contracting and renewal controls |
| ISO/IEC 27036 (information security for supplier relationships) | Any organization adopting ISO 27001 | Security requirements through the supplier life cycle; ICT supply chain; cloud services | Governance roles, reporting to the board, non-security risk |
| EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) | EU banks and investment firms | Outsourcing register, critical or important functions, pre-outsourcing assessment, exit strategies, audit rights | Third parties that are not outsourcing; the broader supplier base |
| The organization’s own TPRM policy | Everyone | Whatever it covers; usually selection and contracting | Usually inventory completeness, monitoring intensity by tier, corrective action and offboarding |
What an existing program usually covers, and what it usually does not
Functions that have audited vendor management before tend to assume the requirement is mostly satisfied, and the pattern in third-party programs generally is more specific than that. Selection due diligence (Control Processes A), contracting (B) and contract approval (C) are usually present and usually tested, because procurement and legal own them and they leave documents. Monitoring (F) is usually present for IT providers and absent for everyone else, and where it is present it is often reduced to collecting assurance reports that nobody reads against the complementary controls the organization is supposed to operate. Inventory (D) is the requirement that fails most often and matters most, because every other requirement is applied to the population the inventory defines; a program that manages 118 relationships beautifully while paying 186 is conformant with nothing. Onboarding (E), corrective action (G), renewal monitoring (H) and offboarding (I) are the requirements that programs built around procurement do not have at all, and offboarding in particular produces findings that reach the audit committee: terminated providers with live access, data never returned, and critical services with no exit plan.
On the governance and risk side the gaps are structural rather than missing documents. Roles (Governance C) exist in the policy and not in practice: relationship ownership defaults to whoever signed, and owners have never been told what monitoring means. Reporting (Governance D) reaches management for IT vendors after incidents and reaches the board rarely. Risk assessment (Risk Management B) happens once, at onboarding, drives nothing, and stops at the first tier of suppliers, so the downstream language in the requirement, which asks about the third party’s own critical suppliers for the relationships that matter most, is the part most programs cannot answer at all. The practical conclusion for planning is that an engagement under the requirement should budget its hours toward D, F, I and the two risk requirements, and should expect its most consequential finding to be a number: the share of paid relationships the program does not know about.
A gap assessment you can run in a week
Before the first engagement under the requirement, most functions want to know how far the organization’s program is from the seventeen, and how far the function’s own method is. The week below does both. It is deliberately light: it uses documents, one reconciliation and one meeting, and it produces the two things planning needs, a first-cut conclusion per requirement and a list of the requirements likely to need the most fieldwork.
| Day | Work | Output |
|---|---|---|
| 1 | Collect the TPRM policy, procedures, RACI, risk methodology, tiering criteria, standard contract clauses, onboarding and offboarding checklists, and the last two reporting packs; map each document to the seventeen requirements | Document map: which requirement each document addresses, and which requirements have no document |
| 2 | Reconcile the third-party inventory to accounts payable vendors with spend in the last twelve months, to the contract repository, and to the identity system’s external accounts; investigate the differences by count and value | Inventory completeness estimate (the single number the audit committee will remember); the Control Processes D conclusion |
| 3 | Select ten relationships across tiers and types (two critical outsourcers, two IT providers, three suppliers, one contractor, one agent, one recently terminated); walk each through the life cycle documents | First-cut conclusions for Control Processes A to I from real relationships |
| 4 | Interview the TPRM owner, procurement, legal, information security and two relationship owners against the governance and risk requirements; ask each who they think owns monitoring | First-cut conclusions for Governance A to D and Risk Management A to D; the roles gap, if there is one |
| 5 | Rate each requirement (meets / partially meets / does not meet / not established), estimate fieldwork hours per requirement, and draft the engagement’s scope and exclusions | Gap summary; hours estimate; a draft applicability record for the engagement |
The conformance record: a template
Third-Party Topical Requirement: applicability and conformance record
Header: Engagement | Requirement version: Third-Party Topical Requirement, issued 15 September 2025, effective 15 September 2026 | Engagement type: assurance / advisory | Trigger: planned subject / identified during engagement / requested | Third-party scope covered: (relationship types, business units, geographies) | Prepared, reviewed, dates.
Rows, one per requirement (Governance A to D, Risk Management A to D, Control Processes A to I): Applicable (yes / no) | Rationale if excluded, tied to the scope statement | Criteria used (requirement statement; organisation policy reference; external framework reference) | Procedures performed with work program reference | Evidence references | Conclusion (meets / partially meets / does not meet / not established) | Finding reference | Included in the report’s coverage table (yes / no).
Footer: Requirements applicable: __ of 17 | Excluded: __ (rationales above) | Conclusions: meets __, partially meets __, does not meet __, not established __ | Inventory completeness estimate: __ per cent against accounts payable | Filed per Standard 14.6 on (date).
Sampling third parties across tiers and life-cycle events
A third-party engagement has more than one population, and most of the sampling mistakes come from treating it as one. Tier decides how deep the testing goes; the life-cycle event decides which requirement a relationship can evidence. A relationship onboarded in the period can show Control Processes A, B and E; one that ended can show I; one whose contract expired can show H. The illustration uses the distributor in the worked example below, whose reconciled inventory held 186 paid service providers: six tier-one, 41 tier-two and 139 tier-three.
| Population | Selection | Illustration (186 providers) | Requirements it evidences |
|---|---|---|---|
| Tier one (critical) | Every relationship | All 6 | Control Processes A to I, Risk Management B and C, and the downstream parties of each |
| Tier two | A random sample sized with the small-population tables | 15 of 41, the exact size for 90% confidence and a 10% tolerable rate | Control Processes B, C, F and G; Risk Management C |
| Tier three | Analytics and existence checks rather than a sample | All 139 through the inventory, contract and expiry analytics | Control Processes C (a contract exists), D and H |
| Relationships entered in the period | Across tiers, weighted to the higher ones | Every new tier-one and tier-two relationship, plus a handful of tier three | Governance A; Control Processes A, B and E |
| Expiries and renewals in the period | Every one, by analytics | All contracts with an end date in the period | Control Processes H |
| Relationships ended in the period | Every one if there are fewer than about twenty; otherwise a sample | All terminations | Control Processes I, with the identity-system match |
| Third-party incidents and issues | Every one in the period | All logged incidents | Risk Management D; Control Processes G |
| Downstream parties of tier-one relationships | Every material subcontractor the contracts allow | Named subcontractors of the six | Risk Management B; Control Processes F |
Test a relationship once for everything it can evidence, rather than once per requirement; a tier-one provider onboarded in the period can support eleven conclusions from a single file review. And resist the temptation to size the tier-two sample by feel. Fifteen of 41 is what the exact calculation gives for a 90/10 conclusion; ten would give noticeably less, and the difference is the kind of thing a quality assessor recomputes.
The request list for a third-party engagement
The list below is sized for an engagement covering all seventeen requirements. Each item names the requirements it supports, which makes the list double as a coverage check: a requirement with no item against it has no evidence planned. Send it with the planning memo, and ask for system extracts rather than exported spreadsheets wherever the item is a population.
| # | Item | Supports |
|---|---|---|
| 1 | Third-party risk management policy, procedures and standards, with version history and approvals | Governance B |
| 2 | Sourcing or make-or-buy framework, and the decision records for relationships entered in the period | Governance A; Control Processes A |
| 3 | Roles and responsibilities (RACI), the list of relationship owners, and owner training or competency criteria | Governance C |
| 4 | The last four reporting packs to management and the board, and the escalation protocol | Governance D |
| 5 | Risk methodology, risk taxonomy and tiering criteria | Risk Management A and B |
| 6 | The third-party inventory with tier, rating, rating date, owner and contract reference | Control Processes D; Risk Management B |
| 7 | Vendor master and twelve months of payments, extracted from the system | Control Processes D |
| 8 | Contract repository listing with start and end dates | Control Processes C and H |
| 9 | External and non-employee accounts from the identity systems | Control Processes D and I |
| 10 | Due diligence files and business cases for relationships entered in the period | Control Processes A |
| 11 | Contract approval workflow records for new and renewed contracts | Control Processes B and C |
| 12 | Onboarding checklists and records | Control Processes E |
| 13 | Monitoring evidence for tier-one and sampled tier-two relationships: service reports, assurance reports and their reviews, re-evaluations | Control Processes F |
| 14 | The third-party issue and incident log | Risk Management D; Control Processes G |
| 15 | Post-incident reviews and root-cause analyses | Control Processes G |
| 16 | Renewal calendar and renewal decisions | Control Processes H |
| 17 | Relationships ended in the period, with offboarding records and data return or destruction certificates | Control Processes I |
| 18 | Subcontractor information for tier-one relationships | Risk Management B |
| 19 | Regulatory mapping for the program (for example, the interagency guidance or a DORA register) | Governance B |
| 20 | Earlier audit, regulatory and second-line reviews of the program, with action status | Planning; Risk Management D |
When the program is immature, the regulation is stricter, or another requirement applies
The IIA’s application guidance for Topical Requirements answers four situations that come up in third-party work more than anywhere else. An immature program in a high-risk area. Where governance, risk management and controls around third parties are barely built, the function still has to address the risk. The guidance allows the requirement to be used in an advisory engagement as a framework to evaluate gaps, and expects the exposure to be brought to the board’s and senior management’s attention; full assurance can follow once there is something to assure. Not enough time, staff or skills. Resource constraints do not waive the duty to assess the risk or decide applicability. The chief audit executive informs the board under Standard 8.2 and closes the gap by training, recruitment, co-sourcing or a rescoping that is documented and agreed or approved by the board.
Stricter regulation. Where a regulation or framework imposes a more demanding obligation, such as DORA for EU financial entities or the US interagency guidance for banks, the higher standard guides the scope, and mapping the requirement to it is good practice. Work already performed by another assurance provider can be referenced if the reliance is documented and its sufficiency assessed, the approach Standard 9.5 on coordination and reliance describes. More than one Topical Requirement. The guidance’s own example is a third party that provides cybersecurity services: both the Cybersecurity and the Third-Party Topical Requirements may apply, while a risk confined to contractual compliance calls for the third-party requirement alone. Behavior can bring in a third, as the Organizational Behavior workbook explains; the rationale for including or excluding each requirement belongs in the planning record.
Reporting coverage and conclusions
The report needs three things the audit committee can read in a minute. The first is a coverage statement that names the requirement and its date, the number of requirements applied and excluded, and where exclusions are covered. The second is a short coverage table by domain. The third is a clear split between findings about the program, which the program’s owner fixes, and findings about individual relationships, which the relationship owner fixes; mixing them produces action plans with the wrong owners. The table below is the format; the entries are illustrative.
| Domain | Requirements applied | Meets | Partially meets | Does not meet | Findings |
|---|---|---|---|---|---|
| Governance | 4 of 4 | 1 | 2 | 1 | Program finding 1 (roles and owner competence) |
| Risk management | 4 of 4 | 0 | 3 | 1 | Program finding 2 (ratings not refreshed; no downstream view) |
| Control processes | 9 of 9 | 3 | 4 | 2 | Program finding 3 (inventory incomplete); relationship findings for two tier-one providers (offboarding, monitoring) |
A coverage statement that works reads like this: “This engagement applied all seventeen requirements of the IIA’s Third-Party Topical Requirement (issued 15 September 2025, effective 15 September 2026) to third parties providing services to the organization. Goods-only suppliers were excluded from the control-process requirements, with rationale on file, and are covered in the FY28 procurement audit.” Keep the per-requirement conclusions in the conformance record and out of the body of the report; the committee needs the pattern, and the assessor needs the record.
The first ninety days after 15 September 2026
Functions that did not prepare during the twelve months since issue are not in trouble; they are in the same position as most of the profession. The first ninety days after the effective date are enough to be conformant on the next engagement if they are spent in the right order. Days one to ten: read the requirement and the user guide, put the calendar and the procedure in the methodology manual (the Topical Requirements explainer has the eight-step method), and flag every FY27 engagement that touches third parties. Days ten to thirty: run the one-week gap assessment above for the organization as a whole, and brief the audit committee in one page on what the requirement is and what the first engagement under it will report. Days thirty to sixty: scope the first engagement against all seventeen, with exclusions justified, and re-estimate its hours; most functions find the inventory reconciliation alone adds a week. Days sixty to ninety: perform it, with the conformance record maintained as fieldwork proceeds rather than assembled at the end, and report with a coverage table by domain. The second engagement will take a third of the preparation, and the third will feel like methodology.
Worked example: scoping a first engagement under the requirement
MidState Beverage, the three-state drinks distributor used across this site, relies on third parties more than its six-person audit function had ever examined as a subject: a cloud payroll provider (whose SOC 1 report the function reviews, with two of four complementary user entity controls found unoperated), the ERP vendor and its hosting provider, a fleet maintenance contractor, a managed security service adopted after the FY27 cyber audit, roughly forty logistics and haulage subcontractors used by the depots, and the function’s own IT audit co-source firm. The FY28 plan carried a 400-hour third-party management audit, added after the requirement calendar mapping described in the Topical Requirements explainer. Scoping it was the first time the function had applied the requirement, and the decisions are the example.
| Decision | What the function did | Recorded as |
|---|---|---|
| Definition and scope | Adopted the requirement’s definition in full; scoped the engagement to all third parties providing services (not goods-only suppliers, which were left to the FY28 procurement audit), so that logistics subcontractors, IT providers, the payroll provider and the maintenance contractor were all in | Scope statement; goods-only suppliers excluded from the control-process requirements with rationale, but the governance and risk requirements assessed for the whole program |
| Applicability | All seventeen applicable; none excluded | Applicability record, 17 of 17 |
| The inventory first | Reconciled the procurement team’s list of 118 service providers to twelve months of accounts payable and to external accounts in the directory; found 186 paid service providers and 31 external accounts belonging to providers not on any list | Control Processes D: does not meet; inventory completeness 63 per cent by count; the first finding, drafted at planning |
| Tiering and depth | Used the organization’s own three tiers where they existed and its own judgment where they did not; full life-cycle testing for the six tier-one relationships, monitoring and contracting tests for a sample of fifteen tier-two, inventory and contract existence only for tier three | Work program with a requirement reference on every step; hours re-estimated from 400 to 460 after the inventory result |
| Overlap with the cybersecurity requirement | The managed security service and the hosting provider triggered the cybersecurity requirement’s third-party-related items as well; evidence gathered once and referenced in both records | Two applicability records, cross-referenced |
| The co-source firm | Treated as a third party of the function itself; its contract, monitoring and offboarding provisions tested against Control Processes B, C, F and I, and the result reported to the audit committee separately | A one-page note to the committee; one finding (no offboarding plan for the function’s own provider) |
| Reporting | Coverage table by domain in the report; the conformance statement referenced the requirement by name and date | Report section “Coverage under the Third-Party Topical Requirement” |
The inventory finding was the engagement before the engagement started, which is the usual experience under this requirement, and it is the reason the gap assessment above puts the reconciliation on day two. The audit committee’s question at the planning briefing was the right one: how can the organization manage third-party risk for relationships it does not know it has? The function’s answer, delivered in the final report with a 63 per cent completeness figure and a 68-relationship gap, was the most useful sentence the committee had heard about third parties in years, and it came from a control-process requirement most vendor audits skip.
Questions about the requirement
Do suppliers of goods count as third parties?
Yes. The requirement’s definition covers relationships to obtain products or services and names vendors and suppliers alongside contractors, subcontractors, outsourced service providers, other agencies and consultants. An engagement can still scope its control-process testing to service providers and exclude goods-only suppliers with a rationale, as the worked example does, but the governance and risk requirements apply to the program as a whole.
Do we have to test every third party?
No. The control-process requirements are assessed for the third parties prioritized by risk, and depth follows tier. The inventory is the exception: completeness can only be tested against every paid relationship, which is why the reconciliation runs on full populations.
Are fourth parties in scope?
They can be. The requirement applies to subcontracted relationships, including those fourth or further downstream, that the third party’s contract with the organization allows, and asks auditors to prioritize them by risk. In practice that means the named material subcontractors of tier-one providers, assessed through risk management B and monitoring under control processes F. The fourth-party risk guide covers how to find them.
Does collecting a SOC report satisfy the monitoring requirement?
Only if someone reads it. An assurance report is monitoring evidence when its scope covers the services used, its exceptions are evaluated, any gap to the organization’s period is bridged, and the complementary user entity controls it assumes are mapped to controls the organization actually operates. The SOC 1 review method and the SOC 2 review method set out the steps.
Are affiliates and intragroup service companies third parties?
The requirement speaks of external individuals, groups or entities and lets auditors adapt the term to the organization’s own definition. Where a regulation treats intragroup arrangements as outsourcing, as the EBA outsourcing guidelines do for EU banks, follow the stricter rule and record the decision in the scope statement.
What does the requirement leave out?
It says it is not intended to address indirect external relationships, interests or involvements, such as regulators, agents and trustees or board members, or internal relationships such as employees. Those relationships carry risk, but they belong to other parts of the audit plan.
Related guides
- IIA Topical Requirements explained: what is mandatory, when, and how to conform
- IIA Cybersecurity Topical Requirement: conformance workbook
- DORA for internal auditors: the five pillars, tested
- How to review a SOC 1 report
- How to review a SOC 2 report
- How to audit the vendor master
- How to audit procurement
- How to audit cloud security
- Co-sourcing vs outsourcing internal audit
- The Global Internal Audit Standards: the complete guide
- GIAS Domain V: performing engagements, standard by standard
- More operational risk guides
- Third-party risk management end-to-end: the full lifecycle program
- Vendor due diligence: what to actually check, by risk tier
- Third-party resilience: continuity when the failure is not yours
- The Organizational Behavior Topical Requirement: a conformance workbook
- Fourth parties and vendor concentration
- Audit sample sizes, including exact sizes for small populations
- User access reviews
Leave a Reply