CAP (ABRET) cheat sheet

Governance triad: directives (policy, standards) set direction, controls enforce it, and monitoring/audit provides assurance that enforcement works; a program missing any leg cannot demonstrate accountability.

Risk = likelihood × impact. Likelihood and impact are scored on defined ordinal scales (commonly 1-5); inherent risk is scored before controls, residual risk after controls, and risk acceptance must be documented by an accountable owner.

Risk treatment options are limited to four: mitigate, transfer, avoid, and accept. 'Accept' is a valid outcome only when a named authority signs off with a rationale and expiry date.

NIST SP 800-39 provides the three-tier risk model: Tier 1 organization, Tier 2 mission/business process, Tier 3 information system. Controls are selected and assessed at Tier 3 but governed by Tier 1 risk tolerance.

A compliance program needs a documented scope, control catalog, assessment cadence, exception process, and remediation tracking; the CAP exam treats the program itself as an auditable system with its own controls.

Segregation of duties: the person who implements a control should not be the sole person who assesses it. Independent assessors, or at minimum a second reviewer, preserve objectivity.

Key risk indicators (KRIs) are leading metrics (e.g., open critical findings age, patch latency); key performance indicators (KPIs) are trailing metrics. Report both to leadership on a fixed cadence.

Privacy risk is assessed separately from security risk: it weighs likelihood and severity of harm to individuals (not just the organization), including re-identification, secondary use, and loss of autonomy.

The authorization boundary defines what is inside the system: hardware, software, firmware, and the data flows crossing the boundary. Anything outside is an interconnection and must be documented as such.

A system boundary must be documented in a system security plan (SSP) with a boundary diagram, data-flow diagram, inventory, and list of external interfaces and their owners.

Scope decisions are risk decisions: excluding a component requires a documented rationale and compensating controls, not silence. Undocumented scope creep is a common audit finding.

FIPS 199 categorization drives scope rigor: confidentiality, integrity, and availability are each rated low/moderate/high, and the high-water mark sets the system's overall impact level.

Data scoping: classify data by sensitivity (e.g., PII, PHI, CUI, public) and map where it is stored, processed, and transmitted; the scope must include data at rest, in transit, and in backups or archives.

Inherited controls come from a common provider (cloud, shared service, enterprise platform). The system inherits the control but retains responsibility for documenting and verifying the inheritance.

Interconnections require an interconnection security agreement (ISA) or MOU that states the controls each party applies and the data exchanged; the boundary is not a wall but a contract.

Scope must be revalidated when the system changes materially: new interfaces, new data types, new hosting model, or major version changes trigger a scope review.

Framework selection criteria: regulatory fit, sector adoption, control granularity, assessment tooling availability, and mapping to existing investments. Document why the chosen framework was selected over alternatives.

NIST Cybersecurity Framework (CSF) organizes outcomes into Identify, Protect, Detect, Respond, Recover, and Govern; it is outcome-oriented and is often used as the program-level umbrella over a control catalog like NIST SP 800-53.

NIST SP 800-53 provides the control catalog (families AC, AU, AT, CM, CP, IA, IR, MA, MP, PS, PE, PL, PM, RA, CA, SC, SI, SA, SR, and privacy PT). SP 800-53B provides baseline control sets by impact level.

Privacy control selection draws on NIST Privacy Framework and the PT family in SP 800-53; privacy controls address notice, consent, data minimization, quality, and monitoring, and are selected alongside security controls, not after them.

Tailoring is expected, not optional: scoping (remove controls not applicable), parameterization (set organization-defined values), and supplementation (add controls for unique risk) must each be documented with justification.

Control selection must trace back to risk assessment results and legal/regulatory obligations; a control with no traced risk or requirement is a candidate for removal, and a risk with no control is a gap.

Approval of the control baseline is a formal governance action: the authorizing official or equivalent approves the baseline, tailoring decisions, and any accepted residual risk before implementation begins.

Mapping between frameworks (e.g., ISO/IEC 27001 Annex A to SP 800-53, or PCI DSS to 800-53) enables reuse but mappings are rarely one-to-one; document partial and many-to-many relationships rather than assuming equivalence.

Implementation statements in an SSP describe how each control is met, not just that it is met: who implements, what mechanism, where in the architecture, and what evidence exists.

Control inheritance must be explicit: 'inherited from provider X, verified by Y' versus 'implemented locally'. Hybrid controls have both a provider and a local component and need both described.

Technical controls (encryption, MFA, logging) are enforced by systems; administrative controls (policy, training, background checks) rely on people and process; physical controls (locks, badges) protect facilities. A control family usually mixes all three.

Configuration baselines (e.g., CIS Benchmarks, DISA STIGs) operationalize CM controls; deviations require documented exceptions with risk acceptance and a remediation date.

Privacy implementation includes data minimization at collection, consent capture and withdrawal, retention limits enforced by automated deletion, and de-identification or pseudonymization where full identifiers are not needed.

Change management is the implementation safety net: every material change is assessed for control impact, tested, approved, and recorded before deployment; emergency changes get retroactive review.

Logging and monitoring must be implemented to support assessment: if you cannot produce evidence (logs, tickets, screenshots, config exports), the control is effectively not implemented for audit purposes.

Compensating controls are used when the primary control is not feasible; they must provide equivalent protection, be documented with rationale, and be reassessed at the same cadence as the primary control.

Assessment methods are examine, interview, and test. Examine reviews documents and configurations; interview queries people; test exercises the control. A robust assessment uses more than one method per control.

Assessment depth increases with assurance need: a self-assessment is cheapest and least independent; independent third-party assessment is most costly and most defensible for high-impact systems.

Sampling: when a control operates repeatedly (e.g., access reviews), assess a sample sized to the population and frequency; a single instance proves existence, not consistent operation.

Assessment evidence must be dated, attributable, and tied to the specific control and time period; evidence from outside the assessment window does not demonstrate current operation.

Findings are classified by severity (critical/high/moderate/low) using defined criteria that weigh exploitability, data sensitivity, and control criticality; severity drives remediation timelines.

A finding is not the same as a risk: a finding is a control deficiency; the risk is the potential impact if it is exploited or persists. Report both, with the risk owner named.

The assessment report should state scope, methods, sampling approach, results per control, findings with evidence, and an overall conclusion (satisfied, satisfied with exceptions, not satisfied).

Continuous monitoring (per NIST SP 800-137) replaces point-in-time assurance with ongoing metrics, automated feeds, and periodic reassessment; it is a control itself, not a substitute for independent review.

Compliance determination combines control assessment results with the authorization decision: the authorizing official accepts residual risk based on the assessment, and that acceptance is the compliance record.

A system security plan (SSP) is the central compliance artifact: boundary, control implementation statements, inherited controls, and a plan of action and milestones (POA&M) for open items.

POA&M entries need a weakness description, severity, responsible owner, resources, milestones, and a completion date; an open POA&M without a date is an audit exception in itself.

Compliance status categories are typically compliant, compliant with exceptions (compensating control or accepted risk), and non-compliant; each exception must reference an approved risk acceptance.

Evidence retention: keep assessment artifacts for the period the framework or regulator requires (commonly 1-3 years, longer for regulated data); retention periods must be documented in the compliance program.

Attestation versus certification: an attestation is a management assertion (often with an independent opinion, e.g., SOC 2); a certification is a formal third-party credential (e.g., ISO/IEC 27001). They carry different evidentiary weight.

Reciprocity and inheritance: if a shared provider is compliant, the system may inherit that status only where the control is genuinely inherited and the provider's assessment covers the same control and period.

Continuous compliance requires automated evidence collection where possible; manual evidence gathering is the most common cause of drift between assessments.

Compliance is a lifecycle, not an event: monitor, assess, remediate, re-authorize. The re-authorization trigger is a significant change or a defined interval (commonly annual for high-impact systems).

Change-driven triggers for reassessment: new data types, new interconnections, new hosting/cloud model, major architecture change, or a breach that affects control effectiveness.

Remediation SLAs should be tiered by severity (e.g., critical within 30 days, high within 90); missed SLAs escalate to the risk owner, not silently roll forward.

Exception management: every exception has an owner, justification, compensating control, expiry, and review date; expired exceptions automatically become findings.

Vulnerability and patch management feed maintenance: scan cadence, patch windows, and remediation tracking are the operational heartbeat of maintained compliance.

Training and awareness must be refreshed on a defined cadence and tracked by completion; lapsed training is a common administrative control failure in audits.

Metrics for maintenance: mean time to remediate, percentage of controls with current evidence, open exceptions aged over threshold, and POA&M closure rate. Trend them over time, not as snapshots.

Lessons learned after incidents and assessments feed back into control selection and tailoring, closing the loop between domains.