Cyber Risk Management & Auditing

Chapter 13
Audit Analytics, Automation and Continuous Assurance

Post Graduate Program in Information Technology
Cyber Risk Management & Auditing   •   Post Graduate

Audit Analytics, Automation and Continuous Assurance

Introduction

Cyber risk auditing is moving from periodic inspection toward evidence-driven, technology-enabled assurance. Traditional audits commonly select a sample of transactions, interview control owners, inspect documents, and report conditions observed during a defined period. These methods remain valuable, but they can be too slow for rapidly changing cloud services, identity environments, software pipelines, and security operations. Audit analytics, automation, process mining, security telemetry, and continuous control monitoring extend the auditor’s reach by enabling broader coverage, more frequent testing, and earlier identification of exceptions.

Technology does not, however, eliminate audit judgment. Automated tests may operate on incomplete, duplicated, poorly defined, or manipulated data. A machine-learning model may identify correlations without establishing control failure or risk causation. A dashboard may display a large volume of indicators while obscuring a material weakness. Continuous assurance therefore requires both technical competence and professional scepticism.

This chapter examines how analytics and automation can support cyber risk management and auditing. It focuses on the audit life cycle, data quality, control monitoring, process mining, automated evidence, audit-management platforms, model limitations, artificial intelligence governance, and the design of a defensible continuous-assurance programme.

Learning Objectives

After completing this chapter, a learner should be able to:

  1. Distinguish audit analytics, continuous auditing, continuous monitoring, and continuous assurance.
  2. Design an analytics workflow from risk question to validated audit conclusion.
  3. Apply security telemetry and automated evidence collection to test cyber controls.
  4. Interpret process-mining results and identify process deviations.
  5. Evaluate data quality, statistical limitations, false positives, and false negatives.
  6. Assess responsible uses of artificial intelligence in audit.
  7. Design governance, documentation, access control, and human-review mechanisms for audit automation.

1. From Periodic Auditing to Continuous Assurance

Audit analytics is the systematic use of data, statistical techniques, queries, visualisation, and computational methods to obtain and evaluate audit evidence. It may support planning, risk assessment, substantive testing, control testing, sampling, anomaly detection, and reporting.

Continuous auditing is an approach in which audit procedures are performed more frequently or continuously, often using automated data acquisition and testing. Continuous monitoring is management’s ongoing observation of controls, risks, and operations. The distinction is important: monitoring is a management responsibility, whereas auditing provides independent or objective assurance. Continuous assurance is the broader outcome produced when reliable, timely evidence supports ongoing conclusions about risk and control effectiveness.

A useful conceptual relationship is:

  • Monitoring asks, “Are operations and controls functioning as management expects?”
  • Auditing asks, “Is the evidence sufficient and reliable to support an independent conclusion?”
  • Assurance asks, “How much justified confidence can stakeholders place in the resulting conclusion?”

Automation can improve frequency and coverage, but assurance also depends on the authority, competence, independence, evidence reliability, and methodological discipline of the assurance provider.

The audit analytics life cycle

A defensible analytics engagement normally follows these stages:

  1. Define the risk question. For example: “Were privileged accounts reviewed and remediated within the required period?”
  2. Translate the question into control criteria. Specify population, time period, thresholds, responsible roles, and required evidence.
  3. Identify data sources. Sources may include identity-management systems, ticketing tools, vulnerability scanners, cloud APIs, endpoint platforms, source-control systems, and configuration repositories.
  4. Acquire and preserve data. Record extraction time, query logic, system owner, access method, time zone, filters, and hash or integrity information where appropriate.
  5. Profile and validate data. Examine completeness, duplicates, missing values, timestamp consistency, unexpected categories, and reconciliation to authoritative totals.
  6. Execute tests. Use deterministic rules, statistical methods, process mining, or carefully governed machine-learning tools.
  7. Investigate exceptions. An exception is an item requiring explanation; it is not automatically a control failure.
  8. Corroborate and conclude. Compare results with other evidence and assess whether the control objective was achieved.
  9. Document and communicate. Preserve reproducible scripts, assumptions, evidence lineage, reviewer sign-off, and limitations.
  10. Feed results into remediation. Assign owners, due dates, risk ratings, and validation procedures.

The crucial design principle is that the risk question precedes the tool. Selecting a platform first often produces impressive visualisations that are weakly connected to audit objectives.

2. Data Foundations for Cyber Audit Analytics

Data sources and telemetry

Cyber audit analytics may use four broad data classes:

Data classExamplesTypical audit use
Identity and accessLogins, role assignments, MFA status, access reviewsLeast privilege, joiner–mover–leaver controls
Security operationsAlerts, endpoint events, vulnerability findings, incident ticketsDetection, response, remediation timeliness
Technology configurationCloud settings, firewall rules, code repositories, configuration snapshotsSecure configuration and change control
Business process recordsTickets, approvals, deployment records, asset registersSegregation of duties and process compliance

Telemetry is generated for operational purposes, not necessarily for audit. Consequently, the auditor must establish whether fields have stable definitions, whether clocks are synchronised, whether records can be altered, and whether retention is adequate for the audit period.

Data quality dimensions

Data quality is multidimensional. Important dimensions include:

  • Completeness: required records and fields are present.
  • Accuracy: values correctly represent the underlying event.
  • Validity: values conform to permitted formats and definitions.
  • Consistency: related systems use compatible definitions and values.
  • Timeliness: records are available within the required time window.
  • Uniqueness: one event is not counted repeatedly.
  • Integrity and provenance: records are protected and their origin is traceable.

A simple completeness measure for a required field is:

Completeness = (Number of records with a usable value ÷ Total records expected) × 100%

The formula assumes that the expected population is known and that a “usable value” has been defined in advance. A value containing an empty string, placeholder, or invalid identifier should not be treated as complete merely because the field is technically populated.

For example, if 9,600 of 10,000 expected access-review records contain a valid reviewer identifier, completeness is 96%. This does not establish accuracy or control effectiveness; it only describes the tested field and population.

Population reconciliation

Before relying on analytics, reconcile the extracted population to an independent control total where possible. If a system reports 12,400 privileged accounts but the identity governance platform reports 12,050, the difference must be investigated. Possible explanations include different extraction times, account definitions, deactivated records, service accounts, or missing integrations. An unexplained difference is an evidence limitation, not merely a technical inconvenience.

Time and identity normalization

Security events frequently use different time zones, timestamp precision, and clock sources. Audit logic should define whether comparisons use UTC, local time, or a documented business time zone. Identity resolution is equally important: “j.smith,” an email address, an HR identifier, and a directory object may represent the same person—or different people. A reliable crosswalk should be controlled, versioned, and independently reviewed.

3. Designing Analytics Tests

Deterministic control tests

A deterministic test applies an explicit rule to each record. For example, a privileged access review may require:

  • an identified owner;
  • completion every 90 days;
  • review of all active privileged accounts;
  • documented removal or approval of inappropriate access; and
  • evidence retained in an approved repository.

A query can identify accounts whose last review date exceeds the allowed interval, but the audit conclusion still requires consideration of exceptions, approved extensions, system scope, and evidence authenticity.

Sampling and full-population analysis

Full-population testing is attractive when data are available and reliable. It can identify every record violating a simple rule. It does not guarantee that the rule is complete or that the population is accurate. Sampling remains appropriate when evidence is costly, records are unstructured, or audit procedures require human interpretation.

For a simple attribute-sampling context, if a population contains N items and the auditor observes d deviations, the observed deviation rate is:

p̂ = d ÷ N

Here, p̂ is an observed rate, not necessarily the true population rate. Inferences require an appropriate sampling design, independence assumptions where relevant, and a stated confidence method. A convenience sample cannot be converted into a statistically defensible confidence statement merely by applying a formula.

Anomaly detection

Anomaly detection identifies observations that differ from an expected pattern. Techniques include threshold rules, peer-group comparisons, clustering, time-series analysis, and supervised classification. Examples include an administrator logging in from an unusual geography, a service account creating interactive sessions, or a deployment occurring without an associated approved change.

An anomaly is a signal for investigation, not proof of misconduct or control failure. Legitimate emergency work, maintenance windows, shared service accounts, and changes in business activity can produce unusual observations.

For an alerting system, two useful measures are:

Precision = True positives ÷ (True positives + False positives)
Recall = True positives ÷ (True positives + False negatives)

A true positive is an alert that correctly identifies an event of interest; a false positive is an alert incorrectly classified as such; a false negative is a relevant event missed by the system. These measures require a defined ground truth or adjudication process. High recall may produce too many alerts for investigators, while high precision may miss important events. The appropriate balance depends on risk, investigation capacity, and the cost of error.

4. Security Telemetry and Automated Evidence Collection

Automated evidence collection can obtain configuration states, access lists, vulnerability results, incident records, approval histories, and deployment metadata through APIs, database queries, agents, or scheduled exports. The principal advantages are repeatability, speed, reduced manual transcription, and broader coverage.

A reliable evidence pipeline should address:

  1. Authority: the audit team is authorised to access the source.
  2. Scope: the extraction includes the correct systems, accounts, environments, and period.
  3. Integrity: records are protected from unauthorised alteration during collection and storage.
  4. Lineage: each report can be traced to source data, extraction logic, transformation, and output.
  5. Repeatability: another qualified reviewer can reproduce the result.
  6. Retention: evidence is retained according to legal, regulatory, and professional requirements.
  7. Confidentiality: secrets, personal data, and sensitive security details are appropriately protected.

A cryptographic hash can help detect file alteration. For a file F, a digest can be represented as H(F). If a later digest differs from the recorded digest, the file has changed or was processed differently. A matching hash supports integrity of the file relative to the hash process; it does not prove that the source was truthful, complete, or authorised.

Evidence automation should therefore capture metadata such as source system, extraction identity, timestamp, query or API version, filters, transformation steps, and reviewer approval. Secrets used by collection jobs must be stored in an approved secrets-management facility rather than embedded in scripts.

5. Continuous Control Monitoring

Continuous control monitoring (CCM) translates control requirements into recurring indicators and tests. A CCM rule for multi-factor authentication might identify active remote users without MFA. A rule for vulnerability management might compare remediation dates with risk-based service-level objectives. A rule for change management might identify production changes lacking a linked approval.

A mature CCM design distinguishes:

  • Control objective: what risk the control is intended to address.
  • Control activity: what people or systems actually do.
  • Data signal: observable evidence of that activity.
  • Test logic: how compliance or deviation is determined.
  • Exception workflow: how results are investigated and resolved.
  • Escalation: when unresolved issues become risk acceptance, incidents, or audit findings.

Indicators should be risk-based. Counting the number of alerts or dashboards may encourage activity without improving control effectiveness. Better indicators link to exposure, duration, affected assets, business criticality, and remediation quality.

A useful exposure-duration measure is:

Exposure-days = ∑ᵢ (End dateᵢ − Start dateᵢ) × Weightᵢ

where each item i represents an exposure, dates are measured in consistent units, and Weightᵢ reflects a documented risk weighting. This measure is meaningful only when start and end events are reliably recorded and weights are not used to create false precision. It should support prioritisation, not replace professional risk assessment.

Continuous monitoring also requires threshold governance. Thresholds should have owners, rationale, review dates, and change history. Otherwise, teams may reduce alert volume by weakening rules rather than improving control performance.

6. Process Mining for Audit

Process mining reconstructs and analyses business processes from event logs. A minimally useful event record normally contains a case identifier, an activity name, and an event timestamp. Optional attributes include user, system, location, amount, approval status, and risk classification.

Three common process-mining tasks are:

  • Process discovery: deriving a process model from event data.
  • Conformance checking: comparing observed traces with a reference model or policy.
  • Process enhancement: enriching a model with performance or risk information.

In cyber auditing, process mining can examine incident response, access provisioning, change management, vulnerability remediation, and software deployment. It may reveal rework loops, bypassed approvals, excessive waiting times, duplicate tickets, or activities performed by unauthorised roles.

Consider a change process expected to follow Request → Approval → Test → Deployment. A trace Request → Deployment → Approval is a conformance deviation, even if approval was eventually recorded. The auditor must then determine whether the sequence reflects a genuine control bypass, a logging delay, or a valid emergency procedure.

Process mining has important limitations. Logs may omit offline approvals, merge multiple cases, record system time rather than event time, or use inconsistent identifiers. A visually precise process map can therefore be misleading if event capture is incomplete. Before drawing conclusions, assess log completeness, case construction, timestamp semantics, and whether exceptional paths are legitimate.

7. Audit-Management Platforms and Workflow Automation

Audit-management platforms commonly support risk registers, audit plans, control libraries, evidence requests, workpapers, issue management, remediation tracking, approvals, and reporting. Their value lies less in their branding than in disciplined configuration and governance.

A platform should provide:

  • role-based access and segregation of duties;
  • immutable or controlled audit trails;
  • versioning of procedures, evidence, and conclusions;
  • links between risks, controls, tests, findings, and remediation;
  • configurable retention and legal holds;
  • integration with authoritative systems;
  • status controls that prevent unsupported closure;
  • export capability for independent review.

Workflow automation should not allow the same person or bot to create evidence, approve its adequacy, close the finding, and alter the audit trail without compensating controls. Automated closure may be acceptable for low-risk, well-defined exceptions, but material findings generally require human review and documented rationale.

8. Artificial Intelligence in Audit

Artificial intelligence can assist with document classification, control mapping, summarisation, anomaly prioritisation, query generation, and identification of similar historical findings. Generative AI can draft workpaper language or suggest tests. These uses may improve productivity, but they create risks of hallucination, confidentiality loss, automation bias, hidden model changes, and unsupported conclusions.

A responsible AI control framework should address:

  1. Purpose limitation: define the approved audit use and prohibited uses.
  2. Data governance: classify inputs, restrict sensitive data, and assess retention by the provider.
  3. Validation: test accuracy, relevance, bias, robustness, and failure modes using representative cases.
  4. Traceability: preserve prompts, model version, data sources, outputs, and reviewer actions where appropriate.
  5. Human accountability: require a qualified person to evaluate material outputs.
  6. Security: protect interfaces, credentials, models, prompts, and retrieved documents against abuse.
  7. Change management: reassess the system after model, data, or configuration changes.
  8. Disclosure: communicate material reliance and limitations to appropriate stakeholders.

AI-generated text is not audit evidence merely because it is fluent. A model may infer a control existed because similar documents usually contain an approval, or may cite a source that does not support its statement. The auditor must verify claims against authoritative records.

Bias is also relevant. If historical findings disproportionately concern a particular team because that team is more heavily monitored, a model trained on those findings may reproduce surveillance bias rather than identify objective risk. Fairness assessment must therefore consider data-generating processes, not just output distributions.

9. A Detailed Illustrative Case: Continuous Assurance for Privileged Access

Background

The fictional organisation Northbridge Health Services operates clinical applications and a hybrid cloud environment. Its policy requires quarterly review of privileged access, MFA for privileged remote access, removal of leaver access within 24 hours, and documented approval for emergency elevation.

Problem

A conventional annual audit found no major issue because it sampled 40 accounts from a population of approximately 18,000 identities. Management nevertheless suspected that service accounts, emergency access, and cloud roles were not consistently covered.

Analysis

The audit team defined the population as all active human and non-human identities with privileged permissions during the quarter. It integrated identity-governance records, HR leaver data, cloud role assignments, MFA status, privileged-session logs, and emergency-access tickets.

Data profiling identified three problems: cloud roles used different privilege labels, 4.2% of accounts lacked a stable owner, and timestamps in the emergency-access system used local time while identity logs used UTC. The team created a controlled role taxonomy, required owner mapping for unresolved accounts, and normalised timestamps to UTC. Reconciliation showed 18,420 privileged identities in the combined population, compared with 17,980 in the identity-governance report. The difference was traced to 440 cloud service identities absent from the governance feed.

Approach and solution

The team implemented four recurring tests:

  1. Compare active privileged identities with completed quarterly reviews.
  2. Compare remote privileged sessions with MFA status.
  3. Join HR leaver records to identity disablement timestamps.
  4. Compare emergency elevation sessions with approved emergency tickets and duration limits.

Rules produced exceptions daily, but they did not automatically become findings. An analyst investigated account ownership, approved service-account exemptions, time-zone conversions, and emergency procedures. A second reviewer validated material exceptions.

Outcome

The programme identified 73 privileged identities outside the governance feed, 11 leaver accounts disabled after the 24-hour requirement, and 19 emergency sessions without a matching ticket. Investigation showed that six emergency sessions were legitimate but logged under a shared incident identifier; the remaining 13 required remediation. Management corrected the integration, prohibited unmanaged privileged roles, and introduced monthly data-quality reconciliation.

Learning points

The most important discovery was not the number of exceptions but the population defect. Without identifying the 440 omitted cloud identities, apparently strong compliance percentages would have been misleading. The case also demonstrates that automated detection, human investigation, data reconciliation, and remediation governance must operate together. Continuous assurance is not simply a dashboard refreshed more frequently.

10. Limitations, Ethics, and Professional Judgment

Analytics can create an illusion of objectivity. A numerical result may conceal subjective choices about population boundaries, thresholds, classifications, weighting, and treatment of missing data. Auditors should document those choices and assess their effect on conclusions.

Privacy is a central concern. Security telemetry may contain employee identifiers, location information, communications metadata, or behavioural patterns. Collection should be lawful, necessary, proportionate, access-controlled, and retained only as long as justified. Cross-border transfer and employment-law requirements may apply.

Independence can be threatened when an audit team designs an automated control and later provides assurance over it. The team should distinguish advisory assistance from management responsibility and apply appropriate safeguards. Security of the audit platform itself is also material: compromised evidence repositories, altered workflows, or excessive administrator privileges can undermine the entire assurance process.

Common failure modes include:

  • automating a poorly defined control;
  • treating all alerts as equally important;
  • ignoring missing or excluded records;
  • changing thresholds without approval;
  • relying on vendor dashboards without understanding logic;
  • using AI output without source verification;
  • closing exceptions because a ticket exists rather than because risk was reduced; and
  • reporting precision beyond what the data supports.

11. Best-Practice Design Principles

An advanced continuous-assurance programme should:

  1. Begin with material cyber risks and explicit control objectives.
  2. Maintain a controlled data dictionary and system-of-record catalogue.
  3. Reconcile populations before calculating compliance rates.
  4. Separate data acquisition, test execution, review, and approval duties.
  5. Preserve code, queries, configurations, versions, and evidence lineage.
  6. Use risk-based thresholds and periodically test their suitability.
  7. Combine automated tests with targeted human investigation.
  8. Measure false positives, false negatives, investigation time, and remediation quality.
  9. Protect personal and security-sensitive information.
  10. Validate AI tools and maintain human accountability for conclusions.
  11. Conduct independent quality review for high-impact analytics.
  12. Reassess controls whenever systems, integrations, regulations, or threat conditions change.

Chapter Summary

Audit analytics extends cyber auditing through structured use of data, queries, statistics, visualisation, process mining, and automation. Continuous monitoring is management’s ongoing activity, while continuous auditing performs assurance procedures more frequently; continuous assurance depends on reliable evidence and sound professional judgment.

The analytics life cycle begins with a risk question and continues through control translation, data acquisition, profiling, testing, investigation, corroboration, documentation, and remediation. Data quality—especially completeness, accuracy, validity, timeliness, uniqueness, and provenance—is fundamental. Full-population analysis can improve coverage but cannot correct a defective population or poorly designed rule.

Security telemetry and automated evidence pipelines require authorisation, scope control, integrity, lineage, repeatability, retention, and confidentiality. Continuous control monitoring converts control objectives into recurring tests and governed exception workflows. Process mining can reveal deviations and bottlenecks, but conclusions depend on complete and correctly interpreted event logs.

Audit-management platforms improve traceability and workflow when configured with access control, versioning, segregation of duties, and controlled closure. Artificial intelligence can assist audit work, but its outputs require validation, source verification, security safeguards, transparency, and human accountability. The central professional lesson is that automation increases analytical capability; it does not transfer responsibility for evidence quality and audit conclusions from people to machines.

Key Terms

Audit analytics: The use of data and computational techniques to obtain and evaluate audit evidence.

Continuous auditing: Performing audit procedures continuously or at more frequent intervals using technology.

Continuous assurance: Ongoing justified confidence based on timely, reliable evidence about risk and control effectiveness.

Continuous control monitoring: Recurring automated or semi-automated testing of control conditions and exceptions.

Security telemetry: Operational data generated by security, identity, endpoint, network, and technology systems.

Data lineage: The traceable history of data from source through transformation to reported result.

Population reconciliation: Comparing an extracted dataset with an independent control total or authoritative source.

Deterministic test: A test that applies explicit, predefined rules to records.

Anomaly detection: Identification of observations that differ from an expected pattern.

False positive: An alert indicating an issue when the investigated condition is not present.

False negative: Failure to alert when a relevant condition is present.

Precision: The proportion of positive alerts that are true positives.

Recall: The proportion of relevant cases detected by a system.

Process mining: Analysis of event logs to discover, compare, or enhance business processes.

Conformance checking: Comparison of observed process traces with a reference process or policy.

Evidence provenance: Information showing where evidence originated and how it was processed.

Audit trail: A chronological record of actions, changes, approvals, and system events.

Automation bias: The tendency to accept automated output without adequate independent evaluation.

Model drift: Change in model performance or data relationships over time.

Human-in-the-loop: A design in which a qualified person reviews or approves significant automated outputs.

Review Questions

Short Answer Questions

  1. Distinguish continuous monitoring from continuous auditing.
  2. Why is population reconciliation important before running an automated control test?
  3. Define false positive and false negative in an audit-alerting context.
  4. What three elements are minimally required for a useful process-mining event log?
  5. Why is AI-generated text not automatically audit evidence?

Long Answer Questions

  1. Explain the complete audit analytics life cycle and identify key evidence-quality risks at each stage.
  2. Discuss how an organisation should design a continuous control-monitoring programme for privileged access.
  3. Explain the role of data lineage, integrity, repeatability, and retention in automated evidence collection.
  4. Critically evaluate the benefits and limitations of process mining in change-management auditing.
  5. Develop a governance framework for responsible use of generative AI in cyber risk auditing.

Analytical / Application Questions

  1. An identity platform reports 20,000 privileged accounts, while a cloud inventory identifies an additional 1,000 accounts not included in the platform. Analyse why a compliance percentage based only on the platform population could be misleading and propose reconciliation procedures.
  2. A detection model produces 800 alerts, of which 200 are confirmed relevant events. It also misses 50 relevant events identified through independent investigation. Calculate precision and recall, state the assumptions, and explain the operational trade-off.
  3. A change log shows 92% of deployments linked to approved tickets. Process mining reveals that many approvals occur after deployment. Explain why the percentage alone is insufficient and design further tests to assess control effectiveness.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes continuous monitoring from continuous auditing?

A. Monitoring is management’s ongoing activity, while auditing provides independent or objective assurance.

B. Monitoring is always manual, while auditing is always automated.

C. Monitoring applies only to financial systems, while auditing applies only to cyber systems.

D. Monitoring produces legal conclusions, while auditing only produces operational metrics.

Correct Answer: A. Monitoring is management’s ongoing activity, while auditing provides independent or objective assurance.

Question 2

If 9,600 of 10,000 expected records contain a valid required value, what is the completeness percentage?

A. 94%

B. 96%

C. 98%

D. 99.6%

Correct Answer: B. 96%

Question 3

Which item is most directly associated with data lineage?

A. The colour scheme of a dashboard

B. The number of analysts viewing a report

C. The traceable history from source data through transformations to output

D. The maximum number of records an API can return

Correct Answer: C. The traceable history from source data through transformations to output

Question 4

An alerting system has 200 true positives and 300 false positives. What is its precision?

A. 20%

B. 40%

C. 60%

D. 66.7%

Correct Answer: B. 40%

Question 5

Which combination is minimally required for a useful process-mining event log?

A. Case identifier, activity name, and timestamp

B. Password, IP address, and encryption key

C. Budget, headcount, and risk appetite

D. Invoice number, tax rate, and currency

Correct Answer: A. Case identifier, activity name, and timestamp

Question 6

What is the principal purpose of conformance checking?

A. To generate encryption keys for event logs

B. To compare observed process traces with a reference process or policy

C. To replace all human review of audit evidence

D. To calculate the storage capacity of a logging platform

Correct Answer: B. To compare observed process traces with a reference process or policy

Question 7

Which statement about a cryptographic hash is correct?

A. A matching hash proves that source data are complete and truthful.

B. A hash can help detect alteration of a file relative to the hash process.

C. A hash eliminates the need for access controls.

D. A hash identifies whether a control was effectively designed.

Correct Answer: B. A hash can help detect alteration of a file relative to the hash process.

Question 8

Which is an appropriate responsible-AI control in auditing?

A. Allowing automated output to close all material findings without review

B. Removing source verification because the model is highly fluent

C. Preserving relevant model information and requiring qualified human review of material outputs

D. Uploading all confidential audit evidence to public AI services

Correct Answer: C. Preserving relevant model information and requiring qualified human review of material outputs

Question 9

Why can full-population testing still produce a misleading conclusion?

A. It always has a smaller population than sampling.

B. It cannot identify any exceptions.

C. It may analyse an incomplete or incorrectly defined population using a flawed rule.

D. It is prohibited for cyber controls.

Correct Answer: C. It may analyse an incomplete or incorrectly defined population using a flawed rule.

Question 10

Which practice most strengthens automated evidence collection?

A. Embedding credentials directly in scripts

B. Changing thresholds without recording approvals

C. Capturing source, extraction time, query logic, transformations, and reviewer approval

D. Deleting intermediate data immediately without retention requirements

Correct Answer: C. Capturing source, extraction time, query logic, transformations, and reviewer approval

Cyber Risk Management & Auditing
Chapter 13 of 15