ATO Readiness Checklist

On this page

This checklist helps deploying agencies prepare for an Authority to Operate (ATO) assessment. Each section covers a category of requirements that must be satisfied before submitting a System Security Plan (SSP) to the authorizing official.

CRAIG tracks NIST SP 800-53 control implementation status via GET /v1/security/nist. Use this endpoint (or craig security nist list) to generate a baseline control assessment report.

1. Infrastructure Prerequisites

These items must be in place before CRAIG services can operate in a production environment.

  • TLS termination configured for all public-facing endpoints (reverse proxy or load balancer with valid certificates)

  • DNS records configured for all CRAIG services and Keycloak

  • Keycloak deployed and configured with the agency’s identity provider (SAML or OIDC federation)

  • PostgreSQL databases provisioned for each service (craig_rules, craig_cases, craig_placement, craig_exchange, craig_financial, craig_reporting, craig_security, craig_composition; craig_intake is pre-created but stays empty — the intake edge is stateless per ADR-017)

  • RabbitMQ cluster deployed with TLS and access control

  • S3-compatible object storage provisioned (e.g., AWS S3, MinIO, Garage) with encryption at rest

  • Container runtime environment configured (Kubernetes, Docker Swarm, or equivalent)

  • Network segmentation: backend services not directly accessible from the internet (BFF pattern enforced)

  • Log aggregation infrastructure configured (syslog, ELK, or cloud-native logging)

2. Security Configuration

These CRAIG-specific settings must be configured for production security.

  • CRAIG_WEB__SESSION_SECRET set from your secret store (≥64 bytes, openssl rand -hex 32); service refuses to start otherwise (ADR-013)

  • CRAIG_WEB__SESSION_MAX_AGE_SECS reviewed against agency idle-timeout policy (default: 1800 s / 30 min)

  • SESSION_SECURE=true — enforces Secure flag on session cookies

  • CRAIG_WEB__CORS_ORIGINS set to specific production origin(s) — not wildcard (*)

  • CRAIG_INTAKE__PUBLIC_RATE_LIMIT set to an appropriate per-hour value for expected intake volume (default 5/hour is deliberately conservative for production)

  • CRAIG_INTAKECAPTCHA_SECRET set to a valid Cloudflare Turnstile secret (or literal disabled only for internal/dev environments); CRAIG_INTAKECAPTCHA_SITE_KEY set on the client/template side

  • Keycloak craig-ui client redirect URIs restricted to production domain only

  • Keycloak craig-api client ROPC grant disabled (or restricted to service accounts) in production

  • Keycloak password policy configured: minimum 12 characters, complexity requirements, password history

  • Keycloak brute-force protection enabled: account lockout after 5 failed attempts

  • Keycloak session timeouts configured: idle timeout (15 min), max session (8 hr)

  • API key rotation policy established for partner intake integrations

3. Compliance Documentation

These documents and assessments must be completed.

  • NIST SP 800-53 control assessment completed using /v1/security/nist — all controls reviewed and status updated

  • NIST architecture mapping reviewed (see NIST Architecture Mapping) and agency-specific controls documented

  • Security review schedule established — biennial reviews per 45 CFR 95.621(f), tracked via POST /v1/security/reviews

  • Data classification policy documented — identify PII, PHI, and CUI categories handled by CRAIG

  • Privacy Impact Assessment (PIA) completed for child welfare data processing

  • Records retention schedule defined and configured in craig-security archive policies

  • Vulnerability disclosure policy published (based on SECURITY.md template)

  • Remediation SLA commitments documented per Security Operations

  • CycloneDX SBOM published as a GitLab Release asset on every tagged release (generated by cargo xtask sbom — wired in .gitlab-ci.yml sbom: + release: jobs; asset name craig-sbom-<tag>.cdx.json). Provides third-party supply-chain attestation for dependency review during authorization.

4. Data Exchange

These items are required for agencies that will exchange data with external partners.

  • Data sharing agreements executed with all exchange partners (per ACF Technical Bulletin #8)

  • Partner endpoint URLs configured in craig-exchange

  • Partner authentication credentials provisioned (API keys or mutual TLS)

  • JWS signing keys generated and registered for intake report integrity verification (ECDSA P-256)

  • ICPC interstate compact agreements in place for participating states

  • Exchange adapter configurations tested for each active partner (CWCA, court, education, health, tribal)

  • Data format mapping validated — AFCARS element codes, NCANDS codes, FIPS codes

5. Testing and Validation

These verification steps confirm the deployment is secure and functional.

  • Penetration test commissioned and completed (see Penetration Test Process)

  • All Critical and High penetration test findings remediated and re-tested

  • E2E test suite (cargo xtask e2e) passes against the production-like environment (the Playwright report gives live counts)

  • Integration test suite (cargo nextest run --workspace --locked --profile integration) passes against production databases

  • Accessibility conformance: the axe-core blocking pre-push gate covers the enumerated page set with zero WCAG 2.1 A/AA or Section 508 violations (page counts and dates live in the VPAT 2.5)

  • Performance baseline established — response times under expected concurrent user load

  • Disaster recovery test completed — full restore from backup verified

  • RBAC boundary testing completed — each role verified to access only authorized endpoints

  • Public intake form tested: rate limiting, CAPTCHA, honeypot, and HTML sanitization verified

6. Operational Readiness

These operational procedures must be in place before go-live.

  • Backup schedule configured — PostgreSQL (daily full, continuous WAL archiving), RabbitMQ definitions, Keycloak realm, object storage

  • Disaster recovery plan documented — RPO and RTO targets defined, restoration procedures tested

  • Incident response plan documented — roles, communication channels, escalation procedures (see Incident Response Overview)

  • On-call rotation established for Critical and High severity incidents

  • Monitoring and alerting configured — service health checks, database connection pools, disk usage, certificate expiry

  • Log retention policy configured — minimum 1 year for audit logs per federal requirements

  • Patch management process documented — how CRAIG updates are evaluated, tested, and deployed

  • User training completed — caseworkers, supervisors, administrators trained on CRAIG web UI and procedures

  • Help desk procedures established for password resets, account lockouts, and access requests

7. Authorization

These are the final steps to obtain the Authority to Operate.

  • System Security Plan (SSP) drafted — references CRAIG’s NIST architecture mapping, documents agency-specific controls, identifies inherited controls from hosting provider

  • Plan of Action and Milestones (POA&M) prepared for any partially implemented or planned controls

  • Security Assessment Report (SAR) from an independent assessor or the agency’s security team

  • Authorizing Official (AO) identified — typically the agency CISO or delegated authority

  • ATO package submitted to the AO: SSP, SAR, POA&M, penetration test report, risk assessment

  • Continuous monitoring plan established — quarterly vulnerability scans, annual penetration tests, biennial security reviews, ongoing audit log review

  • ATO granted with conditions documented — expiration date, POA&M milestones, continuous monitoring requirements

Post-ATO Continuous Compliance

After ATO is granted, the following ongoing activities maintain compliance:

  • Quarterly: Run vulnerability scans (dependency scanning, container scanning). Review and update POA&M.

  • Biennial: Conduct security review per 45 CFR 95.621(f). Record via POST /v1/security/reviews.

  • Annually: Commission penetration test. Review and update SSP. Verify backup and DR procedures.

  • On change: Re-assess controls affected by major CRAIG upgrades, infrastructure changes, or new integrations.

  • Continuously: Monitor audit logs via GET /v1/security/audit. Review breach detection alerts. Apply security patches per remediation SLAs.

Related Pages

Edit this page · latest