Study guide
5.3 CRM, ERP, and GRC System 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.3 CRM, ERP, and GRC System Risks
Key Takeaways Explain This Topic AI
CRM planning risks cluster on customer data (privacy and quality), access (who can see or change accounts), and revenue-process integrity (quotes, orders, discounts, and credit)
ERP planning risks cluster on master data, segregation of duties in roles, automated application controls such as match tolerances, and interfaces that can drop, duplicate, or alter transactions
GRC-system planning risks cluster on completeness of risk and control libraries, integrity of workflow (assessments, issues, attestations), and whether reporting to the board reflects the live system
The exam trap is auditing only the business process while ignoring the system that enforces it, or testing system configuration while ignoring process workarounds, overrides, and shadow spreadsheets
Last updated: August 2026
5.3 CRM, ERP, and GRC System Risks
Quick Answer: When the activity under review runs through a customer relationship management (CRM) , enterprise resource planning (ERP) , or governance, risk, and compliance (GRC) system, planning must recognize system key risks and typical controls—not only the manual process. CRM: customer data, access, and revenue-process integrity . ERP: master data , segregation of duties , automated controls , and interfaces . GRC: completeness of risk/control libraries , workflow , and reporting to the board . The trap is auditing only the process and ignoring the system that enforces it, or only the system and ignoring workarounds.
A.3.f lists these systems in the same breath as asset management and procure-to-pay. That is deliberate. Modern processes are configured in software. If you plan a sales engagement without the CRM, an inventory engagement without the ERP warehouse module, or a risk-management engagement without the GRC tool the board actually reads, you have not identified how the activity works. This is still planning recognition under Standard 13.2 . Deep IT general-control testing, privacy programs, and disaster recovery belong to Chapter 4; procedures to test operating effectiveness belong to Chapter 9. Here you learn which system risks are KEY so objectives and scope can include them.
CRM systems: customer data, access, and revenue integrity
A CRM holds prospects, accounts, contacts, opportunities, quotes, orders, and often service tickets. It is frequently the front door to order-to-cash .
Key risks. Customer data: unauthorized viewing or export of personal or commercial data; incomplete, duplicate, or stale accounts that distort pipeline and billing. Access: sharing rules, profiles, or API keys that let a wide population see or change accounts they should not; terminated users who still have logins; vendors with production access “for support.” Revenue-process integrity: quotes that bypass the price book; discounts or credit terms with no approval; orders booked before credit check; cancelled orders that still hit the ERP; salespeople editing close dates or amounts to make a target.
Typical controls. Role-based access and least-privilege sharing rules; encryption and field-level security for sensitive attributes; data-retention and deletion aligned with policy; duplicate-account rules; approval workflows for discounts, nonstandard terms, and credit; integration logs that reconcile CRM orders to the ERP; and monitoring of mass exports. If revenue recognition depends on CRM stage or “closed-won” status, planning must treat that configuration as a control , not as a sales-ops convenience.
Planning cue. Stem: sales reps apply unlimited discounts, or customer lists are exported to personal email → CRM access and revenue-process integrity, not inventory obsolescence.
ERP systems: master data, segregation, automation, and interfaces
An ERP is the system of record for many of the processes in Section 5.1: vendors, purchase orders, inventory, payables, customers, billing, and the general ledger. Planning that describes “the AP process” without naming the ERP module, roles, and interfaces is describing a paper world the organization left years ago.
Master data. Vendor, customer, material/item, price, and general-ledger master records drive every automated posting. Key risks: unauthorized or poorly reviewed changes; duplicate vendors; inactive customers still orderable; item records with the wrong unit of measure or cost; dormant accounts reused for fraud. Typical controls: change workflows, dual review of sensitive fields (bank account, payment terms, price), periodic master-data certification, and reports of changes.
Segregation of duties (SOD). ERP roles and profiles can combine powers that paper SOD charts claim are split. Key risk: a single user (or a shared generic ID) can create a vendor, post an invoice, and run payment, or can create a customer and write off the receivable. Typical controls: a ruleset of incompatible functions, provisioning through identity management, periodic SOD reviews, and emergency-access (“firefighter”) logs. Superuser or customization access is a planning risk even if everyday clerks look segregated.
Automated controls. Three-way match tolerances, duplicate-invoice edits, credit blocks, quantity tolerances on receipts, and period-close locks are application controls . Key risks: tolerances so wide the match is meaningless; controls turned off in a plant or company code; users with override rights and no logging. Typical controls: documented configuration, change control over those settings, exception reports for overrides, and a known owner for each automated control. Do not assume “the ERP has three-way match” without asking whether it is on, for this company code, at a tight enough tolerance .
Interfaces. Orders, shipments, payroll, bank files, and tax returns often move by batch job, application programming interface, or intermediate file. Key risks: dropped or duplicated transactions; mapping errors (wrong tax code, wrong warehouse); silent failure with no exception queue; timing differences that create cutoff errors. Typical controls: reconciliations of interface totals, exception queues with owners and aging, checksums or hash totals, and alerting when a job fails. An engagement on “webstore sales” that never mentions the nightly load into the ERP has missed the KEY completeness risk.
This is not a substitute for Chapter 4’s IT general controls (change management, logical access at the infrastructure layer, backup). Flag those when the ERP depends on them, then return to the application risks A.3.f is naming.
GRC systems: libraries, workflow, and board reporting
A GRC system is the tool management uses to inventory risks and controls, run assessments and certifications, track issues, and often produce packs for senior management and the board. Internal audit may also live in the same platform. A.3.f asks you to recognize it as a system under review when the activity is risk management, control self-assessment, or board risk reporting—not as a synonym for “we have governance.”
Completeness of risk and control libraries. Key risks: entire processes, locations, or regulatory obligations missing from the universe; controls copied from a template that do not exist in operations; retired products still listed as mitigated; duplicate controls that create a false sense of coverage. Typical controls: a defined owner for the universe, a change process to add or retire risks, mapping to the actual organization chart and system landscape, and periodic completeness reviews against strategy and incidents.
Workflow. Key risks: assessments closed with no evidence; issues closed by the person who owns the gap; attestations completed by a delegate who was never authorized; dates backdated; required reviewers skipped by a configuration loophole. Typical controls: enforced routing, evidence attachments, segregation between owner and closer, and audit logs of workflow events.
Reporting to the board. Key risks: dashboards fed by a side spreadsheet instead of the live GRC tables; filters that hide red-rated risks; stale extracts; KRIs that no longer match the library. Typical controls: reconciling board packs to system reports, version control, and a defined cutoff. If the board believes it is reading the GRC system and is actually reading a slide deck that was last true two quarters ago, the KEY risk is reporting integrity , not the color of the dashboard.
GRC configuration is not a conclusion that governance is effective. The system can be complete and the culture still override it. Planning must keep process (who actually manages risk) and system (what the tool enforces and reports) in the same objective set.
Comparison table: what to recognize at planning
System Key risks Typical controls Stem cue
CRM Customer data leakage or poor quality; excessive access; broken quotes/orders/discounts/credit Least-privilege sharing; field security; discount and credit workflows; CRM-to-ERP reconciliation Sales pipeline, price overrides, customer list exports
ERP Corrupt master data; SOD conflicts in roles; automated controls off or too loose; interface drops/duplicates Master-data change control; SOD ruleset; match tolerances and override logs; interface reconciliations Vendor bank changes, three-way match “in SAP,” nightly loads
GRC Incomplete libraries; weak issue/assessment workflow; board reports that do not match the live system Universe ownership; enforced routing and evidence; pack-to-system reconciliation Risk universe, control certifications, board KRIs
The process-versus-system trap
Two complementary failures show up on CIA items.
Process only. The team walk-throughs warehouse picking standard operating procedures, samples paper packing slips, and never looks at warehouse-management access, cycle-count parameters, or the interface that posts shipments to the general ledger. The SOPs can look fine while the system lets anyone adjust quantity on hand.
System only. The team screenshots ERP configuration, ticks “three-way match is enabled,” and never asks whether receiving clerks override shortages all day, whether a plant is excluded from the company-code settings, or whether a shadow spreadsheet is what supervisors actually use. Configuration is not operating reality.
The planning fix is explicit: name both the process and the enforcing system in objectives and scope . For CRM, that means order-to-cash steps and CRM access, workflows, and the interface. For ERP, process walk-throughs and master data, roles, automated controls, and interfaces. For GRC, how management assesses risk and whether the library, workflow, and board extract are complete and reliable. If a system is out of reach (hosted vendor, no access), that is a scope limitation , not a reason to pretend the process is manual.
Do not smuggle Part 3 function-management topics into this answer (annual plan construction, CAE KPIs, residual-risk acceptance protocol). Do not turn a CRM item into a Chapter 4 privacy-program essay unless the stem makes privacy the activity. Recognize the named system’s key risks , put them in the planning file, and refuse the trap of covering only one side.