5.2 Third-Party Process Risks

5.2 Third-Party Process Risks

Quick Answer: An outsourced process is still the organization’s risk. When the activity under review depends on a vendor, planning must extend objectives and scope to vendor controls—due diligence, contract clauses, System and Organization Controls (SOC) reports or right-to-audit, fourth parties, concentration, and data sharing—or you must document a scope limitation. The IIA Third-Party Topical Requirement (issued 15 September 2025, effective 15 September 2026) will be a mandatory IPPF baseline; CIA scored items follow a lag of at least six months after the effective date (about March 2027). Learn the planning skill now because A.3.f already lists third-party processes.

A.3.f does not treat “the vendor handles it” as a planning conclusion. Standard 13.2, Engagement Risk Assessment, and Standard 13.3, Engagement Objectives and Scope, require you to understand how the activity actually operates. If payroll, fulfillment, hosting, collections, or a call center sits at a third party, the risks of that activity sit there too—and they still belong to the organization that hired the vendor.

This section is planning recognition, not a Part 3 lecture on building the annual plan, and not a substitute for Chapter 4’s cybersecurity and continuity topics. When a vendor relationship is also a cyber or resilience component, those chapters still apply. Here the job is: recognize third-party process risks and the controls a planner should expect, then decide whether scope can reach them.

Residual risk stays with the organization

A contract can allocate performance of a process. It cannot erase the organization’s accountability to customers, regulators, the board, or financial-statement users. If a payroll processor underpays tax withholdings, a cloud warehouse ships the wrong lot, or a collections vendor mishandles personal data, stakeholders still look to the organization. Planning that stops at “we outsourced it” has not identified the key risk.

Typical residual-risk categories to name in the planning file: operational failure (the vendor does not deliver); financial reporting (the vendor’s records feed your books); compliance and privacy; cyber and availability; reputation; and concentration (too much critical activity in one pair of hands). You do not need to test all of them in every engagement. You do need to recognize which of them are key for this activity and whether evidence of vendor controls is obtainable.

Due diligence: before contracting and on a cycle

Due diligence is the set of inquiries and evidence gathered before a third party is selected and on a risk-based cycle afterward. Planning questions: Was financial health, reputation, capability, security, and compliance reviewed before go-live? Is there a current vendor inventory with owners and risk tiers? Has diligence been refreshed after a merger, a material incident, or a change in service? A file that contains only a sales proposal is not diligence.

For higher-risk vendors, diligence typically includes references, financial statements or credit checks, security questionnaires or independent reports, insurance certificates, and screening for sanctions or conflicts. The planner’s job is not to re-perform the procurement team’s entire file. It is to see whether a diligence process exists, whether this vendor was in it, and whether gaps are a key risk for the activity under review.

Contract clauses a planner should expect

The contract is a control if it is complete, current, and used. Clauses that matter for engagement planning:

A right-to-audit clause that management has never exercised, or that the vendor routinely refuses, is a planning constraint, not a comforting sentence in a slide deck. If you need vendor-control evidence and cannot get it from a SOC report or from audit rights, you are looking at a scope limitation (Chapter 2.3), not at an automatic “controls are effective” conclusion.

SOC reports, complementary controls, and right-to-audit

Independent reports on a service organization are often the practical way to see vendor controls when you cannot visit every data center.

Complementary user entity controls (CUECs) are controls the report says you must operate (for example, granting access only to authorized employees, or reviewing output). A Type 2 report that is clean except for CUECs you do not perform is not a free pass. Inclusive versus carve-out methods matter when a subservice organization (a fourth party) is inside or outside the report. A bridge letter may cover a short gap after the Type 2 period; it is not a substitute for a Type 2 when you need operating-effectiveness evidence for the whole engagement period.

International analogues (for example, ISAE 3402) follow the same planning logic: know what was tested, for what period, and what the user entity must still do. If no suitable report exists, right-to-audit, agreed-upon procedures, or direct testing at the vendor become the evidence path—or the limitation is documented.

Fourth parties, concentration, and data sharing

Fourth parties are the vendor’s subcontractors and subservice organizations. Risk does not stop at the contract you signed. Planning should ask: Does the contract require approval or notice of subcontracting? Does the SOC report carve out a cloud host, a payment processor, or a call-center overflow partner? Downstream monitoring should be risk-based: you do not inventory every fifth-tier courier, but you do identify parties that can stop the activity or expose regulated data.

Concentration is over-dependence on one vendor, one geography, or one technology platform. A single payroll processor, a single cloud region, or a single contract manufacturer can turn an operational glitch into an entity-level event. Concentration is a key risk even when that one vendor’s SOC report looks strong.

Data sharing is its own key risk whenever the vendor stores, processes, or can see personal, payment, health, or strategic data. Planning looks for a data-processing agreement, minimum-necessary access, encryption in transit and at rest as applicable, breach-notification clocks, and deletion or return at exit. Sharing a production customer file with a vendor “for testing” without masking is a planning red flag, not a footnote.

Planning: reach vendor controls or call a scope limitation

If the activity under review depends on a vendor, written objectives that ignore vendor controls are incomplete. Scope must name the vendor services, locations, systems, and period you will cover, and the evidence you will use (diligence file, contract, SOC plus CUECs, right-to-audit fieldwork, management monitoring). If management or the vendor blocks that evidence, document the limitation, assess whether a conclusion is still supportable, and escalate significant unresolved limitations. Silent shrinkage—“we will just test the emails we can see in-house”—is the same trap as Chapter 2.3.

You are not required to “audit the vendor’s entire company.” You are required to cover the vendor controls that matter to this activity, in proportion to risk. A low-risk office-supply portal does not get the same scope as a payroll processor holding tax IDs.

Third-Party Topical Requirement: future mandatory baseline, already a planning skill

The IIA Third-Party Topical Requirement was issued 15 September 2025 and becomes effective 15 September 2026 (12 months after issuance). It is a mandatory IPPF element when applicable: a minimum baseline for assessing design and implementation of third-party governance, risk management, and control processes across the lifecycle (policies and owners, risk tiering and monitoring, diligence, contracting, onboarding, ongoing monitoring, corrective action, renewal and offboarding). It is not a requirement that internal audit physically audit every vendor, and it is not a complete local-law work program.

CIA policy is that scored exam questions on new Topical Requirements do not appear until at least six months after the effective date. For this requirement, scored CIA items are expected from about March 2027, not from September 2025 and not automatically on 15 September 2026. Do not claim the Third-Party Topical Requirement is already a scored CIA topic on a 2026 sitting. Do treat third-party processes as testable now, because A.3.f already names them as planning information you must recognize.

When the requirement later becomes scored, the Chapter 2 rule still applies: if third-party risk is the subject of an assurance engagement or a significant component, the Topical Requirement constrains objectives and scope; individual inapplicable elements need documented rationale. Until that CIA lag ends, exam items should still be answered with A.3.f planning recognition and with Standards 13.2 and 13.3—not with “the Topical Requirement is only guidance” and not with “wait until 2027 to think about vendors.”