Study guide
5.2 Third-Party Process Risks
CIA Part 2 Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: CIA Part 2 Exam Orientation
1.1 Current CIA Part 2 Exam Facts 1.2 Eligibility, Fees, and Pearson VUE Scheduling 1.3 Scoring, Results Timing, and the 2025 Syllabus Map
2 Chapter 2: Engagement Objectives and Scope
2.1 Topical Requirements in Objectives and Scope 2.2 Elements Used to Build Engagement Objectives 2.3 Scope Limitations, Stakeholder Requests, and Scope Changes
3 Chapter 3: Evaluation Criteria and Planning Context
3.1 Selecting and Testing Evaluation Criteria 3.2 Applying Topical Requirements When Planning 3.3 Strategy, Risk Management, and Performance of the Activity Under Review
4 Chapter 4: Technology, Continuity, and Finance in Planning
4.1 Cybersecurity, IT General Controls, Privacy, and Data Security 4.2 Business Continuity, Disaster Recovery, and Resilience 4.3 Finance and Accounting Concepts for the Activity Under Review
5 Chapter 5: Business Process and System Risks in Planning
5.1 Asset, Supply Chain, Inventory, Payables, Procurement, and Compliance Processes 5.2 Third-Party Process Risks 5.3 CRM, ERP, and GRC System Risks
6 Chapter 6: Engagement Approach and Project Management
6.1 Agile, Traditional, Integrated, and Remote Approaches 6.2 Project Management While Planning and Conducting Engagements
7 Chapter 7: Engagement Risk Assessment
7.1 Topical Requirements and Pervasive Financial, Operational, IT, Cyber, and Regulatory Risks 7.2 Emerging Risks and the Impact of Change 7.3 Methods to Evaluate and Prioritize Risks and Controls
8 Chapter 8: Structure, Environment, and Culture
8.1 Centralized vs Decentralized, Flat vs Traditional, In-Person vs Remote 8.2 Culture, Group Behavior, and Tone at the Top
9 Chapter 9: Control Design, Effectiveness, and Efficiency Procedures
9.1 Procedures to Evaluate Control Design 9.2 Procedures to Test Operating Effectiveness 9.3 Procedures to Test Control Efficiency
10 Chapter 10: Work Programs, Testing Methodologies, and Resources
10.1 Evaluating Adequacy of the Engagement Work Program 10.2 Testing Methodologies for Accounting, Finance, IT, Operations, and Cybersecurity 10.3 Financial, Human, and Technological Resources and Limitation Implications
11 Chapter 11: Information Sources and Preliminary Survey
11.1 Interviews, Observations, and Walk-Throughs 11.2 Data Analysis as an Information Source 11.3 Policies, Checklists, Risk-and-Control Questionnaires, and Self-Assessments
12 Chapter 12: Evidence Relevance, Sufficiency, and Reliability
12.1 Criteria for Evidence Quality 12.2 Independence, Corroboration, and the Control Environment 12.3 Evidence an Informed, Competent Person Could Rely On
13 Chapter 13: Technology Options for Findings and Conclusions
13.1 Artificial Intelligence, Machine Learning, and Robotic Process Automation 13.2 Continuous Monitoring, Dashboards, and Embedded Audit Modules
14 Chapter 14: Process Mapping and Data Analytics
14.1 Workflow Segments, Process Maps, Walk-Throughs, and RACI 14.2 Structured vs Unstructured Data and the Analytics Process 14.3 Diagnostic, Prescriptive, Predictive, Anomaly, and Text Analysis
15 Chapter 15: Analytical Review and Finding Evaluation
15.1 Ratios, Variances, Trends, and Benchmarking 15.2 Selecting Analytical Techniques for Engagement Objectives 15.3 Comparing Existing Conditions to Evaluation Criteria 15.4 Root Causes, Effects, and Significance of Findings
16 Chapter 16: Workpapers and Engagement Conclusions
16.1 Organizing Complete Workpapers with Sufficient Evidence 16.2 Linking Workpapers to Results; Retention, Regulation, and Policy 16.3 Aggregating Findings and Concluding on Governance, Risk, and Control
17 Chapter 17: Engagement Supervision
17.1 Supervision Throughout Planning and Fieldwork 17.2 Coordinating Assignments and Reviewing Workpapers and Conclusions 17.3 Evaluating Auditors' Performance
18 Chapter 18: Communication During the Engagement
18.1 Formal and Informal Communication Across Planning, Fieldwork, and Reporting 18.2 Situations That Require Escalation 18.3 Selecting Appropriate Stakeholders for Engagement Communication
19 Chapter 19: Final Review and Test Day
19.1 2025 vs 2019 Traps and Part 2 vs Part 3 Boundaries 19.2 Pacing, Test-Center Rules, and Official Results
5.2 Third-Party Process Risks
Key Takeaways Explain This Topic AI
Outsourcing a process does not transfer residual risk: the organization remains responsible for governance, risk management, and control over the outsourced activity
When the activity under review depends on a vendor, engagement objectives and scope must reach vendor controls—due diligence, contract clauses, SOC reports, right-to-audit, fourth parties, concentration, and data sharing—or you have a scope limitation
A Type 1 SOC report addresses design at a point in time; a Type 2 addresses design and operating effectiveness over a period; complementary user entity controls named in the report remain the organization’s job
The IIA Third-Party Topical Requirement was issued 15 September 2025 and is effective 15 September 2026; CIA scored items follow a lag of at least six months after the effective date (about March 2027). A.3.f already tests third-party process recognition now
Last updated: August 2026
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:
- Clause Why it matters at planning
- Service-level agreements and remedies Defines the performance standard you may use as a criterion
- Right-to-audit (and cooperation with internal audit) Determines whether you can obtain evidence at the vendor
Data protection, residency, and breach-notification timelines Key when the vendor processes personal or confidential data
Approval of subcontracting / fourth parties Stops silent transfer of the work to an unknown party
Incident notification and business-continuity expectations Connects to availability of the activity under review
- Termination, transition, and data-return Exit risk if the vendor fails or the relationship ends
- Confidentiality, intellectual property, and insurance Limits residual exposure if something goes wrong
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.
Report What it covers What it does not do
SOC 1 Controls relevant to user entities’ financial reporting (ICFR) Does not, by itself, cover privacy, availability, or operational quality outside ICFR
SOC 2 Trust Services Criteria: security, availability, processing integrity, confidentiality, and/or privacy Does not automatically prove your financial-statement assertions
Type 1 Design of controls as of a point in time Does not evidence operating effectiveness over a period
Type 2 Design and operating effectiveness over a specified period Does not cover months after the period-end without a bridge letter or other evidence
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.”