Internal Control, Enterprise Risk and Governance

Introduction and Context

Accounting information systems (AIS) and enterprise resource planning (ERP) systems transform business events into financial and operational information. They integrate purchasing, sales, inventory, payroll, production, treasury, and reporting. Integration creates efficiency, but it also creates concentration of risk: an incorrect master-data record, excessive user access, an automated configuration error, or a cyberattack can affect many processes simultaneously.

Internal control, enterprise risk management, and governance provide the organizational disciplines required to obtain reliable information, protect assets, comply with obligations, and achieve strategic objectives. In accounting and finance, these disciplines are not limited to preventing fraud. They also support accurate financial reporting, timely decision-making, business continuity, data protection, and accountability for technology-enabled processes.

This chapter applies three influential perspectives:

• COSO, which explains internal control and enterprise risk management from an organizational and objective-setting perspective;
• COBIT, which provides a governance and management framework for information and technology; and
• The Three Lines Model, which clarifies roles in risk management and assurance.

These frameworks are complementary rather than interchangeable. COSO focuses broadly on internal control and risk management, COBIT focuses on governance and management of information and technology, and the Three Lines Model focuses on responsibilities and assurance relationships.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the purposes and limitations of internal control in an AIS or ERP environment.
2. Apply the COSO framework to accounting and technology-related risks.
3. Distinguish governance from management using COBIT concepts.
4. Explain the responsibilities of the first, second, and third lines under the Three Lines Model.
5. Identify conflicts of duty and design segregation-of-duties controls.
6. Distinguish preventive, detective, and corrective controls.
7. Distinguish IT general controls from application controls.
8. Design controls that address risks through appropriate evidence, ownership, frequency, and follow-up.
9. Evaluate a practical ERP control problem and recommend improvements.

1. Internal Control in an Integrated Information Environment

Internal control is a process, effected by an entity’s board, management, and other personnel, designed to provide reasonable assurance regarding the achievement of objectives. The objectives commonly relate to operations, reporting, and compliance. Internal control is therefore a continuing activity, not a document or a one-time project.

In an AIS, controls operate at several levels. A policy may require approval of new suppliers; a workflow may route a supplier request to an authorized manager; a validation rule may reject an incomplete tax number; and a reconciliation may identify payments made to an inappropriate supplier. Effective control design considers the complete chain from business event to system record to report and decision.

Reasonable assurance and inherent limitations

Internal control cannot provide absolute assurance. Limitations include:

• human error, misunderstanding, fatigue, or poor judgment;
• management override of controls;
• collusion between two or more individuals;
• poorly designed or incorrectly implemented automated rules;
• changes in systems, regulations, suppliers, and business processes;
• cost constraints; and
• unavailable, incomplete, or corrupted evidence.

A control should be proportionate to the risk. A high-value payment process normally requires stronger authorization, access, monitoring, and reconciliation than a low-value office-supply process. Management should also consider the risk of control failure, not merely the existence of a control description.

Risk language

A risk is the possibility that an event will affect the achievement of objectives. Risk may have a negative effect, or in broader enterprise-risk usage, may include both threats and opportunities. A control objective states what must be achieved; a control activity is an action or mechanism that helps achieve it.

A useful qualitative model is:

Risk exposure = likelihood × impact

This expression is a prioritization aid, not a universal actuarial equation. Likelihood and impact must be defined consistently, and the multiplication is meaningful only when the organization uses a compatible scoring scale. Residual risk is the risk remaining after controls operate; inherent risk is assessed before considering controls.

2. The COSO Internal Control Framework

The COSO Internal Control—Integrated Framework organizes internal control into five interrelated components and seventeen principles. The five components are:

1. control environment;
2. risk assessment;
3. control activities;
4. information and communication; and
5. monitoring activities.

2.1 Control environment

The control environment establishes the tone and conditions under which controls operate. It includes integrity and ethical values, board oversight, organizational structure, assignment of authority and responsibility, competence, and accountability.

In an ERP environment, the control environment is visible in decisions such as whether senior executives comply with access approval procedures, whether finance staff can report suspected manipulation safely, and whether system owners are held accountable for unresolved control deficiencies. A policy that management routinely bypasses is weaker than a less elaborate policy that management consistently supports.

2.2 Risk assessment

Risk assessment involves specifying objectives, identifying risks, analyzing their significance, considering fraud risk, and assessing changes. Objectives should be sufficiently clear to permit risk identification. For example, “operate the ERP system effectively” is too broad to guide detailed analysis. “Ensure that only approved purchase orders can create obligations above the delegated threshold” is more precise.

Risk assessment should address risks arising from:

• unauthorized access;
• inaccurate or incomplete master data;
• inappropriate configuration;
• interface failure;
• duplicate transactions;
• fraud and management override;
• privacy and cybersecurity incidents;
• third-party service providers; and
• changes to applications, infrastructure, and regulations.

2.3 Control activities

Control activities are actions established through policies and procedures. They may be manual, automated, or hybrid. Examples include approvals, authorizations, verifications, reconciliations, reviews of operating performance, physical controls, and restrictions on access.

Controls should be linked to risks. “The finance manager reviews reports” is incomplete unless the report, review criteria, frequency, evidence, and follow-up responsibilities are specified. A well-designed control statement identifies:

• the risk addressed;
• the control owner;
• the action performed;
• the information used;
• the frequency or triggering event;
• the evidence retained; and
• the response to exceptions.

2.4 Information and communication

Relevant, quality information must be available to those who need it at the right time. Information quality includes accuracy, completeness, validity, timeliness, accessibility, and protection from unauthorized alteration.

Communication occurs internally and externally. A system administrator may need to communicate a security incident to the chief information officer, internal audit, legal counsel, and affected business owners. Financial reporting teams may need reliable communication about system changes that affect revenue recognition, inventory valuation, or tax reporting.

2.5 Monitoring activities

Monitoring determines whether the components of internal control are present and functioning. Ongoing monitoring can include supervisory review, exception reports, dashboard indicators, automated alerts, and reconciliations. Separate evaluations may be performed by internal audit or other independent reviewers.

Deficiencies should be evaluated, communicated to responsible parties, and corrected. Monitoring that identifies repeated exceptions but does not result in action is not an effective control system.

3. COBIT and Governance of Information and Technology

COBIT, published by ISACA, is a framework for the governance and management of enterprise information and technology. It helps organizations translate stakeholder needs into objectives, processes, practices, responsibilities, and performance measures. COBIT is not a detailed accounting-control checklist and does not replace financial reporting standards, cybersecurity standards, or legal requirements.

Governance and management

COBIT distinguishes governance from management:

• Governance evaluates stakeholder needs and conditions, directs priorities and decisions, and monitors performance and compliance.
• Management plans, builds, runs, and monitors activities in accordance with the direction established through governance.

For example, a board or executive governance committee may decide that resilience and protection of customer data are strategic priorities. Management then selects technologies, implements access controls, conducts recovery tests, and reports performance.

COBIT’s governance system considers components such as processes, organizational structures, information, people and competencies, principles, policies and procedures, services and infrastructure, and technology. Its objectives are grouped into governance objectives and management objectives. The framework also emphasizes design factors, such as enterprise strategy, risk profile, compliance requirements, sourcing model, threat landscape, and technology adoption.

COBIT application to ERP control

COBIT can help an organization ask whether:

• information and technology investments support enterprise objectives;
• responsibilities for ERP ownership, security, data, and operations are clear;
• changes are authorized, tested, approved, and migrated appropriately;
• service performance and incidents are monitored;
• vendors are governed and assessed;
• continuity and recovery capabilities meet business requirements; and
• technology risks are reported to the appropriate governing body.

The value of COBIT lies in connecting technology activities with enterprise objectives. Its limitation is that it requires interpretation: organizations must select relevant objectives and tailor practices to their size, complexity, risk appetite, and regulatory environment.

4. The Three Lines Model

The Three Lines Model, associated with the Institute of Internal Auditors, clarifies how responsibilities for risk and control are distributed. It is a model of roles and relationships, not necessarily three separate departments.

First line: operational ownership

The first line consists of management and personnel who deliver products and services and manage risks directly. In an ERP process, this may include a purchasing manager approving requisitions, a warehouse supervisor confirming receipts, and an accounts-payable team performing invoice processing.

The first line owns risks and controls. It should identify risks, operate controls, maintain evidence, and correct failures. Outsourcing a process does not automatically transfer accountability; management remains responsible for understanding and overseeing the risk.

Second line: expertise, support, monitoring, and challenge

The second line provides expertise, frameworks, advice, monitoring, and challenge. Examples include risk management, compliance, information security, privacy, quality, and finance-control functions. A second-line team may define access standards, monitor privileged accounts, review control self-assessments, and escalate unresolved issues.

The second line should have sufficient independence and authority to challenge the first line, although it remains part of management and is not equivalent to internal audit.

Third line: independent assurance

Internal audit is the typical third line. It provides independent and objective assurance and advice on governance, risk management, and control. Internal audit should determine its scope using risk-based planning and should report findings to an appropriate level of authority, often including an audit committee.

Internal audit should not own operational controls. If it designs or operates a control, its later independence in auditing that control may be impaired.

Relationship among the lines

The lines should cooperate without duplicating work. Their relationship can be summarized as follows:

5. Segregation of Duties and Access Governance

Segregation of duties (SoD) reduces the possibility that one person can initiate, approve, record, and conceal an inappropriate transaction. It is especially important in integrated ERP systems because one user may otherwise have access to multiple modules.

A traditional transaction cycle separates four incompatible functions:

1. Authorization: approving a transaction or commitment;
2. Custody: controlling the asset or resource;
3. Recording: entering or maintaining accounting records; and
4. Reconciliation or review: comparing records with independent evidence.

For example, the employee who creates a supplier should not ordinarily be able to approve that supplier, create a payment, and reconcile the bank account. Combining these powers creates a path for fictitious suppliers and concealed payments.

SoD design process

A practical SoD analysis proceeds as follows:

1. Define critical business processes and assets.
2. Identify tasks and system permissions within each process.
3. Identify incompatible combinations.
4. Compare required duties with actual user roles.
5. Remove unnecessary access using least privilege.
6. Design compensating controls for unavoidable conflicts.
7. Review access when employees change roles or leave.
8. Reassess conflicts after system upgrades and organizational changes.

SoD is not identical to having different job titles. Two employees may have different titles but effectively report to the same person and collude. Conversely, a small entity may be unable to achieve full separation and must use compensating controls such as independent review of supplier changes, payment reports, and bank reconciliations.

Access governance principles

Important principles include:

• least privilege: grant only access required for assigned duties;
• need to know: restrict sensitive information to legitimate users;
• role-based access: assign permissions through controlled roles rather than ad hoc individual grants;
• strong authentication: use appropriate authentication, including multifactor authentication for sensitive access;
• privileged-access management: restrict, log, and review administrative powers;
• joiner-mover-leaver controls: provision, modify, and remove access promptly; and
• periodic recertification: require owners to confirm that access remains appropriate.

6. Types of Controls

Preventive, detective, and corrective controls

Preventive controls act before an undesirable event. Examples include authorization limits, segregation of duties, input validation, and system-enforced approval workflows.

Detective controls identify an event after or while it occurs. Examples include bank reconciliations, exception reports, access-log reviews, inventory counts, and variance analysis.

Corrective controls address the cause or consequence of a problem. Examples include restoring data from a verified backup, correcting an erroneous master-data record, disabling a compromised account, and implementing a system change to prevent recurrence.

A single control may have more than one effect, but classification should reflect its primary purpose. A review that detects unauthorized payments is not preventive merely because management hopes the review will discourage future behavior.

IT general controls and application controls

IT general controls (ITGCs) support the reliable operation of information systems across applications. Common categories are:

• access management;
• program development and change management;
• computer operations, including scheduling and incident management;
• backup, recovery, and continuity; and
• infrastructure and security management.

If ITGCs are ineffective, reliance on automated application controls may be reduced because unauthorized changes could alter the control itself or the data on which it operates.

Application controls are embedded in a particular application or process. They include:

• input controls, such as required fields, format checks, and validity checks;
• processing controls, such as calculations, sequence checks, duplicate checks, and automated posting rules;
• output controls, such as report distribution, exception review, and reconciliation; and
• interface controls, such as record counts, control totals, and rejected-transaction reports.

For example, an ERP may prevent an invoice from being posted without a valid purchase order. That is an application control. The process that ensures only authorized developers can alter the invoice-matching configuration is an IT general control.

7. Designing Effective Controls

Control design should begin with the risk rather than with a preferred technology. A useful control specification includes the following elements:

• objective: what the control is intended to achieve;
• risk: what could prevent the objective;
• control activity: what is done;
• owner: who is accountable;
• frequency: when it operates;
• population or scope: what transactions, users, or systems are covered;
• evidence: how performance is demonstrated;
• exception handling: what happens when a failure is found; and
• escalation: who is informed if the issue is significant or repeated.

Controls should be precise enough to test. “Management reviews unusual transactions” should become “The controller reviews the monthly report of manual journal entries above the defined threshold, confirms supporting evidence and business purpose, documents review completion, and investigates unexplained items within ten working days.”

Manual, automated, and hybrid controls

An automated control can improve consistency and speed, but it depends on reliable configuration, data, interfaces, and access restrictions. A manual control may accommodate judgment but is more exposed to inconsistency and override. Hybrid controls combine system-generated information with human review.

Control design should consider false positives and false negatives. An excessively sensitive alert may produce alert fatigue; an overly permissive rule may allow material errors. Thresholds should be risk-based and periodically reassessed.

8. Worked Application: Procure-to-Pay Risk Analysis

Assume an organization uses an ERP system for procure-to-pay. A requester creates a purchase requisition, a manager approves it, purchasing issues a purchase order, the warehouse records receipt, accounts payable records the invoice, and treasury releases payment.

Risk identification

Key risks include:

• a user creates and approves a purchase for personal benefit;
• a fictitious supplier is established;
• goods are paid for but never received;
• the same invoice is paid twice;
• an invoice is posted to the wrong period or account;
• a user changes bank details and diverts payment; and
• a system interface omits transactions.

Control design

A three-way match is a useful application control, but it is not sufficient by itself. If an authorized user creates a false purchase order and receipt, the system may correctly match all three records. Therefore, master-data controls, SoD, physical verification, and monitoring remain necessary.

9. Illustrative Case: Northstar Components’ ERP Access Failure

Background

Northstar Components, a fictional mid-sized manufacturer, implemented an integrated ERP system. To accelerate implementation, the company assigned broad “super-user” roles to several finance and operations employees. User access was reviewed only during annual audits. The supplier-master team and accounts-payable team shared some staff, and emergency access was enabled without systematic post-use review.

Problem

A payment diversion occurred after an employee changed a supplier’s bank account and processed an invoice. The employee did not create the supplier but possessed rights to modify bank details, release invoices, and view payment status. A reconciliation detected the unusual payment two weeks later. Management initially focused on the employee’s misconduct, but the incident also revealed weak access design, inadequate monitoring, and unclear ownership between finance, information security, and internal audit.

Analysis

Using COSO, the control environment was weakened by pressure to complete implementation quickly and by insufficient accountability for access owners. Risk assessment did not consider the combined power of changing bank details and releasing invoices. Control activities lacked SoD and independent verification. Information and communication were fragmented: the bank-detail-change report was not sent to finance control owners. Monitoring relied heavily on an annual review rather than ongoing exception monitoring.

Using the Three Lines Model, the first line had not performed adequate access recertification. The second line had issued a general access policy but did not monitor privileged combinations. The third line had identified access weaknesses in a prior report, but remediation was not tracked to closure.

Using COBIT concepts, governance had not translated the strategic importance of payment integrity into clear technology-risk objectives, ownership, performance measures, and escalation requirements.

Approach and solution

Northstar implemented the following measures:

1. Bank-detail changes required dual approval, independent supplier confirmation, and a cooling-off period before high-value payment.
2. Roles were redesigned so that supplier maintenance, invoice approval, payment release, and bank reconciliation were incompatible.
3. Emergency access became time-limited, ticket-based, and subject to next-day review.
4. A daily report identified bank-detail changes, manual invoice releases, and payments to recently changed suppliers.
5. Finance owned supplier and payment controls; information security owned access standards and monitoring; internal audit independently tested design and operation.
6. Management introduced remediation deadlines and reported overdue high-risk issues to the audit committee.
7. The organization conducted a retrospective review of affected suppliers and payments and corrected compromised records.

Outcome and learning points

The immediate payment was investigated and recovery efforts began. More importantly, the company moved from an annual, largely compliance-oriented access review to risk-based continuous monitoring. The case demonstrates that a control framework is effective only when responsibilities, system permissions, evidence, monitoring, and remediation are connected. It also demonstrates that technology cannot compensate for unclear accountability or poor process design.

10. Governance, Ethics, Regulation, and Contemporary Technology

Internal control supports ethical conduct by making responsibilities visible, reducing opportunities for concealment, and creating channels for escalation. However, controls can also be misused. Excessive surveillance may violate privacy expectations; automated decisions may embed discriminatory or inaccurate data; and pressure to meet performance targets may encourage management override.

Organizations should align control design with applicable company law, financial reporting requirements, privacy obligations, records-retention rules, cybersecurity expectations, and sector regulation. The exact requirements vary by jurisdiction. Compliance should not be treated as a substitute for risk management: a legally compliant control may still be ineffective for the organization’s actual risk profile.

Artificial intelligence and analytics can strengthen monitoring by identifying unusual payment patterns, dormant accounts, access combinations, or transactions outside normal behavior. They also introduce risks involving model error, biased data, explainability, data leakage, unauthorized use of confidential information, and overreliance on automated recommendations. AI-generated alerts should have defined ownership, validation, human review where appropriate, secure data governance, and documented thresholds. An AI system should support—not eliminate—professional judgment and accountability.

Best practices

Effective AIS and ERP governance commonly includes:

• a risk-based control framework mapped to business objectives;
• clear process, data, system, and control ownership;
• role-based access and disciplined joiner-mover-leaver procedures;
• documented SoD rules and compensating controls;
• controlled system development and change management;
• reconciliations between source systems, subledgers, general ledger, and external evidence;
• reliable backup, recovery, and continuity testing;
• exception-based monitoring with defined escalation;
• evidence that demonstrates who performed a control, when, how, and with what result;
• independent assurance without transferring operational ownership to internal audit; and
• timely remediation that addresses root causes rather than merely closing findings.

Chapter Summary

Internal control is a continuing process that provides reasonable, not absolute, assurance over operations, reporting, and compliance. In AIS and ERP environments, risk can spread rapidly because integrated systems connect data, processes, and users. COSO provides five interrelated components—control environment, risk assessment, control activities, information and communication, and monitoring activities—for evaluating internal control.

COBIT complements COSO by distinguishing governance from management and by connecting information and technology decisions with enterprise objectives. The Three Lines Model clarifies that operational management owns risks, second-line functions provide expertise and challenge, and internal audit provides independent assurance. Segregation of duties separates authorization, custody, recording, and reconciliation, while least privilege and role-based access reduce opportunities for misuse.

Preventive, detective, and corrective controls work together. IT general controls support the reliability of the technology environment, whereas application controls address specific transactions and processes. Effective control design identifies the risk, owner, frequency, evidence, scope, exception response, and escalation path. Finally, strong governance requires ethical conduct, regulatory awareness, sound data practices, continuous monitoring, and accountable remediation.

Key Terms

Internal control: A process designed to provide reasonable assurance regarding operational, reporting, and compliance objectives.

Reasonable assurance: A high but not absolute level of assurance because internal control has inherent limitations.

Risk: The possibility that an event will affect the achievement of objectives.

Inherent risk: Risk assessed before considering controls.

Residual risk: Risk remaining after controls are considered.

COSO: A framework for internal control and enterprise risk management.

Control environment: The values, structures, authority, competence, and accountability that support control.

Control activity: An action or procedure designed to address a risk.

COBIT: A framework for governance and management of enterprise information and technology.

Governance: Evaluating needs, directing priorities, and monitoring performance and compliance.

Management: Planning, building, running, and monitoring activities in accordance with governance direction.

Three Lines Model: A model clarifying operational ownership, second-line support and challenge, and independent assurance.

Segregation of duties: Separation of incompatible responsibilities to reduce error and fraud risk.

Least privilege: Granting only the access necessary for assigned duties.

Preventive control: A control intended to stop an undesirable event before it occurs.

Detective control: A control intended to identify an undesirable event or condition.

Corrective control: A control intended to remedy a problem or prevent recurrence.

IT general control: A control supporting the reliable operation of the wider technology environment.

Application control: A control embedded in a particular application or transaction process.

Compensating control: An alternative control used when the preferred control cannot be implemented.

Review Questions

Short Answer Questions

1. What are the five components of the COSO Internal Control—Integrated Framework?
2. Distinguish governance from management in COBIT.
3. What is the purpose of segregation of duties?
4. Give one example each of a preventive, detective, and corrective control.
5. How does an application control differ from an IT general control?

Long Answer Questions

1. Explain how COSO can be applied to risks in an integrated ERP procure-to-pay process.
2. Discuss the responsibilities of the three lines in managing ERP access risk.
3. Explain why reasonable assurance does not mean that internal control eliminates all risk.
4. Compare manual, automated, and hybrid controls, including their principal strengths and weaknesses.
5. Discuss how COBIT complements, but does not replace, COSO in an accounting information systems environment.

Analytical / Application Questions

1. An employee can create suppliers, approve invoices, release payments, and view bank reconciliations. Identify the incompatible duties, assess the risk, and design preventive, detective, and corrective controls.
2. An automated three-way match is operating correctly, but fictitious goods receipts are being entered. Analyze why the application control is insufficient and recommend controls across COSO’s components.
3. An internal audit report identifies excessive privileged access, but management has not implemented the recommendation after nine months. Analyze the issue using the Three Lines Model and propose an escalation and remediation plan.

Multiple Choice Questions with Answers

Question 1

Which COSO component establishes the tone of the organization and includes integrity, ethical values, and accountability?

A. Control environment

B. Risk assessment

C. Control activities

D. Monitoring activities

Correct Answer: A. Control environment

Question 2

Under the Three Lines Model, who normally owns and operates day-to-day controls?

A. The external auditor

B. The first line

C. The third line

D. The governing body alone

Correct Answer: B. The first line

Question 3

Which is an IT general control?

A. A three-way match of an invoice, purchase order, and receipt

B. A duplicate-invoice check

C. A controlled program-change approval process

D. A validity check on a tax code

Correct Answer: C. A controlled program-change approval process

Question 4

Which combination of duties creates the clearest segregation-of-duties conflict?

A. Preparing a purchase requisition and tracking delivery status

B. Maintaining supplier bank details and releasing payments

C. Reviewing an exception report and escalating anomalies

D. Counting inventory and reporting count differences

Correct Answer: B. Maintaining supplier bank details and releasing payments

Question 5

A bank reconciliation primarily operates as which type of control?

A. Preventive

B. Detective

C. Corrective only

D. Authorization

Correct Answer: B. Detective

Question 6

What is the principal distinction between COBIT governance and management?

A. Governance records transactions, while management audits them

B. Governance evaluates, directs, and monitors; management plans, builds, runs, and monitors

C. Governance applies only to finance, while management applies only to IT

D. Governance prevents all risk, while management accepts all risk

Correct Answer: B. Governance evaluates, directs, and monitors; management plans, builds, runs, and monitors

Question 7

Which control best addresses unauthorized changes to ERP application code?

A. Independent bank reconciliation

B. Controlled development, testing, approval, and migration

C. Physical inventory count

D. Customer credit review

Correct Answer: B. Controlled development, testing, approval, and migration

Question 8

A compensating control is best described as:

A. A control that replaces an unavailable preferred control

B. A control that eliminates the need for risk assessment

C. A control performed only by external auditors

D. A control that guarantees zero residual risk

Correct Answer: A. A control that replaces an unavailable preferred control

Question 9

Which principle requires access to be limited to what a user needs for assigned duties?

A. Management override

B. Least privilege

C. Continuous disclosure

D. Data redundancy

Correct Answer: B. Least privilege

Question 10

Why may a correctly operating three-way match still fail to prevent fraudulent payment?

A. Three-way matching cannot compare amounts

B. The ERP cannot store receipt information

C. A false receipt may make an unauthorized transaction appear valid

D. Application controls are always corrective controls

Correct Answer: C. A false receipt may make an unauthorized transaction appear valid