5.3 CRM, ERP, and GRC System Risks

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

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.