CISA sample questions — 25 answered and explained

An auditor who designed or implemented a control has a self-review threat to objectivity when auditing it.

Objectivity is impaired, in fact or appearance, when an auditor evaluates their own earlier work. The first step is to disclose the impairment to audit management, who can reassign the work or apply safeguards. Choosing a safeguard yourself, relying on familiarity or asking the auditee to waive the conflict all skip the disclosure that the decision depends on.

1. Identify the threat: the auditor would review their own design.
2. Recall that impairments must be disclosed to the appropriate party.
3. Leave the choice of safeguard to audit management.
4. Disclose before starting fieldwork.

Exam tip: Disclose any impairment to audit management before the work begins.

Organizational independence comes from a functional reporting line to the audit committee.

The audit committee oversees the audit function's plan, scope and results; the administrative line covers day-to-day matters such as budget and HR. Pairing a functional line to the committee with an administrative line to a senior executive outside the audited areas, typically the CEO, gives the most independence. The reversed arrangement hands control of findings to management, and reporting to the CIO or to risk management puts audit under areas it reviews.

1. Separate functional reporting (scope, findings) from administrative reporting.
2. Place the functional line with the audit committee.
3. Keep both lines away from areas audit reviews.
4. Choose the committee functionally and the CEO administratively.

Exam tip: Report functionally to the audit committee, administratively to a senior executive outside audited areas.

An IS auditor can advise on controls during implementation but must not take on management's responsibility for building them.

Pre-implementation reviews are where auditors add value by recommending controls early. Independence is kept as long as management makes and implements the decisions. Setting up the rules is an operational task that would place the auditor inside the control environment; disclosure or later reassignment softens but does not remove that conflict. Refusing to comment at all throws away the purpose of the review.

1. Separate advising on controls from implementing them.
2. Recall that implementing controls impairs objectivity.
3. Check whether a safeguard removes the impairment or only discloses it.
4. Recommend the rules and leave configuration to management.

Exam tip: Auditors recommend controls; management implements them.

An integrated audit combines financial and operational audit steps to assess controls over a process and its systems.

CISA audit types are defined by purpose. When financial and operational auditing are combined, so that controls over a business process and its supporting systems are assessed together, the engagement is an integrated audit. Compliance audits test conformance to requirements, forensic audits support investigations, and administrative audits examine operational efficiency.

1. Identify the defining feature: financial and operational steps combined.
2. Match each audit type to its purpose.
3. Rule out compliance, forensic and administrative purposes.
4. Choose integrated audit.

Exam tip: Combining financial and operational audit steps is an integrated audit.

A forensic audit discovers, documents and preserves evidence of fraud or crime so it can support legal or disciplinary action.

The deciding facts are suspected wrongdoing and possible legal action. Evidence must then be collected with a chain of custody and methods that keep it admissible, which is what a forensic audit does. Compliance, operational and integrated audits evaluate controls and conformance; they may reveal weaknesses, but they are not designed to build a legal case.

1. Note the trigger: suspected fraud and possible legal action.
2. Ask which audit type is built to preserve evidence for proceedings.
3. Set aside control-evaluation audit types.
4. Choose the forensic audit.

Exam tip: Suspected fraud headed for court needs a forensic audit.

Development and production migration are incompatible duties; combined, one person can deploy unauthorized code undetected.

Segregation of duties separates tasks so that no single person can both make and conceal an error or an unauthorized change. A programmer who can also promote code into production can write, approve in effect, and deploy changes alone, bypassing change control. The other combinations are routine pairings within a single function and do not give one person end-to-end control over a sensitive process.

1. Ask whether one person could both make and hide an unauthorized change.
2. Recognise development plus production access as the classic incompatible pair.
3. Treat the other pairs as routine tasks within one role.
4. Choose the programmer with production migration rights.

Exam tip: Never let the person who writes code also move it into production.

When incompatible duties cannot be segregated, use compensating controls such as independent review of activity.

Combining database administration with security administration lets one person grant themselves access and act on data without anyone noticing. Small organizations often cannot split the roles, so the accepted answer is a compensating control: someone independent, such as a manager, reviews the administrator's logged activity. Rotation needs another person, self-review is not independent, and outsourcing violates the no-budget constraint.

1. Accept that the duties cannot be separated under the constraints given.
2. Look for a compensating control that an independent person performs.
3. Rule out options needing staff or budget the scenario says are unavailable.
4. Choose independent log review.

Exam tip: If you cannot separate duties, add independent review as a compensating control.

Bias from an IT reporting line is fixed by enterprise-wide, business-represented prioritization rather than by moving the bias or splitting budgets mechanically.

When IT reports into one function, that function's projects tend to win. Several remedies sound plausible: changing the reporting line, equal budgets or consultation. Moving the CIO only relocates the bias; equal shares ignore value; consultation leaves the final call with the conflicted CFO. A steering committee on which every business unit sits, deciding priorities against enterprise objectives, addresses the conflict at its source.

1. Identify the conflict: one function controls IT priorities.
2. Test each option on whether it removes the bias or merely moves it.
3. Reject mechanical budget splits that ignore business value.
4. Choose enterprise-wide prioritization by a representative committee.

Exam tip: Fix reporting-line bias with business-wide prioritization, not by moving the reporting line.

Policy states intent; standards set mandatory specifics; procedures give steps; guidelines advise.

The document sets precise, mandatory values (a minimum length and a required change condition). That is what a standard does: it turns a policy's intent, such as protecting accounts, into specific requirements everyone must meet. A policy is broader and changes rarely; a procedure tells someone how to carry out a task step by step; a guideline is advisory.

1. Note that the document sets specific, mandatory values.
2. Recall the role of each document type in the hierarchy.
3. Match mandatory specifics to a standard.
4. Rule out the advisory guideline and the step-by-step procedure.

Exam tip: Specific mandatory values belong in standards, not in policies.

Policies state high-level intent; technical specifics belong in standards and procedures beneath them.

A policy full of product names and port numbers goes out of date quickly and needs senior approval for each technical change, so it is either ignored or stale. The right structure keeps the policy short and stable and puts the technical requirements in standards (what must be configured) and procedures (how to do it), which IT can maintain more often. Monthly reviews, team approval or downgrading to a guideline each damage the policy's authority or its control value.

1. Spot the problem: technical detail at the policy level.
2. Recall what each layer of the document hierarchy should hold.
3. Recommend restructuring rather than more frequent review.
4. Reject options that weaken approval or make requirements optional.

Exam tip: Keep policies high-level; put technical specifics in standards and procedures.

Critical path analysis: delays on the critical path move the completion date; delays within a task's float do not.

The critical path is the longest chain of dependent tasks and has zero float, so a two-week slip on it pushes the completion date out by two weeks. The other task had three weeks of total float; slipping two weeks uses up two of them and leaves one, so it does not affect the end date and does not become critical. The auditor should therefore expect a two-week delay unless the critical task is recovered, for example by adding resources.

1. Recall that critical-path tasks have no float.
2. Apply the critical slip directly to the end date.
3. Subtract the second slip from its float to see that one week remains.
4. Combine both results into a single conclusion.

Exam tip: A critical-path slip moves the end date; a slip within float only uses up float.

A feasibility study looks at technical, economic, operational and schedule feasibility.

Feasibility analysis tests a proposal from several angles. Technical feasibility checks that the system can be built and run with the organization's infrastructure, tools and skills, or ones it can obtain. Economic feasibility weighs costs against benefits, operational feasibility checks that people and processes will adopt it, and schedule feasibility checks the timeframe.

1. List the feasibility dimensions.
2. Match infrastructure, tools and skills to one of them.
3. Rule out the cost, adoption and time dimensions.
4. Choose technical feasibility.

Exam tip: Technical feasibility: can we build and run it? Economic: is it worth it? Operational: will people use it?

Operational feasibility assesses whether the organization's people and processes will accept and use a proposed system.

The study covered economic feasibility (costs and benefits) and technical feasibility (platform), but not operational feasibility: whether users, their skills and current processes fit the new system. The risk left open is a system that works technically and is affordable, yet is resisted or worked around by the business, so the expected benefits never arrive. Capacity and cost risks were analysed, and vendor timing is a different concern.

1. Map each analysed area to a feasibility dimension.
2. Identify the dimension that was skipped.
3. State the risk that the skipped dimension normally addresses.
4. Reject risks already covered by the study.

Exam tip: A system can be affordable and technically sound and still fail if the business will not adopt it.

The direction of a test determines what it proves: floor-to-register for completeness, register-to-floor for existence.

Completeness asks whether everything that exists is recorded, so the test must start from the population of real devices, gathered by physical observation and network discovery, and look for each in the register. Testing from the register to the floor proves recorded items exist but cannot find omissions. Reconciling to the finance ledger compares two records that can share gaps (and uncapitalised devices are not in the ledger), and owner confirmations cover only listed entries.

1. Define the assertion: completeness, nothing missing.
2. Start the test from the real population, not the record.
3. Reject tests that begin from the register or another record.
4. Choose tracing discovered devices to the register.

Exam tip: To prove completeness, start from what exists and look for it in the record.

License compliance is tested by comparing actual installations with entitlements.

Compliance means installed and used copies do not exceed what the organization is entitled to. The best evidence therefore combines both sides: an inventory of installations from a discovery or metering tool and the record of purchased entitlements. Policies, purchase orders and contract clauses each provide only one side, or only intent.

1. Define compliance as usage within entitlement.
2. Look for evidence covering both usage and entitlement.
3. Reject items that show only intent or only purchases.
4. Choose discovered installations compared with entitlements.

Exam tip: License compliance = what is installed versus what was bought; one side alone proves nothing.

Preventing unlicensed software means removing the ability to self-install and controlling distribution centrally.

The root cause is that users can install software freely. Withdrawing their installation rights and distributing software only through a central tool that tracks license counts prevents recurrence. Buying licenses fixes the current gap (it is corrective), periodic scans only detect after the fact, and policy reminders rely on behaviour.

1. Identify the root cause: users can install software themselves.
2. Ask which option removes that ability.
3. Classify the others as corrective, detective or directive.
4. Choose withdrawing installation rights with central distribution.

Exam tip: Stop recurrence at the cause: no self-installation, central license-tracked distribution.

Assurance over disposal comes from device-level evidence reconciled to the organization's own records.

The question is whether these specific drives were destroyed. Sanitization certificates that list each serial number, reconciled against the organization's disposal records, prove both that wiping occurred and that every device sent is accounted for. A certification, a contract clause and a management letter are all general: they speak to the recycler's intent or system, not to the outcome for each device.

1. Identify the assertion: each retired drive's data was destroyed.
2. Prefer evidence specific to each device over general assurances.
3. Require reconciliation so that no device is unaccounted for.
4. Choose serial-level certificates reconciled to disposal records.

Exam tip: For disposal, insist on serial-level sanitization evidence reconciled to what was sent.

Job scheduling software runs approved schedules consistently and keeps execution records.

Scheduling software holds job information, dependencies and timing set up once and approved, then starts jobs automatically and records what ran. This reduces manual operator intervention and the errors that come with it, and gives an audit trail. It does not speed up programs, segregate libraries or back up output; those are other controls.

1. Ask what the scheduler automates: when and in what order jobs start.
2. Link that to reduced manual intervention and errors.
3. Reject benefits that belong to other functions.
4. Choose consistent execution from approved schedules.

Exam tip: A scheduler's value is consistent, approved, recorded job execution with less operator intervention.

Exceptions found in testing are investigated before they are reported as findings.

Jobs outside the approved schedule are exceptions, not yet findings. Reruns and ad hoc requests are common and acceptable when they follow an authorization procedure. The auditor therefore checks each exception for a request, an approval and a business reason. Only then can the auditor conclude whether processing was unauthorized and recommend controls; disabling accounts is never the auditor's call.

1. Treat the difference as an exception to investigate.
2. Check each unscheduled job for authorization and reason.
3. Conclude and recommend only after the facts are known.
4. Leave operational actions to management.

Exam tip: An exception is investigated for authorization before it becomes a finding.

A UPS covers short disturbances; a generator covers long outages.

An uninterruptible power supply sits between the utility supply and the equipment, smoothing sags and spikes and switching to batteries without a break when power fails. Batteries last minutes, so long outages need a standby generator, which the UPS bridges while the generator starts. An emergency power-off is a safety control, and a second feed from the same substation does not remove a shared point of failure.

1. Note the duration: seconds to minutes.
2. Recall that a generator needs time to come online.
3. Recognise the UPS as the instant, conditioning control.
4. Choose the UPS.

Exam tip: UPS for seconds to minutes; generator for hours.

Leaver access should be removed by an event, not a periodic report.

The weakness is the delay between a termination and its removal from systems. Several options improve things, but the deciding factor is how quickly and reliably access is removed. Feeding termination events from the HR system into the identity management system lets accounts be disabled on the termination date with no manual hand-off. A weekly reconciliation is better than monthly but keeps both a delay and a manual dependency; quarterly recertification and a 90-day inactivity rule are detective backstops that leave much longer exposure.

1. Identify the root cause: a periodic, manual notification.
2. Compare how long each option leaves a leaver's access active.
3. Prefer preventive, automated removal over detective reviews.
4. Choose the HR-driven trigger.

Exam tip: Tie deprovisioning to the HR termination event; reviews only catch what it misses.

Test deprovisioning from the authoritative source of leavers.

The test must show that every leaver lost access promptly. HR records are the authoritative, complete population of leavers, so sampling from them catches people for whom no removal request was ever raised, and comparing the termination date with the disable timestamp measures timeliness. Sampling closed tickets tests only removals that were requested, which is exactly where the control usually fails. Manager confirmation is indirect and says nothing about timing, and a walkthrough with interviews supports design, not operating effectiveness.

1. Define what must be proved: every leaver, removed promptly.
2. Pick the population that contains every leaver: HR records.
3. Reject populations that only include requested removals.
4. Compare termination and disable dates for the sample.

Exam tip: To test completeness, sample from the source population, not from the control's own output.

Owners recertify access.

Access recertification asks whether each user still needs their current access. Only the business or data owner (often with line managers) has both the knowledge of job needs and the accountability for the data. The security administrator and service desk operate the provisioning process, so having them review it lacks independence and context, and the auditor performing the control would compromise audit independence.

1. Ask who is accountable for the data.
2. Exclude those who operate provisioning.
3. Exclude the auditor, who tests controls rather than performing them.
4. Choose the business owner.

Exam tip: The data owner recertifies; IT provisions; audit tests.

A review that is completed is not necessarily a review that works.

Blanket approvals of hundreds of entitlements in minutes are a classic sign of a rubber-stamped review. Completion on time is evidence that the control was performed, not that it was performed effectively. The auditor should obtain evidence of effectiveness, for example by re-performing the review for a sample of users and checking whether their access matches their current role (looking for movers and excessive entitlements). Changing the frequency or the reviewer is a recommendation that should follow the evidence, and the security team is the wrong reviewer anyway.

1. Spot the warning sign: zero changes and very fast approvals.
2. Separate evidence that a control ran from evidence that it worked.
3. Gather evidence before recommending changes.
4. Re-perform the review on a sample.

Exam tip: Rubber-stamped reviews are found by re-performing them on a sample.

Multifactor authentication uses different factor types.

Stolen passwords are a something-you-know compromise. Only adding a different factor type, such as something you have (an authenticator app, hardware token) or something you are, stops an attacker who holds the password. Security questions look like a second step but are another knowledge factor and are often phished or researched alongside the password. Complexity, rotation and lockout address guessing, not theft.

1. Identify the threat: the password is already known to the attacker.
2. Recall that MFA needs factors of different types.
3. Recognise security questions as a second knowledge factor.
4. Choose the device-based one-time code.

Exam tip: Two things you know are still one factor; MFA combines know, have and are.