CISA Domain 4: Operations and Business Resilience Explained

CISA Domain 4 is where your study calendar gets decided. Information Systems Operations and Business Resilience carries 26% of the exam, roughly 39 of the 150 questions, tied with Domain 5 at the top of the blueprint.

It reads like two subjects bolted together. The first half is how IT is run day to day: assets, jobs, interfaces, changes, patches, logs, service levels, databases. The second is what happens when that stops: the business impact analysis, backups, the continuity plan, the recovery plan. Both halves are technical operations content assessed from the auditor's seat rather than built from the engineer's, and that gap is where most of the lost marks live.

How much of the CISA exam is Domain 4?

The current outline, effective August 2024, sets five fixed weights, with approximate question counts against the 150-item exam:

Counts are approximate; ISACA publishes the weights, not per-form item counts. For all five domains in depth, see CISA domains explained.

What does the operations half of Domain 4 cover?

Ten areas, best read as one question asked ten ways: is this process defined, owned, monitored, and enforced.

IT asset management. A complete hardware and software inventory across the life cycle, from procurement through disposal. Without one you cannot map controls to assets, confirm license compliance, or prove retired hardware was sanitized before it left the building. The auditor asks whether the inventory is reconciled on a schedule, whether each asset class has an owner, and whether end-of-life products have a replacement plan.

Job scheduling and process automation. Batch jobs, ETL pipelines, and file transfers run in chains where one job feeds the next. The risk is silent failure: a job that aborts at 2 a.m. may not surface until a user notices missing data at 9 a.m., by which point dependent jobs have produced wrong output too. Exception handling is the control that matters, and jobs should run under dedicated service accounts rather than an employee's credentials.

System interfaces. Every interface is a control boundary. What left System A must arrive at System B complete, correctly formatted, and unduplicated. Three controls do that work: input validation before data enters, reconciliation of record counts and control totals after transfer, and error handling for failed checks. A payroll feed with no total-value reconciliation can underpay people for a full cycle before anyone notices.

Shadow IT and end-user computing. Shadow IT is technology in use that IT does not know about; end-user computing is the wider category of business-built tools, mostly spreadsheets. A spreadsheet calculating a bank's reserve requirements may have no version control, no backup, and no review. The exam's preferred answer is almost never "ban it" or "migrate it to IT." Look for compensating controls proportionate to the risk.

Availability and capacity management. Availability is systems being usable when the business needs them, against agreed targets; capacity is the infrastructure carrying current and projected load. A 99.9% target allows roughly 8.7 hours of downtime a year, fine or unacceptable depending on when it falls. The classic finding is a commitment with no monitoring behind it.

Problem and incident management. Learn this one cold, because it recurs. An incident is an unplanned interruption, and incident management restores service fast, workaround included. A problem is the underlying cause, and problem management removes it so the incidents stop. A database that crashes on full temporary tablespace gets restarted in 20 minutes by incident management; only problem management finds the query that fills the tablespace on a schedule. When a stem stresses preventing recurrence, the answer is problem management.

Change, configuration, and patch management. Change management governs how modifications are requested, assessed, approved, implemented, and reviewed, with the change advisory board separating proposal from approval. Emergency changes get expedited approval, never an exemption from documentation and post-implementation review; an unreviewed emergency change is an unauthorized change. Configuration management holds the documented state of production in a CMDB so impact analysis is possible before approval. Patch management sets cadence, pre-production testing, and an exception process for what cannot be patched on time.

Operational log management. Four functions have to work together: generation of the right events, retention long enough for regulators and investigators, integrity protection so logs cannot be edited by the systems or administrators they monitor, and actual review. Logs retained but never read are a control in name only.

Service level management. An SLA commits IT to the business or a customer. An OLA commits one internal IT group to another so the SLA is achievable. An underpinning contract commits an external vendor whose service sits beneath both. The finding writes itself when a vendor promises less availability than the SLA it supports.

Database management. Integrity through constraints and concurrency controls, availability through clustering and transaction logging, confidentiality through privileged access control. DBAs can typically read or change anything and bypass application-layer controls, so segregation of duties, scheduled access reviews, and logging DBA activity where the DBA cannot alter it are what get examined. Shared high-privilege accounts are a recurring finding because they destroy attribution.

What does the business resilience half cover?

Four topics, and the order matters, because each one depends on the one before it.

The business impact analysis comes first and drives everything else. It identifies which processes are critical, how fast they must come back, and how much data loss is survivable, plus criticality rankings alongside the recovery metrics. The auditor checks two things: is the BIA current and methodologically sound, and are its recovery objectives justified by business consequence rather than what IT thought it could deliver.

Backup, storage, and restoration must be engineered to hit the BIA's data-loss target. Full backups are self-contained but slow and large. Incremental backups are fast to write and slow to restore: you replay the full plus every increment in order, and one corrupt link breaks the chain. Differential backups grow through the week but restore from just two sets. The 3-2-1 guideline (three copies, two media types, one offsite) plus immutable storage covers site loss and ransomware. The most consequential finding here is an organization that ran backup jobs for years and never once tested a restore. A completion log proves data was written, nothing more.

The business continuity plan covers the business: who activates it, where people work, how the organization communicates when the primary channel is also down, which manual workarounds carry critical processes, and in what order things restart. Capacity assumptions get tested here: a plan that sends 200 people to a VPN sized for 50 fails on contact.

The disaster recovery plan covers the technology: sites, replication, recovery sequencing, and testing. Site type must match the recovery objective. Hot sites take over in minutes to hours at the highest cost, warm sites in hours to days, cold sites in days to weeks. Reciprocal agreements are cheap in cash and expensive in risk.

RTO vs RPO: what is the difference?

This pair gets confused more than anything else in Domain 4, and the exam tests it directly. One is a duration, the other a position in time.

Recovery time objective is how long a process or system can be unavailable before the impact becomes unacceptable. It points forward from the moment of failure.

Recovery point objective is how much data the organization can afford to lose, expressed as a point in time. It points backward from the moment of failure to the last usable recovery point.

Maximum tolerable downtime sits outside both. It is the limit past which harm becomes permanent, so it is always equal to or greater than the RTO. An 8-hour RTO inside a 24-hour MTD leaves a 16-hour buffer.

A worked example. A regional bank runs a BIA on its core banking system. Retail operations puts the cost of an online banking outage at about USD 400,000 per hour, the regulator requires settlement by end of business, and any outage beyond four hours in business hours triggers regulatory notification. The BIA team lands on an RTO of two hours and an RPO of 15 minutes.

Now watch what those numbers dictate. The 15-minute RPO forces transaction log backups every 15 minutes or continuous replication, because weekly fulls and nightly differentials cannot get closer than the previous night. The 2-hour RTO forces a hot site with near-real-time replication, because a warm site that needs a day to load backups cannot make the window. Two numbers, two architecture decisions, both traced to business consequence.

And here is the trap in the pair. A system back online in 90 minutes carrying data from 48 hours ago has met its RTO and blown its RPO. Both targets have to be satisfied at once, and a question handing you a restored system with a stale dataset is testing exactly that.

What is the big trap in CISA Domain 4?

That everything above is technical operations content tested from the auditor's seat.

You are never asked to write the job schedule, tune the query, configure replication, or build the CMDB. You are asked whether the control over those things is designed properly, whether it operates effectively, what the risk is if it does not, and what the auditor does next. Ask a DR question and the credited answer rarely turns on failover technology. It turns on whether recovery time was measured against the BIA objective and reported to management. A systems administrator who could stand up the site from scratch can still miss that, because building a control and evidencing it are different skills.

The same reflex applies to remediation. When the auditor finds emergency changes going unreviewed, the credited answer is to report the gap and recommend the control, not to join the change advisory board and fix it personally. We take that answer pattern apart in how hard is the CISA exam.

Practically, read every topic here through four questions: what could go wrong, what control addresses it, what evidence proves it operated, and what the auditor recommends when that evidence is missing. Our CISA study guide teaches all five domains that way, with Domain 4 split across two chapters, and every practice question explained including the wrong options.

Where should Domain 4 go in your study plan?

An opinion, since the weights make this a real decision: study Domain 4 second, after Domain 1, never last.

Domain 1 goes first because it teaches the auditor's vocabulary. Evidence sufficiency, control types, materiality, and reporting structure are the language every other domain is graded in, and studying operations without that lens means learning it twice. Then go straight to the 26% domains. Domain 4 carries the most questions and the widest gap between what most candidates know operationally and how the exam wants it framed. Give it your freshest weeks.

Leave Domain 3 for later. At 12% it is the lightest on the exam and the worst place to spend early momentum. Pair Domain 4 with Domain 5 if you can, since together they are 52% of your score and share the same trap.

Within Domain 4, give the resilience half more time than its page count suggests. The operations half rewards familiarity, which most working IT and audit professionals already have. The resilience half rewards precision, and a vague memory of "backups and a DR site" loses to a candidate who can trace the chain from BIA to objective to architecture to test evidence. Still getting oriented? Start with what the CISA exam is.

FAQ

How many questions on the CISA exam come from Domain 4?

Domain 4 carries a 26% weight, which is about 39 of the 150 questions. ISACA publishes the weight but not an exact per-form item count, and some questions on any form may be unscored pretest items, so treat 39 as a planning figure rather than a promise. Domain 5 carries the same weight, so the two together account for roughly half your exam.

What is the difference between RTO and RPO on the CISA exam?

RTO is a duration: the maximum time a system or process can be unavailable before the impact is unacceptable. RPO is a point in time: the maximum data loss the organization can absorb, measured backward from the failure. Both come out of the business impact analysis, and a recovery strategy has to meet both at once. Restoring quickly with old data satisfies the RTO and fails the RPO.

Is Domain 4 the hardest CISA domain?

It causes the most trouble for the most candidates, mostly because it is the largest and because its technical content is assessed rather than built. Technically strong candidates have to unlearn the instinct to fix things. Audit-strong candidates have to get comfortable with operational detail like backup schemes, patch cadence, and database privilege models. Either way the fix is the same: read every topic as a control to evaluate.

Do I need hands-on operations experience to pass Domain 4?

It helps, but it is not what the questions reward. You need to recognize what each process is for, what fails when it is absent, and what evidence demonstrates it worked. Someone who has never scheduled a batch job can still answer scheduling questions correctly by knowing that exception handling, ownership, and service accounts are the controls under examination.

Looking for a plain-English CISA guide? ISACA CISA: Certified Information Systems Auditor Study Guide covers all five domains with four full-length practice exams, every answer explained.

Simply Certified is an independent publisher. CISA and ISACA are trademarks of ISACA. Our books are independent study material and are not affiliated with, endorsed by, or sponsored by ISACA.