CAP1 common mistakes
CAP1 · Understand the traps and how to avoid them.
When asked who accepts residual risk, the candidate names the system owner or ISSO instead of the authorizing official.
The roles sound interchangeable in everyday IT language, and candidates map 'owner' to 'the person in charge' rather than to the RMF accountability model.
What to do instead
Memorize the division of duty: the authorizing official accepts residual risk and grants authorization; the system owner implements and operates; the ISSO supports and monitors. Practice mapping each RMF activity to its accountable role.
Answers RMF sequencing questions by placing assessment before control implementation, or authorization before assessment, instead of following the phase dependencies.
Candidates memorize the phase names as a list but not the outputs and entry/exit conditions that force one phase to precede another.
What to do instead
Build a phase-to-output table: categorize produces the security category, select produces the baseline and tailoring, implement produces the SSP and evidence, assess produces the assessment report, authorize produces the authorization decision, monitor produces ongoing status. Test yourself on which artifact must exist before the next phase can start.
Draws the authorization boundary around only the application server and leaves out the database tier, supporting infrastructure, or interconnected systems that process, store, or transmit the same data.
Candidates equate 'the system' with the user-facing application and overlook data flows and operational control.
What to do instead
Derive the boundary from data flows and management control, not from server inventory. Explicitly list every component, connection, and inherited service that handles in-scope data, and justify exclusions.
Selects the high baseline for every system 'to be safe' instead of selecting a baseline from the FIPS 199 categorization and then tailoring it.
Risk aversion plus a misunderstanding that a higher baseline is always more defensible; candidates skip the categorization-to-baseline linkage.
What to do instead
Categorize confidentiality, integrity, and availability first, use the resulting high-water mark to choose the baseline, then tailor with documented rationale. If you choose above baseline, state the justification rather than defaulting to it.
Writes 'inherited' next to a control in the SSP without naming the providing system, the specific control, the evidence, and the agreement that makes the inheritance valid.
Candidates assume inheritance is automatic once a common control exists somewhere in the organization.
What to do instead
For every inherited control, document the provider, the control identifier, the evidence source, and the formal agreement. Validate that the provider's assessment actually covers the control at the needed strength.
Describes the security assessor as the person who decides whether the system may operate.
Assessment findings feel like a verdict, so candidates conflate the assessor's report with the authorization decision.
What to do instead
Separate the two outputs clearly: the assessor produces findings and an assessment report; the authorizing official weighs those findings against risk tolerance and issues the authorization decision.
States that an authorization to operate remains valid indefinitely unless a major change occurs.
Candidates treat authorization as a one-time milestone rather than a time-bound risk decision with conditions.
What to do instead
Describe authorization as having a defined period, stated conditions, and explicit triggers for reauthorization. Name examples of triggers such as significant change, new interconnection, or adverse monitoring results.
Equates continuous monitoring with the annual security assessment and omits ongoing control monitoring, metrics, and status reporting.
The word 'monitoring' gets collapsed into 'the recurring assessment,' so candidates describe a calendar event instead of a program.
What to do instead
Define continuous monitoring as a strategy covering what is monitored, how often, by whom, which metrics are reported, and how results feed the POA&M and authorization decision. Keep assessment as one input, not the whole program.
Closes a POA&M item as soon as the team reports the fix is complete, without independent evidence or validation.
Candidates treat the POA&M as a task list rather than a risk-tracking record with closure criteria.
What to do instead
Require closure to include the remediation evidence, the validation method, the validator, and the date. Distinguish 'remediated' from 'accepted' and keep risk acceptance documented when remediation is not feasible.
Treats privacy as outside the RMF and fails to integrate privacy impact analysis and privacy controls into categorization and control selection.
Candidates mentally separate security and privacy into different offices and different processes.
What to do instead
Integrate privacy throughout: address privacy in categorization, select privacy controls alongside security controls, and show how privacy risk is assessed, authorized, and monitored with the same rigor as security risk.