CISA Scenario Guide: Work Through Audit Evidence and Risk
Work through CISA evidence, migration, recovery and vendor-assurance cases, including the facts that separate plausible conclusions.
A useful CISA answer addresses the question’s assertion at the stated point in the engagement. The cases below are original teaching illustrations. Each explains what can be concluded, what remains uncertain and how a changed fact affects the next step.
Case 1: a review is documented, but the population is incomplete
A policy requires quarterly review of every account capable of accessing a production application. The audit extract contains 480 employee accounts and signed review evidence for all 480. A separate identity inventory lists 20 enabled service accounts with application access; the extraction excluded them. No other review covers those accounts.
Reasoning: the signed evidence supports review of the 480 included accounts. It does not support complete coverage of the required population. The primary gap is the exclusion of enabled service accounts, not a lack of signatures for employee accounts.
The observed coverage is 480 out of 500 relevant accounts, or 96%. That percentage describes coverage; it does not establish that the 480 entitlements are appropriate. The auditor should assess the omitted population and the cause of the exclusion, while reporting the scope accurately.
Why a tempting conclusion fails: “Every sampled record was approved, so the control operated effectively” confuses the tested subset with the policy’s full population. Increasing the sample within the same incomplete extract would not fix that omission.
Change one fact: suppose the policy expressly assigns service accounts to a separate monthly review. The next step is to inspect that review’s coverage and operation; the employee extract is no longer defective solely because it omits accounts handled by the documented alternative process.
Case 2: conversion totals reconcile, but relationships do not
A billing migration has equal source and target record counts and equal total balances. Validation finds that 16 invoices were assigned to the wrong customer identifiers. The business requirement is that balances and customer relationships remain correct.
Reasoning: total equality can coexist with offsetting errors or misassigned records. The known customer-relationship failures contradict the requirement even though high-level reconciliations pass. Assess the affected records and the mapping/control failure before drawing a readiness conclusion.
| Check | What it establishes | What it leaves open |
|---|---|---|
| Equal record counts | The totals agree | Whether the same records and identities are present. |
| Equal balance totals | Aggregate amounts agree | Whether balances belong to the right accounts. |
| Record-level identity and relationship checks | Specific mappings agree for the items tested | Untested population and other business behavior. |
Why a tempting action fails: repeating the count reconciliation does not address the observed mapping defect. A useful follow-up traces customer identifiers through transformation rules, investigates exceptions and checks the corrected conversion against independently supported requirements.
Change one fact: if no discrepancy has yet been observed and only aggregate reconciliations exist, the conclusion is insufficient evidence for relationship accuracy. That is different from claiming that relationships are already proven incorrect.
Case 3: the server returns before the business service
A payment service has an RTO of 90 minutes and an RPO of 15 minutes, both measured from disruption at 10:00. The database is restored at 10:45 from a usable 09:40 recovery point. Required identity and messaging services become available at 11:35, when end-to-end payment processing is successfully validated. Those dependencies are within the defined recovery scope.
flowchart TD
A["10:00 — disruption"] --> B["10:45 — database restored"]
B --> C["11:35 — payment service validated"]
D["09:40 — usable recovery point"] -.-> B
Reasoning: data loss is 20 minutes, exceeding the 15-minute RPO. Business-service recovery takes 95 minutes, exceeding the 90-minute RTO. The 45-minute database milestone does not meet the service objective because required dependencies and validation were still outstanding.
Why a tempting conclusion fails: “RTO passed because the database was running” changes the recovery object from the business service to one component. The stated objective and scope determine what “restored” means.
Change one fact: if tested transaction replay safely reconstructs all committed activity through 09:55, the recoverable point changes and the demonstrated loss window becomes five minutes. The RTO result still depends on when the complete service was validated. Verify the replay evidence rather than inferring it from the existence of transaction logs.
Case 4: a vendor report does not cover the control relied on
An organization relies on a hosted archive for seven-year record retention. The provider supplies an independent assurance report, but its scope excludes the deletion administration service operated by a subcontractor. The customer’s contract requires the retention outcome; the report does not test the excluded service and no alternative evidence is available.
Reasoning: the report may be useful for included controls, but it does not establish the required assurance over deletion administration. Identify the gap, obtain relevant evidence or an appropriate alternative assessment, and evaluate the customer’s monitoring and contractual rights.
A report title or unmodified opinion does not extend coverage into an expressly excluded service. Likewise, a contract states an obligation; it does not prove that the obligation operated as intended.
Change one fact: if the organization independently prevents early deletion through a tested, enforceable retention mechanism outside the provider administrator’s ability to override, assess that mechanism’s scope and operation. It may address the exposure, but “we have a compensating control” remains a claim until supported.
Case 5: missing approval evidence is not always a design defect
A release procedure requires business-owner approval before production deployment. The workflow includes an approval gate, but two selected releases have no retained approval evidence. The audit is testing compliance during the quarter.
Reasoning: the documented design includes approval. The two exceptions raise questions about operation and evidence retention. Investigate whether the gate was bypassed, approval happened elsewhere, or records were lost. Report what the evidence establishes rather than immediately asserting that the approval requirement was never designed.
Change one fact: if the implemented workflow has no approval step and the requirement exists only in an unused policy document, the design as implemented may not enforce the intended control. That requires a different finding from an otherwise appropriate process with isolated execution exceptions.
Carry the method into fresh questions
For each case, identify the assertion, governing criteria, relevant population/period and decisive facts. Then choose a conclusion or procedure that stays within them. This is a reading discipline, not a mandatory operational sequence for every audit or incident. Urgent containment, mandatory reporting and local authority may change what should happen next.
Use the free practice exam to apply these distinctions without seeing the worked reasoning first, or return to the cheat sheet for the underlying contrasts.