Overview
Information Systems Operations and Business Resilience covers what happens after a system goes live. Its 16 sub-topics cover operations (IT components, asset management, job scheduling, system interfaces, shadow IT and end-user computing, availability and capacity, problem and incident management, change, configuration and patch management, log management, service levels and databases) and business resilience (business impact analysis, system and operational resilience, backup and restoration, the business continuity plan and disaster recovery plans).
Candidates must judge whether operational controls keep systems reliable and changes authorized, and whether recovery capabilities match what the business actually needs. The BIA is the anchor: it sets the recovery time and recovery point objectives that justify every backup, redundancy and alternate-site decision. This domain inherits systems from Domain 3, applies the governance and SLAs from Domain 2, and shares incident and logging foundations with Domain 5.
How it's tested
Questions present an operational setup or a recovery arrangement and ask for the GREATEST risk, the BEST control or what should happen FIRST. Many involve sequencing in resilience planning, and some require interpreting recovery objectives. The right answer usually follows business requirements and authorization, not technical capability.
-
BIA drives the answer
Recovery options are compared. Read the stated recovery time and recovery point objectives, then pick the least costly option that meets both.
-
Authorized and traceable change
A change, patch or job modification reached production. Check whether it was approved, tested, documented and reviewed, including emergency changes after the fact.
-
Restore service vs. fix the cause
Scenarios separate incident management, which restores service quickly, from problem management, which removes the root cause. Choose the process that matches the goal described.
A company's DRP lists a hot site, but no BIA has been done and recovery priorities were set by IT. Options include testing the DRP, upgrading the hot site contract, or performing a BIA. Reasoning: without a BIA, nobody knows whether the hot site is overbuilt, underbuilt or protecting the wrong systems. The BIA comes first because it sets the objectives the plan must meet.
Sub-topics 16
Official sub-topics from the ISACA outline, in outline order.
4.1 IT ComponentsHardware, system software, networks and cloud services that applications rely on.
- What it means
- IT components include servers, storage, end-user devices, operating systems, middleware, network infrastructure and cloud platforms. Each needs configuration, maintenance and monitoring for applications above it to be reliable and secure.
- What to understand
- System software and privileged utilities can bypass application controls, so their access and use must be restricted and logged. Hardware needs preventive maintenance and end-of-support tracking, and cloud components shift some responsibilities to the provider while the customer keeps others.
- How it shows up
- A scenario shows operators with unrestricted access to a utility that edits data directly and asks for the greatest risk, which is undetected changes that bypass application controls.
- Common confusion
- Assuming strong application controls protect data even when lower layers such as the operating system or database are poorly controlled.
4.2 IT Asset ManagementInventorying and managing hardware, software and licenses over their life cycle.
- What it means
- IT asset management maintains an accurate inventory of hardware, software and licenses, records owners and locations, and manages assets from acquisition to secure disposal. A configuration management database can link assets to services and changes.
- What to understand
- An accurate inventory is the foundation for patching, licensing compliance, risk assessment and incident response, because unknown assets go unprotected. Disposal must include media sanitization proportional to data sensitivity.
- How it shows up
- A question asks what the auditor should verify FIRST when assessing patch coverage; the answer is that a complete and current asset inventory exists.
- Common confusion
- Treating asset management as a finance exercise; for audit purposes, its main value is knowing what must be secured, patched and recovered.
4.3 Job Scheduling and Production Process AutomationControlling batch jobs, schedules and automated production processes.
- What it means
- Job scheduling software runs batch and automated jobs in a defined order and at defined times, while production automation, including scripted and robotic process automation, performs repetitive tasks without human intervention.
- What to understand
- Changes to schedules and job parameters must be authorized and logged, job failures must be detected and followed up, and restart and recovery procedures must protect data integrity. Automated accounts that run jobs or bots need restricted, monitored credentials.
- How it shows up
- A scenario shows operators changing job sequences without approval or ignoring failed-job alerts and asks for the greatest concern.
- Common confusion
- Assuming automation removes the need for review; an unreviewed automated job can repeat an error across every transaction.
4.4 System InterfacesControls over data exchanged between systems and organizations.
- What it means
- System interfaces move data between applications, databases and external parties through file transfers, messaging or application programming interfaces (APIs). Each interface has a source, a target, a format and an owner.
- What to understand
- Interface controls confirm completeness and accuracy (record counts, control totals, sequence checks), handle and correct rejected records, protect data in transit, and authenticate both ends. Interface inventories and ownership are needed so failures are noticed and resolved.
- How it shows up
- A question describes a nightly file from a partner that occasionally arrives incomplete without anyone noticing and asks for the best control, which is automated reconciliation of counts and totals with exception reporting.
- Common confusion
- Relying on encryption to ensure completeness; encryption protects confidentiality, not whether all records arrived.
4.5 Shadow IT and End-User ComputingSystems built or acquired by business users outside IT's formal control.
- What it means
- End-user computing includes spreadsheets, databases and tools built by business users, while shadow IT includes applications and cloud services adopted without IT approval. Both can support important processes and reports.
- What to understand
- Risks include errors without testing, no change control, no backup, weak access control and data leaving approved environments. The response is to inventory these tools, rank them by risk, and apply proportionate controls to critical ones rather than banning them outright.
- How it shows up
- A scenario shows a complex spreadsheet feeding financial reports and asks for the greatest concern; lack of change control, testing and access protection is the usual answer.
- Common confusion
- Recommending that all end-user tools be moved into IT development; proportionate controls based on criticality are the expected answer.
4.6 Systems Availability and Capacity ManagementKeeping systems available and sized for current and future demand.
- What it means
- Availability management tracks uptime and failure measures such as mean time between failures and mean time to repair, while capacity management monitors utilization of processing, storage and network resources and forecasts future needs.
- What to understand
- Capacity plans should be based on business growth forecasts and utilization trends, so shortfalls are addressed before they cause outages. Availability targets come from service level agreements and the BIA.
- How it shows up
- A question shows recurring slowdowns at month-end and asks for the best recommendation, which is capacity monitoring and planning tied to business volumes.
- Common confusion
- Treating capacity management as buying more hardware when problems appear; it is a forward-looking planning activity.
4.7 Problem and Incident ManagementRestoring service quickly and eliminating the underlying causes of failures.
- What it means
- Incident management restores normal service as quickly as possible and minimizes business impact. Problem management investigates the root cause of one or more incidents and works to remove it, recording known errors and workarounds.
- What to understand
- Incidents are logged, classified, prioritized by impact and urgency, escalated and closed with user confirmation. Recurring incidents with no root-cause analysis indicate a weak problem management process. Trend analysis of incidents helps identify problems.
- How it shows up
- A scenario shows the same outage recurring monthly, each time closed after a restart, and asks for the greatest concern; the missing root-cause investigation is the answer.
- Common confusion
- Expecting incident management to find root cause; its goal is speedy restoration, and root cause belongs to problem management.
4.8 IT Change, Configuration, and Patch ManagementAuthorizing, testing and tracking changes, configurations and security updates.
- What it means
- Change management ensures every change is requested, assessed for impact, approved, tested, scheduled, implemented with a backout plan and reviewed. Configuration management keeps approved baselines, and patch management identifies, tests and deploys vendor fixes based on risk.
- What to understand
- Emergency changes may be implemented first but must still be logged, approved after the fact and reviewed. Patches are prioritized by severity and exposure, tested where possible, and tracked to completion against the asset inventory. Unauthorized changes are detected by comparing production to the approved baseline.
- How it shows up
- Auditors are asked how BEST to detect unauthorized changes; the answer is comparing production versions or configurations against approved change records or baselines, not reviewing the change log alone.
- Common confusion
- Using the change log as proof all changes were authorized; an unauthorized change would not appear in the log, so the auditor starts from production.
4.9 Operational Log ManagementGenerating, protecting, retaining and reviewing operational logs.
- What it means
- Log management defines which events are recorded, centralizes and protects logs from alteration, synchronizes time across systems, retains logs for required periods, and ensures they are reviewed.
- What to understand
- Logs of privileged activity are most valuable and must be protected from the administrators whose actions they record, for example by sending them to a separate, write-protected store. Time synchronization makes it possible to correlate events, and retention must meet legal and investigative needs.
- How it shows up
- A scenario shows system administrators able to delete their own activity logs and asks for the greatest concern, which is loss of accountability.
- Common confusion
- Assuming logging alone is a control; without review or alerting it provides little detective value.
4.10 IT Service Level ManagementDefining, agreeing and monitoring service levels with the business and providers.
- What it means
- Service level management agrees measurable service targets with customers in service level agreements (SLAs), supports them with internal operational level agreements and supplier contracts, and reports performance against them.
- What to understand
- SLAs must define measurable metrics, responsibilities and remedies, and be based on business requirements. Supplier contracts must support the SLAs the IT function promises; otherwise IT cannot meet them. Performance reports should be independent or verifiable.
- How it shows up
- A question asks what the auditor should check when IT keeps missing an SLA; whether supporting operational agreements and supplier contracts match the SLA is a common answer.
- Common confusion
- Treating an SLA as an internal IT document; it is an agreement with the business customer.
4.11 Database ManagementControls over database design, administration, integrity and access.
- What it means
- Database management systems store and control shared data, enforcing integrity through constraints such as referential integrity, managing concurrent access, and logging transactions for recovery. The database administrator (DBA) has powerful privileges over structure and data.
- What to understand
- Direct database access can bypass application controls, so it should be restricted, logged and reviewed. DBA activity needs independent monitoring, and changes to schemas follow change management. Referential integrity prevents orphan records, such as an order linked to a customer that does not exist.
- How it shows up
- A scenario shows a DBA able to change data with no logging and asks for the best control, which is independent logging and review of privileged database activity.
- Common confusion
- Confusing referential integrity with entity integrity; entity integrity requires a unique primary key, while referential integrity keeps foreign keys valid.
4.12 Business Impact AnalysisDetermining critical processes and how fast and how far they must be recovered.
- What it means
- A business impact analysis (BIA) identifies critical business processes and their supporting resources, estimates financial and non-financial impact of disruption over time, and sets recovery time objectives (RTO) and recovery point objectives (RPO).
- What to understand
- Process owners and senior management provide the input, because they know the impact. The BIA comes before continuity strategy selection and must be updated when the business changes. Lower RTO and RPO values mean higher recovery cost.
- How it shows up
- Questions ask what should be done FIRST when developing a continuity program or which stakeholders provide the most important input; the BIA and business process owners are the answers.
- Common confusion
- Letting IT set recovery priorities based on technical dependencies without business input.
4.13 System and Operational ResilienceDesigning systems and operations to absorb failures and keep running.
- What it means
- Resilience is built with redundancy and fault tolerance, such as clustering, load balancing, redundant array of independent disks (RAID), redundant network paths and power, and geographic distribution, removing single points of failure.
- What to understand
- Resilience reduces the chance a failure becomes an outage, while recovery restores service after one. Redundancy must be tested and its components kept independent; two redundant servers on the same power circuit share a single point of failure.
- How it shows up
- A scenario describes a mirrored server pair in the same rack and asks for the greatest risk, which is a shared single point of failure such as power, network or location.
- Common confusion
- Treating RAID or mirroring as a backup; they replicate corruption and deletion immediately and do not provide historical recovery points.
4.14 Data Backup, Storage, and RestorationBackup types, rotation, offsite and immutable storage, and restore testing.
- What it means
- Full backups copy all selected data; incremental backups copy changes since the last backup of any type; differential backups copy changes since the last full backup. Backups are stored offsite or in separate cloud locations, and increasingly in immutable form to resist ransomware.
- What to understand
- Backup frequency is driven by the RPO, and the only proof that backups work is a successful, periodic restore test. Incremental backups are fastest to create but slowest to restore, while differential backups take longer to create but need only the full plus the latest differential to restore.
- How it shows up
- A question asks the BEST way to confirm that backups are usable; the answer is periodic restoration testing, not checking backup job logs.
- Common confusion
- Mixing up incremental and differential restore requirements, or keeping backups online and writable where ransomware can encrypt them.
4.15 Business Continuity PlanKeeping critical business processes running during and after a disruption.
- What it means
- The business continuity plan (BCP) defines how the organization continues critical processes during a disruption, including roles, communication, manual workarounds, alternate work locations and the link to IT disaster recovery.
- What to understand
- Senior management is responsible for the BCP, which is built on the BIA, maintained as the business changes, distributed so copies are available offsite, and tested regularly. Human safety comes first in any continuity response.
- How it shows up
- A scenario shows a BCP that has not been updated after a major reorganization and asks for the greatest concern, which is that recovery roles and priorities no longer match the business.
- Common confusion
- Treating the BCP and DRP as the same document; the BCP covers business processes and people, while the DRP covers IT recovery.
4.16 Disaster Recovery PlansRestoring IT systems and data after a disaster, and testing that ability.
- What it means
- Disaster recovery plans (DRP) define how IT restores systems, data and connectivity, using recovery sites ranging from hot (ready to run) to warm (partially equipped) to cold (space and utilities only), as well as mobile sites, reciprocal agreements and cloud-based recovery.
- What to understand
- Site choice follows the RTO: shorter RTOs need hotter sites. Plans are tested in increasing depth, from desk-based checklist reviews to structured walkthroughs, simulations, parallel tests and full interruption tests, and test results drive plan updates.
- How it shows up
- Questions ask which test type checks recovery without disrupting production, or which site fits a stated RTO at lowest cost.
- Common confusion
- Recommending a full interruption test as the first test; it carries the highest risk and is used only after less disruptive tests succeed.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
RTO vs. RPO
Recovery time objective is the maximum acceptable time to restore a process or system after disruption, while recovery point objective is the maximum acceptable amount of data loss measured in time.
- Remember
- RTO drives recovery site and failover choices; RPO drives backup and replication frequency.
- Tested as
- Recovery questions give one or both values and ask which strategy meets them.
- Trap
- Choosing faster restoration to fix an RPO problem, when only more frequent backup or replication reduces data loss.
-
Maximum tolerable downtime
The longest a business process can be unavailable before the organization suffers unacceptable harm, identified in the BIA.
- Remember
- The RTO must be shorter than the maximum tolerable downtime, leaving time for verification and resumption.
- Tested as
- BIA questions test the relationship between these values.
- Trap
- Setting RTO equal to maximum tolerable downtime with no margin.
-
Hot, warm and cold sites
A hot site has equipment, software and current data ready within hours; a warm site has some equipment and connectivity but needs configuration and data; a cold site has only space and utilities.
- Remember
- Cost and readiness rise together; select the least costly site that meets the RTO.
- Tested as
- Questions match site type to recovery requirements and budget.
- Trap
- Choosing a hot site by default when the RTO allows a cheaper option.
-
Incremental vs. differential backup
Incremental backups copy data changed since the last backup of any type; differential backups copy data changed since the last full backup.
- Remember
- Restore from incrementals needs the full plus every incremental since; restore from differentials needs the full plus the latest differential.
- Tested as
- Questions ask which approach is faster to restore or to create.
- Trap
- Reversing the restore requirements of the two types.
-
Restore testing
Periodically restoring data from backup to confirm media, procedures and data are usable within the RTO.
- Remember
- A successful backup log does not prove data can be restored.
- Tested as
- Asked as the best evidence that backup arrangements work.
- Trap
- Accepting backup completion reports as sufficient evidence.
-
Incident vs. problem management
Incident management restores normal service quickly; problem management finds and removes the root cause of one or more incidents.
- Remember
- Recurring incidents without root-cause analysis show a problem management gap.
- Tested as
- Scenarios describe repeated outages and ask what is missing.
- Trap
- Expecting the service desk to resolve root causes while restoring service.
-
Emergency changes
Changes made urgently to restore or protect service, implemented before full approval but still logged, approved after the fact and reviewed.
- Remember
- Emergency does not mean uncontrolled; retrospective approval and review are required.
- Tested as
- Change management questions test whether emergency changes are properly documented.
- Trap
- Accepting a lack of documentation because the change was urgent.
-
Detecting unauthorized changes
Compare what is running in production, such as program versions, object code or configurations, with approved change records and baselines.
- Remember
- Start from production and trace back to approvals, not the other way round.
- Tested as
- Asked as the best audit procedure for change management.
- Trap
- Sampling from the change log, which by definition contains only recorded changes.
-
DRP test types
Checklist reviews and structured walkthroughs check plan content; simulations rehearse a scenario; parallel tests recover systems at the alternate site without stopping production; full interruption tests shut down production.
- Remember
- Test progressively, from least to most disruptive.
- Tested as
- Questions ask which test fits a goal or risk tolerance.
- Trap
- Choosing full interruption as the best test regardless of risk.
-
SLA vs. OLA vs. underpinning contract
An SLA is agreed with the business customer, an operational level agreement is between internal IT groups, and an underpinning contract is with an external supplier, both supporting the SLA.
- Remember
- Supporting agreements must be at least as stringent as the SLA they support.
- Tested as
- Questions on missed SLAs often trace to weaker supporting agreements.
- Trap
- Looking only at the SLA when diagnosing missed targets.
-
Mirroring is not backup
RAID and real-time mirroring protect against hardware failure by copying data instantly, which also copies deletions, corruption and ransomware encryption.
- Remember
- Point-in-time, isolated backups are still needed.
- Tested as
- Resilience questions test whether candidates rely on redundancy for data recovery.
- Trap
- Concluding that a mirrored system needs no separate backup.
-
Log integrity and time synchronization
Logs must be protected from alteration, especially by privileged users, and time-synchronized across systems so events can be correlated and used as evidence.
- Remember
- Send privileged activity logs to a store administrators cannot alter.
- Tested as
- Asked as the greatest concern or best control for log management.
- Trap
- Accepting logs stored on the same server the administrator controls.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
RTO vs. RPO vs. maximum tolerable downtime
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Recovery time objective (RTO) | Target time to restore a process or system | Measures downtime; drives site and failover design | Using it to set backup frequency |
| Recovery point objective (RPO) | Maximum acceptable data loss, expressed as time | Measures data loss; drives backup and replication frequency | Thinking a faster recovery site reduces data loss |
| Maximum tolerable downtime | Longest outage the business can survive without unacceptable harm | Upper limit that the RTO must sit inside | Setting the RTO equal to it |
Full vs. incremental vs. differential backup
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Full | Copies all selected data | Slowest to create, simplest to restore | Assuming it is practical to run as often as incrementals |
| Incremental | Copies data changed since the last backup of any type | Fastest to create, restore needs the full plus every incremental | Forgetting that one missing incremental breaks the chain |
| Differential | Copies data changed since the last full backup | Grows daily, restore needs only the full plus the latest differential | Thinking it resets after each differential run |
Hot vs. warm vs. cold site vs. reciprocal agreement
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Hot site | Fully equipped facility ready within hours | Highest cost, shortest RTO | Choosing it when the RTO allows days |
| Warm site | Partially equipped, needs configuration and data restore | Moderate cost, RTO typically in days | Assuming it can meet an RTO of a few hours |
| Cold site | Space, power and environmental controls only | Lowest cost, longest RTO | Forgetting equipment procurement time |
| Reciprocal agreement | Two organizations agree to host each other's processing | Cheap but hard to enforce or test, and capacity may be lacking | Treating it as reliable as a contracted site |
Incident management vs. problem management
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Incident management | Restores normal service as quickly as possible | Goal is speed and minimal business impact | Expecting it to fix root causes |
| Problem management | Identifies and removes root causes of incidents | Goal is prevention of recurrence | Ignoring it when incidents are closed quickly |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Gold-plated recovery
- What candidates pick
- A hot site with synchronous mirroring for every system.
- Why it looks right
- It offers the fastest recovery and the least data loss.
- Why it's wrong
- Recovery should match BIA requirements at reasonable cost; overspending on low-criticality systems is a governance failure.
Clue to watch for If RTO and RPO values are given, find the cheapest option that meets both.
-
Plan before BIA
- What candidates pick
- Test or update the DRP when no BIA exists.
- Why it looks right
- Testing produces evidence and seems proactive.
- Why it's wrong
- Without a BIA, the plan's priorities and objectives have no business basis, so testing it validates the wrong target.
Clue to watch for No BIA, or a BIA years out of date, with FIRST in the question points to performing the BIA.
-
Sampling from the change log
- What candidates pick
- Select changes from the change management system and check that each was approved.
- Why it looks right
- It is a standard compliance test of the change process.
- Why it's wrong
- It confirms recorded changes were approved but cannot detect changes that bypassed the process.
Clue to watch for If the question is about unauthorized changes, start from production.
-
Mirroring as backup
- What candidates pick
- Accept real-time replication as sufficient data protection.
- Why it looks right
- Replication meets a near-zero RPO for hardware failures.
- Why it's wrong
- Corruption, deletion and ransomware replicate instantly; isolated point-in-time backups are still needed.
Clue to watch for Look for threats such as ransomware, accidental deletion or logical corruption.
-
Full interruption test first
- What candidates pick
- Recommend a full interruption test to prove the DRP works.
- Why it looks right
- It is the most realistic test.
- Why it's wrong
- It risks causing the outage the plan exists to prevent; less disruptive tests should succeed first.
Clue to watch for A new or untested plan points to a walkthrough or simulation.
-
Ban the spreadsheets
- What candidates pick
- Prohibit end-user computing and move everything into IT-developed systems.
- Why it looks right
- It removes the uncontrolled tools at once.
- Why it's wrong
- It is impractical and disrupts the business; the expected response is inventory, risk ranking and proportionate controls.
Clue to watch for Look for an option that identifies and controls critical end-user tools.
-
Restart and close
- What candidates pick
- Accept the service desk's practice of restarting the server and closing the ticket each time it fails.
- Why it looks right
- Service is restored quickly, which is the incident goal.
- Why it's wrong
- Repeated incidents signal an unaddressed problem; root-cause analysis is missing.
Clue to watch for The same failure recurring is the clue to problem management.
Answer framework
For an operations or resilience question, tie every control back to an authorized process or a business recovery requirement.
- Decide whether the scenario concerns daily operations or resilience, and identify the specific sub-topic, such as change, incident, logs, backup or continuity.
- For resilience, find the BIA values; if none exist or they are outdated, the BIA comes first.
- Choose recovery and backup options that meet the RTO and RPO at the lowest reasonable cost, and confirm they are tested.
- For operations, check that changes, jobs, patches and privileged actions are authorized, tested, logged and independently reviewed, including emergency changes after the fact.
- Prefer evidence that starts from the production environment or a real restoration, rather than from records that only show what the process captured.
Practice question
Want more like this? The CISA practice test has questions for every domain.
Checklist
0 of 15
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Split this domain into its two halves and study resilience first, because it holds the most predictable question patterns. Learn the BIA, RTO, RPO and maximum tolerable downtime until you can read any recovery scenario and name the cheapest option that works. Then cover resilience techniques, backups and restoration, the BCP and the DRP with its test types.
Next, move through operations in groups: change, configuration and patch management with log management, since auditors test them together; incident and problem management with service levels; then components, asset management, job scheduling, interfaces, end-user computing, capacity and databases.
Commonly underestimated areas are interface controls, end-user computing and database management, which feel minor but appear as greatest-risk scenarios. Pay attention to how direct database or utility access bypasses application controls.
After studying, practice recovery questions with given RTO and RPO values until you answer them quickly, then drill change management questions focused on detecting unauthorized changes. Because this domain carries 26% of the exam, schedule a second review pass shortly before your exam date, and pair it with Domain 5's incident response material.
FAQ
Why is Domain 4 so heavily weighted?
ISACA weights it at 26% in the current job practice, equal to Domain 5. It combines day-to-day IT operations with business resilience, both central to an IS auditor's work.
How many questions come from Domain 4?
ISACA does not publish per-domain counts. As a planning estimate, 26% of 150 questions is about 39.
What is the simplest way to remember RTO and RPO?
RTO is about time to get back up; RPO is about how much data you can afford to lose. RTO chooses the site, RPO chooses backup or replication frequency.
Is a business continuity plan the same as a disaster recovery plan?
No. The BCP keeps business processes and people working during a disruption, while the DRP restores IT systems and data. The DRP supports the BCP.
Are calculations tested in this domain?
Expect interpretation of recovery objectives and backup schemes rather than heavy arithmetic. You may need to compare an RPO with a backup interval or an RTO with a site's readiness.
How does this domain connect to Domain 5?
Log management and incident management here supply the data and processes that security monitoring and incident response rely on in Domain 5.
How long should I study Domain 4?
A planning estimate is 45 to 60 hours within a roughly 200-hour plan. Its breadth means a second review pass is worthwhile.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- CompTIA SecurityX (CASP+) Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Cloud Security Professional Study guide
Test your Domain 4 knowledge
Practice matching recovery arrangements to RTO and RPO values, detecting unauthorized changes, and separating incident from problem management.