Study guide
11.2 Data Analysis as an Information Source
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
11.2 Data Analysis as an Information Source
Key Takeaways Explain This Topic AI
B1a includes data analyses as a method of obtaining information, alongside interviews, observations, and walk-throughs.
In the preliminary survey, full-population scans (duplicates, round-dollar amounts, weekend or holiday postings, sequence gaps) are used to focus later tests — not to issue final conclusions.
Diagnostic, prescriptive, and predictive analytics as an engagement product are Chapter 14; do not import that catalog into the survey.
Information produced by the entity (IPE) must be complete and accurate enough for the scan's purpose; analyzing an incomplete extract aims later tests at the wrong population.
Survey output is a list of areas of focus, refined procedures, and populations worth examining — not a finding that fraud occurred because 18 duplicates appeared on a first-pass report.
Last updated: August 2026
Data analysis is a B1a method, not a closing argument
Quick Answer: Data analyses are the remaining B1a method of obtaining information, with interviews, observations, and walk-throughs. In the preliminary survey , you use data to focus later tests : full-population exception scans for duplicates, round-dollar amounts, weekend postings, and similar anomalies. That output is a map of where to look . Diagnostic and predictive analytics as analysis methods are Chapter 14 . Do not analyze garbage: if the extract is incomplete, the exception list is not a picture of risk.
A walk-through showed you one unmatched invoice that still paid. Data analysis asks a different survey question: how common is that pattern in the whole file? You do not need a data-scientist title to use the method. You need a defined objective, a population that matches the process you just walked, and the humility to treat the first report as a lead list.
GIAS Standard 14.1 still sits in the background: you gather information in order to analyze and evaluate. This section is only the source . Chapter 12 is whether that source is relevant, sufficient, and reliable enough to support a finding. Chapter 14 is when to use diagnostic, prescriptive, predictive, anomaly, and text methods, and how to run the analytics process (objectives, obtain, normalize, analyze, communicate). If an item asks which survey procedure will best aim AP tests at duplicate payments, the answer is a population scan, not a neural net.
Survey analytics versus later analytics
Survey data analysis (this section) Later / Chapter 14 analytics
Job Obtain information that focuses procedures Analyze information to support findings; choose diagnostic, prescriptive, predictive, anomaly, or text methods
Typical work Full-population exception scans; simple sorts and matches; counts of red-flag types Root-cause and effect analysis; models; dashboards as an engagement product
Unit of success "18 exact duplicates and 9 weekend postings — test those populations" "Duplicates cluster in vendor 4412 after a bank-detail change; condition vs criteria; significance"
Danger Calling the scan a conclusion ("fraud") or skipping IPE Running a model on a file you never reconciled to the process
Survey analytics are usually descriptive and exception-seeking . You are allowed to notice a pattern. You are not allowed to skip the investigation that turns a pattern into a condition. Eighteen duplicate invoice numbers can be a system-assign glitch, a re-post after a failed payment, or a second payment to a real vendor. The scan tells you which rows to walk and which vendors to interview. It does not tell the audit committee that fraud occurred.
Full-population exception scans that earn their keep
When the process posts to a system you can extract, a full-population scan in the survey is often cheaper than guessing which 40 items to sample. You are still in B1 (source of information), not in sampling theory. Common survey scans:
Duplicates. Exact matches on vendor + invoice number + amount catch the obvious double-pay. Near-duplicates (same vendor and amount, invoice number off by one character; same invoice number, two vendor IDs) catch splits and master-file clones. The survey output is a list, a dollar total, and a decision: examine all of them, or stratify and test the large ones plus a slice of the rest.
Round-dollar amounts. Invoices ending in 000 or 00.00 are not illegal. They are over-represented in manual journals, estimated accruals, and "just pay it" overrides. A survey count that shows 41 round-dollar vendor invoices over $10,000 in a process that is supposed to be three-way matched is a reason to walk those items and inspect override user IDs. It is not a finding that round-dollar equals fictitious.
Weekend and holiday postings. If the designed review happens on business-day afternoons, postings time-stamped Saturday 02:14 either bypassed the review or used a shared ID. Pair the scan with the interview hint about "the weekend upload." Nine weekend postings in a quarter is a focus area for later tests of the upload job, access, and whether the Friday proposal review ever saw those invoices.
Other survey-useful scans. Sequence gaps in check or invoice numbers; vendors with the same bank account as an employee; payments just under an approval threshold; users who both created a vendor and released a payment. Pick scans that match this engagement's risks , not a generic "run Benford because we have ACL." A payroll engagement cares about duplicate bank accounts and hours over a plausible week; a treasury engagement cares about beneficiary changes and off-hours wires.
Scan What it can flag in survey What it cannot prove by itself
Exact duplicate vendor + invoice + amount Possible double payment or re-post Intent, loss, or that the control never operated
Round-dollar over a threshold Manual or override-heavy items That round amounts are fictitious
Weekend / holiday posting times Activity outside the designed review window That every weekend posting is unauthorized
- Same employee and vendor bank account A conflict worth walking Payroll fraud without HR and payment-file work
- Amounts just under approval limits Possible splitting That splitting occurred on every item near the limit
- Worked example: AP survey scan
You extract the AP invoice register for the quarter after reconciling record count and total to the subledger (IPE, below). Scans return 18 exact duplicates ($612,000), 41 round-dollar invoices over $10,000, 9 weekend postings, and 12 same-vendor same-invoice-number pairs with different amounts. You do not draft four findings. You:
Put duplicate and weekend populations on the work program as examine-all or high-priority tests.
Walk two round-dollar overrides to see whether the same user ID completed match and override (tying back to 11.1).
Interview the clerk who mentioned weekend uploads, now with nine timestamps on the table.
Leave predictive scoring of "likely fraudulent vendor" for a Chapter 14 discussion if the function even does that work — it is not the survey product.
The chart below is the survey output : counts that aim hours. Dollar investigation, root cause, and significance wait until you have evidence Chapter 12 would respect.
Illustrative AP survey exception counts (focus later tests; do not conclude yet)
Loading diagram... Survey data analysis produces focus areas, not engagement conclusions
IPE: do not analyze garbage
Information produced by the entity (IPE) is the report, extract, query, or spreadsheet the organization produces that you are about to treat as the population. Chapter 9.2 introduced IPE when a control is a human review of a system report. Here the IPE is the source you are scanning. If company code 200 is missing, your "no weekend postings" result is a statement about company code 100. If the date parameter is invoice-entry date and you think it is posting date, weekend flags are fiction.
Before you trust a survey scan:
Complete — record count and total dollars reconcile to the subledger or process file that the walk-through used; parked, held, intercompany, and voided items are included or excluded on purpose .
Accurate — a sample of lines traces to source documents for vendor, amount, and date; user IDs are the live IDs, not display names that several people share.
Parameters — period, company codes, document types, and status flags match the activity under review. Screenshot or save the query.
You do not need Chapter 12's full reliability rubric to refuse a bad file. You need the survey discipline: wrong population in, wrong focus out . If IT cannot get a complete extract this week, say so in the work program, use another method (walk-throughs, observations) for those days, and do not pretend a partial scan covered the plant you never received.
How far IPE work has to go before a finding can rest on the scan is an evidence-quality question (Chapter 12). This section only stops you from aiming the engagement at a hole in the extract.
Planning output: areas of focus, not final conclusions
Write the survey analytics so a reviewer sees:
The objective the scan served (focus duplicate-payment tests; see whether weekend activity exists).
The population and IPE steps.
Exception counts and dollars as leads .
The procedure changes: examine-all duplicates; add a walk-through of the weekend job; inspect override IDs on round-dollar items; drop a low-value scan that matched no engagement risk.
Do not write "management's AP process is ineffective" from a first-pass duplicate list. Do not skip interviews and walk-throughs because the spreadsheet is colorful. Do not run a full predictive model in week one and call B1a complete — that is a different syllabus bullet.
Exam traps
Treating a survey exception scan as proof of fraud or as a substitute for period testing.
Analyzing an extract you never reconciled to the process (garbage in).
Importing Chapter 14's diagnostic/predictive catalog into a B1a method-choice item.
Skipping data analysis entirely on a high-volume automated process because "we always sample 40."
Using scans that do not match this activity's risks (Benford on a 12-invoice grant, weekend flags on a plant that posts only on Saturdays by design).
Survey data analysis is done when later procedures have a named population to hit, and when you can explain why that population is the live file, not a convenient slice of it.