CAP (The American College Credentials) common mistakes
CAP · Understand the traps and how to avoid them.
Recites the RMF steps in the wrong order - for example placing Assessment before Implementation, or Treating 'Select' as the first step - and then picks answer choices that depend on that broken sequence.
Candidates memorize an acronym list rather than the dependency chain, so they cannot tell which activity must logically precede another when a scenario describes a partially completed lifecycle.
What to do instead
Lock in the chain and the artifact produced at each link: Prepare (organization-level readiness, roles, overlays) → Categorize (security categorization from information types) → Select (baseline plus tailoring decisions) → Implement (controls actually in place, documented in the SSP) → Assess (assessment plan, then assessment report) → Authorize (authorization package, decision, plan of action and milestones) → Monitor (ongoing assessment, ongoing authorization). When a question asks 'what happens next', name the artifact that must exist before the next step can start.
Assigns duties to the wrong role - says the authorizing official writes the SSP, the security control assessor authorizes the system, or the system owner independently accepts risk on behalf of the organization.
The role names sound interchangeable and all appear in the same lifecycle narrative, so candidates map them by intuition instead of by accountability.
What to do instead
Memorize roles by the verb they own. Authorizing official: accepts residual risk and signs the authorization decision - never performs assessments or authors plans. System owner: accountable for the system, develops and maintains the SSP, ensures controls are implemented and monitored. Information system security officer: day-to-day operation, maintains artifacts, supports assessment. Security control assessor: independent assessor who produces the assessment report. Senior agency official for privacy and the CISO own organization-wide program responsibilities. If an answer choice has the AO 'assessing' or 'implementing' anything, eliminate it.
Downgrades the system categorization - rates the system Moderate because most of its data is Moderate, even though one information type has a High confidentiality impact or one dependency has a High availability impact.
Candidates reason statistically (majority of data, average sensitivity) instead of using the high-water-mark rule, and question stems often bury the single High-impact information type in a list of routine data types.
What to do instead
Apply the rule mechanically: for each security objective, take the highest impact of any information type handled by the system; then the system's overall categorization is the highest of the three objectives. There is no averaging, no majority vote, and no downgrade without documented rationale and senior approval. Read the information-type list for the single outlier before choosing an answer.
Jumps straight from a data description to an impact level without defining the authorization boundary first, then selects a control baseline for a boundary that is too small or too large.
Boundary definition feels like administrative paperwork, so candidates skip it and answer the categorization question with only the sensitivity of the primary dataset in mind.
What to do instead
Establish the order: define the authorization boundary (components, interconnections, users, externally provided services) → inventory the information types inside that boundary → assign impact per objective → categorize. Anything crossing the boundary (interconnections, common controls inherited from a provider) must be explicitly named, because it changes both the categorization and which controls are system-specific versus inherited.
Treats the published Low/Moderate/High baseline as an immutable checklist - either asserting every baseline control must be applied exactly as published, or adding and removing controls without recording why.
The word 'baseline' suggests a fixed legal minimum, and candidates conflate baselining with tailoring, scoping, and overlays, which are separate documented activities.
What to do instead
The baseline is a starting point. Scoping determines which controls are applicable to the system; tailoring includes assigning organization-defined parameter values, adding compensating controls when a control cannot be met as written, and supplementing the baseline for special requirements; overlays provide community-specific adjustments. Every one of these decisions, and its rationale, is documented and approved - an undocumented deviation is the failure, not the deviation itself.
Marks a control as implemented in the SSP on the strength of a team's verbal assurance, or claims inherited/common controls without any evidence from the control provider, and then treats 'documented' as equivalent to 'implemented'.
Implementation reads like a documentation step, and inherited controls feel free because someone else owns them.
What to do instead
Implementation means the control is actually in place and operating, with the responsible role and implementation status recorded in the SSP. For common controls, obtain documented evidence from the provider (provider SSP, service-level agreement, assessment results, or a signed statement of applicability) and record the control as inherited or hybrid in the system SSP. An inherited control with no provider evidence is an untested assumption, not an implemented control.
Selects the wrong assessment method - answers 'test' when the question is whether a policy exists, or accepts a single interview as proof that a technical control is operating effectively.
Examine, interview, and test sound like synonyms in ordinary English, and the stem usually does not use the method names explicitly.
What to do instead
Bind method to objective: examine for documents, records, and configuration artifacts; interview for personnel understanding and process description; test for exercising the mechanism and observing actual behavior. Effectiveness conclusions generally require more than one method, and evidence must be dated, attributable, and reproducible. Ask yourself what the assessor must physically observe before choosing.
Conflates the assessment plan with the assessment report, or assumes any control that fails assessment blocks authorization and must be fully remediated first.
Candidates model the exam as a pass/fail gate, and both the plan and the report are 'assessment documents' produced around the same time.
What to do instead
The assessment plan defines scope, methods, and schedule before fieldwork; the assessment report records findings, evidence, and the assessor's determination afterwards. Open findings become plan-of-action-and-milestones entries with owners, milestones, and target dates. A failed control does not automatically block authorization; it becomes residual risk that the authorizing official documents and accepts or rejects - which is a separate, later decision.
Assumes the authorization decision must be made by the security team, can be informally delegated to the ISSO, or must be withheld until zero findings remain open.
Candidates blur certification (technical assessment of controls) with authorization (management's risk acceptance), and the everyday meaning of 'authorize' implies a technical green light.
What to do instead
Certification is the assessment of controls and the evidence supporting it; authorization is a senior official's risk-based decision to accept operation of the system, documented in the authorization package and signed by an official with the authority to commit resources and accept risk. It can only be delegated in writing under agency policy to an official of comparable seniority. Authorizing with open items and an accepted plan of action and milestones is a normal, documented outcome; so are denial, interim authorization to test, and revocation of an existing authorization.
Describes continuous monitoring as an annual reauthorization event or as 'running a vulnerability scanner', and omits change management, plan-of-action-and-milestones tracking, and ongoing assessment of controls from the monitoring strategy.
Continuous monitoring sounds like periodic reporting, and candidates collapse it into the tools they associate with operations rather than the strategy that governs them.
What to do instead
Continuous monitoring is an ongoing program: an information security continuous monitoring strategy specifying what is monitored, how, and how often; ongoing assessment of a subset of controls at defined frequencies; ongoing authorization decisions informed by that data; plan-of-action-and-milestones updates and closure; and change-driven review of the authorization package when the system, its boundary, or its environment changes. At minimum the authorization package is reviewed at least annually, and significant changes trigger re-categorization, re-assessment, or a new authorization decision.