CAP (ABRET): The Assessment With 265 Not-Applicable Controls

The assessment is not reliable enough to support an authorization. Three defects compound:

• Blanket inheritance: 265 of 320 controls marked Not Applicable based on an undocumented claim is implausible. Inherited controls still require evidence of design and operation from the provider, and the system owner must document the inheritance in the SSP.
• Contradicted AC-2 result: The shared-account admission is material. A sample of 10 with 3 shared accounts means the test result is wrong and the underlying control may be failing. Shared accounts defeat individual accountability and least privilege.
• Independence: The team lead's prior employment with the integrator is a conflict that should have been managed before fieldwork, not merely disclosed on a form.

The AO should not grant an authorization to operate on this record. Defensible options are denial, or a short-term interim authorization with constrained functionality and a re-assessment condition. But even an interim authorization needs a credible assessment of the highest-risk controls. I would require an independent re-assessment of AC-2 and the inheritance claims, a new sampling plan with a documented rationale, and a conflict-of-interest review of the team. The 45-day CJIS deadline is a scheduling problem, not a reason to sign. The AO should notify the audit authority of the status and the remediation plan rather than present the current report as evidence of compliance.

For AC-2, re-test the entire account population rather than a convenience sample. Identify every shared and generic account, disable or convert them to named accounts, and document exceptions with an owner and business justification. Review privileged and dormant accounts. Verify that account creation, modification, and termination are authorized and logged. The assessor should select the sample independently from the account inventory, observe the provisioning workflow, and test termination for recent leavers. Evidence should include the inventory, ticketing records, and a walkthrough. If shared accounts remain, AC-2 is Other than Satisfied, and the risk must be described in the security assessment report.

For the 265 N/A controls, require a control-by-control inheritance justification mapped to the state data center's common control documentation. For each claimed inherited control, obtain the provider's current independent attestation, the specific control description, the customer responsibility matrix, and the right to assess. Where the provider cannot evidence the control, reclassify it as Not Satisfied or Partially Satisfied and assess it at the system level. I would not accept “inherited” without a named provider, a control identifier, and an evidence citation. This will likely move a substantial number of controls back into scope and change the assessment cost and timeline. That is the correct outcome: an inaccurate N/A is worse than an honest gap.

Conditions should be tied to the weaknesses that made the authorization conditional: account management, inheritance evidence, and assessment independence. I would define indicators with thresholds and owners:

• Any reappearance of shared accounts in a quarterly reconciliation.
• Failure to complete the AC-2 remediation milestone by its date.
• Loss or expiration of a provider attestation supporting an inherited control.
• A material change to the data center's common controls.
• Any incident involving unauthorized account use or evidence tampering.

I would also monitor standard continuous-monitoring inputs: vulnerability scan results, POA&M aging, configuration drift, and log review findings. These should be weighted toward the conditional items rather than treated as a generic dashboard.

The trigger should be explicit. A missed milestone, a failed re-test, or a significant change such as a new cloud service, new data type, or new interconnection requires reassessment of the affected controls and an updated authorization decision. Two consecutive missed milestones, or confirmed shared-account use in a privileged context, should cause the AO to suspend the affected functionality, not merely note it. The ISSO should report monthly to the AO, and each report should state residual risk in the same terms used in the original authorization. Continuous monitoring is the evidence stream that lets the AO decide whether the original risk acceptance is still valid.