Domain 4 — Information Systems Operations and Business Resilience (26% · ~39 questions)

Weight: 26% of the exam — the joint-largest domain, alongside Domain 5. Together they are 52% of your marks. This is the domain most candidates under-prepare. Do not rush it.

It splits into two halves:

• A. Information Systems Operations — running the live environment with discipline, evidence and control
• B. Business Resilience — surviving disruption: BIA, recovery objectives, backup, BCP and DRP

The unifying test across both halves: is there a defined, approved, documented, monitored and repeatable process — and can the auditor verify it with reliable evidence? An operator's verbal assurance is not evidence. A system-generated record is.

A. Information Systems Operations

What this section is really testing. Domain 4A is the "run" side of IT. It is not asking how systems are designed or built (that is Domain 3) but whether the live environment is operated with discipline, evidence and control: defined processes, approved baselines, monitored performance, logged activity, and independent proof that the process actually happened. Nearly every question reduces to the same test — is there a defined, approved, documented, monitored and repeatable process, and can the auditor verify it with reliable evidence? ISACA does not test whether you can configure a RAID array or tune SQL. It tests whether you know that RAID is not a backup, that the DBA is not the data owner, that an incident restores service while a problem removes the cause, that logs must be reviewed and not merely retained, that change success must be measured, and that the auditor's best evidence is a system-generated record — scheduler job log, change ticket, reconciliation control total, review sign-off — rather than an operator's verbal assurance or a one-off technical test. Where the build ends, operations begin; 4A is the ongoing control, monitoring and improvement of what already exists.

How the exam asks it

Recurring patterns — recognise the stem, then apply the rule:

IT components

• Auditor's angle: are components inventoried, supported, hardened, patched, monitored, redundant where needed, and covered by change control? Not: are they brand-new or fastest.
• Hardware layers: servers (rack/blade), mainframes (very high I/O and reliability, still common in banking/utilities for batch), storage arrays, tape/media libraries, network devices, endpoints (desktops, laptops, mobile, printers, IoT).
• Operating systems: Windows Server, Linux/UNIX (AIX, Solaris), IBM z/OS; patch level, hardening baseline, supported version = the three audit questions.
• Virtualisation: Type 1 hypervisor (bare metal — ESXi, Hyper-V, KVM) vs Type 2 (hosted on an OS — VirtualBox, Workstation). Type 1 is the production norm.
  • Risks: VM sprawl, orphaned/dormant VMs (unpatched, unmonitored), snapshot sprawl (storage exhaustion), resource contention/noisy neighbour, hypervisor as a single point of failure, VM escape/guest-to-host attack, backup and licensing of virtual images.
• Containers vs VMs: containers share the host OS kernel (lightweight, fast, dense, weaker isolation); VMs each carry a guest OS (heavier, stronger isolation). Container images need scanning, signing and registry control.
• Middleware: application servers, message queues/brokers, ESB, API gateways, transaction monitors — glue that is frequently forgotten in inventories yet is a common single point of failure.
• Networks: LAN/WAN/SD-WAN, routers, switches, firewalls, load balancers, DNS, VPN, wireless. Redundant paths, power (dual PSU, UPS, generator), and diverse carriers matter for availability.
• The component audit question set (applies to every layer):

• Availability design concepts (memorise the ladder):

• RAID levels (a hardware availability control, never a backup):

• Add-ons: hot spare (auto-rebuild), battery-backed write cache, RAID controller as a single point of failure.
• Storage architectures:

• Single point of failure (SPOF) analysis: walk the transaction path and name every sole dependency — one firewall, one ISP, one DNS, one hypervisor host, one database instance, one scheduler, one person who knows the process, one power feed, one backup generator fuel contract. Redundancy that removes a SPOF must itself not be a SPOF (both links in the same duct, both nodes in the same rack/room).
• Why redundancy ≠ backup: redundancy replicates the current state instantly, so it faithfully replicates deletion, logical corruption, ransomware encryption and malicious/erroneous changes. Redundancy protects against hardware failure; backup protects against data loss and rollback in time — they are complementary, not substitutes. (Backup/restore design, BIA, BCP and DR are Section B.)

IT asset management

• Full lifecycle: acquisition → deployment → in-use/maintenance → decommission/disposal, with records at every stage.
  • Acquisition: approved requisition, procurement, ownership/location/owner assigned, asset tag, software licence entitlement recorded.
  • Deployment: standard build/image, baseline configuration recorded in the CMDB, hardening applied, ownership accepted.
  • In use: maintenance and warranty tracking, patch status, licence reconciliation, moves/adds/changes recorded, physical inventory verification.
  • Decommission: data sanitisation, licence reclamation, removal from service, CMDB update, disposal with evidence.

• Hardware and software inventory: must be complete and accurate; software inventory should capture title, version, licence type, quantity, install location and usage.
• CMDB (configuration management database): repository of configuration items (CIs) — hardware, software, services, documents, people — and, critically, the relationships/dependencies between them (which app runs on which server, which server feeds which interface). Relationships are what make the CMDB useful in incident and change impact analysis.
  • Accuracy mechanisms: automated discovery (agent/agentless scanning, network discovery, cloud APIs), reconciliation of discovery output against the CMDB, and periodic physical verification.
• Why the auditor verifies the inventory against reality: an inventory is a claim; the audit test is agreement to the physical/observed population. Approach: select items from the inventory and locate them (existence), then select items in the data centre and trace them to the inventory (completeness) — the second direction is the one that finds the real problem, e.g. a forgotten server still running with no owner, no patching and no monitoring.
• Software licence management and compliance: entitlement (what you bought) vs deployment (what is installed) vs usage (what is actually used). Risks: under-licensing = legal/financial liability and failed vendor audit; over-licensing = waste. Cloud/SaaS subscriptions need the same discipline (renewal dates, seat counts, orphaned accounts).
• Unauthorised software: both a licensing and a security risk (unsupported, unpatched, possibly malware or shadow IT). Detection: inventory tools, allow-listing/application control, endpoint detection.
• End-of-life vs end-of-support: EOL/EOSL means no more vendor patches or support; the system becomes a permanent, unpatchable vulnerability. Auditor's question: is there a documented, funded migration/replacement plan with dates, or an accepted, formally approved risk with compensating controls?
• Secure decommissioning and sanitisation (NIST SP 800-88 Rev. 1 categories — Clear, Purge, Destroy):

• Media handling and chain of custody: label and log every movement of media; secure storage and encrypted transport; sign-off at each handover; when a vendor sanitises or destroys, obtain a certificate of destruction (asset IDs, method, date, technician, witness) — plus evidence you verified the vendor.
• Virtual machines/cloud volumes also need sanitisation and secure deletion of snapshots and backups, not just the primary disk.

Job scheduling and production process automation

• Batch vs online/real-time: batch = scheduled, high-volume, non-interactive (payroll, interest accrual, EOD settlement, billing); online = immediate user interaction; real-time = immediate and continuous (payments, trading). Many critical business processes are still batch, so batch failure is an availability and financial reporting risk.
• Job scheduling software: central scheduler (e.g., enterprise workload automation) vs native schedulers (cron, Task Scheduler, SQL Agent). Controls: who may create/modify/delete jobs and parameters, versioned schedules, promotion of schedule changes through change control.
• Dependencies: jobs run in a defined order with predecessors/successors; the scheduler waits for completion codes. Audit concerns: hard-coded dependencies, jobs that run "whenever", cycles, and dependencies on a job that no longer exists.
• Failure alerting: automatic notification on abnormal end (abend)/non-zero return code, with a defined escalation and time limit; silent failure discovered by users the next morning is a finding.
• Restart/recovery: restart from the last checkpoint rather than from the beginning; idempotent reruns; documented restart points; a rerun must be authorised and logged, and must not create duplicate postings.
• Balancing and reconciliation of batch runs: every batch must prove completeness and accuracy — record counts, control totals, hash totals, sequence checks, reasonableness checks; input total must equal output total plus rejects. Unreconciled batch = potential integrity failure.
• Operator documentation and run books: step-by-step instructions, expected results, error codes, escalation contacts, and authority limits. Operations staff work from the run book; if the run book is stale, the control is stale.
• Manual intervention must be restricted and logged: operators should not be able to edit data or alter jobs without an authorised, time-stamped record (console log/ ticketing) — otherwise they can both cause and conceal an error (segregation of duties).
• "Ghost jobs": undocumented scheduled tasks (old cron entries, forgotten scripts, vendor agents, tasks left by departed staff) that run with production privileges, are outside change control, are usually unmonitored, and often contain hard-coded credentials. Finding them: compare scheduler inventories across tools, review service/agent accounts, and look for unexplained file changes.
• Change control over job schedules: a schedule/parameter change is a change to production logic (a changed date or file path can silently skip processing) and must follow the same approval, testing and documentation route as code.
• Scheduler control points to test:

System interfaces

• Interface styles:

• Interface reconciliation (the core control): every interface must be proven complete and accurate: record counts, control totals, hash totals, sequence/duplicate checks, and a comparison of what was sent against what was received. Both ends should count independently.
• Error handling: invalid records must go to a rejection/suspense queue with an owner, ageing report and defined resolution timeframe — not silently dropped. Interfaces should be idempotent so a retry does not duplicate a transaction.
• Why failed interfaces are a classic risk: they hit availability (business process stops at the boundary), integrity (partial posting: money out but not in), and are often invisible because each system reports itself as healthy. Ownership gap: "the other team's system".
• Common interface failure modes and the control that catches each:

• Architecture controls: middleware decouples systems; an API gateway centralises authentication, rate limiting, logging, versioning and exposure management; interface definitions and credentials must be inventoried and rotated.
• Monitoring and alerting: per-interface dashboards, heartbeat/latency checks, queue depth and rejection-rate alerts, and an owner for each interface — test the interface as a service in its own right.
• Why the auditor tests end-to-end completeness, not one system: testing only the sending system proves the message left; testing only the receiving system proves something arrived. Only an end-to-end trace of a sample transaction through every hop (including transformations and any manual step) proves the business result is complete and accurate. Reconcile totals at each hop.

End-user computing (EUC) and shadow IT

• Definition: solutions built and maintained by business users outside formal IT development — spreadsheets, Access/desktop databases, local scripts and macros, personal BI dashboards, small workflow tools. They exist because IT backlogs are slow — they are legitimate and often necessary, and they are among the highest-yield audit areas because they frequently support financial reporting and decision-making.

• Compensating controls for EUC: maintain an inventory/register of EUC assets with owner, purpose, data classification and criticality; version control with a defined master location; locked/protected formulas and separation of input cells from calculation cells; input validation and range checks; maker-checker independent review and sign-off before use; periodic recalculation/reperformance by an independent person; access control on the file location; backup; and a migration plan to a controlled application for anything critical. Material EUC used in financial reporting should be documented and tested like any other application control.
• Shadow IT: IT assets and services procured or used without IT knowledge or approval — SaaS sign-ups on a corporate card, personal devices and personal cloud accounts for work data, unauthorised VPNs/remote tools, and increasingly unsanctioned GenAI/LLM use (pasting confidential or personal data into public models — an irrecoverable disclosure).
• How to audit shadow IT: internal audit does not begin with a questionnaire. Use discovery: network/DNS/proxy log analysis, SSO/IdP and OAuth application-consent logs, expense and procurement card reviews, cloud spend analysis, browser extension and agent inventories, CASB (cloud access security broker) telemetry, and interviews with business units. Then confirm with the business whether each service holds company data.
• Why outright bans fail: users route around the block (personal devices, home accounts, mobile hotspots), so the activity goes completely invisible — strictly worse than a governed, visible service. Effective response: risk-based sanctioning — a fast, well-marketed approval path; a vetted catalogue of approved SaaS and AI tools; data-classification rules on what may be entered; identity/SSO integration, logging and DLP; and continuous discovery to find the remainder.

System availability and capacity management

• Availability formulas: Availability = MTBF ÷ (MTBF + MTTR). Raising availability means raising MTBF (better design, redundancy, testing) or cutting MTTR (monitoring, automation, spares, skills, tested procedures). In practice MTTR is usually cheaper to improve.
• The nines (memorise exactly):

• Scheduled vs unscheduled downtime: many SLAs exclude agreed, notified maintenance windows from the availability calculation. So the same system can report 99.99% while users are genuinely without service. The auditor's question: is the definition agreed, documented, and does it reflect the business's experience rather than a favourable technical metric?
• Why the measurement method matters: infrastructure-only metrics (server pingable) can look perfect while the service is unusable. Measure with user-perceived / synthetic transaction monitoring; define measurement point, sample method, exclusions, and who computes the figure. The customer and provider should agree the report, not just the target.
• Capacity planning inputs: business growth forecasts and new products, projected transaction volumes and peaks (month-end, year-end, promotions), storage/data growth, user counts, response-time targets, licensing ceilings, and headroom (deliberate spare capacity for growth and failover). Output: a documented plan with triggers/thresholds and a review cycle.
• Why business forecasts must drive it, not history alone: historical trending cannot foresee a new product, a merger, a marketing campaign or a regulatory change; capacity plans built only from the past systematically under-provision at the moment of business change.
• Performance monitoring: CPU, memory, disk I/O (IOPS, latency, queue depth), network (bandwidth, latency, packet loss), application response time, throughput, error rates, concurrent users. Define thresholds, alert on breach, and agree who acts.
• Queuing and bottleneck analysis: the bottleneck is always the slowest resource in the chain — improving anything else changes nothing. As utilisation rises, queue length and response time grow non-linearly (a rule of thumb: response time degrades sharply above roughly 70–80% utilisation), so "average utilisation looks fine" can hide peak-hour saturation. Little's Law (L = λW: items in system = arrival rate × time in system) formalises this. Monitor peaks, not just averages.
• Trend analysis: plot capacity and performance over time, project forward, and act before a threshold breach; a plan without trend data is a guess.
• Chargeback vs showback: chargeback = actual internal billing for IT consumption (drives cost accountability, but can distort behaviour and needs a defensible model); showback = reporting consumption/cost informationally without invoicing (less confrontational, weaker behavioural pull). Either way, cost transparency supports capacity and demand management.

Problem and incident management

• ITIL 4 definitions — get the exact distinctions right:

• Priority = Impact × Urgency. Impact = how much business is affected (users, revenue, regulatory, safety). Urgency = how quickly the business impact escalates. A single VIP user is usually low impact/high urgency; a degraded back-office batch may be high impact/low urgency.
• Incident management lifecycle (memorise the order): detect → log/record → categorise → prioritise → initial diagnosis (and known-error search) → escalate if needed → investigate and diagnose → resolve/restore → verify with the user → close → (if warranted) raise a problem. Each step must be evidenced in the ticket.
• Incident metrics worth naming: time to detect, mean time to restore service (MTTR), first-call resolution %, % resolved within SLA/target, reopen rate, backlog/ageing, incidents per category (feeding Pareto), and % of major incidents with a completed post-incident review.
• Major incident process: separate, pre-defined procedure — dedicated incident manager/bridge, defined communication to the business and (where relevant) to regulators/customers, senior management visibility, resource mobilisation authority, and a post-incident review with actions tracked to closure.
• Escalation: functional = bring in more expertise (Tier 2/3, vendor) — a technical escalation; hierarchical = bring in management for authority, resources, decisions, communication. Do not confuse the two; exam answers often hinge on it.
• Service desk tiers: Tier 1 first line — logging, known-error scripts, first-call resolution; Tier 2 second line — specialist support; Tier 3 third line — engineering/development/vendor. Metrics: first-call resolution rate, first-contact resolution, tickets per analyst, average handle time, reopen rate, time to restore.
• Known error database (KED): searchable record of symptoms → root cause → workaround. Its value is entirely dependent on problems being properly diagnosed and the KED being used by Tier 1.
• Root cause analysis tools: 5 Whys (fast, but stops at the analyst's depth — guard against "human error" as an endpoint); fishbone/Ishikawa (categorise candidate causes — people, process, technology, environment); Pareto analysis (the vital few causes producing most incidents — the best tool for prioritising fixes); timeline/event reconstruction; fault-tree analysis.
• Problem management outputs: confirmed root cause, documented workaround, agreed permanent fix (raised as a change), updated KED, and prevention actions elsewhere (other systems with the same flaw).
• Why the auditor checks the incident-to-problem pipeline: the classic finding is a service desk that closes tickets fast and reopens the same incident every week — indicators are high recurring-incident counts, a large proportion of incidents closed with "no fault found"/"restarted", and an empty or unused problem log. Repeated incidents with no root cause analysis = control deficiency, because the organisation is paying for the same failure repeatedly.
• Incident logging completeness is itself a control: every incident should have a unique ID, time stamps, reporter, category, priority, assignment, actions, resolution and closure. Missing or back-filled logs break trend analysis and forensic reconstruction.
• Post-incident review: blameless, focused on control gaps, producing owned and dated actions; for major incidents, verify that prior review actions were actually implemented.
• Security incident vs operational incident: a security incident (malware, intrusion, data breach, DoS) may look like an outage. Rule: contain and preserve evidence first, involve the security incident response process (Domain 5) and legal/forensics, and restrict communications; restoring service quickly by wiping/rebuilding a compromised host can destroy forensic evidence. Handoff must be explicit, with clear ownership and a single incident record covering both views.

IT change, configuration and patch management

• Change types (ITIL 4):

• Core change controls: formal change request with description, justification, systems affected and CIs; impact and risk assessment (business, security, interfaces, dependencies, regulatory); testing before production (unit, integration, regression, UAT by the business, security testing) with results retained; approval by the CAB (business + IT representation) before deployment; back-out/rollback plan with a go/no-go decision point and defined rollback authority; post-implementation verification that the change achieved the objective and broke nothing; PIR for failed/major changes.
• Segregation of duties: the person who develops a change must not be the person who approves it or deploys it to production. Also keep development, test and production environments separate, with developers having no production write access (and ideally no production read access to sensitive data). Automated deployment pipelines must enforce approval gates, not merely log them.
• Change lifecycle and the evidence each step should leave:

• Emergency change retrospective approval: acceptable only when documented, time-boxed and reviewed afterwards (e.g., within days). An emergency change process that is always used is a bypassed process.
• Change freeze/blackout periods: imposed around financial close, peak trading, holidays or major events; the auditor checks the freeze is defined, communicated, technically enforced, and that any exception is formally approved at a high level.
• Change metrics: change success rate, percentage of unplanned/emergency changes, change-related incident rate, back-out rate, average change lead time. Targets and trends matter more than any single number.
• Configuration management: a configuration baseline (approved, documented configuration of a CI) is what makes "drift" measurable. CMDB accuracy is the foundation of both change impact analysis and incident diagnosis — if the CMDB is wrong, changes miss dependencies and responders chase the wrong component. Detect drift via automated discovery and periodic configuration comparison; remediate or re-baseline through change control.
• Hardening standards: documented, approved secure baselines — CIS Benchmarks, vendor security guides, DISA STIGs — applied at build and checked continuously. Deviations (e.g. a service needed for an app) must be documented exceptions with compensating controls.
• Patch management lifecycle (memorise the loop): identify/inventory → assess → prioritise → test → deploy → verify → report (NIST SP 800-40 provides enterprise patch management guidance).
  • Identify: know the assets, OS/app/firmware versions, and the vulnerability feed (vendor advisories, CVE).
  • Assess/prioritise by risk and exploitability: technical severity (CVSS), whether it is actively exploited (e.g. CISA KEV catalogue), exposure (internet-facing?), asset criticality, data sensitivity, and whether a compensating control already exists. EPSS estimates exploitation likelihood.
  • Test: functional/regression test in a staging environment; note that testing delays are the main reason for patch lag, so balance test depth against risk for critical patches.
  • Deploy: defined patch windows with business agreement, staged/ring deployment, reboot planning, and back-out position (snapshots).
  • Verify: re-scan/attestation that the patch is actually installed (deployment tools fail silently).
  • Report: coverage, ageing and exceptions to management.
• Exceptions and compensating controls: some systems cannot be patched (vendor-locked medical/industrial/ATM systems, unsupported OS). Controls: isolate/segment the network, restrict access, tighten monitoring, virtual patching (IPS/WAF signatures), documented risk acceptance with an owner and an expiry date, and a migration plan.
• 100% patching is not the goal: risk-based prioritisation is. What matters is that high-risk, internet-facing, actively exploited issues are patched within a defined, tight timeframe, and that everything else has a scheduled, justified position. Chasing 100% coverage on low-risk internal systems while an exposed service waits is worse risk management.
• Emergency/out-of-band patching: for actively exploited vulnerabilities the normal cycle is bypassed — expedited change approval, minimal but real testing, immediate deployment, full documentation afterwards.
• Why the auditor tests the process rather than re-running a scan as the primary test: a scan is only a point-in-time snapshot of one tool's view and proves nothing about governance, timeliness, exceptions, testing or coverage. The audit test is the process and its records — patch policy, risk-based SLAs, deployment evidence, verification, exception approvals — with scanning used as corroborating evidence and to select samples.
• Release management interface (Domain 3): change management authorises the transition; release management bundles and coordinates the components (changes, configuration, documentation, training, communications) into a deployable release with a defined schedule and acceptance criteria. Do not conflate a change (one authorised alteration) with a release (the packaged set delivered together).

Operational log management

• What to log (minimum high-value set): authentication successes and failures; privilege escalation and use of administrative/root accounts; access to sensitive data (reads, exports, prints); configuration and permission changes; security events (malware, IDS/IPS, firewall denies); administrative actions (account creation, log clearing, policy changes); job/batch outcomes and interface failures; system and application errors.
• Why failed logins, administrative activity and changes are the highest-value sources: failed logins reveal brute-force and misconfiguration; privileged activity is where the greatest damage can be done and where insiders operate; change records explain why the environment differs, which is essential for distinguishing a legitimate change from an intrusion. A useful heuristic: log the actions that can change the security or integrity state of the environment.
• Log source → what it detects (use this to answer "which log is MOST useful"):

• Log integrity: logs are evidence, so they must be tamper-evident. Controls: write-once/append-only storage, centralised logging (syslog/rsyslog, Windows event forwarding) or SIEM ingestion, hashing/checksums, restricted deletion rights, and separate log infrastructure with separate administrative credentials. Core principle: logs stored only on the host that generated them cannot be trusted if that host is compromised — an attacker (or a rogue administrator) can alter or erase them.
• Clock synchronisation via NTP (RFC 5905): without a common, accurate time source (authoritative NTP servers, internal hierarchy, stratum levels) logs from different devices cannot be correlated, sequence of events cannot be established, and evidence is weakened in investigation or legal proceedings. Time-zone and DST handling must be consistent.
• Retention tied to legal/regulatory requirements: the retention period is driven by law, regulation, contract and investigation needs — not by disk space. Benchmark to know: PCI DSS requires audit logs to be retained at least 12 months, with at least the most recent 3 months immediately available for analysis. Privacy law cuts the other way: personal data must not be kept longer than necessary (e.g. Hong Kong PDPO Data Protection Principle 2), so logs containing personal data need defined retention and secure disposal. Retention must be documented and enforced, with integrity preserved (archives hashed/immutable) and restorable for investigation.
• Log review is a detective control: collection without review detects nothing. Define and evidence: who reviews (an independent person, ideally not the administrator who can change the system), how often (frequency matched to risk — daily for critical systems), what they look at (exception/threshold reports, not raw volumes), what they do on finding (escalation path with timeframes), and how the review is evidenced (signed review record, ticketed anomalies). "Logs are collected but never reviewed" is one of the most common and most defensible audit findings in the whole exam.
• Log volumes and tuning: indiscriminate logging produces alert fatigue and hides the signal; tune rules, prioritise by severity, and monitor false positive/negative rates. Note the trade-off: over-tuning suppresses real events (false negatives), under-tuning drowns analysts (false positives).
• Monitoring vs logging: logging = recording events for later analysis (detective/reactive, forensic); monitoring = actively observing and alerting in near real time (detective/proactive). Both are needed; one does not substitute for the other. Also distinguish logging (record) from auditing (independent review of records against criteria).

IT service level management

• The three agreements — know the difference exactly:

• The logic to remember: one external SLA is delivered by several internal OLAs and supported by several underpinning contracts. If the OLAs/UCs are weaker than the SLA, the SLA is undeliverable — an internal OLA of 12 hours' response cannot support an SLA of 4 hours. Auditors test the consistency between the layers.
• Service catalogue: the published list of live services with description, owner, hours of service, supported users, dependencies, target levels and cost. It is the bridge from business need → service level requirement → measurable metric, and it is a prerequisite for meaningful SLAs (you cannot agree a target for an undefined service).
• Service level requirements are derived from business needs — e.g. "trading floor must be available 07:00–19:00 HKT with sub-2-second response" — not from what IT finds convenient to measure.
• Measurable and unambiguous metrics: each target needs metric definition, measurement point, calculation method, frequency, reporting format, exclusions and owner. Vague commitments ("best efforts", "high availability", "prompt response") are unenforceable and are themselves a finding.
• Typical SLA metric set and the definition trap in each:

• Service credits and remedies: agreed financial or other consequences for breach (credits, escalation, termination rights). The auditor tests whether breaches occurred and whether credits/remedies were actually applied — a clause never invoked is a clause not working.
• Regular service review meetings: scheduled, minuted, with attendance by both business and IT, covering performance against SLA, breaches and root causes, outstanding issues, changes, capacity, upcoming demand and improvement actions.
• What the auditor verifies about SLAs — the three-part test: (1) Do SLAs exist and are they aligned to business requirements and supported by OLAs/UCs? (2) Are the services actually measured against them using a reliable, agreed method, and are reports produced and delivered? (3) Do breaches lead to action — root cause analysis, remediation, service credits, escalation, management attention? Failure at any of the three stages is a finding, and the third stage is the one organisations most often omit.
• Reporting to the business: regular, comprehensible, consistent, honest (including bad news), trended, and with actions — not a raw dump of infrastructure statistics.
• Continual service improvement (CSI): a formal cycle (measure → analyse → improve → re-measure) with an improvement register, owners, dates and benefits realised. Look for whether improvement actions from service reviews and post-incident reviews actually close.
• Reference frameworks: ITIL 4 (best-practice guidance for service management: service value system, practices such as incident, problem, change enablement, service level management, IT asset management); ISO/IEC 20000-1 (the certifiable requirements standard for service management systems — a management-system standard, so it carries audit and certification weight); COBIT 2019 for governance and control objectives; ISO/IEC 27001/27002 for the information security management system; ISO/IEC 27035 for incident management. Know which is a framework/guidance (ITIL, COBIT) and which is a certifiable standard (ISO/IEC 20000-1, ISO/IEC 27001).

Database management

• DBMS types: relational (tables, rows, columns, SQL, strong schema and constraints — the default for transaction processing); NoSQL (document, key-value, wide-column, graph — horizontal scale, flexible schema, often BASE consistency: Basically Available, Soft state, Eventual consistency); in-memory (data held in RAM for extreme speed, durability provided by persistence/snapshotting/logging); plus data warehouses/lakes for analytics.
• ACID properties — the integrity foundation:

• Transactions, commit and rollback: changes are provisional until COMMIT; ROLLBACK undoes uncommitted work; savepoints allow partial rollback. Isolation levels trade correctness against concurrency (read uncommitted → read committed → repeatable read → serializable), with anomalies (dirty read, non-repeatable read, phantom read) possible at weaker levels — banks that need exact balances accept the performance cost of stronger isolation.
• Concurrency control and locking: pessimistic locking (lock before use — safe, blocks others) vs optimistic concurrency (check version at commit — scales better, may fail and retry); row/table/page locks; deadlocks (detected and one transaction rolled back); lock escalation and long-running transactions causing contention.
• Referential integrity and constraints: primary keys (uniqueness), foreign keys (no orphan rows), NOT NULL, CHECK, UNIQUE, default values, domains. Constraints are automated integrity controls — the auditor asks whether they exist and are enforced in the database, not only in application code (a second access path, e.g. a report tool or DBA session, bypasses application-only validation).
• Normalisation vs denormalisation: normalisation (1NF atomic values → 2NF no partial dependency → 3NF no transitive dependency → BCNF) removes redundancy and update anomalies and is right for transactional systems; denormalisation (controlled redundancy, pre-joined or summary tables, star schemas) improves read/query performance in warehouses and reporting systems at the cost of consistency risk. The audit point: denormalised data must be reconciled/refreshed under control.
• DBMS controls: authentication integrated with the directory; roles and least privilege at object level (GRANT/REVOKE); views to restrict rows/columns and hide sensitive attributes; stored procedures to encapsulate authorised operations; triggers for automatic validation/audit logging (but they can be disabled or bypassed — test them); schema-change control; connection encryption; native database auditing (who did what, when).
• DBA privileges — a highly privileged role needing strong compensating controls: the DBA can typically create/modify users and grants, alter or disable constraints and triggers, read and update data directly without going through the application, change or delete audit tables, and move data files. Therefore the DBA can bypass application controls entirely — application-level maker-checker proves nothing if the DBA edits a table afterwards.
  • Compensating controls: separate the DBA role from application/security administration and from data ownership (the data owner is a business role accountable for classification, access approval and use — the DBA is a custodian, not the owner); no routine use of shared super-user accounts; require change records for schema changes; independent monitoring of DBA activity (DAM, OS/audit logs shipped to a system the DBA cannot alter, two-person rule for sensitive production fixes); periodic review of accounts, privileges and directly executed SQL; database changes via controlled migration scripts rather than manual edits.
• Database backup and recovery types:

• Point-in-time recovery (PITR): restore the last full backup, roll forward differentials/incrementals, then apply transaction logs to a chosen moment — e.g. to 10:07, seconds before an erroneous mass update or a dropped table. Without log backups you can only return to the last full backup, losing all work since. Therefore: full backup frequency sets the worst case only when logs are unavailable; log backup frequency sets the real recovery point. Log shipping to a secondary server provides an ongoing standby copy. (Backup strategy, RTO/RPO and DR site design are Section B; know the DB mechanism here.)
• Database performance tuning: indexing strategy (and the write cost of too many indexes), execution plans and statistics, query/schema review, partitioning, buffer/cache sizing, connection pooling, I/O layout (separating logs and data files), archiving/purging old data, avoiding full table scans on large tables, and workload monitoring at peak. Tuning is a capacity and availability control when performance degrades into an outage.
• Splitting the privileged database roles (the control answer to "DBA can do anything"):

• Data integrity checks: periodic DBCC/consistency checks, reconciliation of control totals between application and database, comparison of database totals to interfacing systems, orphan-record and duplicate detection, and validation that batch updates produced the expected row counts.
• Native auditing vs third-party DAM: native database audit trails are convenient and detailed but are stored and administered inside the database by the very privileged users being monitored — a DBA may be able to disable, alter or delete them. DAM (database activity monitoring) is independent: it captures traffic/activity out of band, in a repository with separate administration, providing stronger evidence and real-time alerting on unusual access patterns (bulk reads, off-hours access, privilege use, direct SQL from unexpected sources).
• Encryption at rest and in transit: at rest — TDE/file-level/volume encryption plus key management (keys must not be stored with the data; rotation, HSM/KMS, who can use the key), and note that data extracted by a privileged user is decrypted data, so encryption alone does not stop a rogue DBA — access control and monitoring do. In transit — TLS for application connections and replication. Also tokenisation/masking for non-production copies.
• Cloud-managed databases (e.g. Amazon RDS/Aurora, Azure SQL Database, Google Cloud SQL): the provider manages the platform (patching of the engine, hardware, HA failover, automated backups), but under the shared responsibility model the customer still owns: data classification, who can access the database and the cloud console, network exposure (public accessibility), encryption and key management choices, backup retention and restore testing, snapshot/export sharing, parameter configuration, logging export to the SIEM (e.g. cloud-native audit logs), and monitoring. Auditor's question: is the customer's side of the shared responsibility model evidenced, not assumed? Relevant guidance: ISO/IEC 27017 (cloud controls) and 27018 (PII in public clouds); SOC 2 reports and cloud provider certifications are complementary evidence, not a substitute for testing the customer's own configuration.

TRAPS

Specific ways ISACA makes this section tricky — read the stem for these words:

• Availability percentages — read what counts. Does the SLA exclude scheduled maintenance? Is availability measured at the infrastructure level or the user/service level, and over what period? A high reported figure with a favourable definition is not availability the business experiences.
• Incident vs problem: an incident restores service (workaround acceptable); a problem finds and removes the root cause. If the stem says "recurring incidents", "root cause" or "prevent recurrence", it is testing problem management, not faster restoration.
• A workaround is not a fix. Documented workaround + root cause = known error; only an authorised change delivers the permanent fix.
• Event ≠ incident ≠ problem ≠ change. An alert that nobody acts on is a logged event, not an incident; "we changed the config to fix it" is still a change requiring authorisation.
• The DBA is not the data owner. The business data owner is accountable for data classification, access approval and use; the DBA is a custodian who can bypass application controls — which is exactly why DBA activity needs independent monitoring and separation from security administration.
• RAID is not a backup. Mirroring/striping gives availability against disk failure; it replicates deletion, corruption and ransomware instantly. Any stem pairing RAID with recoverability is a distractor.
• Redundancy, HA and fault tolerance are different promises. HA = automatic failover with some interruption; FT = no interruption at all; redundancy = duplicate components that may still need a switch. "Zero downtime" language points to fault tolerance.
• SAN vs NAS: NAS = file-level (NFS/SMB over Ethernet); SAN = block-level (Fibre Channel/iSCSI, appears as local disk). Offering a NAS share as "block storage for the database" is wrong.
• Clustering vs load balancing: clustering exists for redundancy/failover; load balancing exists for capacity distribution (its health checks are a bonus). Do not swap their purposes.
• Purge vs clear vs destroy, and degaussing limits: clear = reuse inside the organisation; purge = recovery infeasible even in a lab / media may leave the organisation; destroy = physical. Degaussing works only on magnetic media — never on SSD/flash, and overwriting SSDs is unreliable because of wear levelling. Crypto-erasure protects nothing if the key is recoverable.
• Certificate of destruction ≠ a signed statement of good intent. It must tie to specific asset identifiers, method and date, and the vendor's own controls should be reviewed.
• Decommissioning is not finished until the CMDB, licence records, DNS/AD accounts, monitoring and backups are all updated. Forgotten "zombie" servers and accounts remain exploitable.
• Inventory verification direction matters: tracing inventory → floor proves existence; tracing floor → inventory finds the unmanaged assets. Completeness is the finding-producing test.
• Patching: 100% is not the goal, risk-based timeliness is. An answer demanding "all systems patched within X days regardless of risk" is usually wrong; the best answer prioritises internet-facing, actively exploited, high-CVSS vulnerabilities with a defined shorter timeframe.
• The auditor tests the patch process, not a scan. Re-running a vulnerability scan is a point-in-time technical test; policy, prioritisation, deployment records, verification that the patch installed, and approved exceptions are the audit evidence.
• Emergency changes need retrospective approval — not "no approval". A high emergency-change percentage is a process-maturity finding, and a freeze period is not a licence to skip the process.
• Developer ≠ deployer; operator ≠ job-schedule author. A single person who can introduce, approve and deploy a change — or edit production data directly — is an automatic control failure.
• Interface failure is often invisible. Each system can report "healthy" while nothing crosses the boundary. The control is end-to-end reconciliation (counts/control totals) at both ends, not a ping.
• Test the interface, not just the systems. Transactions can be complete in system A and absent in system C after a transformation failure; only an end-to-end trace catches it.
• SFTP, not FTP. Plain FTP sends credentials and data in clear text; file transfers of personal or financial data must be encrypted in transit and at rest.
• "Logs are collected but never reviewed" = finding. Retention and centralisation are not detection. Look for the evidence of review: who, when, what, and what happened next — and reviewers should not be the administrators they monitor.
• Logs on the compromised host are worthless evidence. If the host is compromised or the administrator is rogue, local logs can be altered or deleted — hence append-only/WORM storage, centralisation and separation of log administration.
• No NTP, no correlation. Unsynchronised clocks break sequence reconstruction, correlation and forensic/legal credibility.
• EUC controls: watch for "the spreadsheet is locked, so it's controlled". Protection without maker-checker independent review, version control and an inventory of EUC assets does not control a key spreadsheet.
• Banning shadow IT is the wrong answer. Bans push usage underground and eliminate visibility; risk-based sanctioning with discovery, an approved catalogue and data-usage rules is the effective control.
• SLAs are not proven by existence. The three-stage test: exist → measured → breaches lead to action. Also check that OLAs and underpinning contracts are at least as strong as the SLA.
• Service credits alone are not risk management — they compensate, they do not prevent; the objective is restored service and removed root cause.
• Retention is a regulatory requirement, not a storage decision (PCI DSS: 12 months, 3 months immediately available; privacy law limits retention of personal data) — and archive integrity must be preserved for it to be usable as evidence.
• Transaction log backup is the PITR enabler. A full backup alone cannot recover to a point in time; without log backups you accept losing everything since the last full.
• Constraints in the database beat validation in the application only when both paths exist. If secondary access paths (reporting tools, DBA sessions, extracts) exist, application-only validation is insufficient.
• Native database audit trails are weak evidence when the audited privileged user can disable, alter or delete them — that is the argument for independent DAM.
• Encryption at rest does not stop a rogue DBA — that user reads decrypted data through the DBMS. Access control, least privilege and activity monitoring do.
• Denormalisation is a trade-off, not a mistake — but denormalised/summary data must be refreshed and reconciled under control.
• Cloud-managed databases shift responsibility, not accountability. Provider patches the engine; you still control access, exposure, encryption choices, backup retention, logging and restore testing.
• Capacity: averages lie. Capacity and performance must be assessed at peak; the bottleneck is the slowest resource; response time degrades non-linearly as utilisation approaches saturation.
• Historical trending alone is insufficient — business forecasts and demand changes must drive capacity plans.
• Chargeback ≠ showback: chargeback actually bills (behaviour-changing, needs a defensible model); showback only reports cost informationally.

60-second recall

• Availability = MTBF ÷ (MTBF + MTTR); nines: 99% = 3.65 days/yr, 99.9% = 8.76 h, 99.99% = 52.6 min, 99.999% = 5.26 min.
• Redundancy = spares; HA = automatic failover with some interruption; fault tolerance = zero interruption; clustering = failover, load balancing = capacity.
• RAID 0 stripe/no redundancy, 1 mirror, 5 single distributed parity, 6 double parity, 10 mirror+stripe — never a backup.
• DAS = block/local, NAS = file over Ethernet, SAN = block over FC/iSCSI; SPOF analysis covers hardware, networks, power and people.
• Asset lifecycle: acquire → deploy → maintain → decommission; verify inventory in both directions; CMDB accuracy underpins change and incident management.
• Sanitisation (NIST SP 800-88): Clear / Purge / Destroy; degauss = magnetic only; crypto-erasure depends on key destruction; obtain a certificate of destruction tied to asset IDs.
• Batch controls: record counts, control totals, hash totals, restart from checkpoint, logged and authorised manual intervention; beware ghost jobs.
• Interfaces: reconcile both ends; rejections go to a suspense/rejection queue with an owner; SFTP not FTP; test end-to-end completeness; a failed interface is an availability and integrity risk.
• EUC risks: no change control, no documentation, single-person dependency, unauthorised copies, formula error, version sprawl, no backup/access control. Compensating: inventory, version control, locked formulas, maker-checker, input validation, backup.
• Shadow IT: find it via discovery, SSO/OAuth logs, expense review, CASB; risk-based sanctioning beats bans.
• Incident = unplanned interruption → restore service fast. Problem = cause of incidents → remove root cause. Known error = documented root cause + workaround. Priority = impact × urgency.
• Escalation: functional = expertise, hierarchical = management authority; service desk Tier 1/2/3; first-call resolution.
• RCA tools: 5 Whys, fishbone/Ishikawa, Pareto; recurring incidents never converted to problems = finding; post-incident review with owned actions.
• Security incident → contain, preserve evidence, engage the Domain 5 response process before rebuilding.
• Change types: standard (pre-approved), normal (CAB), emergency (ECAB + retrospective approval); require impact/risk assessment, testing, back-out plan, approval, PIR; metrics = change success rate, unplanned change %.
• Developer ≠ approver ≠ deployer; keep dev / test / prod separate; patch lifecycle = identify → assess → prioritise → test → deploy → verify → report; prioritise actively exploited, internet-facing issues; unpatchable systems need compensating controls and documented risk acceptance; audit the process, not a scan.
• Log high-value events: failed logins, privileged/admin activity, sensitive-data access, configuration changes; centralise to append-only/SIEM; local logs untrusted; NTP required; retention per regulation (PCI DSS 12 months / 3 months immediately available); unreviewed logs = finding; logging ≠ monitoring.
• SLA = provider ↔ customer; OLA = internal team ↔ team; UC = organisation ↔ external supplier; OLAs/UCs must be at least as strong as the SLA; test exist → measured → breach action; ITIL 4 = guidance, ISO/IEC 20000-1 = certifiable requirements.
• ACID = Atomicity, Consistency, Isolation, Durability; transactions need commit/rollback; constraints and views/stored procedures/triggers are DBMS controls.
• The DBA is a privileged custodian, not the data owner — can bypass application controls, so require separation of duties and independent activity monitoring (DAM); native audit trails are weak if the DBA can alter them.
• Backup types: full / differential (since last full) / incremental (since any backup) / transaction log; transaction log backup enables point-in-time recovery.
• Encryption at rest protects stored media, not data from a privileged user; cloud-managed databases leave the customer accountable for access, exposure, keys, retention, logging and restore testing.

B. Business Resilience

What this section is really testing. ISACA is not testing whether you can recite the definition of a warm site. It is testing whether you understand who owns which decision, which document governs which scope, and whether the numbers add up. Almost every question in this section resolves to one of four judgments: (1) does the business own this, or has someone wrongly given it to IT; (2) is the plan/measurement consistent with the BIA, which is the source of truth; (3) is the evidence real evidence (a restore test, a test report) or weak evidence (a backup log, a signed plan, a checklist); and (4) does the specific recovery metric satisfy its constraint (RTO + WRT ≤ MTD, RPO drives backup frequency). If you can always answer "what does the business need, who owns it, and what proves it works", you will get most of these questions right. The section is heavily definition-driven, heavily comparison-driven, and unusually fond of the "most appropriate/best" stem where two answers are both technically true but only one matches the constraint in the question.

How the exam asks it

Recurring patterns to recognise instantly:

• Ownership stems. "Who is responsible for…", "Who should approve…", "Who declares a disaster?" Answer nearly always sits with business management / the business continuity coordinator supported by senior management — rarely IT, never the auditor.
• Constraint-arithmetic stems. Given MTD, RTO, RPO, WRT → is the plan compliant? The exam wants you to notice RTO + WRT > MTD = finding.
• "BEST" / "MOST appropriate" comparison stems. Cold vs warm vs hot vs mirrored vs reciprocal, or full vs incremental vs differential. The discriminator is the stated objective: lowest cost, fastest recovery, specific RTO, easiest to test, highest assurance.
• Evidence-quality stems. "The auditor's BEST evidence that backups are recoverable is…" → an actual restore test into a non-production environment, not a job log, not a vendor claim.
• Scope stems. BCP vs DRP vs crisis management. The exam inserts an IT-only activity into a BCP question, or a life-safety activity into a DRP question.
• Testing-hierarchy stems. "Which test type…" → pick the least disruptive option that achieves the objective; the exam rewards the lowest-risk test that meets the requirement, and reserves full-interruption for the case where realism is explicitly demanded and management has approved.
• Chronology/trigger stems. "The plan should be updated when…" → after significant change, after every test, after every real invocation, and at least annually.

1. Business impact analysis

Purpose. The BIA is the foundation of the entire BCP/DRP effort. It:

• Identifies critical business processes (not systems) and the business impact of their disruption over time.
• Quantifies impact across dimensions: financial (revenue, penalties, SLA credits), regulatory/legal, contractual, operational, reputational/customer, safety.
• Determines dependencies required by each process: IT applications and data, people and skills, facilities, suppliers/third parties, utilities, telecommunications.
• Establishes MTD/MTPD per process and therefore RTO/RPO targets and the recovery priority order.
• Feeds the recovery strategy selection (site type, backup scheme) — the BIA decides how fast, and only then does IT decide how.

Ownership — the single most examined fact in this section.

The BIA is not an IT document. IT supplies dependency facts; the business decides criticality, impact and tolerable downtime. If an exam option says "IT performs the BIA", it is wrong.

Process for conducting the BIA.

1. Obtain senior management sponsorship and define scope, method and participants.
2. Inventory business processes (and the products/services they support) — often from a functional decomposition or process inventory.
3. Interview/workshop with process owners to identify impacts and dependencies.
4. Determine impact over time — the impact curve: at what elapsed downtime does impact become severe, and when does it become unacceptable. This crossing point defines MTD.
5. Rank processes by criticality into tiers (e.g., critical / essential / important / deferrable) and derive the recovery priority order.
6. Map dependencies per process — application, data, interface, person, facility, supplier — and note single points of failure.
7. Set recovery metrics per process: MTD, then RTO and RPO that fit inside it.
8. Document, review and obtain management approval; distribute; set a review cycle.
9. Feed into strategy selection and into the BCP/DRP.

Interview and workshop technique. Use structured interviews with process owners and facilitated workshops to reach consensus on ranking. Cross-check claims — process owners commonly over- or under-state criticality. Ask "what happens at 1 hour, 4 hours, 1 day, 3 days, 1 week?" rather than "how critical is this?" Ask for the worst-case and typical scenarios. Verify dependency claims against IT's application inventory (the IT view and the business view of dependencies frequently disagree — that gap is itself an audit finding).

Why staleness is a finding. The BIA reflects the organisation as it was when written. A new product line, a merger, outsourcing, a migration to cloud, a new regulator, a retired application, a changed supplier — any of these invalidates the criticality ranking and the recovery targets. A stale BIA means the RTO/RPO, the recovery priority order and the DRP are all built on obsolete assumptions. The auditor's test: is the BIA dated, reviewed on a defined cycle, and re-performed after significant business change? Re-approval after change is the evidence sought.

Outputs of the BIA.

2. Key recovery metrics

Learn these as a chain, not as isolated definitions: MTD is the constraint; RTO and WRT consume the budget; RPO sets the data-loss tolerance; SDO and MTO govern the interim period.

The relationship, stated precisely.

• RTO + WRT ≤ MTD. If RTO + WRT > MTD, the plan cannot meet the business requirement — an audit finding requiring either a faster recovery strategy or a renegotiated business expectation.
• RPO drives backup frequency: shorter RPO ⇒ more frequent backups/replication ⇒ more cost and more backup overhead.
• RTO drives the site strategy: near-zero RTO ⇒ mirrored/active-active; hours ⇒ hot site; days ⇒ warm; weeks ⇒ cold.
• Availability = MTBF / (MTBF + MTTR). Expressed as a percentage; note that raising MTBF (better reliability, redundancy, fewer components) and lowering MTTR (spares, vendor SLA, automation, tested run books) both raise availability.
• Cost trade-off: shorter RTO and shorter RPO both raise cost. There is no "best" answer independent of the BIA.

Direction sanity check. MTD is the largest number in the family. RTO < MTD. RPO is a data-loss measure and is not directly comparable to RTO — a plan can have RTO 4 h and RPO 5 min (replication) or RTO 4 h and RPO 24 h (nightly tape).

Worked constraint example — memorise the logic.

• The BIA says the order-processing process has MTD = 24 h.
• The business sets RPO = 1 h (no more than one hour of orders may be lost) ⇒ backups/replication must run at least hourly.
• IT proposes a warm site with RTO = 20 h. Add WRT = 6 h (verify data integrity, reconcile the order backlog, resume business processing) ⇒ 26 h > 24 h ⇒ the plan cannot meet the business requirement — a finding.
• Remedies: reduce RTO (hot site or cloud failover to ~4 h), reduce WRT (pre-staged data, pre-tested validation steps, automated reconciliation), or renegotiate MTD — and only the business can move MTD.
• The audit conclusion to state: the proposed recovery strategy cannot meet the business requirement; escalate for a revised strategy or a documented, business-accepted decision.

3. Recovery site strategies

Reading the question. "Hot site" is not automatically the right answer. The discriminator is what the question optimises:

• Optimises cost or the process has a long MTD ⇒ cold site (or reciprocal).
• Optimises speed and MTD is hours ⇒ hot site.
• Demands near-continuous operation / near-zero RTO ⇒ mirrored site.
• Asks for the quickest to implement for a moderate MTD at moderate cost ⇒ warm site, or cloud DR.
• Mutual aid without a written, tested agreement is nearly always the wrong answer when assurance is the objective.

Cloud/DRaaS cautions the exam likes.

• Shared responsibility: the provider secures its layer; your data, identities, configuration, backup policies and access management remain yours.
• Data residency / cross-border: recovery in another jurisdiction may breach regulatory or contractual requirements (a live issue for Hong Kong organisations subject to outsourcing and personal-data rules).
• Provider's own RTO claims are contract terms, not facts — the auditor wants evidence (test results, SLA reports, exit/portability provisions) and a tested failover, not a datasheet.
• Concentration risk: many organisations on one provider/region; an outage is correlated, not independent.
• Exit strategy / data portability: what happens if the provider fails or you terminate.

4. Data backup, storage and restoration

Backup schemes. The exam almost always asks one of two things: how many media are needed to restore, or which scheme best meets an RPO/restore-time requirement.

Memory hook — "Incremental depends on everything; Differential depends only on the Full."

``text Mon Full | Tue Inc | Wed Inc | Thu Inc | Fri Inc -> restore needs ALL 5 sets Mon Full | Tue Dif | Wed Dif | Thu Dif | Fri Dif -> restore needs Mon Full + Fri Dif = 2 sets `` Fewer media to restore ⇒ faster, simpler, less error-prone restore. That is why differential is often the compromise answer when the question values restore speed over storage.

Rotation, retention and storage.

• Grandfather-Father-Son (GFS): daily (son), weekly (father), monthly (grandfather) — and often yearly. Provides multiple restore points across time horizons with a manageable media count.
• Retention schedule must be driven by business, legal and regulatory requirements — not by media capacity. Ask: how far back must we be able to reconstruct?
• Offsite and geographically separated: a copy in the same building/site is not a disaster-recovery copy. Distance must exceed the plausible disaster footprint while still permitting transport/restoration.
• 3-2-1 rule: 3 copies of the data, on 2 different media types, with 1 copy offsite.
• 3-2-1-1-0: adds 1 copy offline / immutable / air-gapped, and 0 errors — i.e. verified by restore testing. This is the current ransomware-resistant formulation and is highly examinable.
• Encryption of backups: encrypt data at rest (and in transit). Key management is the risk — if the key is lost, destroyed or held only by a departed administrator, the backup is unrecoverable. Keys must be escrowed/managed separately from the media, with documented recovery of the key itself. Note that encryption does not protect against deletion or ransomware encryption on write — hence immutable/offline copies.
• Immutable / WORM storage: write-once-read-many; cannot be altered or deleted within the retention window — defeats ransomware attempts to encrypt or delete backups.
• Air-gapped copies: physically or logically disconnected; ransomware cannot reach what it cannot see. Must be reconnected to test restoration — plan for that operationally.
• Media rotation, vaulting and chain of custody: rotate media on a defined cycle, transport to an offsite vault under documented chain of custody (who handled which media, when, where), with environmental controls and access restrictions at the vault. Logs must allow you to prove a specific backup's whereabouts and integrity.

Backup restoration TESTING — the highest-yield exam area.

• A backup that has never been restored is not a backup; it is a hope. Untested backups provide false assurance.
• Checking backup job logs = weak evidence. A successful job log proves the job ran, not that the data is complete, readable and usable. It is an assertion by the backup software.
• An actual restore test = strong evidence. Take real media, restore to a non-production environment, and prove the restored data is complete and usable.
• Restore scope: restoring individual files proves file-level recoverability; a full-system restore proves the recovery procedure, the media chain, the run book and the time actually achievable (the real RTO). High-value systems need the full end-to-end test.
• Verify after restore: record counts, file counts, checksums/hashes, application startup, application-level integrity checks, reconciliation of control totals, and confirmation that authorisation/access controls came back with the data. Do not sign off on "the restore completed".
• Restoration into a non-production environment is the norm because it avoids impacting live service — except in a failover or full-interruption test, where production behaviour itself is the object of the test.
• Dated restore test evidence is what the auditor asks for: a dated restore test report, the systems and data ranges covered, who performed and who verified it, the measured restore time compared to the RTO, and any exceptions with corrective actions tracked to closure.
• Frequency: restore tests should be on a defined schedule (commonly at least annually per critical system, and after significant change), plus backup media verification more frequently.

5. Business continuity plan (BCP)

Scope. The BCP covers the whole organisation and all critical business processes — people, facilities, suppliers, telecommunications, manual workarounds and information. It is not an IT document. It answers: how does the business keep operating while systems/facilities are unavailable?

Contents.

Distribution and version control — why it matters. Uncontrolled copies (old versions in desk drawers, unauthorised copies on personal devices, plans held only on the intranet that is itself down) create a real risk: staff act on obsolete procedures, contact lists and priorities. Controls: a document owner, a version/revision number with date, a controlled distribution list, retrieval/destruction of superseded copies, and offline copies available to key personnel because the intranet, email and shared drives may be precisely what is unavailable.

ISO 22301 as the reference standard. ISO 22301 (Security and resilience — Business continuity management systems — Requirements) is the international BCM management-system standard. Know it at these levels:

• PDCA structure: Plan (establish BCMS, policy, objectives, BIA and risk assessment) → Do (implement strategies and plans, training, awareness) → Check (exercise, test, monitor, review, internal audit, management review) → Act (corrective action, continual improvement).
• Management-system requirements: top-management commitment and a documented BC policy; defined roles; documented BIA and risk assessment; business continuity strategies and solutions chosen to meet the objectives; business continuity plans and procedures; exercise and testing programme; performance evaluation; continual improvement.
• ISO 22301 requires exercising — a plan that has never been exercised does not satisfy the standard.
• Related: ISO 22317 (BIA guidance), ISO 27031 (ICT readiness for business continuity), ISO 22313 (guidance). Do not confuse ISO 22301 (BCM) with ISO 27001 (ISMS) — they overlap but are distinct.

6. Disaster recovery plan (DRP)

Definition and relationship. The DRP is the IT-focused subset of the BCP. It covers systems, data, networks, infrastructure and applications. It must be consistent with and derived from the BCP — the BCP's priority order and RTO/RPO drive the DRP's recovery sequence.

The three layers are distinct but integrated. In an exam question where a bomb threat, fire or injury is involved, the correct first action belongs to the emergency response/life safety layer — not the BCP and not the DRP.

DRP contents.

• Recovery teams and call trees — team charters, members, alternates, escalation paths; call trees tested.
• Activation procedures — criteria, authority, notification steps, assembly instructions.
• System recovery priority order — driven by the BIA, not by IT convenience or system size. Typical ordering logic: infrastructure/network/identity, then the systems supporting the highest-criticality processes, then dependencies and interfaces before dependents.
• Step-by-step recovery procedures / run books — sufficiently detailed that a competent but unfamiliar person can execute them; include decision points and expected timings.
• Configuration and dependency information — hardware/software baselines, versions, licences, interface and data-flow maps, network diagrams, vendor support details. (Keep this current — stale configuration data is a classic failure cause.)
• Vendor and supplier contacts — hardware, software, telecom, cloud provider, with contractual SLAs and escalation contacts.
• Alternate site procedures — travel, access, equipment, staffing, how to get from cold start to operational.
• Data restoration procedures — which backups, which media, which order, key management, integrity verification steps.
• Validation and testing steps — how to prove the system is fit for service before returning to production: data integrity/reconciliation, functional/regression testing, security and access checks, interface testing, performance/smoke testing, business sign-off. Skipping validation is a genuine and frequently cited audit issue.
• Return to normal / failback procedures — the reverse migration is often harder and riskier than the failover; it needs its own plan, its own data-resynchronisation procedure and its own approval. Failback is a commonly forgotten element and a good exam distractor.

7. Testing the plan — the hierarchy

Learn this as an ordered ladder from least disruptive / lowest assurance to most disruptive / highest assurance.

Also know:

• Call-tree test — verify contact details and reachability of team members; cheap, quick, catches the most common real-world failure (stale phone numbers).
• Failover test — actually move a service to its alternate component/site; scope may be one system (component) or all (full interruption).
• Integrated test — exercises business and IT together, end to end, including manual workarounds, suppliers and communications. This is what proves the BCP and DRP are consistent.

The trade-off the exam wants articulated. Realism vs risk. The higher up the ladder, the more the test proves and the more it can harm the organisation. Choose the lowest-risk test that satisfies the objective. A tabletop is appropriate for validating decisions and communication; it cannot prove that a backup restores or that the RTO is achievable — only a component or failover test can.

Why full interruption needs executive approval. It deliberately stops production service — it can cause customer-facing outage, contractual/SLA breach, data loss or corruption if the failover or the failback misbehaves, and it consumes scarce staff and recovery resources. The decision to accept that risk is a business decision, so it requires senior/executive management approval, a scheduled window, agreed rollback criteria, customer/regulator notification where needed, and a fallback plan.

The auditor's role in testing. The auditor should observe and evaluate, not design or run the test — running it would compromise independence and could amount to auditing their own work. The auditor reviews the test plan, observes execution, examines results and evidence, and evaluates whether findings were properly actioned.

The most common finding. "The plan exists but has never been tested" (or has not been tested within the required period). An untested plan provides false assurance and is treated as an unproven control. Related frequent findings: tests were performed but no results documented; findings raised but not tracked to closure; the test did not cover critical third parties or the cloud environment; the test did not validate the RTO/RPO actually achieved; and no failback was tested.

8. Plan maintenance

• Test and update at least annually — and additionally after any significant change: reorganisation, merger/acquisition, new or retired critical system, infrastructure or cloud migration, new site, new critical supplier, new regulation, and after every test or real invocation (a real disaster is the best test you will ever get — capture the lessons immediately, while the experience is fresh).
• Why an untested/unmaintained plan provides false assurance. Management and staff believe they are prepared; the plan's contact lists, dependencies, procedures and priorities no longer match reality. The failure surfaces during the real event, at maximum cost.
• Plan distribution. Controlled, version-numbered copies; a documented distribution list; offline copies for key personnel; superseded copies withdrawn.
• Evidence the auditor looks for.
  • Approved plan with version/revision history and dates, and management sign-off.
  • BIA with date of last review and sign-off, and evidence of refresh after business change.
  • Test plans, dated test results/reports, attendance, scenarios, and measured recovery times vs RTO.
  • Issues/exceptions log with owner, due date and closure evidence — corrective actions tracked and closed, not just raised.
  • Training/awareness records and call-tree test evidence.
  • Evidence the plan covers third parties and cloud providers, and that their claims were tested.
  • Evidence restoration was actually proven, not just scheduled.

9. Auditing resilience — what the auditor reviews and tests

Two boundaries the auditor must respect.

• The auditor does not write, design or approve the BCP/DRP or the BIA. Doing so destroys independence and would mean later auditing their own work.
• The auditor does not declare a disaster and does not activate the plan. Declaration is a business management decision.

TRAPS

• The BIA is owned by the BUSINESS, not IT and not the auditor. IT provides dependency input only. Any option saying "IT performs/owns the BIA" is wrong.
• IT does not declare a disaster — and neither does the auditor. Declaration authority is business management.
• RTO + WRT must fit inside MTD. If RTO + WRT > MTD, the plan does not meet business requirements ⇒ a finding. Learn this arithmetic; it is asked in several forms.
• MTD is set by the business, and it is the largest/binding constraint. RTO and RPO are derived from it — not the reverse.
• RPO is a data-loss measure, not a downtime measure. It drives backup frequency. Don't confuse it with RTO.
• Incremental = since the last backup of ANY type. Differential = since the last FULL. Restoring an incremental chain needs the last full plus every incremental. This one-line distinction answers many questions.
• Checking backup job logs is NOT evidence of restorability. A dated restore test into a non-production environment with integrity verification is the evidence.
• BCP = business-wide (business-owned). DRP = IT systems (IT-owned). Crisis management/emergency response = life safety first. Three layers, three scopes.
• The DRP is derived from the BCP and must be consistent with it. A DRP with a different recovery priority order than the BIA is a finding.
• The BCP is not just IT. It must cover people, facilities, suppliers, telecommunications, manual workarounds and communications.
• Full-interruption testing requires executive approval because it deliberately risks production. Choose the least disruptive test that meets the objective — the exam rewards the lower-risk test when the objective doesn't require realism.
• The auditor observes tests; does not run them. The auditor reviews plans; does not write them.
• Most common finding: "the plan exists but has never been tested." An untested plan = false assurance.
• Hot site is not always the answer. Read whether the question optimises cost, speed or a specific RTO.
• Reciprocal/mutual aid agreements are low cost but low assurance, hard to test, and unreliable in a regional disaster that hits both parties.
• Snapshots and replication are not backups on their own — they live with the primary copy and can propagate deletion or ransomware encryption. Only immutable/offline/air-gapped copies resist that.
• Losing the encryption key loses the backup. Key management and escrow matter as much as the encryption.
• Offsite must be geographically separated — a copy in the same building is not a DR copy.
• Cloud DR shifts responsibility, it does not remove it. Shared responsibility, data residency, provider RTO claims needing evidence, concentration risk and exit strategy all remain yours.
• Restoring files is not the same as restoring a system. File-level restore proves file recoverability; a full-system restore proves the run book, the media chain and the achievable RTO.
• Failback/return-to-normal is part of the DRP and is frequently omitted. Its absence is a finding.
• A stale BIA invalidates everything downstream — RTO/RPO, priority order and the DRP. Refresh on business change, not only on a calendar.
• Insurance is compensation, not continuity. It does not keep the business running.
• Media without chain of custody cannot be shown to be intact and untampered — vaulting needs documented custody and environmental controls.
• The auditor's evidence hierarchy: test results and observed tests > documented procedures > management assertions and job logs.

60-second recall

• BIA = foundation. Owned by the business; identifies critical processes, impact over time, dependencies; produces MTD, RTO, RPO, priority order.
• MTD is the constraint. RTO + WRT ≤ MTD. Violation ⇒ finding. RPO drives backup frequency.
• Metrics: RTO (restore time), RPO (data loss), WRT (verify + resume after restore), SDO (degraded service level in interim mode), MTO (max time in alternate mode), MTTR (repair), MTBF (reliability).
• Availability = MTBF / (MTBF + MTTR).
• Sites, cheap → expensive / slow → fast: cold (weeks) → warm (days) → hot (hours) → mirrored/active-active (near-zero). Plus mobile and reciprocal/mutual aid (low cost, low assurance). Cloud DR/DRaaS = pay-as-you-go, shared responsibility.
• Backups: full (1 set to restore), incremental (last full + all incrementals), differential (last full + latest differential), synthetic full, snapshot, replication, CDP (near-zero RPO).
• 3-2-1: 3 copies, 2 media types, 1 offsite. 3-2-1-1-0: +1 offline/immutable/air-gapped, 0 errors (verified by restore).
• Immutable/WORM + air-gapped copies = ransomware defence. Encrypt backups and manage the keys — lost key = lost backup.
• A backup is only a backup once it has been restored and verified. Job logs = weak evidence; dated restore test into non-production with integrity verification = strong evidence.
• BCP = business-wide, business-owned (people, facilities, suppliers, manual workarounds, communications, roles, declaration criteria, distribution, training). ISO 22301 = the BCM standard, PDCA, requires exercising.
• DRP = IT-owned subset of the BCP, derived from and consistent with it; run books, priority order per the BIA, vendor contacts, validation before return to service, and failback.
• Crisis management/emergency response = life safety first — the third, distinct layer.
• IT does not declare a disaster; the business does. The auditor neither writes the plan nor declares the disaster.
• Test ladder: read-through → structured walkthrough → tabletop → component → parallel (production unaffected) → full interruption (highest realism, needs executive approval).
• Auditor observes tests; the most common finding is "plan never tested"; maintenance is at least annually and after any significant change, test or real invocation; findings must be tracked to closure.