How does an auditor distinguish control design from operating effectiveness?

Design asks whether the control, if performed as described, could address the stated risk. Operating effectiveness asks whether it actually ran, at the required time and for the relevant population. A documented rule requiring independent approval before production changes may be well designed. If three sampled releases received approval only after deployment, those exceptions show an operating failure. If the rule allows the developer to approve their own release, the design itself is weak, even when every approval is recorded.

How do RTO and RPO guide a resilience assessment?

Recovery time objective (RTO) is the maximum target time to restore a service after disruption. Recovery point objective (RPO) is the maximum target amount of data loss measured in time. Suppose a business impact analysis sets a hypothetical RTO of four hours and RPO of 30 minutes. A tested restoration taking three hours meets the time target. If the newest usable backup is two hours old, it misses the data loss target. Both results matter; meeting one target does not compensate for missing the other.

What changes when an audited service runs in the cloud?

The auditor maps each control to the party responsible for it under the service arrangement, then tests the evidence for that responsibility. A provider may operate the physical facility and underlying infrastructure while the customer controls user access, data classification and some configuration. Provider assurance reports can inform the assessment, but their scope, period, exceptions and customer responsibilities must match the service being audited. A provider report covering physical security does not establish that the customer removed a departed employee’s access.

CISA Study Guide: Audit, Governance, Operations and Security

Start with concept 1 Choose a topic

A CISA auditor asks whether an organization’s information systems support its objectives and whether the controls around them work in practice. That requires more than recognizing a control’s name. You need to identify the risk, decide what evidence would test the control, interpret exceptions and explain their business effect. This guide moves from audit planning and evidence through IT governance, system delivery, operations, resilience and security. Its examples use stated assumptions so you can see how a conclusion follows from the facts. Pay particular attention to ownership and timing: a sound control can fail if nobody performs it, performs it too late or cannot show that it operated.

Information Systems Auditing Process

1. Standards, ethics and independence

An IS auditor needs a clear basis for the work and freedom to report what the evidence shows. The CISA exam content outline includes audit standards, guidelines and ethics in the auditing process domain. Standards guide planning, evidence, supervision and reporting; ethics also require honesty, confidentiality and competent work. Independence is threatened when an auditor has a financial interest, a close relationship with the area being audited, or responsibility for a control under review. A self-review threat is especially direct: someone who designed a control may overlook weaknesses in their own design. Identify the threat before testing, assess whether it affects objective judgment, and change the assignment or apply another effective safeguard. Record the decision so a reviewer can understand who performed the work and why.

Worked example: Six months ago, an auditor configured rules granting administrator access. The current engagement will test whether those rules enforce approved roles. The audit lead assigns that testing to an auditor who did not configure them and records the reassignment. The original auditor may explain how the system works, but should not supply the independent conclusion on those rules.

Watch the distinction: Disclosure alone does not remove a self-review threat. A reviewer still needs objective testing by someone able to challenge the original design and its operation.

Reference: [1]

2. Choose the right audit or review

First identify the question the engagement can answer. An assurance audit evaluates evidence against defined criteria and supports a conclusion within its scope. An advisory assessment can identify risks, options and design weaknesses while management retains responsibility for decisions and implementation. Timing matters: before launch, an auditor may inspect specifications and walkthroughs to judge whether a control is designed to address a risk. Operating effectiveness requires evidence that the control actually ran over a stated period, handled exceptions and covered the relevant population. A review with limited procedures must use correspondingly limited language. In either type of work, define the system boundary, period, criteria and evidence needed before fieldwork begins. Keep the conclusion tied to those choices; a good proposed control has no operating history merely because its design looks sound.

Worked example: A payment platform is due to launch next month. Reviewers inspect its proposed approval workflow and find no limit on a supervisor's approvals. They can report that the design permits excessive payments and recommend a limit. Because no live transactions or approval logs exist, they cannot conclude that approvals have operated effectively.

Watch the distinction: A walkthrough of a proposed workflow is not an operating test. Seeing how staff intend to approve payments does not show what happened during actual processing.

Reference: [1]

3. Plan around risk

Risk-based planning directs scarce audit time toward activities where failure could matter most. Start with business objectives and important assets, then identify threats, likely impact, and controls that might reduce exposure. Consider recent migrations, incidents, new vendors or major releases because change can invalidate a formerly sound control. A simple ranking may combine likelihood and impact, but numerical scores are aids to judgment, not measured probabilities. Examine the assumptions behind each score and the quality of existing controls. A high-impact process with weak or untested controls may deserve attention even if no incident has occurred. Turn the priority into an audit objective and targeted procedures: identify the relevant data, control owners, period and evidence. Revisit the plan when new facts change the risk picture rather than treating the initial ranking as fixed.

Worked example: Two applications each process about 10,000 transactions a month. One stores regulated customer data and completed a migration last week; the other publishes public content and has been stable for two years. The auditor schedules the customer application first, focusing on migrated data and access. Equal volume does not mean equal exposure.

Watch the distinction: Recent incident counts alone are a poor priority rule. An untested new system may have few recorded incidents while carrying substantial impact and control uncertainty.

Reference: [1]

4. Classify controls by purpose

Classify a control by what it does to the stated risk, not by its name or technology. A preventive control blocks an unwanted event before it completes, such as an enforced approval limit. A detective control reveals an event after or during occurrence, such as an exception report reviewed by an accountable person. A corrective control restores the desired state or limits the damage, such as reversing an erroneous posting. Controls also differ in execution: an automated rule may run consistently but depend on sound configuration and access management; a manual review depends on timely, informed action. Test the whole chain. For a report, confirm the source population, logic, delivery, review, investigation and resolution. Then ask whether the timing and precision of the control match the loss it is meant to address.

Worked example: A transfer request exceeds a hypothetical $50,000 internal limit. The system blocks it, so the limit prevents that transfer. A daily report later flags a transfer made through an approved override; the report detects it if someone investigates. If the posting was erroneous, a documented reversal corrects the record but cannot erase every consequence of the delay.

Watch the distinction: A daily exception report cannot be called preventive merely because it might discourage errors. Its direct function is to reveal transactions that have already passed.

Reference: [1]

5. Build an executable audit program

An audit program turns a broad objective into work another auditor could execute and review. State the risk, the control claim, the criterion for success, the population and period, and the evidence to request. Then specify each procedure, who performs it, when it is due and how results will be recorded. A test should say how an exception will be identified, not simply instruct staff to review access. Check that source records are complete before selecting items; an incomplete population can make careful sampling useless. Include practical dependencies, such as obtaining HR departure dates before comparing account removal times. Assign a reviewer and define escalation for missing evidence or unexpected results. A program can evolve as findings arise, but changes should preserve a trace from objective through procedure, evidence and conclusion. Certified internal auditor guidance offers a related perspective on audit planning and evidence.

Worked example: For payroll access, the auditor defines the population as all employees who departed during a hypothetical quarter. HR supplies departure dates and identifiers; IT supplies account disablement timestamps. The auditor matches identifiers, investigates unmatched records, and compares each interval with the organization's stated removal requirement. The workpaper records the extracts, matching method, exceptions and reviewer.

Watch the distinction: Requesting a list of disabled accounts is not enough. Without the full departure population and dates, an auditor cannot identify leavers whose accounts stayed active.

Reference: [1]

6. Select and interpret samples

Choose a sample according to the question being asked. A statistical sample uses a defined population and selection method to support quantified inference, subject to its assumptions and sampling risk. A judgmental sample deliberately targets unusual, high-value or risky items; it is useful for finding specific failures but cannot support a population exception rate. Before selection, determine the sampling unit, period and completeness of the population. For a control test, decide what counts as a deviation and retain evidence for each selected item. If a deviation appears, investigate its cause and possible reach. It may reveal a wider process failure, but further work is needed to establish that reach. Separate sampling risk from nonsampling errors such as a faulty extract, wrong criterion or misread approval. A larger sample does not repair bad population data.

Worked example: An auditor deliberately selects five payments above a hypothetical $100,000 and finds one without approval. The observed result is one exception in five selected payments, or 1 ÷ 5 = 20% of that selected set. Because selection favored high-value items, 20% is not an estimated rate for all payments. The auditor investigates the exception and may expand testing.

Watch the distinction: One exception in five judgmentally chosen items does not prove that one fifth of the population failed. The selection method gives ordinary items no known chance of inclusion.

Reference: [1]

7. Judge evidence quality

Evidence is useful only when it answers the audit question. Relevance links it to a particular control claim; reliability concerns how it was produced and whether it could be altered; completeness concerns missing people, periods or events; timing concerns whether it covers when the control should have operated. Direct system records often carry more weight than an unsupported recollection, but a system export still needs validated fields, scope and provenance. Corroborate important conclusions with independent sources when possible. For a recurring review, look for the population presented to the reviewer, dated evidence of review, identified exceptions and follow-up. An unsigned spreadsheet may show that a list existed, not that anyone examined or acted on it. If evidence is missing, describe the resulting limit; do not convert absence of proof into proof that the control failed.

Worked example: A manager says access is reviewed monthly and supplies an unsigned spreadsheet dated this month. The auditor obtains user exports for earlier months, dated review records, and evidence that flagged accounts were resolved. If March's approval record is absent, the auditor reports that March operation was not demonstrated; the current spreadsheet cannot establish a past review.

Watch the distinction: A document's existence does not establish control performance. Check who used it, when, against which complete population, and what happened to identified exceptions.

Reference: [1]

8. Use analytics to find exceptions

Audit analytics apply a repeatable rule to a defined data set to surface records needing attention. Begin with the control question, then obtain the right source tables, fields, periods and identifiers. Reconcile record counts and totals to source reports, inspect duplicates and null keys, and confirm that join logic does not silently drop records. An unmatched approval identifier may indicate a missing approval, a timing difference, a data defect or a legitimate exception. Preserve the query and input versions so another auditor can reproduce the result. Investigate flagged items against documents and system history before calling them failures. Analytics can test an entire extract, but they do not remove the need to verify that the extract represents the complete population. Try related CISA practice questions to distinguish an exception flag from an audit conclusion.

Worked example: An invoice extract contains 1,000 unique records. A left join to approval records finds 12 with no matching approval ID, leaving 988 matched and 12 flagged; 988 + 12 = 1,000. After checking period alignment and key quality, the auditor examines the 12. A late approval feed or alternate authorized route could explain some matches that initially appear missing.

Watch the distinction: A query result is a lead, not a verdict. Faulty keys, incomplete extracts or valid alternate workflows can make a flagged transaction look unauthorized.

Reference: [1]

9. Write findings that explain risk

A useful finding lets the reader see what rule applied, what actually happened, why it happened if known, and why it matters. The criterion may come from an approved access standard or stated control objective. The condition is the supported exception, with its population, period and tested items. The cause should be evidenced, not guessed; if it remains unknown, say so. Describe the plausible consequence without claiming a breach that the work did not establish. Recommend an action aimed at the cause and make ownership and follow-up testable. Discuss factual accuracy with management, but keep the auditor's conclusion grounded in evidence. Where a sample is judgmental, report exceptions within that sample rather than implying a population rate. This structure helps decision makers prioritize remediation and lets a later auditor determine whether the risk was addressed.

Worked example: A standard requires each privileged account to have an accountable owner. Three of 40 tested accounts have none recorded. The finding names those accounts, states the missing ownership and explains that access may persist through role changes without review. It recommends assigning owners, reconciling all privileged accounts to current roles, and testing the reconciliation in the next cycle.

Watch the distinction: A finding should not claim unauthorized activity merely because ownership is undocumented. The supported issue is weaker accountability and review; misuse would require separate evidence.

Reference: [1]

10. Verify remediation and residual risk

Follow-up tests whether an action addressed the original risk, not merely whether a ticket was closed. First restate the finding, its cause and the intended control outcome. Inspect implementation evidence, then observe or test the control over an appropriate period. For an alert, verify its trigger logic, recipient, delivery and the owner's response to real cases. Separate three states: action not implemented, action implemented but ineffective, and risk sufficiently reduced. Residual risk is the exposure left after controls operate; management may accept it through the organization's risk process, while the auditor reports whether that decision and supporting evidence are sound. A new control can introduce dependencies or gaps, so inspect exceptions and override paths. State any period limit clearly: one successful cycle shows that cycle worked, not that future cycles are guaranteed.

Worked example: Management adds an alert when access reviews become overdue. In the next cycle, the auditor confirms the alert fired for four overdue reviews. Two owners completed their reviews; two ignored the alert. The alert functioned, but the original risk of unreviewed access remains for those two groups. Follow-up stays open or records the unresolved risk for owner action.

Watch the distinction: Closing a remediation ticket after software installation confuses deployment with effectiveness. Test whether the new control led to the required review and resolution.

Reference: [1]

11. Improve audit quality

Audit quality depends on whether a knowledgeable reviewer can retrace the work from objective to conclusion. Workpapers should identify the source, population, period, selection method, procedures, results and evidence for each exception. Supervision catches gaps early, such as unclear criteria or a missing system extract. Review then challenges both support and reasoning: did the evidence cover the claim, were exceptions treated consistently, and was the conclusion limited to tested work? Feedback after an engagement can reveal recurring defects in templates, data requests or review timing. Fix the process, then check whether the fix improves later work. Quality assurance also protects independence and consistency by examining how engagements are planned and reported. A neat file is insufficient if another auditor cannot reproduce the selection or understand why a finding was reached.

Worked example: A reviewer sees a finding about orphaned accounts but cannot identify the sampled records because the workpaper omits account IDs. The team adds links from each exception to the source export and approval history, then records the selection method. Its template now requires these fields, allowing the reviewer to retrace each exception and assess the conclusion.

Watch the distinction: A supervisor's signature does not make incomplete work reproducible. Review must challenge the evidence trail, sampling, criteria and logic behind the stated result.

Reference: [1]

Governance and Management of IT

12. Map external obligations

External requirements come from different authorities and apply under different conditions. Law and regulation can impose binding duties based on location, activity and data subjects. Contracts can create binding promises to customers or suppliers. Industry standards may be voluntary, required by contract, or incorporated into a regulatory framework. Build an obligation register that records the source, applicable entity, data or service, owner and control that implements each duty. Check scope before testing: an obligation for one jurisdiction or data category may not govern every record. Where duties overlap, determine how the organization resolves them with appropriate legal input rather than assuming one retention setting fits all. Audit the mechanism as well as the document: inspect configuration, access, exceptions and evidence that retention or deletion actually occurs. The auditor assesses control coverage and escalates uncertain legal interpretation to qualified counsel.

Worked example: A company stores customer records from two jurisdictions, and one contract promises a stated retention period. The auditor maps each data set to location, legal category and contractual commitment. A single deletion setting applies to every record. The auditor identifies which records that setting affects, compares it with the documented obligations, and tests a sample of actual deletion events before concluding on control alignment.

Watch the distinction: A popular industry standard is not automatically a legal requirement. Establish how each obligation became applicable before treating nonconformance as a breach of law.

Reference: [1]

13. Clarify governance decision rights

Governance sets direction, risk appetite and accountability; management implements decisions and operates controls. Auditors should trace important decisions to people who have authority to make them. A technology specialist can estimate vulnerability and recommend treatment, but accepting business impact belongs to the designated risk owner under the organization's governance structure. Check committee charters, reporting lines, approval limits and escalation paths, then compare them with actual decisions. Be alert to conflicts where the same team designs a control, declares it effective and accepts the remaining risk without independent challenge. Clear decision rights also matter for standards, data ownership and major investments. A responsibility matrix can clarify who proposes, approves, executes and monitors an action, but signatures alone are weak if the approver lacks the information or authority needed to decide.

Worked example: A security team rates exposure of customer data as acceptable after deploying a filter. The risk register identifies a business executive as owner, but shows no owner decision. The auditor asks for evidence of the filter's performance and routes the residual-risk assessment to the named owner. The security team supplies analysis; the owner decides within delegated authority.

Watch the distinction: The team that measures technical risk does not automatically have authority to accept its business consequences. Verify the organization's assigned risk ownership and approval route.

Reference: [1]

14. Test strategy alignment

IT strategy should turn business objectives into choices about services, architecture, investments and capabilities. Start with a stated business result, such as fewer delayed orders, and map the technology needed to produce it. Then examine the portfolio: projects, dependencies, funding, capacity and expected benefits. A metric should measure the intended outcome, not merely project delivery. For example, completing a dashboard says little about whether orders move faster. Challenge assumptions about which bottleneck matters, whether another project must finish first, and who will measure benefits after implementation. An investment can still be justified for a different objective, but decision makers should know when it does not address the named priority. Compare approved strategy with actual spending and operational defects to identify drift. The auditor reports the alignment gap and its effect on the business objective.

Worked example: A retailer wants to reduce late orders. Its order interface fails daily, yet the funded project is a new reporting dashboard. The auditor checks incident data, the dashboard business case and the portfolio decision. If the dashboard only measures delays while the interface causes them, the investment may improve visibility but does not remove the operational bottleneck; management should reassess priority.

Watch the distinction: A project delivered on time is not necessarily strategically successful. Test whether its output changes the business measure it was meant to improve.

Reference: [1]

15. Follow the policy hierarchy

Policy establishes direction and accountability; standards specify mandatory, testable requirements; procedures describe the steps people follow; records show what happened. Trace a control expectation down this hierarchy before judging compliance. A broad rule to secure access cannot, by itself, prove how each account must authenticate. The applicable standard may require a particular method, while procedures explain enrollment and exceptions. Examine whether practice follows both the requirement and the approved exception route. Some identities, such as noninteractive service accounts, may need a different control design, but that difference should have an owner, rationale and compensating controls proportionate to the risk. Test enforcement in configuration and logs as well as reviewing documents. If a procedure conflicts with a mandatory standard, resolve which authority governs and report the gap; a well-written procedure does not override a higher-level requirement.

Worked example: An access policy calls for secure authentication, the internal standard requires multifactor authentication, and a procedure describes employee enrollment. Administrators leave service accounts outside enrollment. The auditor identifies those accounts, checks whether they are noninteractive, examines the approved exception and tests restricted access, secret handling and monitoring. An undocumented bypass fails the governance path even if no misuse is observed.

Watch the distinction: A procedure that staff follow consistently is not sufficient when it conflicts with a mandatory standard. Compare actual practice with the full policy hierarchy and approved exceptions.

Reference: [1]

16. Read enterprise architecture as a risk map

Architecture views show how business processes, applications, data and infrastructure depend on one another. Use them as hypotheses to verify, not as proof that every live connection is documented. Trace a data item from its authoritative source through interfaces, copies, analytics and deletion or archival paths. Ask which system owns the record, how changes propagate, where duplicate values can diverge, and which shared components create failure points. Compare diagrams with configuration, traffic or interface inventories to find unrecorded flows. This method exposes control gaps that are easy to miss when auditing applications one at a time, including inconsistent access, retention and quality rules across copies. Relate each gap to a business or legal obligation. An architecture review is most useful when it identifies the actual path a decision or record takes and the controls at each handoff.

Worked example: A diagram shows two customer databases feeding separate analytics platforms. The auditor confirms that one database is authoritative, then traces a sample deletion request. It removes the record from that database and one platform, while the second platform retains a copy. The issue is a broken propagation path; the auditor identifies its owner and tests how queued or failed deletions are detected.

Watch the distinction: Calling one database authoritative does not make downstream copies harmless. Trace updates and deletions through each live interface and verify their results.

Reference: [1]

17. Evaluate enterprise risk treatment

Enterprise risk treatment starts with a defined event and its potential effect on objectives. Identify the owner, estimate likelihood and impact using the organization's approved scale, then assess existing controls and response options: reduce, avoid, transfer or accept. Residual risk is what remains after controls operate. A likelihood-times-impact score can help rank risks, but an ordinal scale does not make the result a probability or a monetary loss estimate. Test whether the control actually changes likelihood or impact as claimed, and record the assumption. Compare residual exposure with approved appetite and escalation rules; a business owner must decide on acceptance within delegated authority. Also consider concentration, dependencies and changes that make a prior rating stale. Auditors evaluate the integrity of this process and the supporting evidence, rather than accepting a low score at face value.

Worked example: On a hypothetical five-point scale, a risk has likelihood 4 and impact 5, so its initial score is 4 × 5 = 20. A tested control lowers assessed likelihood to 2 while impact stays 5, leaving 2 × 5 = 10. That is a ranking score, not a 50% probability reduction. The owner compares 10 with the organization's approved appetite.

Watch the distinction: A control's existence does not justify a lower residual score. Verify its operation and explain which part of the risk assessment it changes.

Reference: [1]

18. Assess privacy by data life cycle

Privacy controls should follow personal data throughout its life: collection, use, sharing, storage, retention and deletion. Begin with the purpose for each field and ask whether the organization needs it for that purpose. Map downstream copies and recipients, including support tools, analytics and vendors. Then test whether access and use stay within the stated purpose and applicable obligations. Data minimization reduces exposure because a field never collected cannot later leak from that workflow. Removing a field from a form is only one step if historical records or exports still contain it. Retention and deletion controls need ownership, triggers, exceptions and evidence of execution. Jurisdiction and data type affect obligations, so the auditor traces the organization's documented requirements to controls and seeks qualified interpretation where law is uncertain. A security study guide can reinforce the related data protection mechanisms.

Worked example: A support form asks for birth date, but staff locate accounts using an account number. The auditor confirms no support step needs birth date, finds it copied into a case warehouse, and recommends removing the field from new forms. The data owner then assesses existing values under applicable retention rules and tests deletion or justified retention in both systems.

Watch the distinction: Deleting a form field does not dispose of data already collected. Check exports, backups, analytics copies and retention obligations before calling the privacy issue resolved.

Reference: [1]

19. Make data classification operational

Classification turns data value and sensitivity into handling requirements. The owner should define what a label means, who may apply or change it, and which access, sharing, encryption, retention and disposal controls follow. Labels alone are ineffective if systems do not enforce the corresponding rules. Check the data itself, not just the filename or metadata, because exports can combine categories or inherit an incorrect default. Quality governance is related: an authoritative source, validation rules and reconciliation help users know whether data is complete and accurate enough for decisions. Audit a representative flow from creation through export and sharing, including changes of format or location that may strip labels. When a label is wrong, correct both the metadata and the handling consequences, then inspect whether similar exports share the same error.

Worked example: A customer export is labeled public, but inspection shows account numbers. The data owner reclassifies it as restricted under the organization's scheme. The auditor then checks that public links are removed, access is limited to approved users, storage encryption applies and retention follows the restricted-data rule. Reclassification alone would leave the exposure in place.

Watch the distinction: A classification label is not a protective control by itself. Verify that access, transfer, storage and disposal settings change with the label.

Reference: [1]

20. Match IT resources to critical work

Resource management asks whether the organization has the people, skills, funding and capacity to meet its commitments. Review critical services and projects, then map the skills and availability required to operate, change and recover them. A budget can fund hardware while leaving a single person as the only holder of essential knowledge. That creates concentration risk: absence, departure or simultaneous incidents can delay recovery. Evaluate documented procedures, cross-training, alternate coverage and exercises that prove another person can perform the task. Also compare planned work with actual workload; chronic overtime and deferred maintenance can signal that apparent staffing capacity is overstated. Prioritize the consequence for the business service, not just the headcount gap. The auditor should report a specific dependency and test whether management's response reduces it, rather than prescribe an arbitrary staffing number.

Worked example: One engineer can restore a critical database, and the hardware budget is fully funded. The auditor checks the recovery procedure, interviews the alternate engineer and observes a restoration exercise. If the alternate cannot locate encryption keys or complete the restore, cross-training is not yet effective. The finding ties the knowledge gap to delayed service recovery.

Watch the distinction: Adequate spending does not prove adequate capability. A critical service can still depend on one person's undocumented knowledge or availability.

Reference: [1]

21. Control vendor and supply-chain risk

A vendor can satisfy a service target while exposing the organization through weak security, an unapproved subcontractor or an unworkable exit. Start with the service and data the vendor handles, then trace each material risk to due diligence, a contract duty and evidence that the duty operates. Review who may subcontract, where data travels, how incidents are reported and who can inspect relevant controls. An assurance report has value only if its scope and period include the service actually used; examine exclusions and the vendor’s required follow-up actions. Performance reports test delivery, while access records and independent assurance can test other controls. Finally, check how data and service would transfer or be securely returned at termination. The CISA exam content outline includes IT vendor management and supply-chain risk.

Worked example: A payroll vendor moves employee records to a hosting subcontractor without naming it to the customer. The auditor maps the data flow, checks whether the contract required approval or notice, and reviews assurance evidence for that hosting environment and period. A report covering only the payroll vendor’s offices cannot establish host control effectiveness. The finding addresses the breached duty, uncovered risk and an exit path if the host is unacceptable.

Watch the distinction: A strong vendor service score does not establish that subcontracting or data controls are sound. Match each assurance document to the actual service, location and reporting period.

Reference: [1]

22. Interpret IT performance measures

A key performance indicator describes how well a service meets an objective; a key risk indicator signals rising exposure before or alongside failure. Both need a defined population, time window, calculation, owner and response trigger. A closure percentage can improve if staff close easy tickets quickly while serious work accumulates. Segment the data by severity, age and reopenings, then compare trends with service commitments. Check the source system for omitted tickets, altered priorities and clock pauses before accepting a dashboard. A useful measure leads to an action: a growing critical backlog might prompt added specialists, escalation or root-cause analysis. Evaluate indicators together rather than treating one favorable average as proof of control. The auditor also checks whether management acted when a measure crossed its agreed trigger.

Worked example: In a hypothetical month, the help desk closes 190 of 200 eligible tickets within target: 190 ÷ 200 = 95%. Meanwhile, unresolved critical tickets rise from 4 to 15, an increase of 11, or 275% of the starting backlog. The closure KPI meets its target, but the backlog KRI signals worsening exposure. The auditor checks ticket severity and age, then asks what escalation followed.

Watch the distinction: A high overall closure rate can conceal deteriorating service for critical users. Inspect the denominator and severity mix before concluding that the help desk is performing well.

Reference: [1]

Information Systems Acquisition, Development, and Implementation

23. Challenge the project business case

A business case connects a proposed system to a measurable business need and compares credible options, including doing less or retaining the current service. Separate one-time costs from recurring operating costs; identify benefit timing, dependencies, uncertainty and the person accountable for realizing each benefit. Feasibility includes technical integration, skills, legal obligations, delivery time and whether the organization can support the system afterward. For a simple comparison, undiscounted net benefit equals total estimated benefits minus total estimated costs, but money received later is worth less than money spent now. Where timing matters, discount each future net cash flow using an explicitly stated assumed rate. The auditor checks source evidence for estimates and sensitivity to weaker savings or delayed delivery. Approval is a governance decision; an attractive arithmetic result alone does not establish feasibility.

Worked example: A hypothetical system costs $600,000 upfront and saves $250,000 at each of three year-ends, with no other costs assumed. Undiscounted savings are 3 × $250,000 = $750,000, leaving $150,000 above the initial cost; simple payback is $600,000 ÷ $250,000 = 2.4 years. This favorable estimate still depends on three years of realized savings and ignores financing, discounting and operating costs.

Watch the distinction: A positive undiscounted surplus is not a complete approval case. Delayed benefits, missing support costs or an untested integration dependency can reverse the decision.

Reference: [1]

24. Audit the development method

The development method changes where evidence appears, but each important requirement should still be traceable to approval, construction, testing and release. In sequential delivery, stage approvals and baselined documents may provide that trail. In iterative delivery, inspect backlog decisions, acceptance criteria, code review, automated test results and deployment records for each release. For outsourced work, establish who owns requirements and controls, what the supplier must report, and how the customer verifies acceptance. Riskier changes deserve deeper testing regardless of method. The auditor can select a requirement and trace it forward to production, then select a production change and trace it back to an authorized need. Breaks in either direction can reveal omitted requirements or unapproved functionality. Avoid demanding a document whose format does not fit the team’s method; test the underlying control purpose.

Worked example: A team releases every two weeks. For a new refund limit, the auditor finds an approved user story, acceptance criteria specifying role-based limits, a reviewed code change, passed limit tests and the deployment record for release 6. The trail supports implementation of that requirement. If the production limit differs from the approved value, the auditor investigates the change even though the release was on schedule.

Watch the distinction: Agile delivery does not remove the need for authorization or testing. Evidence may sit in linked stories and pipelines instead of a single final sign-off document.

Reference: [1]

25. Design controls into the system

Controls are cheaper to make reliable when their purpose is specified with the business rule. Identify what could go wrong with an input, transaction, calculation, output or interface, then decide where prevention, detection or correction is needed. Application controls enforce transaction rules, such as valid ranges, approval limits and reconciliations. General controls over access, change and operations help keep those rules dependable after launch. For each proposed control, define the trigger, permitted roles, exception path, log record and testable outcome. A controlled override should require a distinct authority and leave evidence for review; simply hiding a warning is weak. The auditor examines design and test cases against the risk, including boundary values and unauthorized roles, while management remains responsible for choosing and operating the control.

Worked example: A claims system lets an adjuster approve a hypothetical $12,000 payment although that role’s authorized limit is $10,000. The auditor traces the rule to design and tests amounts of $10,000 and $10,001. The first should pass if other checks succeed; the second should be blocked or routed to an authorized approver. An override needs a recorded reason, approver and later review.

Watch the distinction: A post-payment exception report may detect an excessive claim, but it cannot enforce approval before money moves. Place the authorization check in the transaction path.

Reference: [1]

26. Decide whether a system is ready

Readiness is a decision about the whole service, not just whether users like its screens. Compare documented release criteria with evidence for functional and integration tests, data reconciliation, security, performance, support staffing, monitoring and recovery. Classify open defects by business consequence and identify workarounds, owners and decision authority. User acceptance confirms that selected workflows meet user needs; it cannot by itself validate financial totals or operational recovery. A go-live decision should record residual risks and who accepts them, especially where a workaround is temporary. The auditor checks whether test results represent the production configuration and whether critical interfaces and roles were exercised. If a release proceeds despite a gap, verify that management understands its impact and has a realistic containment and remediation plan.

Worked example: A purchasing application passes user acceptance, but its reconciliation test still loses one transaction in a failed interface batch. Operations also lacks a restart runbook. The auditor concludes that acceptance of the user screens does not establish transaction completeness or support readiness. The release decision should address the defect, retest the corrected interface and provide a practiced restart procedure before relying on the service.

Watch the distinction: A passed user acceptance test is one input to readiness. It does not clear an unresolved critical defect or show that operators can restore service.

Reference: [1]

27. Control releases and configuration

A release is controlled when the version approved for deployment is the version running in production. Trace the change request through risk assessment, authorization, code review, build, testing and deployment. Compare a build identifier or cryptographic hash with the approved artifact, and check that people who develop code cannot quietly bypass production controls. Configuration baselines should include settings, scripts and infrastructure definitions, since a correct application binary can behave unsafely with the wrong configuration. Emergency changes may move faster, but they still need a recorded reason, bounded access and prompt review. Rollback requires a compatible previous version, data considerations and a rehearsed decision point. The auditor investigates differences between approval and production to determine whether they were authorized and tested, rather than assuming every mismatch caused harm.

Worked example: A release ticket approves version 2.4, but production contains a later hotfix with a different hash. The auditor matches the running artifact to repository and deployment logs, then finds no linked authorization or test result. The difference is an uncontrolled change requiring investigation. A later ticket cannot prove that the earlier deployment was approved; management should establish its effect and record remediation.

Watch the distinction: A matching version label is weak evidence if the underlying build differs. Use the artifact identity and deployment trail to verify what actually reached production.

Reference: [1]

28. Reconcile migration and conversion

Migration testing asks whether every required record moved, retained its meaning and can be recovered if conversion fails. Begin with a defined source population and cutover point. Reconcile counts and control totals through extraction, transformation, rejection and loading; a matching count cannot detect a wrong amount or field mapping. Sample transformed records across ordinary and edge cases, checking key relationships, dates, amounts and access permissions in the target. Investigate rejects individually, including whether they were corrected, excluded with authorization or left for later. A rollback plan must account for changes made after cutover, or returning to the source can lose new transactions. The auditor checks that reconciliation was performed by an accountable party and that unresolved differences were understood before the target became authoritative.

Worked example: A hypothetical cutover extracts 50,000 customer records. The target loads 49,980 and the rejection log lists 20, so 49,980 + 20 = 50,000; the count reconciles. The auditor still samples loaded balances and transformed dates, resolves all 20 rejects and tests rollback. A complete accounting of records does not establish that values or relationships survived conversion.

Watch the distinction: Matching source and target counts cannot prove accurate conversion. A field can be truncated or mapped to the wrong customer while the total record count stays unchanged.

Reference: [1]

29. Review outcomes after implementation

After launch, compare what the organization obtained with the approved requirements and business case using evidence from actual operation. Check whether promised controls work with live roles and volumes, whether users adopted the process, and whether benefits have a measurable owner and baseline. Separate project delivery measures, such as schedule and budget, from business outcomes, such as fewer errors or faster processing. Unmet requirements should become tracked actions with owners, dates and verification criteria; vague lessons learned rarely close a control gap. Review incidents and workarounds because they may reveal design assumptions that testing missed. The auditor’s role is to assess whether management has a fair account of delivered value and residual risk, then follow up on corrective action. A review soon after launch may need later measurement for benefits that take time to appear.

Worked example: A purchasing system launches on its planned date, yet users can create duplicate supplier records. The approved requirement called for duplicate checks. The auditor tests two records with the same identifying details, confirms the duplicate is accepted and records the gap. Management assigns an owner to add validation, clean existing duplicates and retest. On-time delivery does not satisfy the data-quality objective.

Watch the distinction: Meeting the launch date does not establish that the project achieved its purpose. Verify requirements and benefits after real use, then track failed outcomes to closure.

Reference: [1]

Information Systems Operations and Business Resilience

30. Trace infrastructure dependencies

A business service depends on more than its visible application servers. Map its path through identity, name resolution, network links, compute, databases, storage, monitoring and external providers. Mark each dependency by whether failure stops the service, reduces capacity or only affects recovery. Redundant components help only when they do not share the same failure path. For example, two web servers using one authentication system cannot serve users when that system fails. Check architecture diagrams against configurations, traffic paths and recovery tests; diagrams may omit a shared certificate, database or network carrier. The auditor then compares identified weak points with the service’s impact and recovery objectives. This service-level reasoning also helps distinguish a component failure from a customer-visible outage. For adjacent security context, see the CISSP study guide.

Worked example: An online portal uses two web servers behind a load balancer, but both require one authentication service for every login. The auditor traces a login request and confirms no alternate identity path exists. A web-server failover test succeeds, yet an authentication outage would stop new logins on both servers. The finding identifies the shared dependency and calls for a tested service-level recovery path.

Watch the distinction: Two servers do not make a service resilient by themselves. Follow the full transaction path to find shared dependencies that can disable both servers.

Reference: [1]

31. Follow the asset life cycle

Asset control follows an item from approval and receipt through assignment, maintenance, transfer and disposal. A useful inventory links a unique identifier to an owner, location, configuration, support status and data sensitivity. Reconcile purchase and discovery records to the inventory to find assets that were never registered; reconcile inventory to custody records to find items no longer where expected. Disposal evidence should show which device was handled, by whom, when and how data was removed or the media destroyed. A certificate covering a shipment without serial numbers may not prove disposal of a particular laptop. The auditor also checks whether retired devices are removed from management tools and whether leases or supplier returns create different custody paths. Missing records call for tracing, not an automatic conclusion that data was exposed.

Worked example: Ten laptops are marked retired, but disposal certificates list only eight matching serial numbers. The gap is 10 − 8 = 2 devices. The auditor traces those two through transfer logs, storage records and any return-to-lessor documents. Until their custody and data handling are established, the retirement status is unsupported and potential exposure remains unresolved.

Watch the distinction: A retired label in the inventory is not evidence of secure disposal. Match each device identifier to custody and data-removal records before closing its life cycle.

Reference: [1]

32. Control automated jobs

Automated production jobs require controlled inputs, dependencies and recovery points. Confirm that the scheduler starts a job only after required upstream files or jobs complete, records each run and alerts an owner on failure. A successful process exit is insufficient if output totals are wrong, so reconcile expected and produced records or monetary totals. Restart design matters: an idempotent job can repeat without duplicating effects, while another needs a checkpoint that resumes only unfinished work. Review access to scheduling definitions and changes to scripts because an unauthorized schedule change can alter processing silently. The auditor tests a failed run, its alert, investigation, rerun authorization and final reconciliation. Where jobs chain together, follow the failure’s effect downstream so an incomplete input is not treated as complete output.

Worked example: A billing job fails after posting bills for 600 of 1,000 accounts. Repeating all 1,000 without duplicate protection could issue 600 second bills. The auditor checks a checkpoint or processed-account marker, then verifies a controlled rerun posts only the remaining 400. Final reconciliation should show 600 + 400 = 1,000 unique billed accounts and no duplicate invoices.

Watch the distinction: A successful rerun message does not prove correct billing. Reconcile unique outputs and check that already processed records were skipped or safely repeated.

Reference: [1]

33. Reconcile system interfaces

An interface has at least four control questions: what was sent, what arrived, what the receiver accepted and what was ultimately processed. Use unique message identifiers, sequence numbers, counts or control totals to reconcile each stage. An acknowledgment may mean transport receipt rather than valid business processing, so understand its definition. Validate required fields and reject malformed records into a monitored queue. Retries need duplicate protection; otherwise a timeout followed by a retry can create two orders. The auditor checks both completeness and accuracy, including whether mapping changes preserve values. Investigate differences by tracing specific identifiers through logs and exception queues, then verify that corrected records reached the intended destination. A daily total can hide equal and opposite errors, so record-level checks remain important for critical flows.

Worked example: A source transmits 2,000 orders. The receiver acknowledges 1,995 unique message IDs, leaving 2,000 − 1,995 = 5 unaccounted for. The auditor locates three rejected records and two timed-out messages, verifies corrected retries and confirms no duplicate orders were created. Only after 2,000 unique orders are accepted and processed can the interface be considered complete for that batch.

Watch the distinction: A sent count is not a processed count. Transport success can coexist with validation rejects, and retries can repair missing records while also creating duplicates.

Reference: [1]

34. Assess shadow IT and spreadsheets

End-user tools can become critical systems when their outputs determine payments, financial reporting or operational decisions. Discover them through interviews, file locations, data flows and reliance on their results, then rank them by impact and complexity. For a spreadsheet, identify the owner, approved version, source data, protected formulas, access rights and independent review. Trace a calculation from source input to final output, including copied rows and hidden sheets. Reconcile totals to authoritative systems and preserve versions so changes can be explained. A reviewer should be able to test meaningful formulas, not merely sign a cover page. If the tool cannot be controlled adequately, management may need to replace it or add compensating checks. The auditor assesses the control over the decision, even when the tool sits outside central IT.

Worked example: Finance calculates commissions in an unregistered spreadsheet. A copied formula excludes one sales region with hypothetical eligible sales of $80,000 and a 5% commission rate. The omission understates commissions by $80,000 × 0.05 = $4,000. The auditor traces the formula range, reconciles regional sales to the source system and checks whether review would detect future omissions.

Watch the distinction: A spreadsheet used by a small team can still be a critical application. Its importance follows the decisions it drives, not who installed it.

Reference: [1]

35. Forecast service capacity

Capacity decisions should use the demand at the service’s busiest relevant period, not a daily average. Establish current peak throughput, tested sustainable capacity and headroom, then forecast demand using a stated growth assumption. Headroom is tested capacity minus expected peak; a negative result indicates the forecast exceeds demonstrated capability. Check whether capacity measurements include the same transaction mix, response-time target and dependencies expected in production. A database, network link or third-party quota can constrain service before application servers do. Options include scaling, smoothing demand, reducing expensive work or changing service expectations. The auditor examines whether monitoring detects approaching limits and whether planned capacity arrives before demand does. A forecast is uncertain, so sensitivity checks for higher growth or unusual peaks are useful.

Worked example: A hypothetical service peaks at 800 requests per second and has tested sustainable capacity of 1,000 requests per second at the required response time. Forecast growth is 30%, giving 800 × 1.30 = 1,040 requests per second. Expected demand exceeds tested capacity by 40 requests per second. The current 200-request headroom is therefore insufficient; management needs scaling or demand reduction before that peak.

Watch the distinction: A 20% headroom figure based on today’s peak may disappear under growth. Compare forecast peak with capacity tested under the required service conditions.

Reference: [1]

36. Find availability weak points

Availability is a property of the end-to-end service. Redundant servers or sites reduce risk only when their shared dependencies and failover behavior are understood. Map power, carriers, identity, databases, storage, routing, staff and suppliers across both paths. Then ask whether a single event can disable both, whether the alternate path has enough capacity and whether switching actually works within the required recovery time. A failover test should include user transactions, data consistency and return to normal operation, not just a machine boot. Planned redundancy may fail if configurations drift or certificates expire at the same time. The auditor weighs these findings against business impact and tests that represent plausible failures. A successful narrow test supports only the scenario exercised, so document its scope and unresolved common dependencies.

Worked example: An organization has two data centers, each with working application servers, but both internet routes use one carrier. A site-switch test passes while that carrier remains available. The auditor identifies carrier loss as a common failure that could disconnect both sites. A useful test simulates the shared carrier outage and verifies customer transactions through an independent path within the business recovery objective.

Watch the distinction: Geographic separation alone does not remove a common point of failure. Shared carriers, identity services or storage can defeat an otherwise sound site design.

Reference: [1]

37. Separate incidents from problems

Incident management restores service and limits immediate harm; problem management investigates the cause of one or more incidents and prevents recurrence. During an outage, teams may restart a service, switch traffic or use a workaround before the cause is known. Record the timeline, impact, escalation and restoration so users can be informed and service commitments assessed. Repeated incidents or a major single event should trigger analysis of logs, changes and dependencies. The resulting problem record tracks a known error, root-cause hypothesis, permanent fix and evidence that the fix worked. A change may be needed to implement that fix and should follow appropriate control. The auditor checks whether recurrence patterns are visible and whether closed incidents feed problem analysis. Closing each outage ticket after restoration can conceal an unresolved systemic weakness.

Worked example: An application fails four times in one month and is restored within 15 minutes each time by restarting a service. Incident records show quick restoration, but the repeat pattern warrants a problem record. Analysis links each failure to a memory leak after the same batch job. The team tests a fix, deploys it through change control and monitors subsequent runs before closing the problem.

Watch the distinction: Restarting a service can resolve the immediate incident without resolving the defect. Repeated outages call for root-cause analysis and verified corrective action.

Reference: [1]

38. Coordinate change, configuration and patching

Change, configuration and patch processes depend on an accurate view of what exists. Configuration records identify systems, versions, owners and dependencies; change control authorizes modifications; patch management selects, tests, deploys and verifies updates. Compare discovery data with the inventory before calculating coverage, because an incomplete denominator can make deployment appear complete. Risk-based patch decisions consider exposure, exploitability, business impact and compatibility, with documented handling for exceptions. Testing should cover the affected service and a rollback path, while deployment evidence should identify the actual target machines. The auditor traces a patch from approval through test results, distribution logs and post-install verification. For wider control context, the CISA practice questions can help you apply the distinction between approval, deployment and verified coverage.

Worked example: A patch is approved for 100 servers, yet the inventory lists only 92 and the deployment tool reports success on all 92. Coverage against the approved population is 92 ÷ 100 = 92%, leaving eight servers unaccounted for. The auditor reconciles discovery and ownership records, then checks patch state on the eight before calling deployment complete.

Watch the distinction: One hundred percent of an incomplete inventory is not full coverage. Verify the population before accepting a patch success percentage.

Reference: [1]

39. Make operational logs usable

Logs support diagnosis and investigation only when they capture the right events and can be trusted. Identify which actions must be traceable, such as privileged changes, failed access and payment processing, then confirm that each relevant component records actor, action, result and timestamp. Synchronize clocks or record offsets and time zones so events can be sequenced. Protect logs from alteration by the accounts they monitor, retain them long enough for the stated investigation need and ensure someone reviews actionable exceptions. High volume alone is not evidence of effective monitoring; gaps, duplicate records and noisy alerts can obscure a real event. The auditor follows a sample transaction across components, checks time alignment and verifies that a detected anomaly reached an owner. Preserve original records when an investigation may require them.

Worked example: A payment error is logged by the application at 14:05. The database clock is known to run nine minutes fast and records the related update at 14:14. Subtracting nine minutes places the database event at 14:05 on the application clock, so the timestamps may describe one sequence. The auditor verifies the offset and time zones before drawing conclusions, then raises the clock synchronization weakness.

Watch the distinction: Sorting raw timestamps from unsynchronized systems can produce a false event order. Normalize known offsets and time zones before attributing cause.

Reference: [1]

40. Test service-level reporting

A service-level report should apply the agreement’s definitions to a complete record of service events. Identify the measured service, observation window, permitted exclusions, start and end of each outage, data source and rounding rule. Calculate availability as eligible service time minus counted downtime, divided by eligible service time. Inspect tickets and monitoring records for missing events, then verify any maintenance exclusion against the notice and timing terms in the agreement. A provider’s dashboard may use a different boundary than the customer experiences, such as measuring a server while users cannot sign in. When a target is missed, check whether escalation, service credits or corrective plans followed the agreed process. The auditor reports the calculation and interpretation separately, since the number is only meaningful when its scope is clear.

Worked example: Assume a hypothetical 30-day window of 720 hours, no excluded maintenance, 0.72 hour of other downtime and a two-hour outage labeled maintenance without required advance notice. The provider excludes the two hours and reports (720 − 0.72) ÷ 720 = 99.9%. If the notice condition was unmet, counted downtime is 2.72 hours; availability is 717.28 ÷ 720 = 99.622% approximately. The auditor checks the notice record before accepting either figure.

Watch the distinction: An outage does not become excluded maintenance merely because the provider labels it that way. Apply the agreement’s notice and measurement rules to the underlying event record.

Reference: [1]

41. Audit database integrity

Database integrity depends on who can change records, how changes are committed, and whether errors can be detected and recovered. An auditor first maps business roles to database privileges, especially direct write access that bypasses application checks. Transactions should preserve a complete unit of work: if one step fails, the related changes should roll back rather than leave a partial result. Constraints can reject invalid values, while logs connect changes to accountable identities. The auditor tests those mechanisms with approved and rejected transactions, then checks whether logs themselves can be altered. Backups and maintenance matter too: a consistent backup must restore usable data, and maintenance scripts need authorization and reconciliation. A successful restore proves recoverability for the tested point, but it does not establish that every earlier transaction was accurate.

Worked example: A support account can update both customer balances and the audit table. The auditor tests its assigned role and confirms that a balance edit and log deletion are both permitted. This creates a path to change a balance and hide the change. The finding calls for separate, restricted privileges and a protected audit trail. The auditor then tests a sample balance change to confirm its transaction and log remain traceable.

Watch the distinction: Assuming a successful backup proves database integrity overlooks unauthorized edits and partial transactions. Restoration and transaction controls answer different questions, so both need evidence.

Reference: [1]

42. Use a business impact analysis

A business impact analysis starts with business processes, not servers. For each process, identify the products or obligations it supports, the effect of interruption as time passes, and the people, data, facilities, suppliers and technology needed to resume it. A maximum tolerable disruption describes when the impact becomes unacceptable; a recovery time objective sets a planned restoration target within that limit. The recovery point objective addresses acceptable data loss, a separate question. The auditor checks whether impact estimates have credible owners and reflect peaks, deadlines and downstream effects. Next, trace critical processes through their dependencies and compare those dependencies with recovery plans. A highly available application cannot support payments if its identity service or network is unavailable. The CISA exam content outline includes business impact analysis within business resilience.

Worked example: Suppose a payment process reaches major loss after four hours of interruption, while a monthly archive can wait two days. A proposed plan restores the archive first because its server is easier to start. The auditor compares the time-based impacts and recommends prioritizing payments. The payment recovery sequence must also include its network, identity service and transaction data; restoring the application alone would not resume processing.

Watch the distinction: Ranking systems by hardware cost can misstate recovery priority. A modest service may support a time-critical business process, while an expensive platform may tolerate a longer interruption.

Reference: [1]

43. Prove backup and restoration

A backup control is effective only when it can supply data that is recent enough and can be restored within the business target. The recovery point objective (RPO) measures maximum acceptable data loss backward from an outage; the recovery time objective (RTO) measures how long service may take to resume. An auditor compares backup intervals, replication lag and transaction-log coverage with the RPO, then times an end-to-end restore against the RTO. Evidence should include successful jobs, failed-job alerts, protected copies, integrity checks and restoration results. Test a representative data set and verify record counts or other business reconciliations after restoration. A backup marked successful may contain unusable or incomplete data. Also examine whether credentials, encryption keys and restore instructions remain available when the primary environment fails.

Worked example: Assume a database has a one-hour RPO and takes usable backups every four hours, with no intervening transaction logs. If failure occurs just before the next backup, nearly four hours of changes could be lost. That exceeds the RPO by nearly three hours. A completed backup job does not resolve the gap; the organization needs a shorter effective capture interval or another tested recovery method.

Watch the distinction: Confusing backup frequency with recovery time leads to the wrong conclusion. Frequent copies may limit data loss, yet a slow restore can still miss the service’s RTO.

Reference: [1]

44. Keep business operations running

Business continuity covers the work people must keep doing during disruption, including decisions, customer contact, manual processing and supplier coordination. Start with the critical processes identified by the impact analysis, then follow each through its minimum staffing, workspace, communications, records and third parties. A usable procedure names who declares the disruption, how staff receive instructions, what work can be done manually, and how manual records are reconciled when systems return. The auditor checks that alternate arrangements are accessible under the same failure scenario they are meant to address. Exercises should involve business users and realistic constraints, rather than merely confirming that a document exists. Evidence of an exercise includes observed delays, unresolved dependencies, assigned fixes and a repeat test where a significant weakness was found.

Worked example: A call center plans to move to an alternate site during a network outage. Its customer contact lists, however, exist only on the primary network. During an exercise, agents reach the site but cannot call customers. The auditor identifies the shared dependency, tests an approved offline or independent access method, and checks that agents can record and later reconcile calls made during the outage.

Watch the distinction: Treating an alternate building as a complete continuity solution ignores information and people. A staffed site cannot sustain a process if essential records and communications remain unavailable.

Reference: [1]

45. Test disaster recovery dependencies

Disaster recovery focuses on restoring technology services through a workable sequence. That sequence should include infrastructure, network routing, identity, storage, applications, data validation and business handover. An auditor identifies the service’s RTO and RPO, then compares them with timed exercises that include those dependencies. A component may recover quickly while the complete service remains unusable. Review who declares a disaster, who contacts providers, how alternate resources are activated, and how changes made during recovery are reconciled afterward. Test results should record start and end times for each stage, defects and corrective actions. A tabletop discussion can reveal missing decisions, but it cannot demonstrate that systems actually start, connect and process transactions within target. The most persuasive evidence is an exercised service with business users validating output.

Worked example: Assume the payment service has a four-hour RTO. In an exercise, its database is restored after two hours, but missing network routes delay application access until hour six. End-to-end recovery takes six hours, exceeding the target by two hours. The auditor reports the failed service target, identifies routing as the bottleneck, and asks for a retest that includes a successful payment transaction.

Watch the distinction: Calling recovery successful when the database starts confuses a component milestone with a business service. Users must be able to complete the required work within the target.

Reference: [1]

Protection of Information Assets

46. Assess the security program

A security framework helps an auditor evaluate whether security activities form a governed cycle. Begin with information assets and business risks, then examine who owns risk decisions, how controls are chosen, how they operate, and how results drive improvement. A scan or dashboard is a detection mechanism; it has little value without triage, assigned remediation, verification and escalation of overdue work. Trace several findings from discovery through risk rating, owner assignment, action, retest and closure. Check whether management accepted any remaining risk within its decision authority. Metrics should reveal both activity and outcomes, such as unresolved exposure on important assets. The auditor need not assume that adopting a named framework guarantees protection. Its value lies in providing a consistent structure for testing whether the organization identifies, treats and revisits its actual risks.

Worked example: A company runs weekly vulnerability scans, but no team owns fixes. The auditor selects a critical finding on a customer-facing server and finds it appears in four reports without a ticket or risk decision. Detection is working; treatment is not. The auditor recommends an assigned owner, due-date tracking, escalation and a retest that confirms the exposure is closed.

Watch the distinction: A large number of scans does not demonstrate effective security management. Repeated detection without ownership or verified treatment can leave the same exposure in place.

Reference: [1]

47. Protect facilities and equipment

Physical and environmental controls protect the facilities that support information services. The auditor starts with the assets and failure effects: a critical server room calls for controlled entry, power continuity, fire protection and temperature management suited to its equipment. Entry testing goes beyond checking for badges. Compare authorized access lists with current roles, examine visitor escort and exit records, and observe whether doors can be followed through or left open. For environmental protection, trace alarms to people who can respond, maintenance records to installed equipment, and exercises to actual operating conditions. A sensor that reports overheating after business hours offers little protection if nobody receives the alert. Physical controls also interact with logical controls: access to a console, backup media or network port can defeat well-designed software restrictions.

Worked example: A server room requires badges, yet visitors regularly follow employees through an unmonitored door. The auditor observes the entrance and compares visitor records with badge events; three visitors have no corresponding authorized entry. The badge reader controls individual scans but does not account for those entries. The finding addresses door monitoring, escort checks and review of exceptions, then tests whether the changes improve accountability.

Watch the distinction: Assuming a badge reader controls every entry overlooks tailgating and shared credentials. The auditor must test actual entry behavior and records, not just inspect the device.

Reference: [1]

48. Control identity and privilege

Identity and access management follows an account from identity proofing through approval, authentication, role changes and removal. An auditor first identifies authoritative personnel events and maps them to account and privilege changes. Provisioning should reflect a justified role, while elevated access needs narrower approval, monitoring and periodic review. Authentication confirms who is using an identity; authorization determines what that identity may do. Both can work as designed while excessive old permissions persist. Test joiners, movers and leavers by tracing HR records to application grants and removal timestamps. For service and emergency accounts, examine ownership, permitted use and activity logs because ordinary personnel workflows may not apply. Reconcile the complete account population with known owners so that inactive or orphaned identities do not escape a sample based only on current employees.

Worked example: An employee moves from infrastructure support to procurement. HR shows the transfer, and the new procurement role is granted, but the old database administrator role remains. The account is active and its authentication is valid, yet its combined privileges exceed the new job need. The auditor traces the role-change request, confirms the old grant was omitted, and tests whether the mover workflow now removes obsolete access.

Watch the distinction: Checking only whether leavers were disabled misses movers who accumulate rights. An active employee can still hold inappropriate privilege from a previous role.

Reference: [1]

49. Segment and defend networks

Segmentation limits which systems can communicate, reducing the paths available after an account or device is compromised. The auditor begins with zones based on data and function, then obtains the intended flow matrix: source, destination, protocol, purpose and owner. Compare that design with firewall rules and observed connections. Rules should permit necessary traffic narrowly and log denied or unusual attempts where useful. A network diagram alone cannot establish enforcement; test a representative permitted path and a prohibited path from the correct source locations. Also examine administrative access, temporary rules and shared services that may create indirect routes. If test and production are meant to be separate, a direct database connection is an exposure even if no misuse has yet been observed. The finding should identify the reachable asset and the control boundary crossed.

Worked example: A workstation in the test network connects to the production database port. The auditor confirms the connection from that source, finds no approved flow in the network design, and identifies the firewall rule that permits it. The result is an unauthorized route across the intended boundary. A narrowed rule or removal is tested by confirming that necessary production traffic still works while the test path fails.

Watch the distinction: A firewall’s presence does not prove segmentation. Broad rules, temporary exceptions and indirect routes can allow the very movement the boundary was intended to restrict.

Reference: [1]

50. Secure endpoints

Endpoint security needs population coverage as well as effective settings. The auditor establishes the device population from management, network discovery and procurement records, then reconciles it with the security tool’s inventory. Test hardening settings, patch status, malware defenses, tamper protection and whether alerts reach a response team. Coverage percentages can conceal active high-risk devices, especially those outside normal management. For missing agents, determine whether the devices still connect, what data they hold and whether another control applies. Patch review should distinguish a deployed package from a successful installation and a completed restart. Select devices for direct verification, including exceptions and recently added machines. The CISA practice questions can help you rehearse the audit distinction between a reported percentage and verified control coverage.

Worked example: A console reports 98% endpoint coverage across 500 managed laptops. That means 490 are covered and 10 are not: 500 × 0.02 = 10. The auditor identifies those 10 by device ID, finds six are active, and checks their network access and data sensitivity. Remediation must address the active devices; the aggregate percentage alone cannot establish acceptable exposure.

Watch the distinction: Reading 98% as sufficient without identifying the uncovered devices ignores concentration risk. One missing device with privileged access may matter more than many protected low-risk devices.

Reference: [1]

51. Prevent unintended data release

Data loss prevention (DLP) controls inspect or restrict data leaving approved channels. The auditor connects rules to classification and legitimate data flows: which records are sensitive, where they may go, and who may approve an exception. Detection can use content patterns, labels or context such as destination and user role, each with false positives and blind spots. Test both an unauthorized transfer that should be blocked and an approved transfer that should succeed. Then inspect alert ownership, investigation records and exception expiry. A broad permanent bypass can erase the benefit of an otherwise effective rule. Encryption, archives and alternate channels may limit what the tool can inspect, so coverage must be tested against the organization’s actual ways of sending data. DLP evidence supports conclusions about defined flows and rules, not a guarantee that no data can escape.

Worked example: A rule blocks files containing customer identifiers, including a scheduled transfer to an approved vendor. The auditor verifies the vendor’s permitted data and destination, then tests a narrowly scoped exception limited to that sender and route. Logs show the approved transfer succeeds while a trial to an unrelated destination remains blocked. The exception needs an owner and review date so its scope does not expand silently.

Watch the distinction: Disabling the rule because of false positives trades a visible workflow problem for uncontrolled release. Tune the condition and exception using the authorized data flow.

Reference: [1]

52. Choose and manage encryption

Encryption protects data only within a defined threat model. Encryption in transit protects a connection against interception when the endpoints and protocol are correctly authenticated. Encryption at rest protects stored copies if media or storage is exposed, but an authorized application can still read plaintext. The auditor identifies the sensitive data, its paths and copies, then traces which keys decrypt it. Key custody, access separation, rotation, backup and recovery determine whether encryption remains effective and usable. A key stored beside the encrypted data under the same credentials may offer little protection from server compromise. Conversely, losing the only key may make a backup impossible to restore. Review configurations and test both unauthorized access resistance and an authorized restoration. The CISSP study guide offers related security concepts, while the audit conclusion must rest on this system’s evidence.

Worked example: A backup file is encrypted, but its decryption key sits on the same exposed server under the backup account. Someone who compromises that account could obtain both items. The auditor traces key permissions, confirms the shared access path, and tests a separately controlled key store. A restoration exercise then verifies that authorized staff can still recover the backup when the primary server is unavailable.

Watch the distinction: An encrypted file is not automatically safe from every attacker. Key placement and access determine whether the same compromise can reveal both the ciphertext and its key.

Reference: [1]

53. Validate trust through PKI

Public key infrastructure (PKI) binds a public key to an asserted identity through a certificate signed by a trusted issuer. During a connection, the client checks the certificate’s signature chain, validity period, intended use and hostname, then verifies that the server controls the matching private key. Revocation information can indicate that a certificate should no longer be trusted, though its practical handling depends on the application’s configuration. The auditor tests the whole validation path, including trust stores and private-key protection, rather than merely observing encrypted traffic. A valid certificate for the wrong name does not authenticate the intended server. Likewise, a correct certificate cannot compensate for a stolen private key. Renewal processes matter because an expired certificate can interrupt service, while hurried replacement can introduce the wrong key or identity.

Worked example: A client connects to pay.example.test but receives a certificate naming reports.example.test. Its signature chain and dates are valid, yet the hostname does not match the service requested. The auditor treats the identity check as failed and inspects deployment records to find why the wrong certificate was installed. Replacing it is followed by a client-side connection test that checks the name and chain.

Watch the distinction: Seeing a padlock or encrypted session does not alone prove the remote party’s identity. Certificate name and trust checks are part of authenticated encryption.

Reference: [1]

54. Divide cloud control responsibility

Cloud assurance begins by identifying the service model and the actual division of duties. A provider may manage physical hosts and parts of the platform, while the customer still controls identities, data, application settings and permissions. The division varies by service and contract, so the auditor maps each relevant control to an owner and evidence source. For virtualized environments, examine isolation between workloads, privileged administration, images and configuration drift. Provider assurance reports can support conclusions about provider-operated controls, but their scope, period and customer responsibilities need checking. The auditor also tests customer settings directly, such as storage access, logging and encryption configuration. When a finding spans both parties, trace the handoff: who detects it, who receives the alert and who can correct it. An unassigned handoff can leave a known exposure unresolved.

Worked example: A provider’s documentation shows that it secures the host hardware. A customer-managed storage bucket is nevertheless readable without authentication. The auditor tests that setting, identifies the data exposed and maps permission management to the customer’s administrators. The corrective action restricts access and adds configuration monitoring. Provider hardware assurance does not address the customer’s public access setting.

Watch the distinction: Moving data to a cloud service does not transfer every security duty. The relevant question is who controls the exposed setting and who can verify its state.

Reference: [1]

55. Control mobile and connected devices

Mobile and connected devices often enter a network through different enrollment and maintenance paths. An auditor builds a population from device management, network discovery and purchasing records, then checks ownership, supported software, update mechanisms and removal when devices retire. For mobile devices, evaluate screen protection, storage encryption, remote response and separation of organizational data from personal use where applicable. For Internet-of-Things devices, factory credentials, limited patching and unnecessary network reach are common exposure paths. Segment devices by purpose so that a compromised sensor cannot reach unrelated sensitive services. Wireless configuration should authenticate devices and restrict what they can access after connection. Test a representative device and its permitted routes rather than relying on an inventory label. Exceptions need an owner and a compensating control that addresses the specific exposure.

Worked example: A building sensor still uses its factory password and can reach the payroll server network. The auditor finds the sensor in a network scan but absent from the managed inventory. The device owner changes its credential, and the network team limits it to the building controller. The auditor verifies that the sensor still reports readings but can no longer connect to payroll services.

Watch the distinction: A small sensor can create a substantial access path. Its limited computing power does not prevent an attacker from using its network position or default credentials.

Reference: [1]

56. Measure security awareness behavior

Awareness training is a control intended to change how people recognize, report and handle risk. Completion rates show participation, not whether behavior improved. The auditor first identifies the organization’s relevant threats and roles, then checks whether training covers the decisions employees actually face, such as reporting suspicious messages or protecting customer data. Compare activity measures with outcome measures over consistent periods and populations. Phishing simulations can provide clues, but interpretation should consider campaign difficulty, repeat participants and whether people report messages promptly. Follow actual incidents to see whether staff used the reporting channel and received useful feedback. Where results deteriorate, examine content, timing and process barriers before prescribing more training. The CBAP study guide covers related work in defining measurable outcomes; here, the auditor applies that distinction to security behavior.

Worked example: All 800 employees complete annual training. In comparable quarterly exercises, reported suspicious messages fall from 240 to 120 while confirmed clicks rise from 20 to 36. Completion remains 100%, but reporting halves and clicks rise by 16, an 80% increase. The auditor investigates campaign comparability and reporting friction, then tests whether targeted coaching and easier reporting improve the next comparable results.

Watch the distinction: Equating attendance with awareness mistakes an activity measure for behavior. A completed course cannot show that staff will recognize and report a real threat.

Reference: [1]

57. Trace attack paths

An attack path links an entry method to a sequence of opportunities. Phishing may obtain credentials; credential misuse may open a remote service; exploitation or excessive privilege may allow deeper access; lateral movement may reach valuable data. The auditor maps controls at each stage, including phishing resistance, multifactor authentication, privilege limits, segmentation and monitoring. A blocked stage reduces that particular path but does not prove that every path is closed. Examine event records to distinguish an attempt from a successful action, and test whether defenders could see and investigate the sequence. Root cause analysis should separate the initial compromise from later control failures. For example, stolen credentials explain an attempted login, while absent alerts explain why repeated attempts went unnoticed. This reasoning supports specific findings instead of a vague statement that attackers might enter.

Worked example: An attacker obtains a worker’s password through a phishing page and tries it on a remote portal. Multifactor authentication denies the login, so the evidence supports attempted credential misuse, not a successful session. The auditor checks whether the denied attempt generated an alert and whether the worker’s account was protected afterward. The failed login shows that one control interrupted this observed path.

Watch the distinction: Treating a stolen password as proof of system access skips the authentication result. Trace each step and state exactly where the attack succeeded or stopped.

Reference: [1]

58. Interpret security tests

Security tests answer different questions. A vulnerability scan compares observed services and software with known patterns, efficiently finding candidates for investigation. A configuration review checks the actual settings and their alignment with the intended design. An authorized penetration test attempts to demonstrate how an exposure could be used within a defined scope and time. The auditor records each test’s assets, access level, date and limitations before interpreting results. A scan may produce false positives or miss a condition it cannot observe; a penetration test may confirm one route without covering every route. Combine evidence when possible: observed port, enabling rule and demonstrated connection form a stronger finding than a scanner label alone. Protect production operations by ensuring testing is approved and scoped. Report the demonstrated exposure and its business effect without claiming universal vulnerability.

Worked example: A scan identifies an administrative port on a production host. The auditor reviews the firewall configuration and confirms that an internet-facing rule allows the port. During an authorized test, the tester reaches a login prompt through that route. These three observations establish reachable administrative access. They do not show that login succeeded or that other hosts share the condition, so the finding stays within that scope.

Watch the distinction: A scanner severity label is not a complete audit conclusion. Validate the asset, route and business context, then state what the test actually demonstrated.

Reference: [1]

59. Turn security signals into investigation

Security monitoring turns raw events into decisions. First, relevant systems must produce records with usable identity, time and event details. Collection should preserve them long enough for investigation and guard against alteration. Correlation then links events, such as repeated failures followed by a success, to raise a signal. Triage checks context: account history, expected travel or remote access, source reputation and actions after login. The analyst classifies and escalates based on that evidence, documenting the reasoning and response. The auditor tests whether logs from critical sources arrive, clocks are consistent, rules fire on a known pattern, and alerts reach someone able to act. A flood of unreviewed alerts can be as ineffective as missing logs. An alert is a request to investigate; incident classification requires enough evidence to support the conclusion.

Worked example: A rule flags 20 failed logins followed by one success from an unusual location. The analyst checks the successful session’s device, authentication method and actions. If the session belongs to a verified traveler using a known device, the pattern may be benign; if it downloads sensitive files, escalation is warranted. The auditor reviews the records and triage notes to assess whether classification followed evidence.

Watch the distinction: Calling every alert a confirmed breach overstates the evidence. Correlation identifies a suspicious pattern, while investigation establishes what the account actually did and why.

Reference: [1]

60. Respond and preserve evidence

Incident response balances stopping harm, understanding scope and preserving evidence. A practical sequence identifies the event, contains affected systems, collects volatile and stored evidence as appropriate, removes the cause, restores service and reviews lessons learned. The order can adapt to urgency, but actions should be recorded so investigators can explain what changed and when. Chain of custody identifies each person who handled an item, each transfer and its purpose. A cryptographic hash helps verify that a copied image has not changed between collection and analysis; it does not prove that the original device was uncompromised. The auditor checks roles, escalation records, evidence handling, recovery validation and follow-up actions. Isolation may prevent further communication, while immediate reimaging can destroy evidence needed to understand entry and spread. Decisions should reflect business impact and investigation needs.

Worked example: A laptop is suspected of compromise and isolated from the network. Before reimaging, the response team creates a disk image, records the collector, time and transfer to an analyst, and calculates a hash. The analyst obtains the same hash on receipt, supporting that the transferred image is unchanged. The team then restores the laptop from a trusted build and checks for related activity elsewhere.

Watch the distinction: A matching hash verifies consistency between two copies or checks, not the truth of every file on the device. Preserve custody records and investigate the contents separately.

Reference: [1]

Official references and further reading

CISA® Exam Content Outline

All study guides

Information Systems Auditing Process

1. Standards, ethics and independence

2. Choose the right audit or review

3. Plan around risk

4. Classify controls by purpose

5. Build an executable audit program

6. Select and interpret samples

7. Judge evidence quality

8. Use analytics to find exceptions

9. Write findings that explain risk

10. Verify remediation and residual risk

11. Improve audit quality

Governance and Management of IT

12. Map external obligations

13. Clarify governance decision rights

14. Test strategy alignment

15. Follow the policy hierarchy

16. Read enterprise architecture as a risk map

17. Evaluate enterprise risk treatment

18. Assess privacy by data life cycle

19. Make data classification operational

20. Match IT resources to critical work

21. Control vendor and supply-chain risk

22. Interpret IT performance measures

Information Systems Acquisition, Development, and Implementation

23. Challenge the project business case

24. Audit the development method

25. Design controls into the system

26. Decide whether a system is ready

27. Control releases and configuration

28. Reconcile migration and conversion

29. Review outcomes after implementation

Information Systems Operations and Business Resilience

30. Trace infrastructure dependencies

31. Follow the asset life cycle

32. Control automated jobs

33. Reconcile system interfaces

34. Assess shadow IT and spreadsheets

35. Forecast service capacity

36. Find availability weak points

37. Separate incidents from problems

38. Coordinate change, configuration and patching

39. Make operational logs usable

40. Test service-level reporting

41. Audit database integrity

42. Use a business impact analysis

43. Prove backup and restoration

44. Keep business operations running

45. Test disaster recovery dependencies

Protection of Information Assets

46. Assess the security program

47. Protect facilities and equipment

48. Control identity and privilege

49. Segment and defend networks

50. Secure endpoints

51. Prevent unintended data release

52. Choose and manage encryption

53. Validate trust through PKI

54. Divide cloud control responsibility

55. Control mobile and connected devices

56. Measure security awareness behavior

57. Trace attack paths

58. Interpret security tests

59. Turn security signals into investigation

60. Respond and preserve evidence

Official references and further reading

Frequently Asked Questions

Related Study Guides

Certified Information Systems Security Professional (CISSP)

Certified Bank Auditor (CBA)

Certified Internal Auditor (CIA)