CCRTS common mistakes
CCRTS · Understand the traps and how to avoid them.
When asked to set recovery objectives, the candidate picks a single RTO/RPO number for the whole system and applies it to every tier, then justifies it as 'best practice' rather than deriving it from business impact.
Candidates memorize that 'RTO is recovery time and RPO is data loss tolerance' but never practice translating a business process's maximum tolerable downtime into tiered, per-application objectives. The exam supplies a scenario with differing criticality across functions, and the candidate collapses it into one figure because that is the only shape they have rehearsed.
What to do instead
Before answering, list the business functions in the scenario and rank them by financial, regulatory, and safety impact over time. Assign each a distinct MTD, then derive RTO (with margin) and RPO per function. Practice writing a two-line justification for each tier that cites the impact driver, not a generic standard.
The candidate treats a successful restore of a single file or VM as proof the recovery plan works, and selects the option that says the plan is validated.
Candidates conflate 'backup job succeeded' and 'restore completed' with 'recovery capability demonstrated.' They underestimate the dependencies (identity, DNS, network, licensing, data consistency) that only surface in an integrated test, so they pick the cheapest-sounding validation option.
What to do instead
Distinguish three levels explicitly: backup integrity (can I read the data), component restore (can I bring up one system), and end-to-end recovery (can the business function run). For any question about proving recoverability, choose the option that exercises the full dependency chain in an isolated environment and measures against RTO/RPO, and reject single-asset restores as insufficient evidence.
When a scenario involves ransomware, the candidate's first recommended action is to restore from backup immediately, without addressing containment, scope determination, or whether the backups themselves are compromised.
Backup-and-restore is the most familiar resilience reflex, and candidates want to show they know the recovery path. They skip the ordering that the exam is testing: contain, assess scope and persistence, verify backup integrity, then recover in a prioritized sequence.
What to do instead
Adopt a fixed decision order for destructive incidents: isolate and contain, preserve evidence, determine scope and initial access vector, validate backup immutability and cleanliness, then recover in business-priority order with heightened monitoring. When an answer option jumps straight to restore, treat it as a distractor unless containment is already established in the stem.
The candidate selects 'air-gapped' or 'immutable' as a complete answer for backup protection, without checking retention window, credential separation, and whether the deletion path is also protected.
These are the headline buzzwords in ransomware resilience, so candidates stop at the label. They miss that immutability is only meaningful if the attacker cannot also delete or expire the snapshots, and if the retention period exceeds the attacker's typical dwell time before detonation.
What to do instead
For any backup-protection question, verify four things in the option: data cannot be altered or deleted within the retention window, the backup control plane uses separate credentials and network path from production, retention exceeds the assumed dwell time, and recovery has been tested from that copy. Reject options that name immutability without addressing the deletion and credential-separation paths.
The candidate answers incident-response questions by listing phases in order (prepare, identify, contain, eradicate, recover, lessons learned) but cannot map a described event to the correct phase or decide what action belongs next.
Phase lists are easy to memorize and appear in every study guide, so candidates rehearse the sequence instead of the transitions. Exam stems describe messy, overlapping situations, and the candidate applies the label that matches the vocabulary in the stem rather than the actual state of the incident.
What to do instead
Practice classifying short scenarios by asking 'what has already been established, and what decision is still open?' Eradication requires root cause identified; containment can precede root cause; recovery requires validation criteria. Drill the entry and exit conditions of each phase rather than the order, and expect the exam to place actions in the 'wrong but plausible' phase.
The candidate treats the disaster recovery plan and the business continuity plan as interchangeable, and picks options that put business-process continuity steps inside the technology recovery runbook.
The terms overlap in casual usage and many candidates have only seen one of the two documents. They default to the technology-centric answer because that is the domain vocabulary they are most fluent in, even when the question is about keeping a business function operating during an outage.
What to do instead
Fix the boundary in your head: BCP covers keeping business functions running (people, process, manual workarounds, alternate sites for staff); DRP covers restoring technology and data. For each question, identify whether the subject is a business function or an IT service, and choose the plan and owner that matches. Expect distractors that put communication and manual workaround steps under the DRP.
On third-party and cloud questions, the candidate accepts the provider's certification or shared-responsibility statement as evidence that resilience obligations are met, rather than requiring contractual RTO/RPO, tested failover, and exit provisions.
Candidates read 'ISO 27001 certified' or 'the provider is responsible for availability' and treat it as closure. They do not habitually separate the provider's responsibility from the customer's retained responsibility, so they miss that backup, identity, configuration, and data-level recovery often remain with the customer.
What to do instead
For every cloud or vendor option, ask three questions: what does the contract commit to in measurable RTO/RPO and remedies, what has been independently tested or evidenced, and what is the exit/portability path. Map the shared-responsibility split explicitly for the service model (IaaS/PaaS/SaaS) before choosing. Reject options whose only assurance is a certificate or a marketing availability figure.
The candidate recommends a full-scale live failover exercise as the maturity answer in every testing question, ignoring cost, risk, and the progression of test types.
'Test it for real' sounds rigorous and candidates associate it with senior-level judgment. They overlook that the exam often tests selecting the appropriate exercise type for the stated maturity, budget, or risk tolerance, and that an untested organization attempting a live failover is itself a finding.
What to do instead
Learn the exercise ladder and its purposes: plan walkthrough/tabletop, component and backup-restore test, partial failover, full failover, and simulation with injected failures. Match the recommendation to the organization's maturity and constraints stated in the stem, and justify progression. Choose full-scale only when the stem shows prior successful lower-level tests and a business case for the disruption risk.
The candidate answers post-incident review questions by focusing on the technical root cause and remediation ticket, and omits the governance outputs: objective evidence preservation, timeline reconstruction, control-gap analysis, and tracked corrective actions with owners.
Engineers gravitate to the fix, and candidates carry that bias into the exam. They underweight the review's purpose as an assurance and learning mechanism, so they miss options about independent review, metrics, and feeding findings back into risk assessment and plan updates.
What to do instead
For post-incident questions, check for four outputs: a validated timeline built from logs and forensic evidence, a root-cause and contributing-factor analysis (not just the proximate trigger), corrective actions with owners and due dates tracked to closure, and updates fed back into the BIA, risk register, and plans. Prefer options that include governance and follow-through over options that only name a technical fix.
The candidate treats resilience governance as document ownership-naming a plan owner and an annual review-instead of defining risk appetite, accountability at executive level, and measurable reporting to the board.
Governance questions feel abstract, so candidates reach for concrete-sounding artifacts (a policy, an owner, an annual review) and stop there. They miss that the exam is testing whether accountability, tolerance thresholds, and reporting metrics are defined and enforced, which is what distinguishes governance from documentation.
What to do instead
For governance options, test for four elements: a stated risk appetite or tolerance with thresholds, named executive accountability (not just a document owner), metrics reported on a defined cadence to leadership or board, and a mechanism that escalates and enforces when thresholds are breached. Choose options containing measurable reporting and enforcement over options that only assign ownership or schedule a review.