AIS Audit, Assurance and Continuous Monitoring

Introduction and Context

Accounting information systems (AIS) process, store, transmit and report information used for financial reporting, management decision-making, regulatory compliance and operational control. Because accounting data increasingly moves through cloud platforms, application programming interfaces (APIs), robotic process automation, mobile devices and artificial-intelligence-supported tools, an audit cannot focus only on printed documents or year-end balances. It must also evaluate whether systems are properly designed, access is controlled, transactions are complete and accurate, processing is authorised, and evidence is retained.

AIS auditing is the systematic examination of information systems and technology-enabled accounting processes. It combines financial-audit objectives with information-technology control evaluation. Assurance is broader: it is a professional service intended to increase users’ confidence in information or processes by evaluating them against suitable criteria. Continuous monitoring is management’s ongoing process of reviewing controls, transactions and risk indicators, whereas continuous auditing is an auditor-led process that uses frequent or automated procedures to obtain evidence.

The central challenge is to connect technology controls with business and financial-reporting risks. A technically sophisticated system is not necessarily a controlled system, and a system with strong general controls may still contain poorly designed application rules. Effective AIS assurance therefore requires professional judgement, evidence evaluation, data analysis and clear communication.

Learning Objectives

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

1. Explain the relationship between AIS auditing, assurance, continuous auditing and continuous monitoring.
2. Identify information-system risks and map them to relevant controls and audit assertions.
3. Plan system-oriented audit procedures, including tests of controls and substantive procedures.
4. Apply computer-assisted audit techniques (CAATs), audit analytics and log analysis.
5. Interpret SOC and other assurance reports, including their scope and limitations.
6. Evaluate exceptions, communicate findings and recommend practical remediation.
7. Recognise ethical, governance, privacy, cybersecurity and artificial-intelligence considerations.

1. Assurance Architecture in an AIS Environment

Audit, assurance and related services

A financial statement audit provides reasonable assurance that financial statements are free from material misstatement, whether caused by error or fraud. An AIS audit may support that opinion by examining controls over initiation, authorisation, processing, storage and reporting. An internal audit engagement may instead assess efficiency, compliance, cybersecurity or operational resilience. A compliance review evaluates conformity with laws, policies, contracts or standards.

Reasonable assurance is high but not absolute. It is limited by sampling, the possibility of collusion or management override, the effectiveness of audit procedures, and the inherent limitations of internal control. Assurance conclusions must therefore be expressed in relation to defined criteria, a responsible party, intended users, evidence and a conclusion.

Continuous monitoring and continuous auditing

Continuous monitoring is owned by management. Examples include daily review of failed interfaces, automated segregation-of-duties alerts and dashboards showing unusual payment activity. Continuous auditing is performed by internal or external auditors and may involve recurring tests, automated scripts and near-real-time risk assessment. The two processes should complement rather than replace one another.

A useful operating model is:

Risk assessment → Control design → Data capture → Automated testing
       ↑                                                  ↓
Remediation ← Communication ← Investigation ← Exceptions

The quality of this cycle depends on reliable data, clearly assigned responsibility, appropriate thresholds and timely remediation. An alert without investigation, ownership and closure evidence is not an effective control.

Audit assertions in digital processes

Common assertions include occurrence, completeness, accuracy, cut-off, classification, existence, rights and obligations, and presentation. In an AIS, these assertions are supported by both general IT controls and application controls.

2. Risk Assessment and Control Frameworks

General IT controls

General IT controls (GITCs) affect the environment in which applications operate. Important categories are:

• Governance and risk management: policies, accountability, risk registers and oversight.
• Logical access: identity management, authentication, privileged access, role design, joiner-mover-leaver procedures and periodic reviews.
• Change management: documented requests, testing, approval, segregation of development and production, and emergency-change review.
• IT operations: job scheduling, backups, incident management, batch processing, capacity and disaster recovery.
• Cybersecurity: vulnerability management, endpoint protection, network controls, monitoring and response.
• Third-party management: due diligence, contractual controls, service-level monitoring and assurance reports.

A deficiency in a GITC can affect many applications and may prevent reliance on automated application controls. For example, an automated credit-limit check is less persuasive if developers can alter its code directly in production without approval.

Application controls

Application controls operate within a particular process. They include input validation, authorisation rules, automated calculations, edit checks, duplicate detection, interface controls, exception handling and output review. Preventive controls attempt to stop an error; detective controls identify it after occurrence; corrective controls restore the process or data.

Controls may be manual, automated or IT-dependent manual controls. An accountant’s review of an automated exception report is IT-dependent: the auditor must understand both the system that generates the report and the reviewer’s follow-up.

Control objectives and risk-control matrices

A risk-control matrix links risks, assertions, controls, control owners, frequency, evidence and planned tests. It prevents the audit from becoming a disconnected list of technical procedures. For every significant risk, the auditor should ask:

1. What could go wrong?
2. Which assertion or objective is affected?
3. Is the control suitably designed?
4. Has it operated consistently during the relevant period?
5. What evidence demonstrates operation?
6. What alternative procedure is available if reliance is inappropriate?

3. Planning and Performing System-Oriented Audit Procedures

Scoping and risk-based planning

Planning begins with an understanding of the entity, significant accounts, material processes, applications, interfaces, hosting arrangements and key reports. The auditor identifies where data originates, how it changes, where it is stored and how it reaches the general ledger or external report.

Scope should reflect risk rather than technological novelty. A small spreadsheet used for a material valuation may be more important than a complex but immaterial system. Scoping also considers confidentiality, integrity, availability, regulatory requirements, outsourcing and the risk of management override.

Walkthroughs

A walkthrough follows one or more transactions from initiation through final reporting. It normally includes inquiry, observation, inspection and reperformance. A sales walkthrough might trace a customer order to credit approval, dispatch, invoice, revenue posting, receipt and reconciliation. The purpose is to confirm understanding of the process, identify controls and locate points at which errors could enter or escape detection.

Inquiry alone is insufficient evidence that a control operated. The auditor should inspect records, observe performance where relevant and reperform selected procedures.

Tests of control

A test of control evaluates whether a control was suitably designed and operated effectively. Typical procedures include:

• inspecting access-review sign-offs;
• observing a user-provisioning process;
• inspecting change tickets and evidence of testing;
• reperformance of an interface reconciliation;
• examining a sample of approved transactions;
• using scripts to identify transactions that bypassed an approval rule.

The sample must be selected using a defensible method. If an auditor tests a sample of n items and identifies d deviations, the observed deviation rate is:

Here, p̂ is the observed deviation rate, d is the number of deviations and n is the sample size. This is descriptive; it is not automatically the maximum population deviation rate. Sampling conclusions require a defined population, a suitable selection method, an acceptable risk of incorrect reliance and consideration of the deviation pattern. A non-statistical sample still requires professional judgement and documentation.

For a population of 1,000 access records, if 12 are tested and one lacks evidence of review, the observed deviation rate is 1 ÷ 12 = 8.33%. The auditor must not conclude that exactly 8.33% of all records are deficient. The result must be evaluated against the tolerable deviation rate, the nature of the exception and the possibility that the sample was not representative.

Substantive procedures supported by technology

Substantive procedures test monetary amounts or disclosures directly. In AIS audits, they may include full-population analytics, recalculation, confirmation, tracing from source documents to the ledger, vouching from ledger entries to evidence, and reconciliation of independent data sources.

Controls testing and substantive testing answer different questions. A successful approval-control test provides evidence about the operation of approval, not necessarily about the accuracy or recoverability of every resulting balance. Conversely, a substantive analytical procedure may detect misstatement without demonstrating why it occurred or whether the control is sustainable.

4. CAATs, Audit Analytics and Logs

Categories of CAATs

Computer-assisted audit techniques include audit software, database queries, spreadsheets, scripts, process-mining tools and data-visualisation platforms. Common techniques are:

• Data extraction: obtaining ledger, subledger, master-file, access and log data.
• Recalculation: independently recomputing interest, depreciation, tax, totals or ageing.
• Completeness testing: comparing record counts, sequence ranges, control totals and interface logs.
• Duplicate testing: identifying repeated invoice numbers, bank accounts, amounts or payment references.
• Stratification: grouping transactions by value, date, user, location or risk.
• Benford-style analysis: identifying unusual leading-digit patterns as risk indicators, not proof of fraud.
• Exception testing: searching for weekend postings, entries after close, manual journal overrides or transactions above limits.
• Process mining: reconstructing actual event paths and comparing them with the approved process.

The audit trail must be preserved. Analysts should document data owners, extraction dates, filters, transformations, scripts, versions, access permissions and hash or reconciliation evidence where appropriate. An attractive dashboard is not reliable evidence unless its underlying data and logic are controlled.

Audit logs

Logs may record authentication, privilege changes, configuration changes, data access, API calls, failed jobs, journal postings and administrative actions. Their usefulness depends on completeness, accurate timestamps, identity attribution, retention, protection from alteration and the ability to correlate events across systems.

An auditor should examine whether logging is enabled for high-risk events, whether logs are reviewed, who can delete or alter them, whether time is synchronised, and whether alerts are investigated. A log showing that a privileged account changed a vendor bank account is a lead requiring corroboration, not by itself proof of improper conduct.

Analytics: risk scoring and false positives

A simple risk score may combine indicators such as unusual timing, high value, new vendor and override status. Such scores are prioritisation tools, not conclusions. If an automated rule identifies 100 alerts and 20 are confirmed as genuine exceptions, the positive predictive value is:

PPV depends on the quality of the rule and the underlying population. A low PPV may create alert fatigue; a high threshold may reduce false positives but increase false negatives. Thresholds should be periodically evaluated using investigation outcomes, and important cases should not be excluded merely because a model assigns them a low score.

5. Interpreting Assurance Reports

Service organisation reports

Organisations commonly outsource payroll, hosting, payment processing or enterprise-resource planning. The user auditor must understand the service provider’s controls and the effect of those controls on the user entity’s risks.

A SOC 1 report addresses controls relevant to user entities’ internal control over financial reporting. A SOC 2 report addresses trust-services criteria such as security, availability, processing integrity, confidentiality or privacy. Terminology and report forms depend on the applicable professional framework and jurisdiction; the auditor should not treat SOC 2 as a substitute for a financial statement audit.

A Type 1 report describes the design and implementation of controls at a specified date. A Type 2 report includes tests of operating effectiveness over a period and the service auditor’s results. When reading a report, examine:

1. the period and date covered;
2. the description of the system;
3. the control objectives and controls;
4. the service auditor’s opinion;
5. exceptions and management responses;
6. complementary user-entity controls (CUECs);
7. subservice organisations and the carve-out or inclusive method;
8. the suitability of criteria and restrictions on use.

A clean opinion does not mean that every risk is eliminated. CUECs may require the user entity to review access, reconcile reports or configure interfaces. If those controls are not performed, reliance may be impaired even when the provider’s controls operated effectively.

Other assurance evidence

Penetration-test reports, ISO certification, internal-audit reports and management dashboards may inform risk assessment, but each has a defined scope and purpose. Certification generally indicates conformity against specified criteria at a particular time; it is not a universal guarantee of security or financial-reporting reliability.

6. Communicating Findings and Remediation

A useful finding contains a condition, criterion, cause, effect or risk, and recommendation. For example:

• Condition: 14 of 60 privileged-access reviews lacked documented approval.
• Criterion: The access policy requires quarterly review and evidence of approval.
• Cause: Review responsibility was not assigned after a system migration.
• Effect/risk: Excessive access could permit unauthorised changes to vendor and payment data.
• Recommendation: Assign an accountable owner, use a system-generated review workflow, remove unnecessary access promptly and retain evidence.

Findings should distinguish confirmed errors from control weaknesses and risk indicators. Severity should consider likelihood, potential impact, duration, affected population, compensating controls and regulatory consequences. Management’s response should specify an owner, action, target date, resources and success measure.

A professional report is clear, balanced and evidence-based. It should avoid overstating certainty, disclose scope limitations and protect confidential information. Significant matters should be escalated through the organisation’s governance structure, including the audit committee where appropriate.

7. Governance, Ethics and Emerging Technology

AIS assurance involves sensitive personal, financial and security data. Auditors must maintain confidentiality, independence, competence, professional scepticism and due care. They should obtain only necessary data, restrict access, protect extracts and securely destroy them when retention requirements end.

Artificial intelligence can assist anomaly detection, classification, code review and prioritisation. However, models may be biased, opaque, unstable or trained on poor-quality data. An auditor should evaluate data lineage, model governance, access to prompts and outputs, change control, human review, reproducibility and the risk of fabricated or unsupported results. AI output is evidence only when its operation, data and results can be evaluated; it is not a replacement for professional judgement.

Cloud and API-based architectures create shared-responsibility risks. The provider may secure infrastructure while the customer remains responsible for identities, configurations, data classification and business-process controls. Continuous monitoring should therefore cover configuration drift, abnormal privileged activity, failed interfaces, unapproved changes and unusual transaction patterns.

Illustrative Case: Northbridge Retail Group

Background

Northbridge Retail Group uses a cloud ERP system for purchasing, inventory and accounts payable. Supplier bank details are maintained by the procurement team, while payments are released by treasury. The company experienced two near-miss payments to unauthorised bank accounts.

Problem

Management believed that segregation of duties prevented fraud. An initial review found that emergency access could be granted by a system administrator and that the access report excluded temporary accounts. The vendor-change log also recorded events in local server time, while payment logs used coordinated universal time, making correlation difficult.

Analysis

The audit team mapped the process from vendor creation to payment. It extracted vendor-master changes, user roles, approval records and payment files for twelve months. A full-population test identified vendor-bank changes made within 24 hours of a payment and changes performed by privileged or temporary users. Twenty-three cases were flagged; investigation confirmed that 21 were legitimate due to supplier mergers, while two lacked independent confirmation.

The team also tested the interface from the ERP to the bank. Record counts agreed for ordinary batches, but failed transfers were manually re-entered without a documented second-person review. The service provider’s SOC 1 Type 2 report covered the ERP application but excluded the bank interface, which remained a complementary user-entity responsibility.

Approach and solution

Northbridge introduced independent supplier callback verification, prohibited direct payment release by vendor-master administrators, and required documented approval for emergency access. It synchronised timestamps, retained immutable audit logs and created daily monitoring rules for high-risk vendor changes. Treasury received an exception report, and unresolved exceptions were escalated within one business day.

Outcome

After three months, monitoring identified no unauthorised payment, but it revealed four legitimate emergency changes that lacked timely closure documentation. Management corrected the documentation weakness and revised the emergency-access procedure. The audit conclusion was that the control environment had improved, but operating effectiveness required continued monitoring.

Learning points

The case demonstrates that segregation of duties must include temporary and emergency access, that interfaces may fall outside a service provider’s assurance report, and that analytics generate leads requiring investigation. It also illustrates why timestamp integrity and clear ownership are essential to a reliable audit trail.

Challenges and Limitations

AIS auditing faces rapidly changing systems, fragmented data ownership, outsourced processing, encryption, insufficient logging, incompatible data formats and scarce specialist skills. Automated testing can create false assurance when populations are incomplete or scripts are not independently reviewed. Continuous monitoring can also produce excessive alerts, encourage superficial compliance and raise privacy concerns.

Auditors should document limitations explicitly, validate completeness and accuracy of data, test the logic of analytics, retain reproducible evidence and combine automated procedures with interviews, inspection, observation and professional judgement. No single control or report establishes assurance over the entire AIS.

Best-Practice Audit Workflow

A disciplined workflow is:

1. Define users, objectives, criteria and material risks.
2. Map processes, applications, interfaces, data stores and responsible parties.
3. Identify GITCs, application controls and CUECs.
4. Perform walkthroughs and assess control design.
5. Obtain complete, accurate and authorised data.
6. Design control and substantive tests proportionate to risk.
7. Validate scripts, parameters, samples and exception populations.
8. Investigate exceptions and corroborate conclusions.
9. Evaluate service-provider reports and scope limitations.
10. Communicate findings with owners, dates and risk-based priorities.
11. Follow up remediation and test whether improvements operate effectively.

Chapter Summary

AIS audit and assurance connect financial-reporting objectives with technology, data and process risks. General IT controls establish the environment for reliable applications, while application controls address transaction-level risks. Auditors plan through risk assessment, process walkthroughs, control testing and substantive procedures. CAATs, audit analytics and log analysis can test complete populations and identify unusual activity, but their conclusions depend on data quality, controlled scripts and human investigation. SOC 1 and SOC 2 reports must be interpreted according to their purpose, period, scope, exceptions and complementary user controls. Continuous monitoring is management-owned; continuous auditing is auditor-led. Effective communication describes evidence, criteria, cause, effect and remediation without overstating certainty. Privacy, independence, cybersecurity, cloud responsibility and AI governance are essential to credible modern assurance.

Key Terms

AIS audit: Examination of technology-enabled accounting processes and controls.

Assurance: A service that increases intended users’ confidence in information or processes.

Continuous auditing: Auditor-led recurring or automated evidence-gathering and evaluation.

Continuous monitoring: Management’s ongoing review of controls, transactions and risks.

General IT controls: Controls over access, changes, operations, security and governance.

Application control: A control embedded in a specific business application.

IT-dependent manual control: A human control that relies on system-generated information.

CAAT: A computer-assisted audit technique used to obtain or analyse evidence.

Audit trail: Records showing events, users, times and changes in a system.

Control objective: The outcome a control is intended to achieve.

Risk-control matrix: A structured link between risks, controls, evidence and tests.

Walkthrough: Tracing a transaction through a process to validate understanding.

Deviation: A departure from a prescribed control procedure.

SOC 1: A service-organisation report relevant to user entities’ financial reporting controls.

SOC 2: A report addressing specified trust-services criteria.

CUEC: A complementary user-entity control required for a service control to function.

False positive: An alert incorrectly classified as an exception.

Process mining: Reconstruction and analysis of actual process paths from event data.

Management override: Circumvention of controls by authorised management personnel.

Review Questions

Short Answer Questions

1. Distinguish continuous monitoring from continuous auditing.
2. What are general IT controls? Give three examples.
3. Why is inquiry alone generally insufficient evidence that a control operated?
4. What information should an auditor examine in a SOC 1 report?
5. Define a complementary user-entity control.

Long Answer Questions

1. Explain how an auditor should plan an AIS audit from risk assessment through reporting.
2. Compare preventive, detective and corrective application controls with examples.
3. Explain how CAATs and audit analytics can test completeness, accuracy and occurrence.
4. Discuss the interpretation and limitations of Type 1 and Type 2 service-organisation reports.
5. Evaluate the ethical, privacy and governance risks of using AI in continuous monitoring.

Analytical / Application Questions

1. An auditor tests 40 access reviews and finds three without evidence of approval. Explain what can and cannot be concluded, and identify further procedures.
2. A payment-monitoring rule produces 200 alerts, of which 30 are confirmed exceptions. Calculate the PPV and recommend how the monitoring process should be evaluated.
3. Design a risk-control matrix and continuous-monitoring plan for supplier bank-account changes in a cloud ERP system.

Multiple Choice Questions with Answers

Question 1

Which activity is primarily management’s responsibility?

A. Continuous monitoring of controls

B. Issuing an external audit opinion

C. Testing a financial statement audit sample

D. Interpreting a service auditor’s report for audit evidence

Correct Answer: A. Continuous monitoring of controls

Question 2

Which control is a general IT control?

A. Three-way matching of an invoice

B. Quarterly review of privileged access

C. Automated tax calculation

D. Duplicate invoice-number validation

Correct Answer: B. Quarterly review of privileged access

Question 3

An auditor tests 20 controls and finds 2 deviations. What is the observed deviation rate?

A. 2%

B. 5%

C. 10%

D. 20%

Correct Answer: C. 10%

Question 4

What does a Type 2 service-organisation report generally include?

A. Only management’s future control plans

B. Operating-effectiveness testing over a period

C. A guarantee that no user-entity controls are needed

D. A complete opinion on the user entity’s financial statements

Correct Answer: B. Operating-effectiveness testing over a period

Question 5

Which assertion is most directly addressed by reconciling record counts across an interface?

A. Completeness

B. Classification

C. Rights and obligations

D. Presentation

Correct Answer: A. Completeness

Question 6

A log showing a privileged user changed a vendor bank account is best treated initially as:

A. Conclusive proof of fraud

B. A risk indicator requiring corroboration

C. Evidence that the payment is valid

D. A substitute for management investigation

Correct Answer: B. A risk indicator requiring corroboration

Question 7

If 20 of 100 alerts are confirmed exceptions, the positive predictive value is:

A. 5%

B. 20%

C. 80%

D. 120%

Correct Answer: B. 20%

Question 8

Which item is commonly a complementary user-entity control?

A. The provider’s internal payroll policy

B. The provider’s building security design

C. The customer’s review of system-generated access reports

D. The auditor’s selection of financial-statement samples

Correct Answer: C. The customer’s review of system-generated access reports

Question 9

What is the main purpose of a process walkthrough?

A. To guarantee that every transaction is correct

B. To trace transactions and validate process understanding

C. To replace all substantive procedures

D. To determine the market value of the entity

Correct Answer: B. To trace transactions and validate process understanding

Question 10

Which practice most improves the reproducibility of audit analytics?

A. Deleting the original data after analysis

B. Changing filters without documenting them

C. Retaining scripts, parameters, data lineage and transformation records

D. Relying solely on a visual dashboard

Correct Answer: C. Retaining scripts, parameters, data lineage and transformation records