Use this guide to connect information systems audit principles with practical control decisions. The concepts move from audit foundations through governance, system development, operations and information protection, then apply those foundations to accounting systems. Each worked example resolves a specific problem. The accounting applications provide a financial-controls perspective for candidates using the CISA Examination (with accounting specialty) Free Practice Test.
Information Systems Auditing Process
1. Audit charter and engagement scope
An audit charter establishes the audit function's authority, responsibilities and reporting relationships. An engagement scope translates that mandate into the systems, processes, locations and period to be examined. Detailed procedures belong in the engagement plan. Adequate authority includes access to relevant evidence, while responsibility for operating controls remains with management.
Worked example: A payroll audit requires access to a hosted application's logs. The auditor uses the charter's access authority, then specifies the payroll period and relevant interfaces in the engagement scope.
Mistake to avoid: Treating the charter as a list of detailed tests or assigning control operation to auditors.
Source: CISA® Practice Quiz
2. Independence and objective judgment
Independence concerns relationships and responsibilities that can impair an audit; objectivity concerns impartial judgment. An auditor should identify actual or apparent conflicts and apply appropriate safeguards. Advising on control options does not automatically mean owning the control, but designing, approving and operating a process creates a significant self-review concern.
Worked example: An auditor previously managed an access migration. Another auditor evaluates that migration, while the former manager supplies factual background without deciding the audit conclusion.
Mistake to avoid: Assuming technical expertise eliminates a conflict arising from auditing one's own work.
Source: CISA® Certification | Certified Information Systems Auditor®
3. Risk-based audit planning
Risk-based planning prioritizes work according to threats to business objectives, their potential consequences and relevant controls. Consider financial exposure, operational dependence, sensitive information and recent change. Inherent risk describes exposure before controls; residual risk reflects exposure after controls. A priority assessment should be supported by evidence rather than technology novelty alone.
Worked example: A modest payment interface can release cash without independent authorization. It receives higher audit priority than a larger read-only reporting platform because the potential business loss is greater.
Mistake to avoid: Ranking systems solely by purchase price, transaction volume or technical complexity.
Source: CISA® Certification | Certified Information Systems Auditor®
4. Control design versus operating effectiveness
Design effectiveness asks whether a control could address the stated risk if performed properly. Operating effectiveness asks whether it actually worked consistently during the relevant period. A walkthrough helps establish understanding and implementation, but broader evidence is needed to support a conclusion about recurring operation. Both the control's timing and its precision matter.
Worked example: A policy requires independent approval of supplier changes. The design is appropriate, but sampled records show approvals occurred after payments, so operation did not prevent the identified risk.
Mistake to avoid: Concluding that a documented policy proves the control operated effectively.
Source: CISA® Certification | Certified Information Systems Auditor®
5. Evidence relevance, reliability and sufficiency
Relevant evidence addresses the audit objective; reliable evidence deserves confidence given its origin and handling. Sufficiency concerns the amount needed to support a conclusion. Direct observation, controlled system records and corroboration can strengthen evidence, but no source is automatically conclusive. Resolve contradictions and assess whether information was complete and protected from alteration.
Worked example: A manager says backups always succeed. The auditor examines job records and a documented restore result; the restore evidence supports recoverability more directly than the statement alone.
Mistake to avoid: Collecting many screenshots that do not establish the control's operation or evidence integrity.
Source: CISA® Certification | Certified Information Systems Auditor®
6. Tests of controls and substantive procedures
Tests of controls evaluate whether safeguards operated as intended. Substantive procedures directly examine transactions, balances or other outcomes for errors. The same audit may need both. Strong control evidence can support planned reliance, while weak controls may require more direct investigation of consequences. The procedure must answer the specific audit objective.
Worked example: For an automated fee calculation, inspecting approved rate changes tests a control. Independently recalculating selected customer charges tests the resulting amounts. Neither procedure fully substitutes for the other.
Mistake to avoid: Using an accurate transaction calculation as proof that all rate changes were authorized.
Source: CISA® Certification | Certified Information Systems Auditor®
7. Sampling and defensible population conclusions
A sample must match the objective, relevant period and defined population. Random selection can support statistical inference when the method and evaluation are appropriate. Judgmental selection can target unusual or risky items, but its results do not automatically estimate the population error rate. Evaluate exceptions by cause and significance, not merely by count.
Worked example: An auditor examines all exceptionally large refunds and finds two unauthorized items. This establishes specific exceptions, but does not establish the authorization failure rate among ordinary refunds.
Mistake to avoid: Projecting results from deliberately selected high-risk items as though they formed a random sample.
Source: CISA® Certification | Certified Information Systems Auditor®
8. Validating audit data before analysis
Data analysis is only as dependable as the extracted population. Validate source systems, date filters, record counts, key fields and relevant totals before interpreting results. Joins can omit unmatched records or multiply transactions. A query returning every requested row still may exclude transactions absent from the selected source or extraction conditions.
Worked example: Joining invoices to line items increases 2,000 invoice records to 7,500 rows. The auditor aggregates lines by invoice before testing duplicate payments, preventing ordinary line repetition from becoming false exceptions.
Mistake to avoid: Treating a technically successful query as evidence that its population is complete and correctly structured.
Source: CISA® Certification | Certified Information Systems Auditor®
9. Root cause before corrective recommendations
A control exception identifies an observed condition, not necessarily its cause. Determine how the failure arose, how widely it extends and what consequences followed before recommending a remedy. Distinguish process design, configuration, human execution and deliberate circumvention. A recommendation should address the cause while preserving the intended business function.
Worked example: Orders exceed an approval limit because the workflow checks each line separately. Training approvers would not fix that design; evaluating the total order value addresses the identified cause.
Mistake to avoid: Recommending retraining or a software change before establishing why the control failed.
Source: CISA® Practice Quiz
10. Findings, ownership and follow-up evidence
A useful finding connects the expected condition, observed condition, cause and business consequence. Recommendations should be practical, and management should identify accountable owners and intended actions. Follow-up determines whether the response actually reduces the risk. A completed task or closed ticket is weaker evidence than verified implementation and effective operation.
Worked example: Management closes a finding after enabling approval logging. Follow-up reveals approvals still occur after release, so the logging change improves evidence but does not resolve the authorization weakness.
Mistake to avoid: Closing findings solely because management reports that an action has been completed.
Source: CISA® Certification | Certified Information Systems Auditor®; CISA® Practice Quiz
Governance and Management of Information Technology
11. Connecting IT decisions to business objectives
IT governance directs technology toward business objectives while balancing value, risk and resources. Management executes the resulting plans and operates services. Audit evaluates whether these arrangements work. Assess a technology proposal through the business outcome it supports, rather than assuming that technical capability or modernization alone establishes value.
Worked example: A retailer proposes faster analytics. Its business objective is reducing unavailable stock, so the business case links analytics to replenishment decisions and stock availability rather than dashboard speed alone.
Mistake to avoid: Treating successful technology installation as evidence that the intended business objective was achieved.
Source: CISA® Certification | Certified Information Systems Auditor®
12. Decision rights and accountable ownership
Clear decision rights distinguish who approves priorities, owns risks, operates controls and receives assurance. Accountability should align with the authority and information needed to act. A committee can coordinate decisions, but vague collective responsibility makes unresolved risks harder to manage. Outsourcing execution does not eliminate the organization's responsibility for its business outcomes.
Worked example: IT maintains a reporting platform, but the finance owner approves reporting definitions. A disputed revenue measure therefore goes to finance for a business decision, with IT implementing the approved definition.
Mistake to avoid: Assigning all technology-related business decisions to the technical team.
Source: CISA® Certification | Certified Information Systems Auditor®
13. Risk appetite and residual risk acceptance
Risk appetite expresses the broad amount and type of risk an organization is willing to pursue or retain. More specific tolerances translate that direction into operating boundaries. After controls, residual risk should be evaluated and accepted by an appropriately authorized owner. Audit provides an independent assessment rather than deciding management's acceptable risk.
Worked example: A delivery company accepts brief reporting delays but very little disruption to dispatch. Management funds dispatch redundancy first because its consequences conflict more strongly with the organization's risk boundaries.
Mistake to avoid: Assuming security staff or auditors alone should set enterprise risk appetite.
Source: CISA® Practice Quiz
14. Policies, standards and controlled exceptions
A policy states management's direction; standards specify required conditions; procedures explain execution. Exceptions should identify the departure, associated risk, approving authority, compensating measures and review or expiry conditions. An exception can be a governed decision, but repeated renewals may indicate that the underlying requirement or architecture needs reconsideration.
Worked example: A legacy service cannot meet an access standard. Its approved exception requires restricted connectivity and periodic access review until replacement, making the remaining exposure explicit and reviewable.
Mistake to avoid: Allowing an informal exception to become a permanent undocumented alternative to the standard.
Source: CISA® Certification | Certified Information Systems Auditor®
15. Performance measures that reflect outcomes
A useful IT measure connects service performance to a business objective and has a clear definition, owner and dependable data source. Activity measures describe work performed; outcome measures describe what that work achieved. Combine measures when a single target could encourage undesirable behavior. Trend changes require investigation rather than automatic praise or blame.
Worked example: A help desk closes more tickets, but users repeatedly reopen them. Management examines durable resolution and user impact alongside closure counts, revealing that speed alone overstated service improvement.
Mistake to avoid: Using a convenient operational count as a complete measure of business value.
Source: CISA® Certification | Certified Information Systems Auditor®
16. Technology business cases and total cost
A business case compares credible benefits, costs, risks and alternatives. Include implementation, integration, support, migration and eventual exit costs where relevant. Benefits need assumptions and accountable owners. Simple payback illustrates recovery timing but omits later cash flows and the time value of money, so it cannot settle every investment decision.
Worked example: A system costs $90,000 initially and saves $30,000 annually after support costs. Simple payback is three years, assuming savings occur as forecast; management still evaluates risk and later benefits.
Mistake to avoid: Counting gross savings while omitting the recurring costs needed to produce them.
Source: CISA® Certification | Certified Information Systems Auditor®; CISA® Practice Quiz
17. Third-party due diligence and concentration risk
Due diligence evaluates whether a provider can meet the organization's operational, security and continuity needs. Assess financial resilience, relevant controls, subcontracting, dependencies and exit arrangements. Several contracts with different suppliers may still share a critical underlying provider. Assurance reports help only when their scope, period and exceptions address the service actually used.
Worked example: Two payroll service options rely on the same hosting platform. Selecting both does not diversify that platform dependency, so management evaluates a recovery or exit option beyond either supplier.
Mistake to avoid: Assuming different vendor names necessarily provide independent services or recovery capacity.
Source: CISA® Certification | Certified Information Systems Auditor®; CISA® Practice Quiz
18. Service agreements and usable exit protection
A service agreement should define measurable service expectations, responsibilities, reporting and remedies appropriate to business needs. Exit protection addresses continued access to data, documentation and essential capabilities. Source code escrow may help where release conditions, current deposits, dependencies and usable rights are established; possession of code alone does not guarantee operational continuity.
Worked example: A specialist application has escrowed source code but no build instructions or dependency packages. The auditor identifies a usability gap because the deposited materials do not yet support a practical recovery.
Mistake to avoid: Treating contractual penalties or an escrow label as proof that service can continue.
Source: CISA® Practice Quiz
19. Data ownership and accountable analytics
Data governance assigns responsibility for definitions, quality, permitted use and lifecycle decisions. Analytics and AI depend on these foundations: an impressive output can still reflect incomplete inputs or unsuitable assumptions. Business owners should define acceptable use and review consequential outputs. Technical teams maintain platforms, but cannot independently determine every business meaning or consequence.
Worked example: An automated collections model labels disputed invoices as unwillingness to pay. The receivables owner corrects the data definition and requires review before customer actions, reducing decisions based on misleading inputs.
Mistake to avoid: Assuming automated analysis is reliable because its calculations are reproducible.
Source: CISA® Certification | Certified Information Systems Auditor®
Information Systems Acquisition, Development & Implementation
20. Requirements and traceable acceptance criteria
Requirements should express business functions and relevant control, security, performance and recovery needs. Traceability connects each requirement to design decisions, tests and acceptance evidence. This makes omissions visible and supports informed approval. A requirement that cannot be evaluated objectively is difficult to verify, even when stakeholders agree with its wording.
Worked example: “Protect payment changes” becomes a requirement for independent approval before release. The acceptance test attempts an unapproved change and confirms that it cannot reach the payment stage.
Mistake to avoid: Accepting broad requirements such as “secure” or “reliable” without verifiable conditions.
Source: CISA® Certification | Certified Information Systems Auditor®
21. Critical paths and project dependencies
The critical path is the longest-duration dependency path and determines the earliest completion under the stated schedule assumptions. Shortening a noncritical activity may leave the project finish unchanged. When accelerating work, check dependencies, costs and whether another path becomes critical. Resource constraints can require additional analysis beyond the dependency network.
Worked example: Two parallel paths take nine and seven days. Reducing the seven-day path by two days does not change completion. Reducing the nine-day path to six days makes completion seven days.
Mistake to avoid: Paying to accelerate whichever individual task is longest without examining the project paths.
Source: CISA® Practice Quiz
22. Lifecycle controls and readiness gates
System development controls should fit the delivery approach while preserving authorization, evidence and accountability. A readiness gate assesses whether defined conditions have been met before a consequential transition. Iterative delivery can use frequent, focused gates rather than one final review. The objective is informed progression, not documents produced merely to satisfy a checklist.
Worked example: A monthly release requires completed tests, resolved critical defects and an approved recovery plan. One missing recovery prerequisite prevents deployment even though all planned features have been coded.
Mistake to avoid: Equating development progress with readiness to place a system into production.
Source: CISA® Certification | Certified Information Systems Auditor®
23. Separating development and production authority
Separating environments and incompatible duties reduces the opportunity for unauthorized changes. Developers need suitable development access, while production deployment should follow controlled approval and execution. Where staffing limits separation, independent review and reliable logging can reduce exposure, but their effectiveness must be assessed. A job title alone does not reveal actual system permissions.
Worked example: A developer prepares a release, a business owner approves it, and an independent service account deploys the approved package. The auditor verifies permissions and records rather than relying on role descriptions.
Mistake to avoid: Assuming separate teams provide segregation when their accounts retain the same production privileges.
Source: CISA® Certification | Certified Information Systems Auditor®
24. Testing levels and business acceptance
Unit testing examines individual components; integration testing examines their interactions; system testing evaluates the assembled solution. User acceptance assesses whether the solution meets agreed business needs. Security and performance testing address additional objectives. Passing one level does not establish another, especially where interfaces, realistic volumes or unusual business conditions are involved.
Worked example: Tax and invoice modules pass unit tests, but their integration applies tax twice. Integration testing exposes the defect before business users assess end-to-end invoicing against acceptance criteria.
Mistake to avoid: Using successful component tests as proof that complete business transactions are correct.
Source: CISA® Certification | Certified Information Systems Auditor®
25. Secure design and untrusted input
Secure development treats external input as untrusted and enforces authorization at the point where a protected action occurs. Input validation checks permitted form and business meaning; parameterized database access separates data from executable commands. These controls serve different purposes. Server-side enforcement remains necessary when a client interface can be bypassed.
Worked example: An order screen rejects negative quantities, but the backend also validates submitted quantities and the user's authority. Direct requests therefore cannot bypass the business rule merely by avoiding the screen.
Mistake to avoid: Relying exclusively on browser validation or assuming input validation replaces authorization.
Source: CISA® Certification | Certified Information Systems Auditor®
26. Normal and emergency change control
Change control connects a proposed modification to authorization, impact analysis, testing, deployment and verification. Emergency changes may follow an expedited path, but should remain identifiable and receive appropriate retrospective review. Distinguish urgency from permission to bypass accountability. Reliable records should show what changed, why it changed and how the resulting service was evaluated.
Worked example: An urgent integration repair receives expedited approval and documented deployment. Subsequent review confirms the fix, examines broader effects and resolves the temporary access granted for the work.
Mistake to avoid: Treating every urgent request as exempt from authorization, evidence and follow-up.
Source: CISA® Certification | Certified Information Systems Auditor®
27. Data conversion and exception reconciliation
Conversion assurance checks whether data moved completely and accurately while preserving its business meaning. Reconcile record counts, relevant financial totals, key relationships and rejected records. Agreement of one total is insufficient: omissions and duplicates can offset each other. Transformation rules and exceptions should be understood, tested and approved by responsible data owners.
Worked example: A migration preserves a $450,000 receivables total, but assigns $12,000 to the wrong customer. Customer-level reconciliation detects the error that the overall financial total could not reveal.
Mistake to avoid: Approving conversion solely because the old and new grand totals match.
Source: CISA® Certification | Certified Information Systems Auditor®
28. Implementation choices and rollback feasibility
Direct, phased, pilot and parallel implementation approaches distribute transition risk differently. Choose according to business impact, dependencies and the ability to reconcile activity. A rollback plan must consider data created after cutover, not just restoring software. Parallel operation can provide comparison, but inconsistent processing between systems can also create reconciliation problems.
Worked example: A new billing service runs for one branch first. Its rollback plan preserves newly issued invoices and reconciles them before returning processing to the old system, avoiding lost or duplicated billing.
Mistake to avoid: Assuming restoring an old application automatically restores a consistent business state.
Source: CISA® Certification | Certified Information Systems Auditor®
29. Post-implementation review and realized benefits
A post-implementation review evaluates whether the delivered system meets objectives, operates with suitable controls and produces expected benefits. Compare actual outcomes with the business case and investigate deviations. Distinguish a defective solution from adoption problems or unrealistic original assumptions. Recommendations should reflect observed causes rather than assuming every variance proves project mismanagement.
Worked example: An automation project reduces processing time but not staffing costs because work shifted to exception handling. The review identifies additional workflow redesign before claiming the forecast cost savings.
Mistake to avoid: Declaring benefits achieved at launch or blaming overruns without examining their causes.
Source: CISA® Certification | Certified Information Systems Auditor®; CISA® Practice Quiz
Information Systems Operations and Business Resilience
30. Capacity, utilization and service bottlenecks
Capacity management anticipates whether resources can meet service needs under expected demand and peaks. Average utilization can conceal short periods of saturation. Diagnose the constrained component using service measurements rather than assuming that more hardware solves every slowdown. Dependencies, queueing and workload changes can affect response time even when some resources remain underused.
Worked example: Application servers use little processing capacity, but a storage queue grows during payroll runs. Increasing application servers would not address the observed storage bottleneck; storage performance needs investigation.
Mistake to avoid: Inferring adequate service capacity from a low average utilization figure.
Source: CISA® Certification | Certified Information Systems Auditor®
31. Incident restoration and problem management
Incident management seeks to restore an interrupted service. Problem management investigates underlying causes and prevents recurrence. A workaround can resolve an immediate incident while leaving the problem open. Track recurring patterns and distinguish symptoms from causes. The business impact and urgency of an interruption guide response priorities rather than technical inconvenience alone.
Worked example: Restarting an overnight reporting service restores availability, but the failure returns weekly. Problem investigation identifies an accumulating resource leak, leading to a durable correction rather than repeated restarts.
Mistake to avoid: Closing the underlying problem merely because a temporary workaround restored service.
Source: CISA® Certification | Certified Information Systems Auditor®
32. Asset inventories and configuration baselines
An asset inventory identifies what exists and who is responsible for it. Configuration information records relevant settings and relationships. A baseline defines an approved reference state against which changes can be evaluated. These records support maintenance, vulnerability assessment and recovery, but must be reconciled with actual environments to remain dependable.
Worked example: A discovered server is absent from the inventory and has no owner. Assigning ownership and comparing its configuration with the approved baseline reveals unsupported software requiring a managed response.
Mistake to avoid: Treating an inventory as accurate indefinitely without checking it against deployed assets.
Source: CISA® Certification | Certified Information Systems Auditor®
33. Batch scheduling and dependent job completion
Batch operations require controls over scheduling, dependencies, errors and completion. A successful individual job does not prove that the full business process completed correctly. Monitor rejected records, missing inputs and downstream delivery. Restart procedures should establish whether a job can safely repeat or whether partially processed transactions need reconciliation first.
Worked example: An invoice export succeeds, but the preceding customer update fails. Operations pauses the dependent import and resolves the missing update instead of treating the export's success message as end-to-end completion.
Mistake to avoid: Restarting partially completed jobs without checking whether transactions would be duplicated.
Source: CISA® Certification | Certified Information Systems Auditor®
34. Backup completion versus recoverability
A backup records a recoverable copy; a restore demonstrates whether the copy can be used. Evaluate coverage, integrity, access protection and relevant dependencies. Backup success messages do not establish that an application can operate from restored data. Recovery tests should verify a consistent, usable state and document exceptions for correction.
Worked example: A database restores successfully, but the application cannot start because its encryption key was not recoverable. The backup process therefore did not preserve everything required for usable recovery.
Mistake to avoid: Equating successful backup jobs with tested application recovery.
Source: CISA® Certification | Certified Information Systems Auditor®
35. Business impact analysis and recovery priorities
A business impact analysis identifies how disruption affects activities over time and what resources they depend on. It supports recovery priorities and objectives based on consequences, including financial, operational and safety impacts. Map dependencies such as people, facilities, data and suppliers. System size or departmental influence should not determine recovery order by itself.
Worked example: Dispatch supports time-sensitive deliveries, while historical reporting can wait. The analysis prioritizes dispatch and its identity service because recovering dispatch without authentication would not restore the business activity.
Mistake to avoid: Ranking recovery systems without identifying the business activities and dependencies they support.
Source: CISA® Certification | Certified Information Systems Auditor®
36. Recovery time and recovery point objectives
The recovery time objective addresses the targeted time to restore a service after disruption. The recovery point objective addresses the acceptable data loss expressed as a time interval. They answer different questions and require suitable supporting capabilities. Objectives should follow business needs; observed recovery results determine whether the implemented arrangements can meet them.
Worked example: A service must resume within four hours and lose no more than thirty minutes of data. A two-hour restore using yesterday's backup meets the time target but fails the data-loss target.
Mistake to avoid: Assuming a fast restore also establishes acceptable data recovery.
Source: CISA® Certification | Certified Information Systems Auditor®
37. Recovery strategy and correlated failures
A recovery strategy must address the failure conditions it is intended to survive. Redundancy within one location can help with component failure but may leave shared power, network or site risks. Evaluate geographic and technical dependencies without assuming that distance alone proves independence. Recovery also requires people, access, data and workable procedures.
Worked example: Two servers share one storage array. They tolerate a server failure but remain exposed to array failure, so management evaluates storage resilience or a separate recoverable copy.
Mistake to avoid: Calling a service resilient merely because it has duplicate servers.
Source: CISA® Certification | Certified Information Systems Auditor®
38. Continuity exercises and demonstrated capability
A discussion exercise evaluates understanding and decision paths; a technical recovery exercise demonstrates selected operational capabilities. Neither automatically proves every scenario. Define objectives, realistic conditions and evidence before the exercise, then address identified gaps. Include business validation because a running system can still contain unusable data or fail to support required work.
Worked example: A recovery test starts the order application on time, but users cannot retrieve active orders. Business validation records a failed objective even though infrastructure restoration succeeded.
Mistake to avoid: Declaring continuity readiness from a discussion exercise or successful server startup alone.
Source: CISA® Certification | Certified Information Systems Auditor®
39. Network continuity and independent routes
Alternative routing can preserve connectivity when a link or device fails, provided routes and supporting services are appropriately independent. Verify physical paths, provider dependencies, capacity and failover behavior. Two connections may share a conduit or upstream service. Data backups address a different risk and cannot directly replace an unavailable network path.
Worked example: Two office connections enter through the same cable duct. A route review identifies the shared failure point, so the organization evaluates a path using a different entry and supporting infrastructure.
Mistake to avoid: Assuming separate connection contracts establish independent network paths.
Source: CISA® Practice Quiz
40. Physical safeguards and life safety
Physical controls protect people, equipment and continued operations against unauthorized entry and environmental hazards. Assess access, power, cooling, detection and maintenance in their business context. Life safety takes priority over asset protection. Security arrangements should permit safe evacuation, and auditors should refer hazardous conditions to responsible personnel rather than attempt technical remedies themselves.
Worked example: A proposed access redesign restricts entry to authorized staff. Review also checks that emergency evacuation remains safe and does not depend on normal authentication, preserving the life-safety requirement.
Mistake to avoid: Evaluating physical security only as prevention of theft or unauthorized entry.
Source: CISA® Practice Quiz
Protection of Information Assets
41. Confidentiality, integrity and availability
Confidentiality limits inappropriate disclosure; integrity protects information and processing from improper alteration; availability supports timely authorized use. The same incident can affect several objectives, but controls should address the specific exposure. A readable, accessible report can still be unreliable if its data were altered. Security decisions should follow business consequences across all three objectives.
Worked example: A sales report remains accessible but contains altered prices. The primary observed failure concerns integrity, so the investigation focuses on modification authority and evidence rather than merely restoring access.
Mistake to avoid: Treating every security problem as disclosure or assuming availability proves trustworthy information.
Source: CISA® Certification | Certified Information Systems Auditor®
42. Classification and proportionate handling
Classification connects information sensitivity and business impact to handling requirements. Owners need to understand the organization's classification scheme before selecting a category. Labels should drive practical controls over access, sharing, storage and disposal. Automated classification can assist, but ambiguous business context may require owner judgment and periodic reassessment.
Worked example: An anonymized summary can be shared broadly, while its underlying named customer records require restricted handling. The owner classifies each according to content and impact rather than the shared spreadsheet format.
Mistake to avoid: Choosing a classification solely from file type or the protection already applied.
Source: CISA® Practice Quiz
43. Least privilege and incompatible duties
Least privilege limits access to what an authorized task requires. Segregation of duties prevents one person from controlling incompatible stages of a sensitive process. These principles overlap but are distinct: individually necessary permissions can become risky in combination. Evaluate effective access across applications and groups, including inherited permissions and alternative processing paths.
Worked example: A clerk needs supplier maintenance access, but also inherits payment-release rights through another group. Removing the incompatible release permission addresses the combined exposure without preventing supplier maintenance.
Mistake to avoid: Reviewing each role independently while ignoring the user's combined capabilities.
Source: CISA® Certification | Certified Information Systems Auditor®
44. Authentication versus authorization
Authentication establishes a claimed identity; authorization determines what that identity may do. Strong authentication does not correct excessive permissions. Multiple authentication factors should represent different factor types, rather than several secrets of the same type. Evaluate session handling and account recovery as well, because they can undermine otherwise strong authentication.
Worked example: A user signs in with a password and a separate possession factor but can approve their own expense claims. Authentication is strengthened, while the authorization and segregation weakness remains.
Mistake to avoid: Treating multifactor authentication as proof that a user's permissions are appropriate.
Source: CISA® Certification | Certified Information Systems Auditor®
45. Access lifecycle and periodic review
Access should reflect approved responsibilities throughout hiring, transfer and departure. Transfers are especially important because old permissions may accumulate. Periodic review supplements event-driven changes and should involve owners who understand the business need. Include service accounts and external users where relevant. A recorded approval is meaningful only if the reviewer evaluates effective access.
Worked example: A buyer moves to financial reporting but retains purchase approval rights. The transfer review removes the former role, preventing unnecessary authority from persisting until the next scheduled review.
Mistake to avoid: Focusing only on new starters and leavers while ignoring role changes.
Source: CISA® Certification | Certified Information Systems Auditor®
46. Privileged access and protected activity records
Privileged accounts can change systems, security settings and sometimes audit evidence. Restrict their use, assign accountability and protect relevant activity records from the same authority being monitored. Temporary privileged access should have a defined purpose and ending condition. Logging supports detection only when events are captured, retained and reviewed appropriately.
Worked example: An administrator can modify production data but cannot erase the separately protected activity records. A review detects an unexplained adjustment even after the visible data are restored.
Mistake to avoid: Relying on current-state comparisons alone to detect temporary unauthorized changes.
Source: CISA® Certification | Certified Information Systems Auditor®; CISA® Practice Quiz
47. Encryption and key lifecycle dependencies
Encryption protects confidentiality when appropriate algorithms and key management are used. It does not independently establish authorization, data accuracy or availability. Keys require controlled generation, access, replacement and recovery arrangements suited to the system. Protecting data while losing the only usable decryption key can turn a confidentiality safeguard into an availability failure.
Worked example: Archived records are encrypted, but the retired system held their only key. A retrieval test fails, demonstrating that the archive plan needs recoverable key access as well as stored files.
Mistake to avoid: Assuming encrypted storage is sufficient without evaluating key protection and recoverability.
Source: CISA® Certification | Certified Information Systems Auditor®
48. Hashes, signatures and trustworthy reference values
A cryptographic hash summarizes data so that changes can be detected against a trusted reference. It does not encrypt the data or identify the author. A digital signature can support integrity and signer authentication when verification keys and identity bindings are trustworthy. These controls depend on protecting the reference information and verification process.
Worked example: A downloaded package matches a hash published through a trusted separate channel. This supports package integrity; a hash copied from the same compromised download page would provide weaker assurance.
Mistake to avoid: Treating any matching hash as proof of authenticity or confidentiality.
Source: CISA® Certification | Certified Information Systems Auditor®
49. Network segmentation and limited trust
Segmentation restricts communication between systems according to business need, limiting exposure and movement after compromise. Evaluate actual permitted flows, management access and exceptions rather than network labels alone. A segmented design is ineffective if broad rules reconnect the zones. Identity, endpoint and application controls remain necessary within permitted paths.
Worked example: Guest devices cannot connect to payroll services, while a defined business application can use one required interface. Reviewing the rule set confirms the limited flow instead of assuming separate network names provide isolation.
Mistake to avoid: Believing segmentation removes the need to control access within each segment.
Source: CISA® Certification | Certified Information Systems Auditor®
50. Vulnerability prioritization and remediation evidence
Vulnerability management identifies weaknesses, evaluates business exposure and verifies corrective action. Technical severity is one input alongside reachability, exploitability, asset importance and existing safeguards. A patch deployment report does not always prove the weakness is resolved. Where remediation is delayed, document accountable risk decisions and evaluate the effectiveness of compensating controls.
Worked example: An exposed payment service receives urgent attention ahead of an isolated test system with a similar weakness. Verification checks the corrected service rather than relying solely on a successful deployment status.
Mistake to avoid: Prioritizing every weakness by technical score alone or assuming installation proves remediation.
Source: CISA® Certification | Certified Information Systems Auditor®
51. Security monitoring and event correlation
Monitoring turns selected events into information about suspicious activity. Useful records need relevant detail, consistent timestamps, appropriate retention and protection. Correlation across identity, application and infrastructure events can reveal a sequence that individual records miss. Alerts require investigation and tuning; a large volume of unreviewed events does not establish effective detection.
Worked example: A sign-in event and a bank-detail change appear unrelated until their timestamps and account identifiers are correlated. The sequence supports investigation of possible account misuse.
Mistake to avoid: Equating log collection with effective monitoring or ignoring clock differences between systems.
Source: CISA® Certification | Certified Information Systems Auditor®; CISA® Practice Quiz
52. Incident containment and evidence preservation
Security response balances limiting harm, maintaining essential operations and preserving evidence. Responsibilities and escalation paths should be clear before an incident. Record important actions and protect evidence integrity so later analysis can distinguish the attack from the response. Containment does not establish eradication, and service restoration does not establish that the underlying weakness is resolved.
Worked example: A compromised account is disabled while responders preserve relevant records and investigate affected transactions. Re-enabling access waits for an authorized assessment of the cause and remaining exposure.
Mistake to avoid: Deleting suspicious records or declaring resolution immediately after the visible symptom disappears.
Source: CISA® Certification | Certified Information Systems Auditor®
Accounting Information Systems and Financial Controls
53. Assertions and the direction of transaction testing
Accounting-system audit work should distinguish whether recorded transactions occurred from whether all relevant transactions were recorded. Vouching recorded entries to supporting evidence addresses occurrence; tracing source events into records addresses completeness. The direction matters because records cannot reveal every item missing from themselves. The appropriate procedure follows the stated risk.
Worked example: To test missing sales, an auditor traces completed dispatch records into invoices. Starting with existing invoices would mainly examine recorded sales and could miss dispatches never billed.
Mistake to avoid: Using the same starting population and direction for both occurrence and completeness.
Source: CISA® Certification | Certified Information Systems Auditor®
54. Double-entry balance and substantive accuracy
Double-entry accounting records equal total debits and credits, supporting internal arithmetic consistency. A balanced entry can still use the wrong accounts, period, customer or amount. System controls should distinguish balancing validation from transaction authorization and correct classification. The accounting equation likewise does not prove that every asset, liability or transaction is genuine.
Worked example: Equipment costing $8,000 is recorded as a debit to office expense and a credit to cash. The entry balances, but its classification is wrong under the stated assumption that capitalization is appropriate.
Mistake to avoid: Treating a balanced ledger as proof that transactions are valid and correctly classified.
Source: CISA® Certification | Certified Information Systems Auditor®
55. Batch totals and offsetting interface errors
Accounting interfaces can use record counts, monetary totals and other control totals to detect processing differences. Each total addresses particular error types. Matching monetary totals cannot exclude offsetting omissions and duplicates, so reconcile identifiers and exceptions as well. Totals should come from a dependable source independently of the processing stage being checked.
Worked example: A $240 invoice is omitted and another $240 invoice is duplicated. The monetary total remains unchanged, but matching invoice identifiers reveals both errors.
Mistake to avoid: Concluding that an interface is complete and accurate because one financial total agrees.
Source: CISA® Certification | Certified Information Systems Auditor®
56. Supplier master data and payment destination changes
Supplier master data determines where and to whom payments are directed. Changes to sensitive fields require authorization, independent validation and a traceable record appropriate to the risk. Separate master-data changes from payment release where feasible. Contact details in the change request itself should not be the sole basis for confirming its authenticity.
Worked example: A request changes a supplier's bank account. The responsible team verifies it through an established independent contact route and obtains required approval before the new destination is used.
Mistake to avoid: Authenticating a change by calling only the new contact number provided in the request.
Source: CISA® Certification | Certified Information Systems Auditor®
57. Purchase matching and controlled exceptions
Matching a purchase order, receipt and invoice helps establish that billed goods were authorized, received and priced as expected. It does not prove every purchase was necessary or eliminate collusion. Differences require defined investigation and approval. Services, partial deliveries and other circumstances may need different evidence rather than automatic rejection or unrestricted override.
Worked example: An order authorizes 80 units at $15 each, but only 72 arrive. An invoice for $1,200 exceeds the $1,080 supported by that receipt and requires resolution before payment.
Mistake to avoid: Approving an invoice solely because it matches the order while ignoring receipt evidence.
Source: CISA® Certification | Certified Information Systems Auditor®
58. Revenue interfaces and duplicate processing
Revenue interfaces should support complete processing without recording the same business event twice. Stable transaction identifiers and controlled replay behavior help distinguish a retry from a new event. Technical delivery success is different from successful accounting posting. Reconcile source events, posted transactions and rejected items, with clear ownership of unresolved exceptions.
Worked example: A $650 sale is resent after a timeout. The receiving interface recognizes the original transaction identifier and confirms its existing posting instead of creating a second sale.
Mistake to avoid: Assuming every retransmitted message represents a new accounting transaction.
Source: CISA® Certification | Certified Information Systems Auditor®
59. Period close, cutoff and controlled reopening
Cutoff assigns transactions to the appropriate accounting period according to their economic circumstances and applicable reporting rules. A period lock prevents ordinary changes after close but does not establish correct initial cutoff. Authorized reopening should preserve approval and change evidence. Distinguish transaction dates, processing dates and accounting dates when investigating differences.
Worked example: Goods are received on the final day of a period, but the invoice arrives later. Review considers the receipt and applicable accounting policy rather than assigning the transaction solely by invoice-entry date.
Mistake to avoid: Treating a closed period as proof that all transactions were recorded in the correct period.
Source: CISA® Certification | Certified Information Systems Auditor®
60. Spreadsheet controls in financial reporting
A financial spreadsheet can become a critical system when it drives journals or reports. Evaluate source completeness, formulas, access, version control and independent review according to its importance. Protected cells reduce accidental editing but do not prove formula correctness. Review should cover changed logic and output reasonableness, including hidden rows and excluded ranges.
Worked example: A reconciliation totals rows 2 through 100, but new transactions occupy rows 101 through 110. Independent range review identifies the omission before the spreadsheet supports a journal.
Mistake to avoid: Assuming a familiar template remains reliable after data volumes or formulas change.
Source: CISA® Certification | Certified Information Systems Auditor®
Sources
Credential identity and scope:
All study guides