Control Testing, Evidence and Audit Reporting

Introduction and Context

Cyber risk management depends not only on defining controls, but also on determining whether those controls are suitably designed and operate as intended. A policy may require multifactor authentication, a procedure may require quarterly access reviews, and a system may generate review logs; however, assurance is obtained only when an auditor gathers sufficient, appropriate evidence and reaches a defensible conclusion.

Control testing connects governance intentions with operational reality. It supports internal audit, external assurance, regulatory examinations, certification audits, third-party reviews, and management self-assessment. In cyber risk management, testing is particularly demanding because controls are distributed across people, processes, applications, infrastructure, cloud services, suppliers, and automated technologies. Evidence may also be volatile, incomplete, privileged, or technically difficult to interpret.

This chapter presents a professional approach to testing control design and operating effectiveness, evaluating deficiencies, identifying root causes, formulating findings, communicating assurance opinions, and tracking remediation. The discussion applies to common frameworks such as COBIT, ISO/IEC 27001, NIST Cybersecurity Framework, SOC reporting, and organization-specific control frameworks. These frameworks differ in terminology, but the underlying assurance logic is similar.

Learning Objectives

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

1. Distinguish control design effectiveness from operating effectiveness.
2. Select and apply inquiry, observation, inspection, reperformance, and technical evidence appropriately.
3. Evaluate evidence for sufficiency, appropriateness, reliability, relevance, and completeness.
4. Design defensible samples and document test procedures and results.
5. Classify deficiencies, determine their root causes, and assess their risk significance.
6. Write clear audit findings and assurance opinions for technical and managerial audiences.
7. Develop practical remediation plans and track closure without compromising independence.
8. Recognize ethical, regulatory, privacy, and emerging-technology implications of control testing.

1. The Assurance Logic of Control Testing

A control is an action, mechanism, or condition intended to prevent, detect, correct, or reduce a risk. Examples include privileged-access approval, vulnerability scanning, backup restoration tests, security awareness training, segregation of duties, and incident escalation.

A useful assurance chain is:

Risk → Control objective → Control activity → Evidence → Test procedure → Result → Conclusion → Remediation.

The chain prevents a common error: testing an activity without establishing what risk it addresses. For example, checking that vulnerability reports exist does not by itself demonstrate that critical vulnerabilities are remediated within the required period. The control objective might require timely identification, prioritization, assignment, remediation, and exception approval. Each element may require different evidence.

1.1 Design effectiveness

Design effectiveness asks whether the control, if performed as described, is capable of addressing the relevant risk. A control is poorly designed when it lacks an owner, operates at the wrong frequency, covers only part of the risk, lacks defined criteria, or cannot produce evidence.

Examples of design weaknesses include:

• A policy requires management approval but does not identify the approving role.
• A backup control runs daily but no one tests whether backups can be restored.
• A quarterly access review excludes service accounts and privileged accounts.
• A security alert is generated, but no escalation threshold or response time exists.

Design testing normally examines policies, standards, process maps, risk assessments, role descriptions, configuration requirements, and control specifications. It may include walkthroughs to determine how the control is expected to operate.

1.2 Operating effectiveness

Operating effectiveness asks whether a suitably designed control actually operated consistently, by an appropriately authorized person or system, during the period under review. A well-designed control may fail operationally because staff did not perform it, evidence was not retained, the system configuration changed, or exceptions were not handled.

For example, a quarterly access review may be appropriately designed but ineffective if two of the four required reviews were not completed, if the reviewer lacked independence, or if review evidence did not show that inappropriate access was investigated.

Design and operating conclusions should be kept separate. A control can be:

2. Defining the Test Before Gathering Evidence

A defensible test begins with a precise test objective. The objective should identify the population, period, control attributes, evidence required, and evaluation criteria.

A control test specification commonly includes:

• Control objective: What risk is the control intended to address?
• Control owner: Who is accountable for operation and oversight?
• Frequency: Continuous, daily, weekly, monthly, quarterly, or event-driven.
• Population: The complete set of items or events subject to the control.
• Period: The time interval under review.
• Attributes: Characteristics that must be present, such as approval, timeliness, completeness, or segregation.
• Failure rule: The condition that constitutes an exception.
• Evidence source: System logs, tickets, reports, approvals, configurations, or other records.
• Conclusion scale: Effective, partially effective, ineffective, or another approved classification.

Consider a control requiring all critical vulnerabilities to be remediated within 15 calendar days unless a documented risk acceptance is approved. A test should not merely ask whether vulnerability scans occurred. It should determine whether the population of critical vulnerabilities was complete, whether each item was dated, whether remediation occurred within 15 days, and whether approved exceptions existed for items outside the requirement.

3. Evidence: Quality, Reliability and Sufficiency

Audit evidence supports the conclusion. Evidence is not synonymous with documentation: a document may be inaccurate, incomplete, or unrelated to the control objective. Evidence should be evaluated through four connected qualities.

Relevance means that the evidence addresses the control assertion being tested. A firewall policy may be relevant to design but not prove that a rule was reviewed during the audit period.

Reliability concerns the degree to which evidence can be trusted. Evidence generated directly from a controlled system is often more reliable than an unverified spreadsheet, but system-generated evidence is not automatically reliable. The auditor should understand access rights, configuration, logging, retention, and the possibility of alteration.

Sufficiency concerns the quantity and coverage of evidence. One approval may demonstrate that an approval process exists, but not that a monthly control operated throughout a year.

Appropriateness combines relevance and reliability. Evidence should be both enough in amount and suitable in nature.

Evidence also has a time dimension. A current screenshot may show present configuration but cannot prove that the same configuration existed six months earlier. Historical logs, change records, archived reports, or independently time-stamped records may be needed.

3.1 Evidence hierarchy and corroboration

No single hierarchy applies in every engagement, but evidence generally becomes stronger when it is independently generated, directly observable, time-relevant, complete, and difficult for the subject of the audit to manipulate. Direct observation of a live process, a system-generated immutable log, and an independently confirmed supplier report may each be persuasive for different assertions.

Corroboration is especially important where evidence is self-produced. For example, management's statement that privileged access is reviewed should be corroborated with review records, identity-system data, exception tickets, and evidence that access was removed when required.

Auditors should preserve chain of custody for sensitive evidence. The record should identify who extracted it, when it was extracted, from which source, using what method, and whether it was transformed or filtered. Personal data, credentials, security incidents, and forensic artifacts should be protected through least privilege, encryption, access logging, and approved retention practices.

4. The Five Core Testing Methods

4.1 Inquiry

Inquiry obtains information through interviews, written questions, or discussions with control performers, owners, system administrators, and management. It is efficient for understanding process design, exceptions, and changes.

Inquiry is generally weak as the sole evidence of operating effectiveness because people may misunderstand requirements, remember events incorrectly, or present an idealized process. It should usually be corroborated by inspection, observation, reperformance, or technical evidence.

Good inquiry is open enough to reveal reality but specific enough to support testing. Questions should address what happens, who performs it, when it occurs, what happens when it fails, and where evidence is retained.

4.2 Observation

Observation involves watching a control being performed. It can be valuable for physical security, incident triage, change deployment, secure disposal, or backup operations. Observation demonstrates operation at a particular time, not necessarily throughout the period.

The auditor should record the date, participants, system or location, procedure observed, deviations, and whether the activity was a normal or specially arranged event. A demonstration may be staged; therefore, observation should be supported by historical records where the conclusion concerns recurring operation.

4.3 Inspection

Inspection examines documents, tickets, configurations, reports, approvals, logs, contracts, and other records. It is often the principal method for testing evidence of historical operation.

Inspection should evaluate authenticity, completeness, date, responsible party, approval, exceptions, and linkage to the relevant population. A screenshot without system context may be insufficient. A ticket marked “resolved” may not show that the underlying vulnerability was fixed or independently validated.

4.4 Reperformance

Reperformance independently executes or reconstructs a control to determine whether it produces the expected result. Examples include recalculating a risk score, rerunning an access-conflict query, restoring a backup in a test environment, or independently verifying that a sample of terminated users no longer has access.

Reperformance provides strong evidence but can be technically demanding. It must be conducted safely, with authorization and appropriate safeguards. The auditor should preserve the input population, logic, tools, parameters, and output so another qualified person can reproduce the procedure.

4.5 Technical evidence

Technical evidence includes configuration exports, API results, database queries, endpoint telemetry, cloud audit trails, vulnerability reports, identity-provider records, code repository history, and security-monitoring data. Technical evidence can provide scale and precision, but its interpretation requires knowledge of architecture and data limitations.

A technically sophisticated report may still be unreliable if the data source excludes systems, timestamps are inconsistent, logs can be altered, or the query logic is flawed. Auditors should validate scope, time zone, field meaning, extraction logic, access permissions, and completeness controls.

5. Sampling and Data Analytics

Testing every transaction may be practical for automated controls or small populations, but many manual and event-based controls require sampling. Sampling is a method of obtaining evidence about a population by examining less than the entire population. The sample must be selected and evaluated in a way that supports the intended conclusion.

The auditor should define:

• The population and its completeness;
• The unit of sampling, such as a user, ticket, change, or month;
• The sampling period;
• The selection method;
• The expected deviation rate;
• The tolerable deviation rate; and
• The response to deviations.

Random selection reduces selection bias. Systematic selection may be appropriate when the population is ordered and the interval is justified. Stratification is useful where risk differs materially—for example, separating privileged accounts from ordinary accounts. Judgmental selection can target high-risk items but generally does not support statistical projection to the entire population.

A simple deviation rate is:

The rate describes the sample; it is not automatically the true population rate. Statistical projection requires appropriate assumptions, sampling design, and confidence considerations. If 4 deviations are found in a sample of 40, the observed deviation rate is 10%. This does not prove that exactly 10% of the population failed.

Data analytics can test entire populations, identify anomalies, and support continuous auditing. Examples include detecting accounts with no owner, changes made outside approved windows, vulnerabilities exceeding service levels, or multiple users sharing a credential. Analytics results still require validation: duplicates, missing fields, system-generated records, and false positives can distort conclusions.

6. Documenting Test Workpapers

A workpaper should allow an experienced reviewer, who was not involved in the test, to understand what was tested, how it was tested, what evidence was obtained, and why the conclusion follows. A strong workpaper contains:

1. Control identifier and objective.
2. Risk and relevant requirement.
3. Population, period, and completeness procedures.
4. Test steps and sampling rationale.
5. Evidence references and extraction details.
6. Exceptions and evaluation criteria.
7. Auditor conclusion.
8. Review notes and resolution.
9. Restrictions, assumptions, and limitations.

Evidence should be indexed rather than copied indiscriminately. The workpaper should distinguish an observation from an inference. For example, “eight of 50 sampled changes lacked documented approval” is an observation; “change governance is ineffective” is a conclusion requiring interpretation of the control objective, risk, and compensating controls.

7. From Exception to Deficiency

An exception is a departure from a stated criterion. A deficiency is a control problem significant enough to warrant attention. Not every exception has the same significance. Evaluation should consider the nature, cause, duration, frequency, affected assets, likelihood, impact, compensating controls, and whether the issue is isolated or systemic.

Common classifications include:

• Control observation: A low-impact improvement opportunity.
• Deficiency: A control weakness that reduces assurance and requires corrective action.
• Significant deficiency: A more serious weakness requiring escalation under the organization’s methodology.
• Material weakness or equivalent critical classification: A deficiency that creates a substantial possibility that a significant risk will not be prevented or detected in time. Exact legal meaning depends on the applicable reporting regime.

The auditor must apply the relevant framework and organizational thresholds rather than inventing classifications. Quantitative thresholds may assist, but cyber risk often involves nonlinear effects. A single exposed privileged credential or untested recovery capability may be highly significant even if few records are affected.

7.1 Root-cause analysis

A finding should not stop at the immediate symptom. Root-cause analysis distinguishes:

• Event: What happened?
• Condition: What was observed?
• Criterion: What should have happened?
• Cause: Why did the condition occur?
• Effect or risk: What could result?
• Contributing factors: What allowed the issue to persist?

Methods such as the “five whys,” causal trees, process mapping, and barrier analysis can help. A useful cause analysis may identify unclear ownership, inadequate funding, incompatible tools, weak governance, excessive manual work, poor training, or incentives that prioritize availability over security. “Human error” is rarely a sufficient root cause because it does not explain why the process depended on an error-prone action without a preventive or detective barrier.

8. Formulating High-Quality Audit Findings

A finding should be factual, fair, concise, risk-oriented, and actionable. A widely used structure is:

• Title: A precise statement of the issue.
• Criteria: Requirement, policy, standard, or expected practice.
• Condition: What testing found.
• Cause: Why the gap occurred.
• Risk/effect: Why it matters.
• Recommendation: What management should do.
• Management action plan: Owner, action, milestone, target date, and success measure.

Example:

Title: Privileged access reviews did not consistently include emergency accounts.

Criteria: The access standard requires quarterly review of all privileged identities, including emergency accounts.

Condition: Inspection of four quarterly review packages found that emergency accounts were excluded from two packages. In one quarter, the review population could not be reconciled to the identity-management system.

Cause: The review report was generated from an application list that did not include centrally managed emergency identities, and no completeness reconciliation was required.

Risk: Inappropriate privileged access may remain active without timely detection, increasing the likelihood and impact of unauthorized changes or data exposure.

Recommendation: Management should define a complete privileged-identity population, automate reconciliation to the authoritative identity source, require documented investigation of exceptions, and retain evidence of review and removal.

This formulation avoids unsupported claims. It does not assert that compromise occurred; it explains the exposure created by the control gap.

9. Assurance Opinions and Audit Reporting

An audit report communicates scope, criteria, procedures, results, limitations, and the overall conclusion. The opinion should be traceable to the evidence and consistent with the engagement’s terms. Common forms include:

• Unmodified or satisfactory assurance: No significant exceptions were identified within scope.
• Modified or qualified assurance: The objective was substantially achieved, but identified exceptions or scope limitations prevent an entirely positive conclusion.
• Adverse or unsatisfactory assurance: Deficiencies are sufficiently pervasive or severe that the control objective was not achieved.
• Disclaimer or no conclusion: Evidence or access limitations prevent a reliable conclusion.

Terminology varies across internal audit, SOC, regulatory, and certification contexts. An auditor must not use a term with a specialized legal or professional meaning unless the applicable standard supports it.

A report should explain scope and limitations explicitly. For example, a review of cloud identity controls may exclude the cloud provider’s underlying physical infrastructure because that responsibility is addressed through the provider’s independent assurance report. The limitation should not be hidden; the report should state how reliance on the provider report was evaluated.

Reports have multiple audiences. Executives need risk significance, accountability, and decisions. Technical leaders need affected systems, evidence, and corrective design. Regulators need traceability and compliance with criteria. Excessive technical detail can obscure the conclusion, while excessive simplification can make remediation impossible.

10. Remediation and Follow-Up

Remediation is complete only when the underlying deficiency has been addressed and evidence demonstrates sustainable operation. Installing a tool, issuing a policy, or closing a ticket is not necessarily remediation.

A remediation plan should specify:

Follow-up testing may examine design implementation first and operating effectiveness later. For example, a new access-review workflow may be implemented in March, but operating effectiveness cannot be established until enough review cycles have occurred. Closure should therefore distinguish “implemented,” “operating,” and “validated.”

Risk acceptance is not the same as remediation. Acceptance should be explicit, authorized by the appropriate risk owner, time-bounded where appropriate, and supported by an assessment of residual risk and compensating controls. Audit may validate the acceptance process but should not accept risk on management’s behalf.

11. Case Study: Illustrative Cloud Access Review Failure

Background

A fictional financial-services organization operates customer applications in a public cloud. Its security standard requires monthly review of privileged access, removal of unnecessary access, and documented approval by the application owner and security function.

Problem

Internal audit was asked to assess whether the control operated effectively over twelve months. Management supplied twelve review spreadsheets and stated that all privileged access had been reviewed.

Analysis

The auditors first tested design. The requirement identified the frequency, reviewer roles, and expected action, so the control was broadly capable of addressing the risk. However, it did not specify how the population should be reconciled across cloud subscriptions, emergency accounts, and service identities.

For operating effectiveness, auditors obtained the authoritative identity-provider export, cloud access logs, approval records, removal tickets, and management spreadsheets. Reperformance of the population reconciliation identified 18 privileged cloud identities absent from at least one monthly review. Four were emergency accounts, six belonged to a former project, and eight were service identities. Two former-project accounts remained active for more than 90 days after their business need ended.

Inquiry revealed that the spreadsheet was generated manually by an application administrator. The identity platform and cloud platform used different identifiers, and no automated reconciliation existed. The security team reviewed the submitted spreadsheet but did not independently verify completeness.

Finding and approach

The finding was classified as a significant control deficiency under the organization’s risk methodology because the gap affected privileged access across multiple environments and persisted over several months. The root causes were incomplete control design, fragmented identity data, and unclear responsibility for population completeness—not merely administrator error.

Management agreed to establish an authoritative privileged-identity inventory, integrate cloud and identity-provider data, require monthly exception workflow, and assign accountability to the cloud security owner. Emergency accounts would receive separate monitoring and documented break-glass review.

Outcome

After implementation, audit inspected three monthly cycles, reperformed the reconciliation, and verified removal of unnecessary accounts. The design conclusion became effective. Operating effectiveness was initially reported as “not yet established” because only three cycles had occurred; subsequent follow-up after the required period confirmed consistent operation.

Learning points

1. A management-produced report is not evidence of population completeness.
2. Design testing should examine data sources and reconciliation, not only policy wording.
3. Technical identities require explicit treatment; service and emergency accounts are not peripheral exceptions.
4. Remediation closure should be based on sustainable evidence, not tool deployment alone.
5. A balanced finding identifies risk without alleging an unproven breach.

12. Governance, Ethics and Contemporary Practice

Control testing involves access to sensitive information and can itself create cyber risk. Auditors should use least-privilege access, protect credentials and personal data, avoid copying production secrets, and conduct intrusive tests only with written authorization. Penetration-style reperformance must have defined boundaries and rollback procedures.

Independence and objectivity are essential. An auditor who designed or operated a control may have a conflict in evaluating it. Advisory assistance may be permissible under applicable professional rules, but management must retain ownership of decisions and controls.

Regulatory expectations increasingly emphasize accountability, resilience, third-party risk, privacy, and evidence of continuous control operation. Cloud services, software supply chains, zero-trust architectures, infrastructure as code, and distributed systems complicate traditional evidence models. Control evidence may be generated by APIs, pipelines, policy-as-code engines, and immutable logging platforms.

Artificial intelligence can assist with anomaly detection, evidence classification, duplicate identification, and natural-language comparison of policies. It should not replace professional judgment. AI-generated summaries may omit exceptions, misunderstand context, or reproduce biased classifications. Auditors should preserve source evidence, validate model outputs, document prompts or configurations where relevant, and ensure that confidential information is not disclosed to unauthorized services.

Best practice is therefore evidence-centered rather than document-centered. Organizations should define authoritative data sources, synchronize time, retain tamper-evident logs, automate population reconciliation, map controls to risks, and use continuous monitoring where it improves timeliness without creating unmanageable false positives.

Chapter Summary

Control testing provides the bridge between cyber-risk expectations and defensible assurance conclusions. Design effectiveness assesses whether a control is capable of addressing its risk; operating effectiveness assesses whether it operated consistently during the relevant period. Inquiry, observation, inspection, reperformance, and technical evidence each have distinct strengths and limitations, and stronger conclusions usually result from appropriate corroboration.

Reliable testing requires a defined population, period, criterion, test procedure, evidence strategy, and exception rule. Sampling and analytics can improve coverage, but their limitations must be understood. Exceptions should be evaluated for significance, root cause, duration, and compensating controls. High-quality findings connect criteria, condition, cause, risk, recommendation, and management action.

Audit opinions must reflect the evidence, scope, limitations, and applicable professional terminology. Remediation should be tracked through accountable owners, milestones, success criteria, and follow-up validation. In contemporary environments, cloud identities, automated pipelines, APIs, AI tools, and third-party services require technically informed evidence practices, strong governance, ethical handling of data, and continued professional skepticism.

Key Terms

Control design effectiveness: The extent to which a control is capable of addressing its intended risk.

Operating effectiveness: The extent to which a control operated consistently as designed during a specified period.

Audit evidence: Information used to support an audit conclusion.

Sufficiency: The quantity of evidence supporting a conclusion.

Appropriateness: The relevance and reliability of evidence.

Inquiry: Obtaining information through questions or discussions.

Observation: Watching a control or process being performed.

Inspection: Examining records, configurations, reports, or other artifacts.

Reperformance: Independently executing or reconstructing a control.

Population: The complete set of items or events from which testing may be performed.

Sampling: Examining less than the entire population to obtain evidence.

Exception: A departure from a defined criterion.

Deficiency: A control weakness requiring attention because it reduces assurance.

Root cause: The underlying reason a control problem occurred or persisted.

Compensating control: An alternative control that reduces the risk created by a primary control gap.

Assurance opinion: The auditor’s conclusion regarding the subject matter within scope.

Scope limitation: A restriction that prevents sufficient appropriate evidence from being obtained.

Residual risk: Risk remaining after controls and planned treatments are considered.

Remediation: Corrective action intended to address a deficiency and reduce its underlying risk.

Continuous auditing: Repeated or automated audit procedures performed more frequently than periodic audits.

Review Questions

Short Answer Questions

1. What is the difference between design effectiveness and operating effectiveness?
2. Why is inquiry generally insufficient as the sole evidence of operating effectiveness?
3. Define sufficiency and appropriateness of audit evidence.
4. What elements should be included in an audit finding?
5. Why is remediation closure different from implementation of a new tool?

Long Answer Questions

1. Explain how an auditor should design a test for a control requiring critical vulnerabilities to be remediated within a defined service level.
2. Compare inquiry, observation, inspection, reperformance, and technical evidence, including the principal limitations of each.
3. Discuss how population completeness affects the reliability of access-review testing.
4. Explain how root-cause analysis improves the quality and sustainability of cyber-audit recommendations.
5. Describe the structure of an assurance report and explain how scope limitations should be communicated.

Analytical / Application Questions

1. An organization supplies twelve monthly access-review spreadsheets, but the auditor discovers that the spreadsheets are generated from only one of three identity repositories. Analyze the design and operating-effectiveness implications and propose a test approach.
2. A sample of 40 change tickets contains four missing approvals. Calculate the observed deviation rate and explain why the result cannot automatically be treated as the exact population failure rate.
3. Management closes a finding after deploying an automated privileged-access tool, but only one review cycle has occurred. Determine what additional evidence is needed before the finding can be considered sustainably remediated.

Multiple Choice Questions with Answers

Question 1

Which question primarily assesses control design effectiveness?

A. Did the control operate during every month of the audit period?

B. Is the control, if performed, capable of addressing the identified risk?

C. How many exceptions occurred in the sample?

D. Was the remediation plan completed by its due date?

Correct Answer: B. Is the control, if performed, capable of addressing the identified risk?

Question 2

Why is inquiry commonly insufficient as the sole evidence of operating effectiveness?

A. Inquiry cannot identify the control owner.

B. Inquiry is prohibited in technical audits.

C. Responses may be inaccurate or describe intended rather than actual practice.

D. Inquiry always produces statistical evidence.

Correct Answer: C. Responses may be inaccurate or describe intended rather than actual practice.

Question 3

Which method involves independently reconstructing an access-conflict query?

A. Inquiry

B. Observation

C. Inspection

D. Reperformance

Correct Answer: D. Reperformance

Question 4

A sample contains 4 deviations out of 40 items. What is the observed deviation rate?

A. 4%

B. 10%

C. 16%

D. 40%

Correct Answer: B. 10%

Question 5

Which item is most directly concerned with whether an evidence source can be trusted?

A. Reliability

B. Frequency

C. Stratification

D. Remediation

Correct Answer: A. Reliability

Question 6

What is the principal purpose of identifying a root cause?

A. To increase the number of findings

B. To assign blame to an individual

C. To address the underlying reason the deficiency occurred or persisted

D. To eliminate the need for evidence

Correct Answer: C. To address the underlying reason the deficiency occurred or persisted

Question 7

Which statement best describes a scope limitation?

A. A control operated more frequently than required.

B. The auditor could not obtain sufficient appropriate evidence for a reliable conclusion.

C. A control had a clearly documented owner.

D. Management accepted residual risk after remediation.

Correct Answer: B. The auditor could not obtain sufficient appropriate evidence for a reliable conclusion.

Question 8

Which evidence would best support the completeness of a privileged-access review population?

A. A verbal statement from the application administrator

B. A screenshot of one user account

C. Reconciliation of the review population to authoritative identity and cloud sources

D. A policy stating that privileged access must be reviewed

Correct Answer: C. Reconciliation of the review population to authoritative identity and cloud sources

Question 9

Which action represents risk acceptance rather than remediation?

A. Removing unnecessary privileged accounts

B. Automating reconciliation between identity sources

C. Explicitly approving the residual risk while leaving the control gap temporarily unresolved

D. Testing three completed review cycles

Correct Answer: C. Explicitly approving the residual risk while leaving the control gap temporarily unresolved

Question 10

Why should AI-generated audit summaries be validated against source evidence?

A. AI outputs are always legally binding.

B. AI may omit exceptions or misunderstand technical context.

C. Source evidence is never relevant to audit conclusions.

D. Validation prevents any use of automation.

Correct Answer: B. AI may omit exceptions or misunderstand technical context.