StateRAMP AI Compliance Checklist: 10 Tests for the Revision 5 Package
This StateRAMP AI compliance checklist turns the current GovRAMP Revision 5 package into 10 gradable actions for AI-enabled cloud services. Each item names an owner, required evidence, and a pass condition covering the assessed boundary, AI disclosures, identity, model routes, prompt protection, audit records, continuous monitoring, incident drills, and responsibility gaps.

A reviewer opens the Revision 5 System Security Plan, traces an AI data-flow arrow to a model endpoint, and asks for the control owner and evidence. This StateRAMP AI compliance checklist prepares that exact test. The program now publishes as GovRAMP, and its Security Program is built on NIST SP 800-53 Revision 5. AI functionality adds model integrations, prompt data, response handling, and policy decisions to the assessed cloud service.
I have ordered these actions by dependency. Logging belongs after identity, routes, and data classification because a beautifully retained record with a shared service account in the identity field proves very little.
1. Fix the AI verification boundary
Owner: system owner with the security architect.
Evidence: updated system description, boundary diagram, network diagram, data-flow diagram, ports and protocols worksheet, interconnections worksheet, and inventory.
The current GovRAMP SSP asks providers to describe every assessed service and feature inside the verification boundary. Draw the authenticated application, HTTP policy point, model endpoint, audit store, and each external service. Label the direction, protocol, authentication method, encryption, and data class on every AI flow. Mark external model APIs as interconnections and name their hosting environment.
Pass when: a reviewer can choose any model route from runtime records and locate it in the diagram, inventory, and interconnections worksheet with one consistent owner and data type.
2. Complete the July 2026 AI disclosure
Owner: product owner with legal, privacy, and security review.
Evidence: one completed GovRAMP AI Self-Reporting Addendum for each AI-enabled product or service.
The addendum asks about automated decisions, external models and APIs, customer-data processing, training and tuning, sensitive-data protection, activation, administrative disablement, user notice, audit visibility, version control, rollback, known risks, and limitations. GovRAMP published it on 24 July 2026 as an initial due-diligence touchpoint.
Pass when: every answer matches the SSP and current product configuration, each external model appears in the interconnections worksheet, and supporting policies are linked. A blank field has an accountable owner and remediation date.
3. Carry the originating identity into the AI request
Owner: application engineering with IAM.
Evidence: identity assertion schema, validation configuration, role mapping, and a joined authentication-to-model-call sample.
NIST SP 800-53 Revision 5 uses IA-2 for user identification and authentication, AC-3 for access enforcement, and AC-6 for least privilege. The outbound LLM call should preserve the person or named agent that originated it, even when the application authenticates to the model with a service credential.
Pass when: a sampled production request resolves to the originating principal, relay application, assigned role, requested model route, policy decision, and timestamp. Shared credentials may remain at the provider connection, while the decision evidence still names the originator.
4. Inventory every model route and integration
Owner: cloud security with AI platform engineering.
Evidence: observed destination inventory reconciled against the CM-8 inventory and SSP interconnections.
The GovRAMP Revision 5 controls matrix includes CM-8 for system component inventory. For an AI-enabled service, inventory has to include hosted models, external model APIs, embedding services, retrieval components, and agents inside the assessed service. Runtime observation finds the endpoint a developer added after the last architecture review.
Pass when: a dated reconciliation shows every observed model hostname and route in the approved inventory. Each difference has an approval, removal, or investigation record. The evidence sheet should look like a ledger with timestamps and owners, rather than a slide containing provider logos.
5. Classify prompt and response data on the HTTP path
Owner: data protection lead with application security.
Evidence: data-classification rules, synthetic tests, request findings, response findings, and handling outcomes.
The July 2026 addendum separates public, internal, confidential, and regulated data and asks providers to describe detection, protection, and redaction mechanisms. Apply that scheme to assembled prompts and model responses. A source document classification can miss sensitive fragments inserted by retrieval, tool output, or user text after the document was labeled.
Pass when: staged requests containing approved synthetic markers create repeatable classification findings and the expected permit, redact, or deny action. The response-side test joins to the request and records its own disposition.
6. Turn written AI rules into access enforcement
Owner: CISO policy owner with AI platform engineering.
Evidence: versioned policy, role-to-route mapping, test cases, and per-request decisions.
AC-3 requires access enforcement and AC-6 covers least privilege. Translate the AI usage policy into rules that evaluate the originating identity, role, data class, requested route, and operation before the HTTP request reaches the model. Document the behavior when identity, classification, or policy state is missing.
Pass when: an approved role reaches its permitted route, a disallowed role receives a denial, and a regulated-data test follows the documented handling rule. Every record names the exact policy version. My opinion is that a policy document earns its place in the SSP only after one staged request proves it can stop traffic.
7. Generate protected per-decision audit records
Owner: security engineering with the audit-log custodian.
Evidence: AU-2 event selection, AU-3 field definition, AU-12 generation configuration, AU-9 access controls, retention settings, and integrity test.
The record should contain the request identifier, originating principal, relay, model route, policy version, prompt classification, decision, UTC timestamp, and linked response disposition. Store protected content or a documented fingerprint and controlled retrieval path according to the approved data-handling design.
Pass when: the retained store rejects alteration or deletion attempts by the calling application, a staged field modification fails the integrity check, and the response path blocks model output until the required audit commit completes.
8. Review AI events through continuous monitoring
Owner: continuous-monitoring lead with the SOC.
Evidence: saved queries, monthly review record, findings, remediation tickets, and updated monitoring matrix.
CA-7 covers continuous monitoring and AU-6 covers audit review, analysis, and reporting. GovRAMP's document library publishes the Continuous Monitoring Guide, matrix completion guide, and reporting template beside the Revision 5 packages. Add AI-specific queries for unapproved endpoints, denied regulated-data requests, missing identity, policy changes, and abnormal model routes.
Pass when: the latest reporting period includes executed queries, reviewer sign-off, findings, and dispositions. A dashboard with no recorded review date fails this completion test.
9. Run an AI incident reconstruction drill
Owner: incident-response lead with application and legal representatives.
Evidence: scenario, selected UTC window, retrieved events, impact analysis, containment action, communications decision, and lessons assigned.
Use IR-4 for incident handling and IR-5 for incident monitoring. Pick a staged scenario in which an authenticated user sends regulated data to an unapproved model route. Reconstruct the originating principal, prompt classification, destination, policy state, response, and any downstream action from retained evidence.
Pass when: the team produces a scoped event set, applies a rule change to the next relevant request, documents the communication decision, and opens remediation for any missing field. Endpoint forensics and account compromise investigation remain separate evidence streams.
10. Close the control responsibility gaps
Owner: system owner with compliance and each control provider.
Evidence: completed Control Responsibility Matrix, SSP narratives, inherited-control references, customer guidance, gaps, and Plan of Action and Milestones entries.
The GovRAMP SSP allocates inherited controls, provider services, and customer responsibilities. AI makes that boundary visible. The model provider handles its service. Application IAM establishes the principal. The HTTP AI control point can enforce a request policy. The customer owns workforce rules and configuration choices.
Pass when: every mapped control names a provider, implementation status, implementation narrative, test, evidence artifact, and open gap. The July 2026 Security Assessment Framework.pdf) package should lead a reviewer to the same answer as the responsibility matrix.
Completion record
Use one row per action and preserve the reviewer decision:
The result field should use pass, partial, or fail. Partial means the evidence proves only part of the control objective, with the uncovered portion named. That small discipline prevents an AI gateway, an IAM platform, or a model provider from being presented as the owner of an entire Revision 5 control family.
DeepInspect
DeepInspect contributes evidence for items 3 through 9 at the authenticated HTTP AI boundary. It receives application-supplied identity context, evaluates role, prompt classification, model route, and policy version, applies the permit, redact, or deny decision before the request reaches the LLM, inspects the response, and creates a signed, tamper-evident per-decision record.
Its coverage is deliberately narrower than the GovRAMP package. The system owner still defines the verification boundary, completes the July 2026 addendum, assigns inherited and customer responsibilities, and runs the broader Revision 5 assessment and continuous-monitoring program. Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does StateRAMP still use that name in current documents?
Current official materials publish under GovRAMP, while StateRAMP remains common in procurement language and search terms. Use the GovRAMP document library for current templates, framework text, Revision 5 packages, continuous-monitoring material, and the July 2026 AI addendum.
- Does the AI Self-Reporting Addendum prove compliance?
The addendum supports initial government due diligence. GovRAMP states that it is outside the role of a full procurement or compliance tool. Providers still need SSP narratives, control ownership, independent assessment where the selected status requires it, tested artifacts, and continuous-monitoring evidence.
- Which checklist item should happen first?
Fix the verification boundary first. Identity, route inventory, classification, policy tests, and audit records all depend on knowing which AI features, endpoints, components, and connections sit inside the assessed service. Boundary drift turns later evidence into a record of an undefined system.
- Can a provider use model-vendor logs for item 7?
Provider logs can contribute destination and inference events. The service provider still needs evidence that connects the originating principal, application role, prompt classification, local policy version, and enforcement decision to that provider event. The correlation identifier and custody model belong in the SSP narrative.
- Which items can an AI gateway cover?
A gateway can contribute to identity-bound request enforcement, model-route inventory, prompt and response classification, policy decisions, protected audit records, monitoring queries, and incident reconstruction for HTTP traffic routed through it. Boundary documents, IAM assurance, organizational policy approval, vendor contracts, vulnerability management, model validation, training, and incident communications keep their existing owners.