Study guide
14.2 Structured vs Unstructured Data and the Analytics Process
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
14.2 Structured vs Unstructured Data and the Analytics Process
Key Takeaways Explain This Topic AI
B4c: structured data sits in predefined fields (tables, keys, types); non-structured data — the syllabus term, commonly called unstructured — is language, images, and documents without a reliable schema.
B4d analytics process, in order: defining objectives, obtaining relevant data, normalizing data, analyzing data, communicating results.
The classic trap is analyzing — sorting, charting, modeling — before the audit question is defined.
Normalization is hygiene (dates, units, IDs, sign convention); joining keys must identify the same real-world entity in both files; completeness against the process total comes before analysis.
Extract-duplicate rows from a bad join are not automatically a duplicate-payment condition. Chapter 11.2 was survey scans; this section is the process those scans must follow.
Last updated: August 2026
B4c and B4d: know the data, then run the steps in order
Quick Answer: B4c asks you to explain data types , including structured and non-structured (commonly called unstructured). B4d asks you to explain the data analytics process : defining objectives , obtaining relevant data , normalizing data , analyzing data , and communicating results — in that order. Hygiene, completeness, and joining keys live inside obtain-and-normalize. The classic trap is analyzing before you have an audit question .
Chapter 11.2 used data analysis as a survey source : exception scans that aim later tests. This section is the process you follow whenever analytics will support engagement work. Chapter 13 is which tools might run the query. Chapter 15 is ratio, variance, trend, and benchmarking review. Do not import those catalogs into a B4c–d item. GIAS Standard 14.1 still requires information that can be analyzed; B4d is how that analytic work is sequenced .
Structured versus non-structured data
Structured data sits in predefined fields: tables, columns, data types, keys. ERP invoice registers, payroll registers, user-access lists, general-ledger extracts, and a well-designed warehouse table are structured. Once keys are clean you can filter, join, and total them.
Non-structured data is the syllabus wording. Most shops say unstructured . There is no reliable field layout: contracts in PDF, emails, chat, images of bills of lading, recorded calls, board minutes, policy wikis, free-text ticket comments. Meaning lives in the language or the picture, not in column D.
Semi-structured sources (JSON payloads, XML invoices, application logs, an email with headers plus a free-text body) sit between. The exam's official pair is structured and non-structured, so classify by whether you can already treat it as fields . A PDF invoice that an OCR job has already turned into vendor, date, and amount is structured for that test ; the original PDF is still non-structured evidence you may need to inspect. A keyword search of 400 contracts is not a complete structured population; it is a text pass over non-structured files (Section 14.3).
Type Engagement examples What you can do readily What you cannot assume
Structured AP register, vendor master, GL, badge logs, access tables Join, sort, duplicate tests, completeness counts That field labels mean what you think (posting date versus entry date)
Non-structured Contracts, emails, invoice images, chat, policies Read, search, text analysis, sample inspect That a keyword search was complete, or that silence means the clause is absent
Semi-structured (practical middle) Logs, XML/JSON, ticket systems Parse into fields, then treat as structured That every line parsed; dropped lines are completeness issues
Internal audit uses both on the same objective. Duplicate-payment work is mostly structured (register plus vendor master). Whether the contract allowed that payment term is non-structured until you mine or read the clause. Choosing only the easy table is how you miss the right.
Board minutes stored as a PDF do not become structured because they are official. Files do not become structured because they landed in the workpaper system. Structure is schema , not prestige or storage location.
Loading diagram... B4d analytics process — do not skip to analyze
The analytics process — five steps, in order
The 2025 list is five steps. The exam will punish skipping the first.
1. Defining objectives. Write the audit question the analysis must answer, tied to engagement objectives and evaluation criteria. Examples: Are there exact duplicate vendor-invoice-amount payments in Q1 for in-scope company codes? Which user IDs both changed a vendor bank account and released a payment? Is this extract complete against the AP subledger? If you cannot say what decision the output will support, you do not have an objective. You have a fishing trip. Defining objectives is not the same as Section A's engagement objectives, but it must serve them. Run analytics on AP is not a question.
2. Obtaining relevant data. Relevant means the population, period, fields, and grain that match the question. Request the invoice register for the scoped company codes and the posting-date period, including voids, parks, and reversals on purpose — included or excluded with a reason, not because the export button omitted them. Obtain authorization and a repeatable extract: query saved, parameters screenshot. Then test information produced by the entity (IPE) : record count and dollars to the subledger or process file the walk-through used; a handful of lines to source for vendor, amount, and date. Chapter 11.2 already taught you not to scan garbage in the survey. B4d makes obtain a named step so eagerness to analyze is not an excuse to skip it.
3. Normalizing data. Make fields comparable before you join or score. Normalization is hygiene , not a finding:
Dates to one timezone and one meaning (invoice date versus posting date versus baseline date).
Currency to one unit, or as-posted amounts plus a documented FX source — not a silent mix of USD and local.
Vendor names and IDs to the same grain (strip Inc., leading zeros; know DBA versus legal name).
Amounts to one sign convention (reversals as negatives, not a second positive that inflates volume).
Text trimmed; encoding fixed so Müller does not split from Muller unless you intend that split.
Duplicate rows that are extract artifacts (the same invoice pulled twice because of a many-to-many join) removed. That is not the same as a duplicate payment condition. Hygiene first; condition second.
Joining keys are the fields that must identify the same real-world thing in two files: vendor ID, invoice number, employee ID, PO number, user ID. If AP uses vendor number and the bank file uses IBAN , you need a crosswalk, not a hopeful name match. A fuzzy name join is a method you document , not a silent default. Wrong keys manufacture false duplicates and false comfort. Display names that three people share are not a user-ID key.
Completeness belongs to obtain and normalize. If the question is the Q1 population and the extract is 3,870 rows against a 4,200-invoice subledger, stop . Find parked items, intercompany, or company code 200. Analyzing the 3,870 because we have to start somewhere is how you miss the plant that never loaded. Large is not complete.
4. Analyzing data. Only now apply the method that fits the question (Section 14.3). Sorts, matches, diagnostics, models — they all wait for a defined question and a clean, complete file. Analysis on a file you never reconciled is theater with decimals.
5. Communicating results. Tell a decision-maker what the analysis showed, with population, limitations, and what you still must test. A chart that lacks a question is decoration. This step is communication of analytic results during the engagement (Section C covers methods and stakeholders). It is not Part 3's final-report attribute list and not Chapter 15's finding elements (criteria, condition, cause, effect, significance). You can say: 18 exact duplicates, $612,000, file complete to the subledger, override IDs not yet inspected. You cannot skip to residual-risk acceptance language.
- Step Done looks like Failure mode
- Define objectives A sentence the output can answer, linked to the engagement objective Run analytics on AP
Obtain relevant data Population, period, fields, IPE, saved parameters Convenient extract from last year, or company code 100 only
- Normalize Comparable dates, units, IDs; documented join keys Joining on vendor name because numbers look messy
- Analyze Method that matches the question (14.3) Sort descending and call it predictive
- Communicate Results, limitations, next tests Screenshot of a pivot with no population statement
- Worked example: vendor master joined to AP
Objective: Identify payments released after a bank-detail change by the same user ID in Q1.
Obtain: Vendor-master change log (who, when, old/new bank), AP payment register (who released, when, vendor, amount), HR termination list (leftover IDs). Reconcile payment dollars to the subledger.
Normalize: User IDs to the live directory (display names collapse three people). Bank fields to IBAN or account-plus-routing, not free text. Timestamps to posting timezone. Vendor ID as the join key, not vendor name.
Analyze: Join change-log to payments on vendor ID where change-user equals release-user and payment date is on or after the change date. That is a structured match serving an SOD question — not yet a fraud conclusion.
Communicate: 11 payments, $2.1 million, four user IDs; two IDs belong to terminated staff. Next: inspect whether those IDs were shared, and walk two items.
If the team had sorted the payment register by amount and started calling large items high risk, they would have skipped the objective, the join, and the terminated-ID story. That is the B4d trap in one motion.
Exam traps
Analyzing before defining the audit question.
Treating non-structured PDFs as a complete population because a keyword returned hits.
Joining on names when a stable ID exists — or assuming IDs mean the same grain in both files.
Calling extract-duplicate rows a duplicate-payment finding.
Skipping completeness because the file is large enough.
Jumping from a pivot to a Part 3 residual-risk memo, or answering B4d with a Chapter 15 current-ratio calculation.
The process is done when a reviewer can re-perform the extract from saved parameters, see the completeness tie-out, name the join keys, and read a result that answers the question you wrote in step 1.