CAP (ABRET) common mistakes
CAP · Understand the traps and how to avoid them.
Treating the RMF as a linear waterfall: finishing all of 'Categorize' before touching 'Select', and refusing to loop back to earlier steps after a change, so answers describe a one-pass pipeline instead of iterative steps with feedback.
Study guides present the steps as a numbered list, so candidates memorize the order and read it as sequential project phases rather than a continuous cycle where assessment findings and changes push work back to earlier steps.
What to do instead
Practice describing the RMF as an ongoing cycle with explicit feedback paths. For any scenario question, ask 'what step produces this output, and what step consumes it?' and be ready to say which earlier step must be revisited when a control fails, a system changes, or a categorization changes.
Confusing the roles: assigning authorization decisions to the system owner or the assessor, or letting the security control assessor approve the system, and describing the authorizing official as someone who performs assessments.
Job titles in security overlap with common industry usage, and candidates map 'security manager' or 'auditor' onto whichever role feels closest instead of the specific accountability each role carries in the authorization process.
What to do instead
Build a small role table: who categorizes, who selects and documents controls, who implements, who assesses independently, who accepts risk and authorizes, who monitors continuously. Anchor each role to its single accountability and test yourself with 'who signs what' questions.
Treating the control baseline as a fixed checklist: assuming every control in the selected baseline must be implemented identically, and missing that tailoring, scoping, and documented rationale for not applying a control are expected and legitimate.
Baselines are published as numbered control lists, which look exhaustive and mandatory; candidates rarely internalize that selection is a documented decision process with justification for inclusions, exclusions, and compensating measures.
What to do instead
When a question mentions a control that does not fit the system, look for the answer that documents the tailoring decision and rationale rather than one that forces implementation or silently drops the control. Learn to distinguish 'not applicable with justification' from 'ignored'.
Confusing the system boundary with the authorization boundary, or drawing the boundary around the whole organization, so questions about scope, inherited controls, and interconnection get answered with the wrong set of components.
Both terms sound like 'the edge of the system', and candidates do not separate the technical and logical components under direct control from the set of components covered by a single authorization decision, including shared and inherited services.
What to do instead
For each scenario, list components, data flows, users, and external connections, then decide which are inside the authorization boundary and which are inherited or provided by another party. Practice identifying common controls, hybrid controls, and interconnections, and note who is accountable for each.
Answering implementation questions with policy language: choosing 'develop a policy' or 'provide training' when the scenario asks how a control is actually implemented, and never distinguishing policy, procedure, and mechanism.
Governance content dominates early study, and policy-sounding answers feel safe and comprehensive; candidates default to the most formal-sounding option rather than the one that describes an operating mechanism with evidence.
What to do instead
Classify each answer option as policy, procedure, or mechanism before choosing. When the question asks about implementation, prefer the option describing a concrete, operating capability with an owner and evidence of operation, and reserve policy answers for governance questions.
Treating assessment as a paperwork review: describing control assessment as checking that documents exist, instead of examining whether controls are implemented correctly, operating as intended, and producing the intended outcome.
Compliance habits from audit-style study encourage 'is there a document?' thinking, and candidates miss that control assessment examines design, implementation, and effectiveness, including interviews, observation, and testing, not just document collection.
What to do instead
For each control, prepare three questions: is it designed correctly, is it implemented, and is it producing the intended outcome? Practice choosing assessment methods (examine, interview, test) appropriate to each control type and justify why document review alone is insufficient.
Conflating continuous monitoring with periodic reassessment: describing continuous monitoring as an annual review or a scan, and missing that it is an ongoing strategy covering control effectiveness, changes, and risk posture, feeding authorization decisions.
The phrase 'continuous monitoring' invites a narrow reading as automated scanning, and candidates collapse it into scheduled audits because those are familiar compliance rhythms.
What to do instead
Frame continuous monitoring as a program with defined metrics, frequencies, data sources, and reporting to the authorizing official. Practice distinguishing automated technical feeds, manual review cycles, and event-driven triggers, and identify which one a given scenario is describing.
Assuming authorization is permanent: answering that a system stays authorized until the next scheduled review, and ignoring triggers such as significant change, new threats, incidents, or changes in risk tolerance that require reauthorization or a new decision.
Authorization feels like a one-time milestone with a date stamp, and candidates do not connect ongoing monitoring outputs to the possibility of a revised or revoked authorization.
What to do instead
Memorize the category of events that invalidate or require revisiting an authorization: significant changes to the system or environment, new or changed threats and vulnerabilities, incidents, and changes in organizational risk tolerance. In scenarios, ask 'does this event change the risk decision?' before answering.
Mixing up the compliance program lifecycle: describing compliance maintenance as a one-time project closeout, or treating the governance program as something created after controls are implemented, rather than a program that is established first and maintained continuously.
Exam outlines list domains in order, and candidates read that order as chronology, so governance and maintenance get placed at the end of the effort instead of framing and sustaining it.
What to do instead
Map each domain to when it operates: governance and risk framing set direction up front; scope, selection, and implementation follow; assessment, authorization, and maintenance run continuously afterward. Use that map to eliminate answers that place a step in the wrong phase.
Choosing the most restrictive or most expensive control as the 'best' answer, rather than the control proportionate to the identified risk, the system categorization, and the organization's stated risk tolerance.
Security training rewards 'more controls equals safer', and candidates equate maximum rigor with correct judgment, forgetting that risk management is about justified, proportionate decisions and documented acceptance of residual risk.
What to do instead
Before answering, identify the impact level and the specific risk being addressed, then pick the option that is justified by that risk and consistent with the organization's tolerance. Practice recognizing when accepting and documenting residual risk is the correct answer rather than adding controls.