AIS Governance, Ethics and Digital Transformation

Introduction

Accounting information systems (AIS) are no longer limited to recording transactions and producing financial statements. They now support enterprise planning, customer relationships, supply-chain coordination, taxation, regulatory reporting, performance management, fraud detection and strategic decision-making. Cloud platforms, application programming interfaces (APIs), robotic process automation, artificial intelligence (AI), mobile technologies and data analytics have expanded the value of AIS, but they have also increased exposure to cyberattack, privacy violations, algorithmic error, operational dependency and regulatory scrutiny.

For this reason, AIS must be governed rather than merely installed. Governance establishes who has authority, who is accountable, how risks are evaluated, how technology investments are justified, how suppliers are controlled and how ethical responsibilities are enforced. Digital transformation is therefore not simply the replacement of paper with software. It is a coordinated change in processes, information, technology, people and organisational responsibilities.

This chapter integrates IT governance, accountability, professional ethics, compliance, investment appraisal, vendor management and digital-transformation strategy. It also considers emerging technologies and develops a practical approach to designing AIS that are useful, secure, resilient and ethically responsible.

Learning Objectives

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

1. Explain the purpose and scope of AIS governance.
2. Distinguish governance from management and operational control.
3. Apply accountability, risk-management and internal-control principles to AIS.
4. Evaluate ethical issues involving financial information, privacy, cybersecurity and AI.
5. Explain how laws, regulations and professional standards influence AIS design.
6. Assess technology investments using financial and non-financial criteria.
7. Evaluate cloud and software vendors through due diligence and contract controls.
8. Develop a structured digital-transformation strategy for an accounting function.
9. Recommend resilient and responsible improvements to an AIS.

1. The Meaning and Scope of AIS Governance

AIS governance is the system by which an organisation directs, controls and evaluates its accounting information resources. It includes decision rights, policies, structures, processes, controls, performance measures and assurance activities. Its purpose is to ensure that information technology supports organisational objectives while risks remain within acceptable boundaries.

Governance should answer five fundamental questions:

• Direction: What outcomes should the AIS support?
• Authority: Who may make technology and information decisions?
• Accountability: Who is answerable when information is inaccurate, unavailable or misused?
• Risk: What could prevent the system from achieving its objectives?
• Assurance: How will management know that controls are operating effectively?

Governance is distinct from management. Governance evaluates needs, establishes priorities, approves major decisions and monitors results. Management plans and executes activities within that direction. For example, a board or technology steering committee may approve a cloud migration and define risk tolerance; management then selects suppliers, plans implementation and monitors service performance.

A sound governance structure normally includes the board or audit committee, executive management, a chief information or technology officer, the chief financial officer, information-security leadership, internal audit, process owners and users. The exact structure depends on organisational size, but responsibility should never be so dispersed that no person can be held answerable.

1.1 Governance frameworks

Several recognised frameworks support AIS governance. They are complementary rather than interchangeable.

COSO is especially useful for connecting technology controls to financial-reporting objectives. COBIT provides a broader governance and management structure for information and technology. ISO/IEC 27001 focuses on information-security management, while ISO 22301 addresses continuity. A company may use all of these without treating any one of them as a complete substitute for the others.

2. Accountability, Roles and the Three Lines

Accountability means that a person or body is answerable for decisions and outcomes. Responsibility refers to the duty to perform an activity. These concepts should be documented using a responsibility assignment matrix, such as a RACI matrix:

• Responsible: performs the work.
• Accountable: owns the outcome and approves it.
• Consulted: provides relevant expertise.
• Informed: receives updates or results.

A common weakness in AIS projects is treating the IT department as accountable for all system outcomes. IT may operate infrastructure, but finance owns accounting policies, process owners own business requirements, senior management accepts residual risk, and internal audit provides independent assurance. Accountability must therefore follow decision authority and business impact.

The three-lines model provides a useful allocation of roles:

1. First line: operational management owns risks and performs controls, such as reconciliations, approval checks and access reviews.
2. Second line: risk, compliance, security and finance functions support, monitor and challenge the first line.
3. Third line: internal audit independently evaluates governance, risk management and controls.

External auditors, regulators and certification bodies are outside the three internal lines but provide additional external assurance. Independence is essential: an internal auditor should not design and then objectively assess the same control without appropriate safeguards.

3. AIS Risk Management and Internal Control

AIS risk management is a continuing process of identifying, analysing, treating and monitoring threats to information and technology. Typical risks include:

• unauthorised access or privilege escalation;
• incomplete, duplicated or inaccurate transactions;
• system outage and loss of processing capacity;
• ransomware, phishing and other cyberattacks;
• inappropriate changes to programs or master data;
• failure of a supplier or cloud provider;
• privacy breaches;
• non-compliance with tax, financial-reporting or records-retention rules;
• biased or unexplained automated decisions; and
• loss of knowledge when key employees leave.

Risk analysis can be qualitative or quantitative. A simple qualitative model may classify risk by likelihood and impact. A quantitative expected-loss estimate can be expressed as:

Here, ALE is annualised loss expectancy in currency per year, SLE is single-loss expectancy in currency per incident, and ARO is annual rate of occurrence, measured as expected incidents per year. The model assumes that the estimated loss per event and event frequency are reasonably stable and that the estimates are meaningful. It is a decision-support approximation, not a prediction of exact future losses. For example, if a ransomware event is estimated to cause a loss of $80,000 and is expected once every four years, ARO is 0.25 and ALE is $20,000 per year. The calculation does not include the cost of controls unless those costs are separately evaluated.

Controls should be designed in relation to risks. Important AIS controls include:

• Preventive controls: segregation of duties, authentication, authorisation limits and input validation.
• Detective controls: exception reports, reconciliations, log monitoring and internal-audit testing.
• Corrective controls: backup restoration, error correction, incident response and recovery procedures.
• General IT controls: access administration, change management, backup, operations and vendor oversight.
• Application controls: completeness checks, validity tests, sequence checks, duplicate detection and automated calculations.

A control is not effective merely because it exists in a policy. It must be suitably designed, implemented and operated consistently. Evidence should show who performed it, when it was performed, what was reviewed and how exceptions were resolved.

3.1 Resilience and continuity

Availability is a financial and operational requirement. Two important continuity measures are:

• Recovery time objective (RTO): the maximum acceptable time before a service is restored after disruption.
• Recovery point objective (RPO): the maximum acceptable period of data loss measured in time.

If an organisation has an RPO of four hours, backups or replication should limit potential data loss to approximately four hours, subject to the system design. If its RTO is eight hours, recovery procedures should restore the required service within eight hours. RTO and RPO are business decisions, not simply technical specifications; more demanding objectives usually increase cost.

A resilient AIS requires tested backups, alternative processing arrangements, documented incident-response procedures, dependency mapping, recovery priorities and periodic exercises. Backups that have never been restored are an assumption, not evidence of recoverability.

4. Professional Ethics in AIS

Ethics concerns what ought to be done, not only what is legally permitted. A system can comply with a minimum legal rule and still produce an ethically unacceptable outcome. Accounting professionals commonly apply principles of integrity, objectivity, professional competence and due care, confidentiality, and professional behaviour. These principles are reflected in international and national professional codes, although exact wording and enforcement differ by jurisdiction.

4.1 Integrity and objectivity

Integrity requires truthful representation of transactions and system capabilities. A finance professional should not conceal a material system failure, override an automated control without justification or manipulate dashboards to create a misleading impression. Objectivity requires resisting conflicts of interest, management pressure and personal incentives that could distort judgement.

A technology vendor may offer gifts to an employee involved in procurement. Even if the gift does not change the decision, it may create a reasonable perception of bias. A conflict-of-interest declaration, procurement separation and transparent evaluation criteria help protect both actual and perceived objectivity.

4.2 Confidentiality and privacy

Confidentiality concerns the unauthorised disclosure or use of information obtained through professional work. Privacy is broader: it concerns how personal information is collected, used, shared, retained and deleted. AIS may contain employee identities, bank details, customer records, tax identifiers and commercially sensitive information.

Responsible data governance requires purpose limitation, data minimisation, access based on legitimate need, retention schedules, secure disposal, accurate records and documented handling of data-subject rights where applicable. Privacy obligations vary by jurisdiction, and organisations must identify the laws applicable to their activities, locations and data flows rather than assuming that one regime applies universally.

4.3 Competence and professional scepticism

Professionals should understand enough about data, technology and controls to evaluate evidence critically. Blind reliance on a software-generated result is not competence. Automated output may be incomplete because of incorrect configuration, poor source data, changed business rules or model limitations.

Professional scepticism means asking whether information is reasonable, complete and supported. It is especially important when AI produces journal-entry suggestions, risk scores, forecasts or fraud alerts. Human review should be proportionate to the consequence and uncertainty of the decision.

5. Regulatory Compliance and Assurance

AIS must support compliance with the legal and professional environment in which an organisation operates. Relevant requirements may include company law, taxation, financial-reporting standards, securities regulation, anti-money-laundering rules, employment law, electronic-transactions law, data-protection legislation and sector-specific regulation.

Compliance should be translated into system and process requirements. For example:

Compliance mapping should identify the requirement, process owner, system control, evidence produced, testing frequency and remediation owner. This avoids a common failure in which an organisation has a policy but cannot demonstrate operation.

Assurance can include management self-assessment, control testing, internal audit, external audit, penetration testing, service-organisation reports and regulatory examinations. A third-party assurance report is useful but does not remove the customer’s responsibility to assess whether the provider’s controls address the customer’s own risks. The organisation must understand the scope, period, exceptions and complementary user controls in the report.

6. Technology Investment and Business Value

Technology investment should be evaluated as a business decision, not as a contest to acquire the newest platform. The business case should identify the problem, alternatives, expected benefits, implementation cost, operating cost, risks, dependencies, affected users and measures of success.

Relevant financial methods include payback period, return on investment and discounted cash-flow analysis. A simple return on investment is:

Net benefit is the total quantified benefit less relevant costs over the selected period. The measure is easy to communicate but can ignore timing, risk and benefits that are difficult to quantify.

For investments with cash flows occurring at different times, net present value is more informative:

Here, C₀ is the initial investment at time zero, Cₜ is the net cash flow in period t, r is the discount rate per period, and n is the number of periods. Cash flows and the discount rate must use the same time unit. The method assumes that projected cash flows and the discount rate are sufficiently reliable and that cash flows can be compared on a common present-value basis. A positive NPV indicates value under the assumptions used; it does not guarantee success.

A broader appraisal should include:

• improved control quality and auditability;
• reduced processing time and error rates;
• faster close and reporting cycles;
• scalability and interoperability;
• employee experience and capability;
• cybersecurity and resilience;
• regulatory enablement;
• environmental and social effects; and
• risks of implementation failure or vendor dependence.

Worked investment example

An organisation considers an AIS upgrade costing $120,000 immediately. It expects net cash benefits of $50,000 in year 1, $55,000 in year 2 and $45,000 in year 3. Using a discount rate of 10% per year:

The present values are approximately $45,455, $45,455 and $33,809. Therefore:

Under these assumptions, the project has a positive NPV of approximately $4,719. The decision should still consider implementation risk, non-financial benefits, sensitivity to lower savings and whether the forecast includes training, migration, support and control costs. A positive NPV based on optimistic assumptions is not sufficient approval evidence.

7. Vendor and Cloud-Service Management

Outsourcing processing does not outsource accountability. A cloud provider may operate infrastructure, but the organisation remains responsible for appropriate accounting, privacy, security, compliance and business decisions.

Vendor due diligence should evaluate:

1. financial stability and ownership;
2. relevant experience and service capacity;
3. security architecture and access controls;
4. data location, transfer and subcontracting arrangements;
5. incident notification and cooperation obligations;
6. backup, recovery and continuity capabilities;
7. service-level performance and remedies;
8. audit and assurance rights;
9. data portability and exit assistance; and
10. pricing, renewal, termination and liability terms.

A service-level agreement should define measurable targets such as availability, incident response, recovery objectives, support hours and reporting. The organisation should distinguish provider responsibilities from customer responsibilities. In a cloud environment, security is usually a shared responsibility: the provider may secure the underlying infrastructure while the customer must configure identities, permissions, data and applications correctly.

Vendor concentration creates systemic risk. Dependence on one provider, one integration partner or one specialist employee can make recovery difficult. Mitigations include documented interfaces, export testing, multi-supplier strategies where justified, contractual exit support and retention of critical knowledge.

8. Digital-Transformation Strategy for AIS

Digital transformation changes how value is created and controlled. It should begin with strategic outcomes rather than technology labels. A disciplined approach includes the following stages.

Stage 1: Establish the case for change

Clarify the organisational problem. Examples include a slow month-end close, fragmented data, weak visibility over cash, repeated manual entries or inadequate regulatory reporting. Define measurable outcomes such as reducing reconciliation exceptions, shortening the close cycle or improving forecast accuracy.

Stage 2: Assess the current state

Document processes, applications, data flows, integrations, control points, manual workarounds and pain points. Identify duplicated data, spreadsheet dependencies, unsupported software and single points of failure. A process map should include both normal flow and exception handling.

Stage 3: Define the target operating model

The target state should explain future processes, roles, data ownership, technology architecture, controls and decision rights. Standardisation is often valuable, but not every process should be forced into a single design if legal, operational or customer requirements differ.

Stage 4: Prioritise the portfolio

Evaluate initiatives by strategic value, risk reduction, feasibility, dependency and cost. A small number of high-value improvements may be more effective than a large programme with weak adoption. Pilot projects can test assumptions before major investment.

Stage 5: Govern implementation

Use stage gates for requirements, design, testing, migration, training, go-live and post-implementation review. Testing should include functional, integration, security, performance, user-acceptance and recovery testing. Financial master data and opening balances require particular care during migration.

Stage 6: Manage adoption and benefits

Transformation fails when users do not understand the reason for change or when incentives favour old practices. Training should be role-specific, supported by procedures and reinforced by management. Benefits should be measured after implementation rather than assumed at approval.

Stage 7: Continuously improve

Monitor incidents, control exceptions, user feedback, process performance, security alerts and regulatory changes. Digital transformation is a continuing capability, not a one-time software installation.

9. Emerging Technologies and Responsible Use

Artificial intelligence and machine learning

AI may classify transactions, identify anomalies, extract invoice data, draft reconciliations or support forecasting. Its risks include inaccurate outputs, automation bias, non-transparent reasoning, data leakage, model drift and discriminatory outcomes. Responsible use requires documented purpose, approved data sources, validation, human oversight, access restrictions, monitoring and a clear escalation process.

An AI-generated journal entry should not be posted solely because a model produced it. The system should preserve source evidence, explain the basis of the suggestion where feasible, apply approval rules and record the reviewer’s decision.

Robotic process automation

RPA can automate repetitive, rule-based tasks, but a bot may reproduce an error at high speed. Bot credentials should be controlled, scripts should be versioned, exceptions should be reviewed and activity logs should be retained. Automation should not be used to conceal a poorly designed process.

Blockchain and distributed ledgers

Distributed-ledger technology can provide shared transaction records in selected environments, but it does not automatically guarantee that input data are accurate, that governance is appropriate or that legal rights are enforceable. It should be assessed against simpler alternatives and the organisation’s actual business problem.

APIs, open banking and real-time reporting

APIs improve integration and timeliness but increase dependency on interfaces, authentication, rate limits and data-quality controls. Real-time information is valuable only when the underlying data are accurate, authorised and appropriately interpreted.

Sustainability and digital responsibility

Technology decisions have energy, hardware, labour and disposal implications. Responsible AIS governance includes accessibility, inclusion, responsible procurement, energy considerations and avoidance of unnecessary data retention. Sustainability reporting also requires reliable definitions, evidence and control over non-financial data.

10. Illustrative Case: Meridian Components Ltd.

This is a fictional illustrative case. Meridian Components Ltd. is a medium-sized manufacturer operating in three countries. Its finance function uses a legacy enterprise system, numerous spreadsheets and a cloud payroll provider. The monthly close takes 18 working days. Bank reconciliations are partly manual, user access reviews are inconsistent and supplier master-data changes are not independently approved. Senior management proposes a rapid migration to a cloud enterprise-resource-planning platform with AI-assisted invoice processing.

Background and problem

The proposed project promises a shorter close, lower processing cost and improved group reporting. However, the initial business case excludes data cleansing, user training, parallel operation, privacy review and integration testing. The vendor’s standard contract permits subcontractors in several jurisdictions and provides only general incident-notification language.

Analysis

The governance committee identifies four major risks. First, inaccurate or duplicated supplier data could result in incorrect payments. Second, weak role design could allow one employee to create a supplier and approve payment. Third, payroll and employee information could be transferred without adequate privacy analysis. Fourth, AI invoice suggestions could be accepted without sufficient review.

A RACI analysis assigns the CFO accountability for finance-process outcomes, the CIO accountability for technology delivery, process owners responsibility for requirements and controls, the data-protection officer responsibility for privacy advice, and internal audit an independent assurance role. The committee also requires a documented risk register and stage-gate approvals.

Approach and solution

Meridian adopts a phased implementation. It first maps procure-to-pay, order-to-cash and record-to-report processes. It establishes data owners and cleans supplier and chart-of-accounts records. Role-based access is designed using least privilege and segregation-of-duties analysis. Changes to supplier master data require independent approval, and payment files require dual authorisation.

The vendor contract is revised to address data location, subcontractors, breach notification, service levels, audit evidence, recovery objectives, data export and exit assistance. Meridian tests backups and recovery before go-live. AI invoice processing is initially restricted to low-risk invoices; exceptions and low-confidence results require human review. The organisation retains source documents and an audit trail linking invoice, approval, posting and payment.

A pilot is conducted in one country, followed by parallel reporting for two close cycles. Success measures include close days, unmatched invoices, access-review completion, duplicate-payment exceptions, system availability and user adoption. Internal audit reviews the design before full deployment and performs a post-implementation review.

Outcome

The phased approach delays the final rollout but exposes data-quality and access-design problems before they become production failures. After implementation, Meridian reports improved visibility and fewer manual reconciliations, while maintaining human approval for material or unusual transactions. The project does not eliminate risk; it makes risk ownership, evidence and response more explicit.

Learning points

1. A technology business case must include control, migration, training and exit costs.
2. Cloud adoption changes responsibility; it does not remove it.
3. AI should be introduced according to risk and confidence, not novelty.
4. Data governance is a prerequisite for useful automation.
5. Phased implementation and measurable benefits reduce transformation risk.

11. Challenges and Limitations

AIS governance involves unavoidable trade-offs. Stronger controls may slow processing or increase user effort. Extensive monitoring may improve security but create privacy concerns. Standardisation can reduce cost but limit local flexibility. Real-time reporting may increase timeliness while also magnifying errors. Automation may reduce routine labour while creating new requirements for oversight and technical competence.

Quantitative investment models are limited by uncertain forecasts, omitted benefits, changing discount rates and dependence on assumptions. Risk matrices can create false precision when likelihood and impact are poorly estimated. Compliance checklists may encourage minimum compliance rather than ethical judgement. Frameworks also require interpretation; adopting a framework logo does not prove effective governance.

Finally, digital transformation can fail through cultural resistance, weak leadership, inadequate skills, poor data, unrealistic schedules or unclear accountability. Governance should therefore evaluate organisational capability as seriously as software functionality.

12. Best-Practice Recommendations

An organisation seeking responsible AIS improvement should:

• align technology decisions with business and reporting objectives;
• document decision rights and assign one accountable owner for major outcomes;
• maintain a risk register linked to controls and evidence;
• use least privilege, segregation of duties and periodic access review;
• protect data throughout collection, processing, transmission and disposal;
• test backups, incident response and recovery rather than merely documenting them;
• require independent review of material changes and high-risk automation;
• include privacy, security, continuity and exit requirements in vendor contracts;
• evaluate investments using both financial and non-financial criteria;
• introduce AI through controlled pilots with human oversight;
• measure benefits after implementation and correct underperformance; and
• cultivate ethical competence, professional scepticism and a speak-up culture.

Chapter Summary

AIS governance directs and controls information and technology so that systems support organisational objectives, comply with applicable requirements and remain within acceptable risk limits. Governance differs from management: governance establishes direction, authority and accountability, while management executes approved plans.

Effective AIS governance combines recognised frameworks, clear roles, internal controls, risk assessment, resilience planning and independent assurance. Accountability should be allocated across operational management, specialist oversight functions and internal audit. Controls must address access, change, processing accuracy, data quality, privacy, cybersecurity, continuity and auditability.

Professional ethics requires integrity, objectivity, confidentiality, competence and professional behaviour. Legal compliance is necessary but does not exhaust ethical responsibility. Technology investments should be evaluated through business cases that consider cost, benefits, risk, resilience, people and long-term dependency. NPV can support comparison of timed cash flows, but its conclusions depend on assumptions.

Vendor management must address security, privacy, service levels, subcontractors, audit rights, continuity and exit. Digital transformation is a staged organisational change involving processes, data, people, controls and technology. AI, RPA, APIs and distributed ledgers can create value, but responsible use requires validation, human oversight, traceability and risk-based governance. The central principle is that transformation should make the AIS more useful, accountable, secure, resilient and ethically defensible—not merely more technologically advanced.

Key Terms

AIS governance: Direction, control and evaluation of accounting information resources and technology.

Accountability: The obligation to answer for decisions, actions and outcomes.

COBIT: A framework for governing and managing enterprise information and technology.

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

Three lines model: Allocation of risk ownership, oversight and independent assurance across an organisation.

Risk appetite: The amount and type of risk an organisation is willing to accept in pursuing objectives.

General IT controls: Controls over access, changes, operations, backup and technology administration.

Application controls: Controls embedded in software to validate, authorise, process and report transactions.

Recovery time objective (RTO): Maximum acceptable time to restore a service.

Recovery point objective (RPO): Maximum acceptable period of data loss measured in time.

Professional scepticism: A questioning evaluation of evidence and explanations.

Data minimisation: Collecting and retaining only data necessary for a legitimate purpose.

Service-level agreement: Contractual specification of measurable service expectations and remedies.

Vendor concentration risk: Risk arising from excessive dependence on one provider or source.

Digital transformation: Organisational change using digital technologies, redesigned processes, data and capabilities.

Robotic process automation: Software automation of repetitive, rule-based activities.

Artificial intelligence: Computational techniques that perform tasks associated with human judgement or pattern recognition.

Net present value: Present value of expected future cash flows less initial investment.

Audit trail: Evidence linking transactions, approvals, changes and reports through the system.

Residual risk: Risk remaining after controls and treatments are applied.

Review Questions

Short Answer Questions

1. Distinguish AIS governance from AIS management.
2. What are the three lines in the three-lines model?
3. Define RTO and RPO.
4. State four principles relevant to professional ethics in AIS.
5. Why does outsourcing technology not outsource accountability?

Long Answer Questions

1. Explain how COSO, COBIT and ISO/IEC 27001 can complement one another in AIS governance.
2. Discuss the controls required to protect the integrity and confidentiality of accounting information.
3. Explain the stages of a responsible digital-transformation strategy for an accounting function.
4. Evaluate the financial and non-financial factors that should be included in an AIS investment decision.
5. Discuss the governance and ethical risks associated with AI-assisted accounting processes.

Analytical / Application Questions

1. An organisation wants to migrate its general ledger and payroll to a cloud provider. Develop a due-diligence and contract-control checklist addressing security, privacy, continuity, auditability and exit.
2. A finance manager proposes allowing an AI system to post all low-value invoices automatically without human review. Analyse the proposal and recommend approval conditions, controls and performance measures.
3. A company has an estimated single-loss expectancy of $100,000 for a cyber incident and an annual rate of occurrence of 0.2. Calculate the annualised loss expectancy and explain why the result alone should not determine the security budget.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes governance from management in an AIS context?

A. Governance performs all daily system operations, while management audits them.

B. Governance establishes direction and accountability, while management executes approved plans.

C. Governance is concerned only with cybersecurity, while management is concerned only with accounting.

D. Governance eliminates the need for internal controls, while management replaces them.

Correct Answer: B. Governance establishes direction and accountability, while management executes approved plans.

Question 2

Which function normally provides the third line of independent assurance?

A. Operational process owners

B. The software vendor

C. Internal audit

D. The help desk

Correct Answer: C. Internal audit

Question 3

A system has an estimated single-loss expectancy of $80,000 and an annual rate of occurrence of 0.25. What is its annualised loss expectancy?

A. $20,000

B. $80,250

C. $320,000

D. $20,250

Correct Answer: A. $20,000

Question 4

Which control is primarily preventive?

A. A post-processing exception report

B. A tested backup restoration

C. Segregation of duties over supplier creation and payment approval

D. An internal-audit investigation after an incident

Correct Answer: C. Segregation of duties over supplier creation and payment approval

Question 5

What does an RPO specify?

A. The maximum acceptable time to restore service

B. The maximum acceptable period of data loss

C. The maximum number of users on a system

D. The required time for an audit report

Correct Answer: B. The maximum acceptable period of data loss

Question 6

Which consideration is most directly associated with vendor exit risk?

A. The colour scheme of the vendor’s dashboard

B. The provider’s ability to export usable data and support transition

C. The number of employees in the customer’s finance department

D. The age of the organisation’s office building

Correct Answer: B. The provider’s ability to export usable data and support transition

Question 7

Why is human oversight important when AI suggests accounting entries?

A. AI systems cannot process any numerical information.

B. Human review can assess source evidence, exceptions and model limitations.

C. Human oversight guarantees that all entries are legally correct.

D. AI suggestions are always random until approved.

Correct Answer: B. Human review can assess source evidence, exceptions and model limitations.

Question 8

Which item is a non-financial factor in an AIS investment decision?

A. Initial purchase price only

B. Discount rate only

C. Improved auditability and regulatory capability

D. Annual depreciation only

Correct Answer: C. Improved auditability and regulatory capability

Question 9

Under a shared-responsibility cloud model, which statement is most accurate?

A. The provider is responsible for every customer configuration and access decision.

B. The customer has no responsibility once data enter the cloud.

C. Provider and customer responsibilities must be explicitly understood and controlled.

D. Cloud services cannot be audited.

Correct Answer: C. Provider and customer responsibilities must be explicitly understood and controlled.

Question 10

A positive NPV means that a project:

A. Is guaranteed to succeed operationally.

B. Creates value under the stated cash-flow and discount-rate assumptions.

C. Has no implementation risks.

D. Will recover its investment in the first period.

Correct Answer: B. Creates value under the stated cash-flow and discount-rate assumptions.