Study guide
2.3 Scope Limitations, Stakeholder Requests, and Scope Changes
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
2.3 Scope Limitations, Stakeholder Requests, and Scope Changes
Key Takeaways Explain This Topic AI
Identify and document relevant scope limitations during planning: what is limited, why, who imposed it, and whether remaining scope can still support an engagement conclusion
Communicate significant unresolved limitations to the CAE; the CAE takes unresolved significant limitations to senior management and, if necessary, the board—do not hide them in a quietly shortened work list
Stakeholder requests to expand, delay, or narrow work must be evaluated against risk, the charter, resources, independence, and applicable Topical Requirements, then accepted or declined in writing
Mid-planning and mid-fieldwork changes to objectives or scope need change control: assess impact, obtain the right approval, communicate, and update planning documentation—never silently shrink scope because a manager is uncomfortable
Last updated: August 2026
2.3 Scope Limitations, Stakeholder Requests, and Scope Changes
Quick Answer: During planning, identify and document relevant scope limitations, evaluate and document stakeholder requests, and use a change-control method when objectives or scope change. If remaining work cannot support a conclusion, say so and escalate. Do not silently shrink scope because a manager is uncomfortable with overtime testing, a location, or a cybersecurity component.
The 2025 Part 2 expanded specs make three planning skills explicit: (c) identify and document relevant scope limitations during planning; (d) evaluate approaches for managing and documenting stakeholder requests; (e) identify effective methods for addressing changes in objectives and scope. Standard 13.3 pairs with those bullets: scope must be sufficient to achieve the objectives . If it is not, you have a limitation, a change, or both—not a private understanding with the auditee.
Identify and document scope limitations during planning
A scope limitation is a restriction that prevents internal audit from accomplishing the engagement objectives as written. Typical sources:
Source Example in a payroll assurance engagement Why it is a limitation
Denied access Payroll director refuses auditor access to the pay-file approval log You cannot evidence a key control named in the objective
Excluded population Management carves out a recently acquired subsidiary Acquisition-integration risk that justified the objective is untested
Missing data Timekeeping system for contractors cannot produce a period extract Completeness of hours—often an FLSA issue—cannot be tested
Timing / freeze ERP cutover during the only available fieldwork window The period in the objective cannot be covered
Resource constraint that cuts coverage No IT auditor available, so privileged-access testing is dropped Cyber component of the objective is untested; may also engage a Topical Requirement
Imposed “no-go” topics “Do not look at executive payroll” High-risk exclusion requested by the activity under review
Identify during planning , not for the first time in the draft report. Walk-throughs, access requests, data-availability checks, and a frank conversation about locations and systems are how you find limitations before you imply that the scope is clean.
Document four things in the planning record: (1) what is limited (population, location, system, period, control area); (2) why (access denied, data does not exist, resource gap, management request); (3) who imposed or caused it; (4) impact on the ability to conclude against the written objectives. If a Topical Requirement applies, also record whether the limitation knocks out a baseline element.
Then decide whether remaining scope still supports a conclusion. Three honest outcomes exist:
Still sufficient. Excluding a de minimis location that has no payroll employees does not threaten a U.S. wage-and-hour objective. Document why it is not relevant.
Limited conclusion possible. You can conclude on in-scope company codes but cannot conclude on the acquired subsidiary. The objective or the communication of results must disclose that boundary. Do not write a full-population conclusion from a truncated scope.
Not sufficient. If overtime completeness is central to the objective and the timekeeping extract will never be produced, remaining tests of tax deposits do not rescue the engagement. Options: delay, obtain alternative evidence, change the documented objective through change control, or escalate and, if necessary, decline or defer the engagement. What you may not do is run a thin test and issue an unmodified conclusion.
Standard 13.3’s escalation logic is the exam’s backbone: discuss significant limitations with management of the activity to try to resolve them; if unresolved, take them to the CAE ; the CAE takes unresolved significant limitations to senior management and, if necessary, the board . That path is not optional customer service. A senior manager’s discomfort is not a resolution.
Evaluate and document stakeholder requests
Stakeholders will ask you to expand, delay, redirect, or narrow the engagement. Every request gets the same discipline: evaluate against risk, the internal audit charter, independence/objectivity, resources, applicable Topical Requirements, and the written objectives —then document accept or decline and the rationale.
Expand. Adding a warehouse, a regulation, or a fraud allegation can be the right risk-based move. Check capacity and skills. If you accept, you are in change-control territory: the objective and scope must be updated so the file still matches the work. An undocumented expansion is how teams either miss the new risk or get accused of a fishing expedition.
Delay. Operational timing (month-end, system freeze) can be legitimate. If delay means you cannot cover the period named in the objective, treat it as a limitation or a change , not as informal courtesy.
Redirect from assurance to advisory. “Stop the audit and just help us design the control” is a service-type change . It needs a documented agreement on the new nature and scope, a clear stop to the assurance conclusion, and a self-review analysis if the same people later assure that design. Do not keep the assurance title while doing advisory work.
Narrow. This is the dangerous request. “Please leave executive payroll out.” “Skip overtime; it makes my team look bad.” “No cybersecurity—this is an operations audit.” Evaluate it as a potential scope limitation and, if the excluded area is material to the objective or to an applicable Topical Requirement, as a potential independence/objectivity issue (subordinating judgment). Approaches that the exam considers effective:
Explain the impact on the ability to conclude and try to resolve with the requestor.
Accept a documented limitation only if remaining scope is still sufficient or the conclusion will be expressly limited—and the CAE concurs.
Decline a narrowing that would make the engagement misleading.
Escalate significant unresolved narrowing; do not “meet in the middle” by dropping the high-risk test and leaving the original objective on the page.
A request to add a low-risk pet project while dropping a high-risk area is two requests. Evaluate them separately. Accepting the pet project does not pay for dropping overtime.
Change control for mid-planning and mid-fieldwork changes
Objectives and scope are living documents, but they are not sticky notes. Effective methods have the same bones whether the change happens in week one of planning or week three of fieldwork:
Recognize the trigger. New regulation, fraud allegation, system outage, data that will never arrive, a Topical Requirement topic identified mid-engagement, a stakeholder request, a resource loss.
Assess impact on written objectives, remaining scope, resources, independence, and the ability to conclude.
Propose a documented change (revise objective, revise scope, add a limitation disclosure, pause, or split into a separate engagement).
Obtain the right approval. Routine scheduling tweaks may sit with the engagement supervisor. Changes that alter purpose, drop a high-risk area, or threaten the conclusion go to the CAE . Advisory nature/scope changes go back to the requesting stakeholder for re-agreement.
Communicate to affected stakeholders—management of the activity, the engagement team, and anyone who received the original planning communication (Standard 13.1 is about communication throughout planning, not only at the end).
Update the file : planning memo or scope statement, time budget, and any maps of what will and will not be covered. Fieldwork already performed stays in the workpapers with a note that the purpose changed; you do not pretend the old objective still governs.
Silent shrinkage is the failure mode. The payroll manager is uneasy about overtime sampling, the in-charge quietly reduces the sample and never edits the objective, and the report still says the engagement evaluated wage-and-hour compliance. That is not agile auditing. It is an undisclosed scope limitation. The same is true if a cybersecurity component becomes obvious in fieldwork and the team “stays operational” to keep the calendar.
Resource limits can cause a scope limitation. Chapter 10 treats resource implications in depth. The planning rule for this chapter is simpler: a missing specialist is not permission to keep the original objective and skip the work. Either obtain the skill, change the documented scope with CAE approval, or escalate that the engagement cannot be performed as planned.
If a change expands objectives in the field—fraud red flags in contractor payments—do not wander without a written update. Expansion without change control creates unplanned work, supervision gaps, and a report that no longer matches the opening communication. Write the new purpose, confirm it is still assurance (or explicitly convert), and then gather evidence against the new statement.
The testable sequence is always: objectives first, scope sufficient to those objectives, limitations visible, requests evaluated, changes controlled. Comfort is not a planning control.