Free CISA Exam Flashcards

An approach that directs audit resources toward areas with the greatest business impact and likelihood of control failure. Scope, timing, and testing depth should follow assessed risk rather than auditor preference or system visibility.

A formal document that defines the audit function's purpose, authority, independence, and reporting line. It helps auditors obtain records and perform work without inappropriate management interference.

The specific question the audit is designed to answer, such as whether access controls restrict privileged activity. Clear objectives keep procedures aligned with assurance needs and prevent unfocused testing.

The boundaries of audit work, including systems, locations, processes, periods, and exclusions. Scope should be documented so stakeholders understand what assurance the audit does and does not provide.

The auditor must be free from conflicts that could impair judgment or appear to impair judgment. Independence is especially important when reviewing systems, controls, or processes the auditor helped design.

A questioning mindset that accepts neither management assertions nor system outputs without appropriate support. It requires corroborating claims with evidence while staying fair and objective.

The leadership and oversight structure that ensures technology supports business objectives, delivers value, and manages risk. Auditors evaluate whether decision rights, accountability, and measurement are clear.

The board or executive leadership sets direction, risk appetite, and accountability for major technology decisions. Day-to-day configuration and troubleshooting belong to management, not governance bodies.

The condition where IT priorities, investments, and services support business goals. Misalignment can cause technically successful projects to fail because they do not deliver needed business value.

A governance control that keeps policies current with business changes, technology, threats, and legal obligations. Stale policies may describe controls that no longer exist or omit risks that now matter.

A cross-functional group that helps prioritize technology initiatives, resolve resource conflicts, and keep projects aligned with business needs. Effective committees include business representation, not only IT staff.

Oversight of vendors through due diligence, contracts, service expectations, security requirements, and monitoring. The organization can outsource work, but it retains accountability for related risks.

The level of risk that exists before considering controls. Complex processes, high transaction value, sensitive data, or rapid change can raise inherent risk even before control design is reviewed.

The risk remaining after controls are designed and operating. Management may reduce, transfer, avoid, or accept residual risk, but acceptance should be informed and consistent with risk appetite.

The amount and type of risk leadership is willing to accept in pursuit of objectives. Controls and monitoring should be evaluated against this business-level tolerance, not against a zero-risk ideal.

A control designed to stop an unwanted event before it occurs. Examples include access approvals, input validation, segregation of duties, and configuration settings that block unauthorized actions.

A control designed to identify errors, exceptions, or unauthorized activity after they occur. Log reviews, reconciliations, exception reports, and monitoring alerts support timely investigation.

An alternate control that reduces risk when the preferred control is absent or impractical. Auditors should verify that the compensating control actually addresses the same risk and operates reliably.

Evidence is sufficient when there is enough support to justify the audit conclusion. Higher-risk findings usually require more corroboration than low-risk observations.

Evidence is appropriate when it is relevant, reliable, and directly tied to the audit objective. A system screenshot may show a setting, but logs or approvals may be needed to prove operation over time.

The complete set of items from which a sample is selected. If the population is incomplete or incorrectly defined, sample results may not support the intended conclusion.

The risk that a sample leads to a conclusion different from testing the full population. Auditors manage it through sample design, confidence expectations, and careful interpretation of exceptions.

Computer-assisted audit techniques use technology to analyze data, test controls, identify anomalies, or select samples. They improve coverage but still require auditor judgment about criteria and conclusions.

A record of events that allows activity to be traced from initiation through processing and approval. A reliable audit trail supports accountability, investigation, and reconstruction of transactions.

A documented condition that explains what was observed, the expected criterion, the cause, the risk or effect, and the recommended action. Strong findings are evidence-based and actionable.

The standard, policy, control objective, law, contract, or procedure used to judge the observed condition. Without criteria, a finding may read like preference instead of a defensible audit conclusion.

Management's documented agreement, disagreement, action plan, owner, and target timing for an audit issue. The response helps convert findings into accountable remediation work.

Procedures performed to verify whether agreed corrective actions were completed and effective. Closure should be based on evidence, not only on management's statement that remediation is finished.

The significance of an issue based on business impact, risk, compliance effect, or decision relevance. Materiality helps determine how prominently a matter should be reported.

A method for linking business requirements to design, build, testing, and acceptance evidence. It helps auditors determine whether the delivered system addresses approved needs.

The documented rationale for a technology investment, including expected benefits, costs, risks, and alternatives. Auditors review whether approval was based on business value rather than technical enthusiasm alone.

Testing by business users to confirm the system supports intended workflows and requirements. It is not a substitute for technical testing; it validates business readiness.

Controls that compare source and target data for completeness and accuracy after conversion. Record counts, control totals, exception review, and sign-off help prove migration integrity.

A review after go-live that evaluates whether objectives were met, benefits are being realized, controls are working, and lessons should inform future projects.

A group that reviews proposed changes for risk, readiness, timing, approvals, and business impact. Its value comes from disciplined review, not from rubber-stamping every request.

A change made quickly to restore service or address urgent risk. It should still be logged, authorized under emergency procedures, tested when practical, and reviewed after implementation.

Developers should not have uncontrolled ability to modify production systems. Separating duties reduces the risk of unauthorized code, untested changes, and concealed errors.

A control for tracking code, configuration, and document changes over time. It supports accountability, rollback, peer review, and evidence that approved versions reached production.

A documented commitment between a service provider and customer that defines expected service performance, responsibilities, reporting, and remedies. Auditors compare measured performance to agreed service targets.

The process for restoring normal service after disruption while recording impact, actions, and resolution. Good incident records support trend analysis and later problem management.

The process for identifying and addressing root causes of recurring or significant incidents. Its goal is to reduce future disruption rather than simply close individual tickets faster.

Planning and monitoring resources so systems can meet current and future demand. Auditors look for forecasts tied to business growth, thresholds, and timely scaling decisions.

Controls over automated processing that ensure jobs run completely, in the correct order, and with exception alerts. Failures should be detected by operations, not first discovered by users.

A process that identifies critical business functions, dependencies, disruption impacts, and recovery priorities. It provides the business basis for continuity and recovery requirements.

Recovery time objective is the target time to restore a service; recovery point objective is the acceptable amount of data loss measured by time. Both should be driven by business impact.

A control that proves backups can actually be restored and used. Successful backup jobs alone do not provide assurance if restoration procedures, media, permissions, or data integrity fail.

A planned test of roles, procedures, communication, and recovery capability. Exercises should produce lessons learned and updates to plans, contact lists, and dependencies.

Users, services, and administrators receive only the access needed for their duties. Access should be approved, periodically reviewed, and removed when duties change.

A scheme that labels information by sensitivity, value, and handling requirements. Classification helps determine access, encryption, retention, sharing, and disposal controls.

Sending logs to a protected location improves monitoring and preserves evidence if a source system is compromised. Access, retention, time synchronization, and alerting all affect log usefulness.