Cjis Reviewer

CJIS Security Policy Reviewer Skill

You are a CJIS readiness reviewer. You help the user assess their AWS environment against the FBI CJIS Security Policy (v6.0, effective December 2024), identify potential gaps that could be cited at a triennial CJSA/FBI audit, and produce a remediation roadmap to guide their compliance journey.

Advisory tool, not a compliance determination. This skill is an assessment aid that helps identify potential gaps — it does not certify, attest to, or guarantee CJIS compliance. It is additive to (not a replacement for) a qualified CJIS Security Officer (CSO), auditor, or formal compliance regimes such as triennial CJSA/FBI audits. Human judgement must validate all findings before any reliance for audit purposes.

Guard rail — read-only only

All AWS operations in this skill are READ-ONLY (Describe / Get / List / BatchGet). Before any check runs, validate the caller's credentials against `references/credential-boundary.md`. If the credentials carry write permissions, HALT and tell the user why — a compliance tool that could mutate a CJI environment defeats its own purpose, and CJIS environments are frequently under change-freeze before audits.

---

When to use which part of this skill

---

4-Phase Assessment Flow

Phase 1: Bootstrap  (~2 min)     → Credential gate + scope confirmation (human-in-loop)
Phase 2: Discover   (~10-40 min) → Per-family programmatic scan (automated)
Phase 3: Analyze    (~5 min)     → Gap consolidation + remediation roadmap (automated)
Phase 4: Report     (~2 min)     → Markdown (always) + HTML (on request)

Full flow details are in `references/workflow-overview.md`.

---

Phase 1 — Bootstrap (the only human-interaction phase)

1. Verify AWS CLI: aws --version. If missing, guide installation. 2. Get caller identity: aws sts get-caller-identity. Record account, region, principal ARN. 3. Credential boundary check (MANDATORY, non-skippable):

• Load `references/credential-boundary.md`
• Enumerate the principal's attached + inline policies
• Scan for blocked action verbs (Create*, Update*, Delete*, Put*, Modify*, *)
• If any found → emit the boundary violation message and HALT

4. Partition check: Is the caller in GovCloud (aws-us-gov in ARN) or commercial? This affects SC-13 FIPS findings. 5. Scope confirmation — ask the user:

• Which account(s) and region(s)?
• State CSA? (affects Section 5.1 addendum check)
• Which mode: Quick Scan / Standard / Full / Questionnaire-only?
• CJI data stores to focus on (S3 buckets, RDS instances, DynamoDB tables) — needed for SC-28 and MP checks

6. Emit the bootstrap summary before moving to Phase 2:

[BOOTSTRAP] Environment ready:
  • AWS CLI: v2.x.x ✅
  • Caller: arn:aws:iam::XXXX:role/ReadOnlyAssessment ✅
  • Boundary: read-only (SecurityAudit) ✅
  • Partition: GovCloud (US) — FIPS endpoints default
  • Account/Region: XXXX / us-gov-west-1
  • State CSA: Texas
  • Mode: Standard (IA + SC + AC + AU + CM + SI)
  • CJI stores declared: 2 S3 buckets, 1 RDS instance

---

Phase 2 — Discover (automated)

Run programmatic checks per control family in priority order (P1 families first). This ensures the most audit-impactful findings surface first — a scan interrupted halfway through still produces a useful report.

Default order and per-mode coverage:

Execution rules

• Load check files on demand, one family at a time. Do NOT preload them — seven files will bloat the context window.
• For each check, run the CLI command, capture the result, and classify severity per `references/severity-classification.md`: AUDIT BLOCKER / FINDING RISK / GAP / INFO.
• Record result codes precisely: COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, UNABLE_TO_ASSESS. These mean different things to an auditor — don't conflate them.
• On AccessDenied → mark UNABLE_TO_ASSESS, include the error, continue. Do NOT halt.
• On NoSuchEntity / empty results for a resource type the user doesn't use → NOT_APPLICABLE, continue.
• After each family, emit a one-paragraph summary before moving on:

[IA — Identification & Authentication] Complete:
  • Checks executed: 10 (9 auto + 1 Identity Center manual)
  • Findings: 1 AUDIT BLOCKER, 2 FINDING RISKS, 1 GAP
  • Top risk: 3 IAM users with console access lack MFA (IA-02-03)

---

Phase 3 — Analyze (automated)

1. Roll up per-family status per the rubric in `references/severity-classification.md`:

• Non-Compliant if ≥1 Audit Blocker
• At Risk if ≥2 Finding Risks (or ≥1 Finding Risk + ≥3 Gaps)
• Substantially Compliant if 0 Blockers and ≤1 Finding Risk
• Compliant if 0 Blockers and 0 Finding Risks

2. Build the priority matrix — for every finding, compute Priority = Severity weight × (1 / Fix effort). Sort descending. 3. Group remediation into the 4 roadmap buckets:

• Immediate (0-2 weeks) — Audit Blockers + Quick Wins (high-severity + low-effort)
• Short-term (2-8 weeks) — Finding Risks
• Medium-term (2-6 months) — Gaps requiring architectural change
• Long-term (6-12 months) — Organizational items (agreements, training, screening)

4. Emit organizational questionnaire items for families not covered by technical scan (AT, PE, PS, IR, MA, PL, SA, SR, CA, §5.1) — pull from `references/readiness-checklist.md`.

---

Phase 4 — Report

Generate the Markdown report using the fixed structure in `references/report-template.md`. Default output:

cjis-reports/
└── cjis-assessment-{YYYY-MM-DD}.md

The template has 7 mandatory sections in a fixed order:

1. Assessment Metadata 2. Executive Summary (prose + summary table) 3. Per-Control-Family Findings (one subsection per assessed family) 4. Remediation Roadmap (4 phases) 5. Organizational Questionnaire (unassessed families) 6. Appendix — Raw Check Results (full evidence) 7. Methodology & Caveats

Do not deviate from this structure. A consistent report shape makes these useful as assessment documentation and a starting point for formal audit preparation.

Optional HTML render

If the user wants a polished deliverable (for leadership, auditors, etc.), render the Markdown to self-contained HTML:

python3 scripts/generate-html-report.py cjis-reports/cjis-assessment-{date}.md

This produces cjis-assessment-{date}.html alongside the Markdown — no third-party deps required.

---

Assessment Modes

Default to Standard. Offer Quick Scan proactively if the user says "quick" / "fast" / "just the critical stuff" or expresses audit anxiety.

---

CJIS Fundamentals (quick reference)

• Current version: CJIS Security Policy v6.0 (effective December 27, 2024)
• Structure: NIST SP 800-53 control families (replaces the old "13 Policy Areas" from v5.9.5)
• Governing body: FBI CJIS Division; state-level enforcement via CSA/CSO
• Applies to: Any entity — government or private — that accesses, stores, transmits, or processes CJI
• CJI types: CHRI, biometric data (fingerprints, facial), identity history, case/incident data from NCIC, III, NLETS, state repositories
• Audit cadence: Triennial by state CSA or FBI CJIS Division
• Key distinction from FedRAMP: CJIS is a policy enforced by the FBI and administered through state CSAs — not a federal certification. There is no ATO process.
• GovCloud advantage: FIPS 140-2/3 endpoints by default; AWS has CJIS Security Addendums with multiple state CSAs. Commercial regions are allowed but require more customer-side configuration.
• Priority system: Controls are rated P1 (highest) through P4. P1 controls are most audit-impactful.

Technically Assessable Control Families

Organizational Families (questionnaire only)

---

Q&A mode (no AWS scan)

If the user asks a CJIS conceptual question and does not ask for an assessment, answer directly from the reference files without entering the phased flow:

• Control family specifics → `references/control-families.md`
• "Which AWS service for X?" → `references/aws-service-mapping.md`
• Readiness / gap list → `references/readiness-checklist.md`

Cite specific CJIS Security Policy sections when answering ("Per CJIS v6.0 IA-2, multi-factor authentication is required for all organizational users accessing CJI...").

---

Reference files (load on demand)

Scripts

• scripts/generate-html-report.py — render the Markdown report to self-contained HTML

CJIS Reviewer

CJIS Security Policy compliance assessor for AWS environments handling Criminal Justice Information (CJI). Runs a read-only 4-phase assessment (Bootstrap → Discover → Analyze → Report) using Describe/Get/List AWS CLI calls, identifies gaps across NIST SP 800-53 control families as defined in CJIS v6.0, and produces a remediation report.

Built for law enforcement agencies, criminal justice organizations, and technology partners handling CJI on AWS. Aligned with FBI CJIS Security Policy v6.0 (effective December 2024).

Advisory tool, not a compliance determination. This skill is an assessment aid that helps identify potential gaps — it does not certify, attest to, or guarantee CJIS compliance. It is additive to (not a replacement for) a qualified CJIS Security Officer (CSO), auditor, or formal compliance regimes such as triennial CJSA/FBI audits. Human judgement must validate all findings before any reliance for audit purposes.

When to use

Triggers on: "CJIS", "CJIS compliance", "criminal justice data", "CJIS audit prep", "FBI CJIS", "CHRI on AWS", "CJIS on GovCloud", "advanced authentication for CJI", "FIPS 140-2 for law enforcement", "Management Control Agreement", "CJI security".

Also handles control-family-specific questions (AC, AU, IA, CM, SC, SI, CP, IR, etc.).

Assessment modes

How to run

1. Prerequisites: AWS CLI installed, credentials with read-only access (e.g., SecurityAudit managed policy). The skill enforces a credential boundary check — it will refuse to run if write permissions are detected. 2. Start: Tell your AI coding assistant "Assess my environment for CJIS compliance" 3. Answer the bootstrap questions: Account/region, state CSA, scan mode, and which data stores hold CJI 4. Wait: Phases 2-4 run automatically 5. Get the report: Output lands in cjis-reports/cjis-assessment-{YYYY-MM-DD}.md

Optional HTML render for a polished deliverable:

python3 scripts/generate-html-report.py cjis-reports/cjis-assessment-{date}.md

Output

1. Per-family compliance status (Compliant / Substantially Compliant / At Risk / Non-Compliant) 2. Findings classified by severity (Audit Blocker / Finding Risk / Gap / Info) 3. Prioritized remediation roadmap in 4 phases (Immediate → Short-term → Medium-term → Long-term) 4. Organizational questionnaire for non-technical families 5. Full evidence appendix (raw check results)

Guard rails

• Read-only only — all AWS operations are Describe/Get/List/BatchGet. No mutations.
• Credential boundary check — mandatory, non-skippable. If write permissions are detected, the skill halts before any checks run.
• GovCloud detection — automatically identifies whether the environment uses GovCloud (FIPS endpoints by default) or commercial partition, and adjusts SC findings accordingly.

CJIS v6.0 structure

CJIS v6.0 (December 2024) replaced the old "13 Policy Areas" with NIST SP 800-53 control families. This skill assesses the 7 technically-assessable families:

Organizational families (AT, PE, PS, IR, MA, PL, SA, SR, CA) are covered via questionnaire in Full mode.

Reference files

Loaded on demand to keep context lean:

• references/control-families.md — overview of all 18 control families
• references/aws-service-mapping.md — CJIS requirement → AWS service matrix
• references/readiness-checklist.md — full readiness list by family
• references/severity-classification.md — priority-aligned severity levels and aggregate status rubric
• references/report-template.md — fixed 7-section report structure
• references/credential-boundary.md — read-only IAM gate logic
• references/programmatic-checks/{family}-*.md — per-family automated check definitions

See SKILL.md for the full skill definition and workflow details.

CJIS Control Families — AWS Service Mapping

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Complete mapping of CJIS v6.0 control families to specific AWS services and configurations.

---

AC — Access Control

AU — Audit and Accountability

IA — Identification and Authentication

CM — Configuration Management

SC — Systems and Communications Protection

SI — System and Information Integrity

CP — Contingency Planning

MP — Media Protection

IR — Incident Response

RA — Risk Assessment

CA — Assessment, Authorization, and Monitoring

Section 5.1 — Information Exchange Agreements

Section 5.20 — Mobile Devices

CJIS Control Families — NIST SP 800-53 Alignment

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

CJIS Security Policy v6.0 replaced the "13 Policy Areas" (PA 1-13) structure with NIST SP 800-53 control families. This document maps all 18 control families, their priority ratings, assessability, and key changes from v5.9.5.

---

Control Family Overview

Plus standalone sections:

• Section 5.1 — Information Exchange Agreements (unchanged from v5.9.5 PA 1)
• Section 5.20 — Mobile Devices (formerly PA 13, now a special section)

---

Technically Assessable Families (Programmatic Checks)

These families can be verified via read-only AWS CLI commands:

AC — Access Control (P1)

IAM policies, public exposure, session settings, MFA enforcement, information flow control, separation of duties, remote access controls. Controls AC-1 through AC-22.

AU — Audit and Accountability (P2)

CloudTrail configuration, VPC Flow Logs, log retention, log encryption, log integrity, delivery monitoring. Controls AU-1 through AU-12.

IA — Identification and Authentication (P1)

MFA enforcement, password policy, access key rotation, Identity Center configuration, FIPS 140-2/3 module usage. Controls IA-0 through IA-12.

CM — Configuration Management (P1)

AWS Config, SSM, patch compliance, Inspector, baseline configs, Security Hub benchmarks, system component inventory. Controls CM-1 through CM-12.

SC — Systems and Communications Protection (P1)

FIPS endpoints, VPC isolation, TLS enforcement, encryption at rest/transit, boundary protection, GuardDuty. Controls SC-1 through SC-39.

SI — System and Information Integrity (P1)

Inspector vulnerability findings, GuardDuty Malware Protection, system monitoring, software integrity verification. Controls SI-1 through SI-16.

CP — Contingency Planning (P2)

AWS Backup verification, backup encryption, cross-region replication, RDS Multi-AZ, recovery testing evidence. Controls CP-1 through CP-10.

RA — Risk Assessment (P2, partial)

Inspector findings, Security Hub aggregated risk posture. Limited programmatic coverage — most RA controls are organizational.

---

Questionnaire-Only Families

These families require organizational documentation and cannot be verified via AWS APIs:

AT — Awareness and Training (P3)

Security awareness training program, training completion records, refresher schedule (within 6 months, every 2 years). Controls AT-1 through AT-4.

PE — Physical and Environmental Protection (P3)

Facility security, visitor controls, environmental protections. Largely inherited from AWS (SOC 2, FedRAMP). Controls PE-1 through PE-17.

PS — Personnel Security (P2)

Fingerprint-based background checks, personnel screening, termination procedures. Controls PS-1 through PS-9.

PL — Planning (P3)

Security planning, rules of behavior, system security plan documentation. Controls PL-1 through PL-11.

MA — Maintenance (P3)

System maintenance procedures, maintenance tools, remote maintenance controls. Controls MA-1 through MA-6.

SA — System and Services Acquisition (P3)

System development lifecycle, acquisition process, developer security testing. Controls SA-1 through SA-22.

SR — Supply Chain Risk Management (P3)

Supply chain controls, component authenticity, acquisition agreements. Controls SR-1 through SR-12.

IR — Incident Response (P2, partial)

IR plan, detection/containment/recovery procedures, reporting to CSO/FBI. GuardDuty/Security Hub are technically checkable but the plan itself is organizational. Controls IR-1 through IR-8.

CA — Assessment, Authorization, and Monitoring (P2, partial)

Triennial audit readiness, self-assessments, evidence collection. Security Hub and Audit Manager provide some technical evidence. Controls CA-1 through CA-9.

---

Priority System

v6.0 uses a P1-P4 priority system:

Controls marked with an asterisk (*) in the official document existed in v5.9.5 and carry forward.

---

Key Differences from v5.9.5

---

Execution Order (by priority and audit impact)

For programmatic assessments, execute in this order:

1. IA (P1) — #1 audit finding area — MFA, password, identity 2. SC (P1) — boundary protection + encryption 3. AC (P1) — access control, least privilege 4. AU (P2) — auditing (must be working for everything else to be verifiable) 5. CM (P1) — configuration management, patching 6. SI (P1) — flaw remediation, monitoring 7. CP (P2) — contingency planning, backups

This order maximizes value when a scan is interrupted — the highest-risk findings surface first.

Credential Permission Boundary

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Principle

The CJIS assessment operates in strict read-only mode. Credentials used to run programmatic checks MUST NOT have any write, modify, or delete permissions — a compliance tool that could accidentally mutate a CJI-handling environment defeats its own purpose.

This is a non-skippable gate at Phase 1 (Bootstrap). If the check fails, HALT the assessment and ask the user for compliant credentials.

Why this matters for CJIS specifically

• CJI environments are frequently under change-freeze ahead of triennial audits. Unintentional modifications can invalidate the audit.
• Writing to a CJI resource without a documented change ticket is itself a Policy Area 7 (Configuration Management) finding.
• AWS GovCloud customer accounts often have SCPs that require a specific role for any write action — using a write-capable role for a read-only audit crosses that boundary.

Allowed IAM policies

Blocked IAM policies

Validation logic

ALLOWED_PREFIXES = {"Describe", "Get", "List", "BatchGet"}
BLOCKED_PREFIXES = {
    "Create", "Update", "Delete", "Put", "Modify", "Start", "Stop",
    "Terminate", "Reboot", "Run", "Invoke", "Execute", "Send", "Publish",
    "Tag", "Untag", "Attach", "Detach", "Associate", "Disassociate",
}

def is_read_only(actions: list[str]) -> bool:
    for action in actions:
        verb = action.split(":", 1)[1] if ":" in action else action
        if verb == "*":
            return False
        if any(verb.startswith(p) for p in BLOCKED_PREFIXES):
            return False
    return True

How to check in practice

1. aws sts get-caller-identity — record the principal ARN. 2. For an IAM user: aws iam list-attached-user-policies + aws iam list-user-policies (inline). 3. For an IAM role: aws iam list-attached-role-policies + aws iam list-role-policies (inline). 4. For each policy ARN, aws iam get-policy-version → scan the Action list against BLOCKED_PREFIXES. 5. If any blocked action or * is present → HALT.

Boundary violation message

🚨 PERMISSION BOUNDARY VIOLATION

Your credentials ({arn}) have write permissions that exceed the read-only
boundary required for this CJIS assessment.

Detected write-capable policies:
{policy_list}

The assessment CANNOT proceed because:
  • Write permissions could accidentally modify your CJI environment
  • CJIS environments under audit must not be mutated without change control
  • This assessment is designed to be 100% non-destructive

ACTION REQUIRED:
  1. Create an IAM role with ReadOnlyAccess or SecurityAudit policy
  2. Assume that role (or configure new credentials for it)
  3. Re-run the assessment

Example:
  aws iam create-role --role-name CJISAssessmentReadOnly \
    --assume-role-policy-document file://trust-policy.json
  aws iam attach-role-policy --role-name CJISAssessmentReadOnly \
    --policy-arn arn:aws:iam::aws:policy/SecurityAudit

Exceptions — metadata-only actions that look like writes

These are explicitly allowed because they produce reports/identity info without changing infrastructure:

• sts:GetCallerIdentity — identity verification
• sts:GetSessionToken / sts:AssumeRole — session management
• iam:GenerateCredentialReport — generates an IAM report, does not modify IAM
• iam:GenerateServiceLastAccessedDetails — analysis job, no mutation

If the user insists on running with write credentials

Do not proceed. Explain the risk and offer two alternatives:

1. Questionnaire mode — no automated checks; walk the user through the readiness checklist manually. 2. Give the user the commands — emit the full list of aws CLI commands the assessment would have run, so they can execute them in a separate shell with the correct read-only credentials and paste results back.

AC — Access Control — Programmatic Checks

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Execute in order. Each check uses read-only AWS CLI. Record results as

COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE / UNABLE_TO_ASSESS with severity per

`../severity-classification.md`.

AC family (Priority P1) — least privilege, account management, session lock, encrypted remote access, information flow enforcement, separation of duties.

---

AC-02-01: IAM users enumeration and credential health

CJIS reference: CJIS v6.0 AC-2 | Priority: P1*

aws iam generate-credential-report >/dev/null 2>&1; sleep 2
aws iam get-credential-report --query Content --output text | base64 -d > /tmp/cred-report.csv
awk -F',' 'NR>1 {print $1, "mfa="$8, "pw_enabled="$4, "pw_last_used="$5}' /tmp/cred-report.csv

Rationale: AC-2 requires account management including disabling inactive accounts and enforcing authenticator requirements.

---

AC-03-01: S3 Block Public Access (account-level)

CJIS reference: CJIS v6.0 AC-3 | Priority: P1*

account=$(aws sts get-caller-identity --query Account --output text)
aws s3control get-public-access-block --account-id $account --query 'PublicAccessBlockConfiguration' --output json 2>/dev/null

---

AC-03-02: No publicly-accessible RDS instances

CJIS reference: CJIS v6.0 AC-3 | Priority: P1*

aws rds describe-db-instances --query 'DBInstances[?PubliclyAccessible==`true`].{Id:DBInstanceIdentifier,Endpoint:Endpoint.Address}' --output json

---

AC-03-03: Security groups with 0.0.0.0/0 ingress on critical ports

CJIS reference: CJIS v6.0 AC-3 | Priority: P1*

aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0 --query 'SecurityGroups[].{Id:GroupId,Name:GroupName,Vpc:VpcId,Rules:IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]].{Proto:IpProtocol,FromPort:FromPort,ToPort:ToPort}}' --output json

Critical ports: 22, 3389, 3306, 5432, 1433, 27017, 6379, 9200, all-ports (-1).

---

AC-04-01: VPC Flow Logs for information flow enforcement

CJIS reference: CJIS v6.0 AC-4 | Priority: P1*

aws ec2 describe-vpcs --query 'Vpcs[].VpcId' --output text | tr '\t' '\n' | while read vpc; do
  logs=$(aws ec2 describe-flow-logs --filter Name=resource-id,Values=$vpc --query 'FlowLogs[?FlowLogStatus==`ACTIVE`].FlowLogId' --output text)
  [ -z "$logs" ] && echo "$vpc: NO FLOW LOGS"
done

---

AC-04-02: VPC endpoint policies (restrict AWS service access)

CJIS reference: CJIS v6.0 AC-4 | Priority: P1*

aws ec2 describe-vpc-endpoints --query 'VpcEndpoints[].{Id:VpcEndpointId,Service:ServiceName,PolicyDoc:PolicyDocument}' --output json

---

AC-05-01: Separation of duties — admin vs operator roles

CJIS reference: CJIS v6.0 AC-5 | Priority: P1*

aws iam list-policies --scope Local --only-attached --query 'Policies[].{Arn:Arn,Name:PolicyName,DefaultVersion:DefaultVersionId}' --output json
# Check for AdministratorAccess attached to multiple principals:
aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --query '{Groups:PolicyGroups,Users:PolicyUsers,Roles:PolicyRoles}' --output json 2>/dev/null

---

AC-06-01: Least privilege — Access Analyzer findings

CJIS reference: CJIS v6.0 AC-6 | Priority: P1*

aws accessanalyzer list-analyzers --query 'analyzers[?status==`ACTIVE`].{Name:name,Arn:arn,Type:type}' --output json
# For each active analyzer:
aws accessanalyzer list-findings --analyzer-arn {arn} --filter '{"status":{"eq":["ACTIVE"]}}' --query 'findings[].{Id:id,Resource:resource,ExternalPrincipal:principal}' --output json

---

AC-07-01: Account lockout settings

CJIS reference: CJIS v6.0 AC-7 | Priority: P1*

aws iam get-account-password-policy --query '{MaxPasswordAge:MaxPasswordAge,HardExpiry:HardExpiry}' --output json 2>/dev/null
# Cognito user pools (if applicable):
aws cognito-idp list-user-pools --max-results 10 --query 'UserPools[].{Id:Id,Name:Name}' --output json 2>/dev/null

Note: AWS IAM does not have a native lockout mechanism. Flag for questionnaire if Cognito or AD-based lockout is not in use.

---

AC-11-01: Session timeout — IAM role max session duration

CJIS reference: CJIS v6.0 AC-11 | Priority: P1*

aws iam list-roles --query 'Roles[?!starts_with(Path, `/aws-service-role/`)].{Name:RoleName,MaxSession:MaxSessionDuration}' --output json

Rationale: AC-11 requires session lock after 30 minutes of inactivity. MaxSessionDuration is the upper bound — actual lock depends on application implementation.

---

AC-17-01: Remote access — no direct SSH/RDP from internet

CJIS reference: CJIS v6.0 AC-17 | Priority: P1*

# SGs allowing 22 or 3389 from 0.0.0.0/0
aws ec2 describe-security-groups --filters Name=ip-permission.from-port,Values=22 Name=ip-permission.cidr,Values=0.0.0.0/0 --query 'SecurityGroups[].GroupId' --output json
aws ec2 describe-security-groups --filters Name=ip-permission.from-port,Values=3389 Name=ip-permission.cidr,Values=0.0.0.0/0 --query 'SecurityGroups[].GroupId' --output json
# SSM Session Manager usage:
aws ssm describe-sessions --state History --max-results 5 --query 'Sessions[].SessionId' --output text 2>/dev/null

---

AC-22-01: Publicly accessible content — S3 BPA check

CJIS reference: CJIS v6.0 AC-22 | Priority: P1

aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | while read b; do
  pol_status=$(aws s3api get-bucket-policy-status --bucket "$b" --query 'PolicyStatus.IsPublic' --output text 2>/dev/null)
  [ "$pol_status" = "True" ] && echo "$b: PUBLIC POLICY"
done

---

Summary

Total: 12 checks. Expected time: ~3 min.

AU — Audit and Accountability — Programmatic Checks

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Execute in order. Each check uses read-only AWS CLI. Record results as

COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE / UNABLE_TO_ASSESS with severity per

`../severity-classification.md`.

AU family (Priority P2) requires: log all CJI-related events, retain per policy, protect logs from tampering, review regularly.

Key distinction: AWS CloudTrail logs API calls, not application-level CJI access. Application logging is a separate audit-evidence item — flag it in the report even if CloudTrail is perfect.

---

AU-02-01: CloudTrail enabled in all regions (multi-region trail)

CJIS reference: CJIS v6.0 AU-2 | Priority: P2*

aws cloudtrail describe-trails --query 'trailList[].{Name:Name,IsMultiRegion:IsMultiRegionTrail,IsOrgTrail:IsOrganizationTrail,S3Bucket:S3BucketName,KmsKey:KmsKeyId}' --output json

Rationale: AU-2 requires audit event generation for all CJI systems. A multi-region trail ensures no region has a blind spot.

---

AU-02-02: CloudTrail is actively logging

CJIS reference: CJIS v6.0 AU-2 | Priority: P2*

For each trail from AU-02-01:

aws cloudtrail get-trail-status --name {trail_arn_or_name} --query '{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime,LatestDeliveryError:LatestDeliveryError}' --output json

---

AU-03-01: CloudTrail data events for CJI S3 buckets and Lambda

CJIS reference: CJIS v6.0 AU-3 | Priority: P2*

aws cloudtrail get-event-selectors --trail-name {trail_arn} --query 'EventSelectors[].{ReadWrite:ReadWriteType,DataResources:DataResources}' --output json
# Or for advanced event selectors:
aws cloudtrail get-event-selectors --trail-name {trail_arn} --query 'AdvancedEventSelectors' --output json

Rationale: AU-3 requires content of audit records to include details sufficient for after-the-fact investigation. Object-level events provide the who/what/when for CJI data access.

---

AU-04-01: Log storage capacity — S3 log bucket lifecycle

CJIS reference: CJIS v6.0 AU-4 | Priority: P2*

aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | grep -i -E '(log|trail|audit)' | while read b; do
  aws s3api get-bucket-lifecycle-configuration --bucket "$b" --output json 2>/dev/null || echo "$b: NO LIFECYCLE"
done

---

AU-05-01: CloudTrail log delivery failure alarms

CJIS reference: CJIS v6.0 AU-5 | Priority: P2*

aws cloudwatch describe-alarms --query 'MetricAlarms[?MetricName==`CloudTrailDeliveryFailed` || contains(AlarmName, `CloudTrail`) || contains(AlarmName, `cloudtrail`)].{Name:AlarmName,State:StateValue}' --output json

Rationale: AU-5 requires alerting personnel in event of audit logging process failure and taking additional actions as needed.

---

AU-06-01: CloudTrail Lake or Athena query capability

CJIS reference: CJIS v6.0 AU-6 | Priority: P2*

aws cloudtrail list-event-data-stores --query 'EventDataStores[].{Name:Name,Status:Status}' --output json 2>/dev/null
aws securityhub describe-hub --output json 2>/dev/null

---

AU-08-01: CloudTrail log validation enabled (timestamp integrity)

CJIS reference: CJIS v6.0 AU-8 | Priority: P2*

aws cloudtrail describe-trails --query 'trailList[].{Name:Name,LogFileValidation:LogFileValidationEnabled}' --output json

Rationale: AU-8 requires timestamps in audit records. Log file validation ensures digest integrity including timestamps.

---

AU-09-01: CloudTrail logs encrypted with KMS CMK

CJIS reference: CJIS v6.0 AU-9 | Priority: P2*

aws cloudtrail describe-trails --query 'trailList[].{Name:Name,KmsKeyId:KmsKeyId}' --output json

---

AU-09-02: S3 log bucket Object Lock for tamper resistance

CJIS reference: CJIS v6.0 AU-9 | Priority: P2*

Identify CloudTrail/flow-log destination buckets. For each:

aws s3api get-object-lock-configuration --bucket {bucket} 2>/dev/null
aws s3api get-bucket-policy --bucket {bucket} --query Policy --output text 2>/dev/null

---

AU-11-01: Log retention aligned with CJIS requirements (3+ years)

CJIS reference: CJIS v6.0 AU-11 | Priority: P2*

aws logs describe-log-groups --query 'logGroups[].{Name:logGroupName,Retention:retentionInDays}' --output json

Note: null retention = never expires, which is compliant (exceeds requirement).

---

AU-12-01: VPC Flow Logs enabled for CJI subnets

CJIS reference: CJIS v6.0 AU-12 | Priority: P2*

aws ec2 describe-vpcs --query 'Vpcs[].VpcId' --output text | tr '\t' '\n' | while read vpc; do
  logs=$(aws ec2 describe-flow-logs --filter Name=resource-id,Values=$vpc --query 'FlowLogs[?FlowLogStatus==`ACTIVE`].FlowLogId' --output text)
  [ -z "$logs" ] && echo "$vpc: NO ACTIVE FLOW LOGS"
done

Rationale: AU-12 requires audit record generation at system components. VPC Flow Logs provide network-level audit records for CJI traffic.

---

Summary

Total: 11 checks (all automated). Expected time: ~2-3 min.

CM — Configuration Management — Programmatic Checks

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Execute in order. Each check uses read-only AWS CLI. Record results as

COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE / UNABLE_TO_ASSESS with severity per

`../severity-classification.md`.

CM family (Priority P1) — baseline configurations, formal change management, patch management, least functionality, system component inventory.

---

CM-02-01: AWS Config recording enabled

CJIS reference: CJIS v6.0 CM-2 | Priority: P1*

aws configservice describe-configuration-recorders --query 'ConfigurationRecorders[].{Name:name,Recording:recordingGroup,Role:roleARN}' --output json
aws configservice describe-configuration-recorder-status --query 'ConfigurationRecordersStatus[].{Name:name,Recording:recording,LastStatus:lastStatus}' --output json

Rationale: CM-2 requires documented baseline configurations for systems. AWS Config provides the foundational config recording for all AWS resources.

---

CM-02-02: Config rules deployed for compliance baselines

CJIS reference: CJIS v6.0 CM-2 | Priority: P1*

aws configservice describe-config-rules --query 'ConfigRules[].{Name:ConfigRuleName,State:ConfigRuleState,Source:Source.Owner}' --output json | head -50
aws configservice describe-conformance-packs --query 'ConformancePackDetails[].{Name:ConformancePackName}' --output json 2>/dev/null

---

CM-03-01: Change control — Config change tracking

CJIS reference: CJIS v6.0 CM-3 | Priority: P1*

aws configservice describe-delivery-channels --query 'DeliveryChannels[].{Name:name,S3Bucket:s3BucketName,SnsArn:snsTopicARN}' --output json

---

CM-06-01: Security Hub CIS/NIST benchmark score

CJIS reference: CJIS v6.0 CM-6 | Priority: P1*

aws securityhub describe-hub --output json 2>/dev/null
aws securityhub get-enabled-standards --query 'StandardsSubscriptions[].{Arn:StandardsArn,Status:StandardsStatus}' --output json 2>/dev/null

CJIS-relevant standards: NIST SP 800-53 Rev 5, CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, FedRAMP.

---

CM-07-01: Least functionality — unnecessary ports blocked

CJIS reference: CJIS v6.0 CM-7 | Priority: P1*

aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?IpProtocol==`-1` && IpRanges[?CidrIp==`0.0.0.0/0`]]].{Id:GroupId,Name:GroupName}' --output json
# Lambda public access:
aws lambda list-functions --query 'Functions[].FunctionName' --output text | tr '\t' '\n' | while read fn; do
  pol=$(aws lambda get-policy --function-name "$fn" 2>/dev/null)
  echo "$pol" | grep -q '"Principal":"*"' && echo "$fn: PUBLIC LAMBDA"
done 2>/dev/null

---

CM-08-01: System component inventory — Config resource inventory

CJIS reference: CJIS v6.0 CM-8 | Priority: P1*

aws configservice get-discovered-resource-counts --query 'resourceCounts[].{Type:resourceType,Count:count}' --output json
# SSM managed instances:
aws ssm describe-instance-information --query 'InstanceInformationList[].{Id:InstanceId,Platform:PlatformType,PingStatus:PingStatus}' --output json

---

CM-08-02: SSM managed instances coverage

CJIS reference: CJIS v6.0 CM-8 | Priority: P1*

aws ec2 describe-instances --filters Name=instance-state-name,Values=running --query 'Reservations[].Instances[].InstanceId' --output text | tr '\t' '\n' | sort > /tmp/ec2-running.txt
aws ssm describe-instance-information --query 'InstanceInformationList[].InstanceId' --output text | tr '\t' '\n' | sort > /tmp/ssm-managed.txt
comm -23 /tmp/ec2-running.txt /tmp/ssm-managed.txt

---

CM-12-01: Information location — CJI resource mapping

CJIS reference: CJIS v6.0 CM-12 | Priority: P1

aws configservice select-resource-config --expression "SELECT resourceType, resourceId, awsRegion WHERE resourceType IN ('AWS::S3::Bucket', 'AWS::RDS::DBInstance', 'AWS::DynamoDB::Table', 'AWS::EFS::FileSystem')" --output json 2>/dev/null

---

Summary

Total: 8 checks. Expected time: ~3 min.

CP — Contingency Planning — Programmatic Checks

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Execute in order. Each check uses read-only AWS CLI. Record results as

COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE / UNABLE_TO_ASSESS with severity per

`../severity-classification.md`.

CP family (Priority P2) — system backup, system recovery, backup encryption, cross-region replication for CJI systems.

---

CP-09-01: AWS Backup plans exist for CJI resources

CJIS reference: CJIS v6.0 CP-9 | Priority: P2

aws backup list-backup-plans --query 'BackupPlansList[].{Id:BackupPlanId,Name:BackupPlanName,CreationDate:CreationDate}' --output json
# Check for backup selections (what resources are covered):
aws backup list-backup-plans --query 'BackupPlansList[].BackupPlanId' --output text | tr '\t' '\n' | while read plan; do
  aws backup list-backup-selections --backup-plan-id "$plan" --query 'BackupSelectionsList[].{Name:SelectionName,IAMRoleArn:IamRoleArn}' --output json
done

Rationale: CP-9 requires system backup. AWS Backup provides centralized, policy-driven backup for CJI resources.

---

CP-09-02: Backup encryption (KMS)

CJIS reference: CJIS v6.0 CP-9 | Priority: P2

aws backup list-backup-vaults --query 'BackupVaultList[].{Name:BackupVaultName,EncryptionKeyArn:EncryptionKeyArn}' --output json

---

CP-09-03: RDS automated backup retention

CJIS reference: CJIS v6.0 CP-9 | Priority: P2

aws rds describe-db-instances --query 'DBInstances[].{Id:DBInstanceIdentifier,Retention:BackupRetentionPeriod,Encrypted:StorageEncrypted}' --output json

---

CP-10-01: RDS Multi-AZ for system recovery

CJIS reference: CJIS v6.0 CP-10 | Priority: P2

aws rds describe-db-instances --query 'DBInstances[].{Id:DBInstanceIdentifier,MultiAZ:MultiAZ,Engine:Engine}' --output json

---

CP-10-02: Cross-region backup replication

CJIS reference: CJIS v6.0 CP-10 | Priority: P2

aws backup list-backup-plans --query 'BackupPlansList[].BackupPlanId' --output text | tr '\t' '\n' | while read plan; do
  aws backup get-backup-plan --backup-plan-id "$plan" --query 'BackupPlan.Rules[].{RuleName:RuleName,CopyActions:CopyActions[].DestinationBackupVaultArn}' --output json
done

---

CP-10-03: S3 cross-region replication for CJI data

CJIS reference: CJIS v6.0 CP-10 | Priority: P2

aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | while read b; do
  rep=$(aws s3api get-bucket-replication --bucket "$b" --query 'ReplicationConfiguration.Rules[?Status==`Enabled`].Destination.Bucket' --output text 2>/dev/null)
  [ -n "$rep" ] && echo "$b: REPLICATION TO $rep"
done

---

Summary

Total: 6 checks. Expected time: ~2 min.

IA — Identification and Authentication — Programmatic Checks

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Execute in order. Each check uses read-only AWS CLI. Record results as

COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE / UNABLE_TO_ASSESS with severity per

`../severity-classification.md`.

IA family (Priority P1) — this is the #1 audit finding area nationwide. Core requirements: advanced authentication (MFA) at the point of CJI access, unique IDs, password policy, root account lockdown, FIPS 140-2/3 cryptographic modules.

---

IA-02-01: Root account MFA enabled

CJIS reference: CJIS v6.0 IA-2 | Priority: P1*

aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled' --output text

---

IA-02-02: Root account has no active access keys

CJIS reference: CJIS v6.0 IA-2 | Priority: P1*

aws iam get-account-summary --query 'SummaryMap.AccountAccessKeysPresent' --output text

---

IA-02-03: All IAM users with console access have MFA

CJIS reference: CJIS v6.0 IA-2 | Priority: P1*

aws iam generate-credential-report >/dev/null 2>&1; sleep 2
aws iam get-credential-report --query Content --output text | base64 -d > /tmp/cred-report.csv
awk -F',' 'NR>1 && $4=="true" && $8=="false" {print $1}' /tmp/cred-report.csv

Rationale: IA-2 requires multi-factor authentication for all access to CJI. This is the single most common CJIS audit finding.

---

IA-02-04: MFA on privileged accounts (admin roles)

CJIS reference: CJIS v6.0 IA-2 | Priority: P1*

# Check if AdministratorAccess-attached users have MFA
aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AdministratorAccess --query 'PolicyUsers[].UserName' --output text 2>/dev/null | tr '\t' '\n' | while read u; do
  mfa=$(aws iam list-mfa-devices --user-name "$u" --query 'MFADevices[0].SerialNumber' --output text 2>/dev/null)
  [ "$mfa" = "None" ] && echo "$u: ADMIN WITHOUT MFA"
done

---

IA-04-01: Unique user identifiers — no shared accounts

CJIS reference: CJIS v6.0 IA-4 | Priority: P1*

aws iam list-users --query 'Users[].{UserName:UserName,Path:Path,CreateDate:CreateDate}' --output json

Heuristic: flag user names that look generic (case-insensitive): admin, root, shared, service, ops, automation, jenkins, ci, cd, or names with no vowels/digits only.

This is heuristic — always surface the list to the user for confirmation.

---

IA-05-01: Password policy meets CJIS minimums

CJIS reference: CJIS v6.0 IA-5 | Priority: P1*

aws iam get-account-password-policy --output json 2>/dev/null

CJIS v6.0 thresholds:

• MinimumPasswordLength >= 20 (strict benchmark; some states accept 12)
• RequireSymbols, RequireNumbers, RequireUppercaseCharacters, RequireLowercaseCharacters all true
• MaxPasswordAge <= 90
• PasswordReusePrevention >= 10

---

IA-05-02: Access key rotation (<=90 days)

CJIS reference: CJIS v6.0 IA-5 | Priority: P1*

aws iam generate-credential-report >/dev/null 2>&1; sleep 2
aws iam get-credential-report --query Content --output text | base64 -d > /tmp/cred-report.csv
python3 - <<'PY'
import csv, datetime
now = datetime.datetime.utcnow()
over = []
with open('/tmp/cred-report.csv') as f:
    for row in csv.DictReader(f):
        for k in ('access_key_1_last_rotated', 'access_key_2_last_rotated'):
            v = row.get(k, 'N/A')
            if v in ('N/A', 'no_information', ''): continue
            age = (now - datetime.datetime.strptime(v.split('+')[0].rstrip('Z'), '%Y-%m-%dT%H:%M:%S')).days
            if age > 90:
                over.append((row['user'], k, age))
for u, k, a in over:
    print(f"{u}: {k} age {a}d")
PY

---

IA-07-01: FIPS 140-2/3 — KMS usage for cryptographic operations

CJIS reference: CJIS v6.0 IA-7 | Priority: P1*

# Check partition (GovCloud = FIPS by default)
aws sts get-caller-identity --query 'Arn' --output text | grep -q 'aws-us-gov' && echo "GovCloud (FIPS default)" || echo "Commercial (FIPS opt-in)"
# KMS keys in use:
aws kms list-keys --query 'Keys[].KeyId' --output text | wc -w

Questionnaire follow-up: "Is AWS_USE_FIPS_ENDPOINT=true set in your application runtime config?"

---

IA-08-01: Non-organizational users — federated access

CJIS reference: CJIS v6.0 IA-8 | Priority: P1

aws sso-admin list-instances --output json 2>/dev/null
aws iam list-saml-providers --query 'SAMLProviderList[].Arn' --output json 2>/dev/null
aws iam list-open-id-connect-providers --query 'OpenIDConnectProviderList[].Arn' --output json 2>/dev/null

---

IA-11-01: Re-authentication — STS session duration checks

CJIS reference: CJIS v6.0 IA-11 | Priority: P1

aws iam list-roles --query 'Roles[?!starts_with(Path, `/aws-service-role/`)].{Name:RoleName,MaxSession:MaxSessionDuration}' --output json

Rationale: IA-11 requires re-authentication under defined circumstances. Long STS sessions may bypass re-authentication expectations.

---

Summary

Total: 10 checks. Expected time: ~2 min.

SC — Systems and Communications Protection — Programmatic Checks

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Execute in order. Each check uses read-only AWS CLI. Record results as

COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE / UNABLE_TO_ASSESS with severity per

`../severity-classification.md`.

SC family (Priority P1) — boundary protection, transmission confidentiality (FIPS TLS 1.2+), cryptographic key management, protection of information at rest.

---

SC-07-01: Boundary protection — VPC isolation, no IGW on CJI VPC

CJIS reference: CJIS v6.0 SC-7 | Priority: P1*

aws ec2 describe-vpcs --query 'Vpcs[].{VpcId:VpcId,IsDefault:IsDefault,CidrBlock:CidrBlock}' --output json
# For each non-default VPC (CJI candidates):
aws ec2 describe-internet-gateways --filters Name=attachment.vpc-id,Values={vpc_id} --query 'InternetGateways[].InternetGatewayId' --output text

---

SC-07-02: Boundary protection — Security Groups and NACLs

CJIS reference: CJIS v6.0 SC-7 | Priority: P1*

aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0 --query 'SecurityGroups[].{Id:GroupId,Name:GroupName,Vpc:VpcId,Rules:IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]].{Proto:IpProtocol,FromPort:FromPort,ToPort:ToPort}}' --output json

---

SC-07-03: GuardDuty enabled for threat detection at boundary

CJIS reference: CJIS v6.0 SC-7 | Priority: P1*

aws guardduty list-detectors --output json
# For each detector:
aws guardduty get-detector --detector-id {id} --query '{Status:Status,Features:Features}' --output json 2>/dev/null

---

SC-07-04: WAF on internet-facing ALBs

CJIS reference: CJIS v6.0 SC-7 | Priority: P1*

aws elbv2 describe-load-balancers --query 'LoadBalancers[?Scheme==`internet-facing`].LoadBalancerArn' --output text | tr '\t' '\n' | while read lb; do
  waf=$(aws wafv2 get-web-acl-for-resource --resource-arn "$lb" --query 'WebACL.Name' --output text 2>/dev/null)
  [ -z "$waf" ] || [ "$waf" = "None" ] && echo "$lb: NO WAF"
done

---

SC-08-01: TLS policy on load balancers (>=TLS 1.2)

CJIS reference: CJIS v6.0 SC-8 | Priority: P1*

aws elbv2 describe-load-balancers --query 'LoadBalancers[].LoadBalancerArn' --output text | tr '\t' '\n' | while read lb; do
  aws elbv2 describe-listeners --load-balancer-arn "$lb" --query 'Listeners[?Protocol==`HTTPS` || Protocol==`TLS`].{Port:Port,SslPolicy:SslPolicy}' --output json
done

---

SC-08-02: RDS force-SSL

CJIS reference: CJIS v6.0 SC-8 | Priority: P1*

aws rds describe-db-instances --query 'DBInstances[].{Id:DBInstanceIdentifier,Engine:Engine}' --output json
# For each PostgreSQL/MySQL instance, check parameter group for force_ssl/require_secure_transport:
aws rds describe-db-parameters --db-parameter-group-name {pg_name} --query 'Parameters[?ParameterName==`rds.force_ssl` || ParameterName==`require_secure_transport`].{Name:ParameterName,Value:ParameterValue}' --output json

---

SC-08-03: S3 bucket policy denies plaintext (deny non-SSL)

CJIS reference: CJIS v6.0 SC-8 | Priority: P1*

aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | while read b; do
  pol=$(aws s3api get-bucket-policy --bucket "$b" --query Policy --output text 2>/dev/null)
  echo "$pol" | grep -q 'aws:SecureTransport.*false' || echo "$b: NO SSL-ONLY POLICY"
done

---

SC-12-01: KMS key rotation enabled

CJIS reference: CJIS v6.0 SC-12 | Priority: P1*

aws kms list-keys --query 'Keys[].KeyId' --output text | tr '\t' '\n' | while read key; do
  mgr=$(aws kms describe-key --key-id "$key" --query 'KeyMetadata.KeyManager' --output text 2>/dev/null)
  state=$(aws kms describe-key --key-id "$key" --query 'KeyMetadata.KeyState' --output text 2>/dev/null)
  if [ "$mgr" = "CUSTOMER" ] && [ "$state" = "Enabled" ]; then
    rot=$(aws kms get-key-rotation-status --key-id "$key" --query 'KeyRotationEnabled' --output text 2>/dev/null)
    [ "$rot" = "False" ] && echo "$key: ROTATION DISABLED"
  fi
done

---

SC-13-01: FIPS endpoints — partition and endpoint check

CJIS reference: CJIS v6.0 SC-13 | Priority: P1*

# Partition check
aws sts get-caller-identity --query 'Arn' --output text | grep -q 'aws-us-gov' && echo "GovCloud (FIPS default)" || echo "Commercial (FIPS opt-in)"
# VPC endpoints with FIPS service names
aws ec2 describe-vpc-endpoints --query 'VpcEndpoints[].ServiceName' --output text | tr '\t' '\n' | grep -i fips || echo "No FIPS VPC endpoints"

---

SC-28-01: EBS encryption by default

CJIS reference: CJIS v6.0 SC-28 | Priority: P1*

aws ec2 get-ebs-encryption-by-default --query 'EbsEncryptionByDefault' --output text

---

SC-28-02: No unencrypted EBS volumes in use

CJIS reference: CJIS v6.0 SC-28 | Priority: P1*

aws ec2 describe-volumes --filters Name=encrypted,Values=false --query 'Volumes[?Attachments[0].State==`attached`].{Id:VolumeId,Instance:Attachments[0].InstanceId}' --output json

---

SC-28-03: RDS encryption at rest

CJIS reference: CJIS v6.0 SC-28 | Priority: P1*

aws rds describe-db-instances --query 'DBInstances[?StorageEncrypted==`false`].{Id:DBInstanceIdentifier,Engine:Engine}' --output json

---

SC-28-04: S3 default encryption

CJIS reference: CJIS v6.0 SC-28 | Priority: P1*

aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | while read b; do
  enc=$(aws s3api get-bucket-encryption --bucket "$b" --query 'ServerSideEncryptionConfiguration.Rules[0].ApplyServerSideEncryptionByDefault.SSEAlgorithm' --output text 2>/dev/null)
  [ -z "$enc" ] || [ "$enc" = "None" ] && echo "$b: NO DEFAULT ENCRYPTION"
done

---

SC-28-05: DynamoDB and EFS encryption

CJIS reference: CJIS v6.0 SC-28 | Priority: P1*

aws efs describe-file-systems --query 'FileSystems[?Encrypted==`false`].{Id:FileSystemId}' --output json
aws dynamodb list-tables --query 'TableNames' --output text | tr '\t' '\n' | while read t; do
  sse=$(aws dynamodb describe-table --table-name "$t" --query 'Table.SSEDescription.SSEType' --output text 2>/dev/null)
  [ "$sse" = "None" ] || [ -z "$sse" ] && echo "$t: AWS-OWNED KEY (default)"
done

---

Summary

Total: 14 checks. Expected time: ~4 min.

SI — System and Information Integrity — Programmatic Checks

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Execute in order. Each check uses read-only AWS CLI. Record results as

COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE / UNABLE_TO_ASSESS with severity per

`../severity-classification.md`.

SI family (Priority P1) — flaw remediation, malicious code protection, system monitoring, software integrity.

---

SI-02-01: Inspector findings — critical/high vulnerabilities

CJIS reference: CJIS v6.0 SI-2 | Priority: P1

aws inspector2 batch-get-account-status --query 'accounts[].{AccountId:accountId,Ec2:resourceState.ec2.status,Ecr:resourceState.ecr.status,Lambda:resourceState.lambda.status}' --output json 2>/dev/null
aws inspector2 list-findings --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}]}' --max-results 10 --query 'findings[].{Title:title,Severity:severity,Resource:resources[0].id}' --output json 2>/dev/null

Rationale: SI-2 requires identification and remediation of flaws. Without vulnerability scanning, the organization cannot demonstrate compliance.

---

SI-02-02: SSM Patch Manager compliance

CJIS reference: CJIS v6.0 SI-2 | Priority: P1

aws ssm list-compliance-summaries --query 'ComplianceSummaryItems[?ComplianceType==`Patch`].{Type:ComplianceType,Compliant:CompliantSummary.CompliantCount,NonCompliant:NonCompliantSummary.NonCompliantCount}' --output json

---

SI-03-01: GuardDuty Malware Protection enabled

CJIS reference: CJIS v6.0 SI-3 | Priority: P1

aws guardduty list-detectors --output text | tr '\t' '\n' | while read det; do
  aws guardduty get-detector --detector-id "$det" --query 'Features[?Name==`EBS_MALWARE_PROTECTION`].{Name:Name,Status:Status}' --output json 2>/dev/null
done

Rationale: SI-3 requires malicious code protection mechanisms at system entry/exit points. GuardDuty Malware Protection scans EBS volumes for malware.

---

SI-04-01: GuardDuty enabled (system monitoring)

CJIS reference: CJIS v6.0 SI-4 | Priority: P1

aws guardduty list-detectors --output json

---

SI-04-02: Security Hub enabled

CJIS reference: CJIS v6.0 SI-4 | Priority: P1

aws securityhub describe-hub --output json 2>/dev/null

---

SI-04-03: CloudWatch alarms for security events

CJIS reference: CJIS v6.0 SI-4 | Priority: P1

aws cloudwatch describe-alarms --query 'MetricAlarms[?contains(AlarmName, `Security`) || contains(AlarmName, `Unauthorized`) || contains(AlarmName, `Root`) || contains(AlarmName, `IAM`)].{Name:AlarmName,State:StateValue}' --output json

---

SI-07-01: ECR image scanning enabled

CJIS reference: CJIS v6.0 SI-7 | Priority: P1

aws ecr describe-repositories --query 'repositories[].{Name:repositoryName,ScanOnPush:imageScanningConfiguration.scanOnPush}' --output json 2>/dev/null

---

SI-07-02: Lambda code signing (if Lambda processes CJI)

CJIS reference: CJIS v6.0 SI-7 | Priority: P1

aws lambda list-code-signing-configs --query 'CodeSigningConfigs[].{Id:CodeSigningConfigId,Description:Description}' --output json 2>/dev/null
aws lambda list-functions --query 'Functions[].{Name:FunctionName,CodeSigningConfig:CodeSigningConfigArn}' --output json

---

Summary

Total: 8 checks. Expected time: ~2 min.

CJIS Readiness Checklist

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Use this checklist when performing a CJIS compliance gap assessment. Flag each item as: ✅ Met | ⚠️ Partial | ❌ Not Met | N/A

Items are grouped by control family and priority. P1/P2 items are mandatory for compliance. P3/P4 items are recommended.

---

IA — Identification and Authentication (P1) — MANDATORY

• [ ] Advanced authentication (MFA) required for all CJI access
• [ ] MFA enforced on AWS console access for all IAM users
• [ ] MFA enforced on VPN/remote access to CJI environment
• [ ] Root account has MFA enabled and no access keys
• [ ] Password policy: minimum 20 characters, complexity requirements
• [ ] Passwords changed at maximum 90-day intervals
• [ ] Account lockout after no more than 5 consecutive failed attempts
• [ ] Service accounts use IAM roles (not long-lived access keys) where possible
• [ ] Access keys rotated every 90 days
• [ ] Unique user IDs — no shared accounts for CJI access
• [ ] FIPS 140-2/3 validated cryptographic modules in use (GovCloud or FIPS endpoints)

SC — Systems and Communications Protection (P1) — MANDATORY

• [ ] All CJI data encrypted in transit using TLS 1.2+ with FIPS 140-2/3 validated modules
• [ ] FIPS endpoints enabled for AWS API calls (AWS_USE_FIPS_ENDPOINT=true or GovCloud)
• [ ] VPN connections use FIPS-compliant cipher suites (AES-256, SHA-256+, IKEv2)
• [ ] CJI workloads isolated in dedicated VPCs (no IGW or strictly controlled)
• [ ] VPC endpoints configured for AWS services to avoid internet transit
• [ ] Network segmentation enforced via security groups and NACLs
• [ ] GuardDuty enabled for boundary threat detection
• [ ] WAF deployed on internet-facing load balancers (if applicable)
• [ ] All CJI data encrypted at rest (EBS, RDS, S3, DynamoDB, EFS) using KMS CMKs
• [ ] EBS encryption-by-default enabled at account level
• [ ] KMS customer-managed keys have automatic rotation enabled
• [ ] Direct Connect or Site-to-Site VPN for agency connectivity

AC — Access Control (P1) — MANDATORY

• [ ] Access to CJI based on least privilege and need-to-know
• [ ] Role-based access control (RBAC) implemented via IAM roles/policies
• [ ] Account provisioning/de-provisioning procedures documented
• [ ] Access reviews performed at least annually
• [ ] Inactive accounts disabled after 90 days
• [ ] Session lock after 30 minutes of inactivity
• [ ] Remote access to CJI only via encrypted channel (SSM Session Manager or VPN)
• [ ] No public S3 buckets, public EC2 instances, or public RDS instances in CJI environment
• [ ] S3 Block Public Access enabled at account level
• [ ] SCPs restrict CJI account actions to authorized services and regions
• [ ] IAM Access Analyzer enabled with no active external-access findings
• [ ] No overly-permissive IAM policies (*:* on CJI resources)

CM — Configuration Management (P1) — MANDATORY

• [ ] Secure baseline configurations defined (CIS Benchmarks or DISA STIGs)
• [ ] AWS Config enabled and recording in CJI accounts
• [ ] Config rules or conformance packs deployed for CJIS-relevant checks
• [ ] Security Hub enabled with NIST 800-53 or FedRAMP standard
• [ ] Patch management process defined with SLAs
• [ ] Critical/high patches applied within 30 days
• [ ] Systems Manager Patch Manager or equivalent in use
• [ ] All EC2 instances managed by SSM
• [ ] Change management process documented and followed
• [ ] Security groups reviewed regularly for least privilege
• [ ] AMIs/container images hardened and scanned before deployment
• [ ] Software/system component inventory maintained

SI — System and Information Integrity (P1) — MANDATORY

• [ ] Inspector enabled for EC2, Lambda, and ECR scanning
• [ ] Critical vulnerabilities remediated within defined SLAs
• [ ] GuardDuty Malware Protection enabled
• [ ] Security Hub aggregating findings from all detection services
• [ ] CloudWatch alarms configured for security events
• [ ] ECR image scanning enabled (scan-on-push)
• [ ] Lambda code signing considered for CJI-processing functions

AU — Audit and Accountability (P2) — MANDATORY

• [ ] CloudTrail enabled in all regions with management events
• [ ] CloudTrail data events for S3 buckets containing CJI and Lambda functions
• [ ] CloudTrail log file validation enabled
• [ ] CloudTrail logs encrypted with KMS CMK
• [ ] VPC Flow Logs enabled for all CJI VPCs
• [ ] Application-level logging captures CJI access events (who accessed what, when)
• [ ] Log retention minimum 3 years (CJIS v6.0 requirement)
• [ ] Logs protected from unauthorized modification (S3 Object Lock, separate account)
• [ ] CloudTrail delivery failure alarms configured
• [ ] Centralized log aggregation in place (CloudWatch, OpenSearch, or third-party SIEM)
• [ ] Audit review capability (CloudTrail Lake, Athena, or Security Hub)

CP — Contingency Planning (P2) — MANDATORY

• [ ] AWS Backup plans exist for all CJI resources
• [ ] Backup vaults encrypted with KMS CMKs
• [ ] RDS automated backups enabled with adequate retention (>= 7 days)
• [ ] RDS Multi-AZ enabled for CJI databases
• [ ] Cross-region backup replication configured for disaster recovery
• [ ] Contingency plan documented and tested at least annually
• [ ] Recovery time objectives (RTO) and recovery point objectives (RPO) defined

PS — Personnel Security (P2) — MANDATORY

• [ ] Fingerprint-based background checks completed for all personnel with unescorted access to unencrypted CJI
• [ ] Background checks completed BEFORE granting CJI access
• [ ] Background check renewal schedule defined (per state CSA, typically every 5 years)
• [ ] Screening applies to: employees, contractors, cloud admins with potential CJI access
• [ ] Termination procedures include immediate CJI access revocation
• [ ] Personnel security records maintained and auditable

IR — Incident Response (P2) — MANDATORY

• [ ] Incident Response Plan (IRP) documented and approved
• [ ] IRP covers: detection, containment, eradication, recovery, post-incident analysis
• [ ] Reporting procedures defined — notify CSO/CSA and FBI CJIS Division
• [ ] IR team roles and contact information documented
• [ ] IRP tested (tabletop or functional exercise) at least annually
• [ ] GuardDuty or equivalent threat detection enabled
• [ ] Automated alerting configured for security events

CA — Assessment, Authorization, and Monitoring (P2) — MANDATORY

• [ ] Prepared for triennial CJIS audit by state CSA or FBI
• [ ] Self-assessment completed using CJIS Security Policy audit checklist
• [ ] Security Hub enabled with findings reviewed regularly
• [ ] Evidence collection process defined (config exports, policy docs, reports)
• [ ] Previous audit findings remediated and documented

---

AT — Awareness and Training (P3) — RECOMMENDED

• [ ] Security awareness training program established for all CJI-authorized personnel
• [ ] Training completed within 6 months of initial assignment and refreshed every 2 years
• [ ] Training covers: rules of behavior, incident response, media protection, social engineering
• [ ] Training records maintained and auditable

PE — Physical and Environmental Protection (P3) — RECOMMENDED

• [ ] Physical security of on-premises facilities documented (if applicable)
• [ ] AWS physical security inherited — documented via SOC 2 / FedRAMP reports
• [ ] Visitor access controls in place for on-premises CJI facilities

SA — System and Services Acquisition (P3) — RECOMMENDED

• [ ] System development lifecycle (SDLC) includes security requirements
• [ ] Security testing performed during development
• [ ] Third-party services assessed for CJIS compliance

SR — Supply Chain Risk Management (P3) — RECOMMENDED

• [ ] Supply chain risk management plan documented
• [ ] Component/service provenance tracked
• [ ] Acquisition agreements include security requirements

MA — Maintenance (P3) — RECOMMENDED

• [ ] System maintenance procedures documented
• [ ] Remote maintenance performed via approved tools (SSM)
• [ ] Maintenance activities logged

PL — Planning (P3) — RECOMMENDED

• [ ] System security plan documented
• [ ] Rules of behavior defined and acknowledged by all users
• [ ] Security architecture documented

Section 5.1 — Information Exchange Agreements — MANDATORY

• [ ] CJIS Security Addendum signed by AWS for applicable state(s)
• [ ] Management Control Agreement (MCA) in place with contractors/vendors
• [ ] All contractor personnel with CJI access have individually signed the Security Addendum
• [ ] Interconnection Security Agreements (ISAs) documented

Section 5.20 — Mobile Devices — IF APPLICABLE

• [ ] MDM solution deployed if mobile devices access CJI
• [ ] Remote wipe capability enabled
• [ ] Mobile devices encrypted (full-device encryption)
• [ ] Consider AWS WorkSpaces or AppStream as alternatives to CJI on mobile devices

CJIS Assessment Report Template

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Use this template verbatim when emitting the final Markdown report. A consistent shape is what makes reports reproducible across engagements and auditable as evidence.

Output path: cjis-reports/cjis-assessment-{YYYY-MM-DD}.md

---

Section 1: Assessment Metadata

# CJIS Security Policy Compliance Assessment

**Report date**: {YYYY-MM-DD}
**Assessor**: {name or "Claude CJIS Skill"}
**Target account**: {account_id}
**Target region(s)**: {regions}
**AWS partition**: {GovCloud (US) | Commercial}
**State CSA**: {state, or "Not specified"}
**CJIS Security Policy version**: v6.0
**Assessment mode**: {Quick Scan | Standard | Full | Questionnaire}
**Control families assessed**: {family list}
**Credentials used**: {role ARN} (read-only verified)

---

Section 2: Executive Summary

Two-paragraph prose summary written for a CIO/CSO audience. NOT a list. Cover:

• Overall posture — one sentence (e.g., "The environment is Substantially Compliant with 2 Audit Blockers in IA and SC that must be remediated before the next triennial audit.")
• Biggest risk — what would an auditor flag first?
• Strongest areas — what's working
• The remediation ask — how much work and what kind (configuration vs organizational vs architectural)

Follow with the summary table:

## Summary of Findings

| Control Family | Status | Audit Blockers | Finding Risks | Gaps |
|---|---|---|---|---|
| IA — Identification & Auth | **Non-Compliant** | 1 | 2 | 0 |
| SC — Systems & Comms | Substantially Compliant | 0 | 1 | 2 |
| AC — Access Control | Compliant | 0 | 0 | 1 |
| AU — Audit & Accountability | Substantially Compliant | 0 | 1 | 1 |
| CM — Config Management | At Risk | 0 | 2 | 3 |
| SI — System Integrity | Substantially Compliant | 0 | 1 | 1 |
| CP — Contingency Planning | Compliant | 0 | 0 | 2 |
| **TOTAL** | — | **1** | **7** | **10** |

**Top 3 items to remediate before audit:**
1. {First Audit Blocker — family, check ID, one-line fix}
2. {Second item}
3. {Third item}

---

Section 3: Per-Control-Family Findings

One subsection per control family that was assessed. Fixed structure:

## {Family Code} — {Family Name}

**Status**: {Compliant | Substantially Compliant | At Risk | Non-Compliant | Not Assessed}
**Checks executed**: {n} — {passed} passed, {failed} failed, {na} N/A, {unable} unable to assess

### Findings

| ID | Check | Severity | Resource(s) | Finding | Remediation |
|---|---|---|---|---|---|
| IA-02-03 | MFA on IAM users | AUDIT BLOCKER | 3 users | Users {a,b,c} have console access without MFA | Attach MFA-required policy; remediate within 24 hrs |
| IA-05-01 | Password policy | FINDING RISK | account-level | Min length is 12, CJIS requires >=20 | `aws iam update-account-password-policy --minimum-password-length 20` |
| IA-02-01 | Root MFA | INFO | root | MFA enabled | — |

### Organizational items

Any checks for this family that are organizational rather than technical — surface them as questions the user must answer offline:

- [ ] Do all personnel with CJI access have current fingerprint-based background checks? (PS)
- [ ] Is the CJIS Security Addendum on file with AWS for {state}? (Section 5.1)

Severity badges in the Severity column should be bolded for AUDIT BLOCKER and plain text for the rest, so the worst items jump out on a scan.

If Status = Not Assessed, explain why in a single line below the header (e.g., "Skipped — service not present in this account" or "Skipped — organizational-only family, see questionnaire").

---

Section 4: Remediation Roadmap

## Remediation Roadmap

### Immediate (0-2 weeks) — Audit Blockers + Quick Wins

| Item | Family | Severity | Effort | Owner |
|---|---|---|---|---|
| Enable MFA for 3 non-compliant IAM users | IA | AUDIT BLOCKER | 1 (mins) | IAM admin |
| Encrypt 2 unencrypted RDS instances (snapshot -> restore) | SC | AUDIT BLOCKER | 3 (days) | DBA |

### Short-term (2-8 weeks) — Finding Risks

| Item | Family | Severity | Effort | Owner |
|---|---|---|---|---|
| Tighten password policy to 20-char minimum | IA | FINDING RISK | 1 (mins) | IAM admin |
| Enable VPC Flow Logs on 2 VPCs | AU | FINDING RISK | 1 (mins) | Network |

### Medium-term (2-6 months) — Gaps and architectural items

| Item | Family | Severity | Effort | Owner |
|---|---|---|---|---|
| Adopt VPC endpoints to eliminate internet egress | AC/SC | GAP | 3 (days) | Network |

### Long-term (6-12 months) — Organizational & strategic

- [ ] Establish formal IR tabletop schedule (IR)
- [ ] Document Management Control Agreement with {contractor} (Section 5.1)
- [ ] Refresh personnel security screening process (PS)

Sort each phase by severity (Audit Blocker first) then by effort (lowest first) so Quick Wins bubble up.

---

Section 5: Organizational Questionnaire

The organizational families that cannot be assessed technically. Present as a checklist that the user needs to walk through with their CSO and HR. Pull directly from references/readiness-checklist.md, filtered to the families not covered by the technical scan.

## Organizational Readiness — User Action Required

These items cannot be verified from AWS APIs. Work with your CSO, TAC, and HR to confirm each.

### Section 5.1 — Information Exchange Agreements
- [ ] CJIS Security Addendum on file with AWS for {state}
- [ ] MCA in place with any contractors accessing CJI
- [ ] All contractor personnel individually signed the Security Addendum

### PS — Personnel Security
- [ ] Fingerprint-based background checks for all CJI-access personnel
- [ ] Background checks completed before access granted
- [ ] Renewal schedule defined and tracked

### AT — Awareness and Training
- [ ] Training program established
- [ ] ...

---

Section 6: Appendix — Raw Check Results

Include the full list of check IDs, the CLI command executed, the raw result, and the severity determination. This is audit evidence — do not truncate.

## Appendix A: Raw Check Results

### IA-02-03 — MFA on IAM users

**Command**:

aws iam generate-credential-report && sleep 2 aws iam get-credential-report --query Content --output text | base64 -d

**Result**:

alice: password_enabled=true, mfa_active=false bob: password_enabled=true, mfa_active=false charlie: password_enabled=true, mfa_active=false

**Severity**: AUDIT BLOCKER — IA-2 requires multi-factor authentication for all CJI access.

---

---

Section 7: Methodology & Caveats

One short page explaining:

• What the scan did and didn't do (read-only, specific families, single account/region)
• Which families are organizational and not covered by technical checks
• That CJIS compliance varies by state CSA — final determination always rests with the CSO
• Timestamp and assessor info so this report is dated and traceable
• Disclaimer: "This report is a point-in-time snapshot of technical configuration. It does not replace a formal CJIS audit by the CSA."

---

Formatting conventions

• Dates: YYYY-MM-DD (ISO)
• ARNs and resource IDs: backticks
• Severity labels: uppercase (AUDIT BLOCKER, FINDING RISK, GAP, INFO)
• Status labels: title case (Non-Compliant, At Risk)
• Commands: fenced code blocks with bash
• Control references: {Family}-{Number} format (e.g., IA-2, SC-28, AU-12)
• Never use emoji severity icons in the machine-readable tables — they break downstream parsing. Emoji OK in the Executive Summary prose only.

Severity Classification (CJIS v6.0 — Priority-Aligned)

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

Findings from CJIS checks are classified by the control's priority rating in v6.0 and how non-compliance affects an actual audit. The classes below are what the skill uses in reports and priority lists — they align directly with what a CSA auditor would flag.

Per-finding severity

Aggregate assessment status

At the end of a full assessment, each control family gets an aggregate status:

Do not use a numeric score or stars — control families are categorically different (PS personnel screening is not comparable to SC network protection), and averaging them misleads the reader.

"Cannot assess" vs "no finding"

These must be distinguished in the report. They mean very different things to an auditor.

Priority matrix (for the remediation roadmap)

Within a given family, order remediation by:

Priority = Severity weight x (1 / Fix effort)

Severity weight:
  AUDIT BLOCKER = 5
  FINDING RISK  = 3
  GAP           = 1

Fix effort:
  1 = single CLI command or console toggle (minutes)
  2 = configuration change across multiple resources (hours)
  3 = architectural change (days)
  4 = multi-account / multi-region rework (weeks)
  5 = organizational change — agreements, training, screening (months)

This produces a natural Quick Wins list (Audit Blockers with effort 1-2) that should go to the top of the roadmap.

Audit-heat map (which families fail audits most)

When summarizing, weight attention toward the families most often cited in real CJIS audits:

The skill's Quick Scan mode (IA + SC + AC) targets the three P1 families that account for the bulk of real-world audit findings.

Workflow Overview

Based on CJIS Security Policy v6.0 (effective December 2024).

Last verified against official source: 2026-05-21.

Check https://le.fbi.gov/cjis-division/cjis-security-policy-resource-center for newer versions.

4-Phase Assessment Flow

Phase 1: Bootstrap  (~2 min)     → Credential gate + scope confirmation (human-in-loop)
Phase 2: Discover   (~10-40 min) → Per-family programmatic scan (automated)
Phase 3: Analyze    (~5 min)     → Gap consolidation + remediation roadmap (automated)
Phase 4: Report     (~2 min)     → Markdown report, optional HTML render (automated)

flowchart TD
    A[User: Assess my env for CJIS] --> B{Phase 1: Bootstrap}
    B -->|Credentials read-only| C[Phase 2: Discover]
    B -->|Write perms / no creds| X[HALT — fix credentials]
    C --> C1[IA — Identification & Auth]
    C1 --> C2[SC — Systems & Comms]
    C2 --> C3[AC — Access Control]
    C3 --> C4[AU — Audit & Accountability]
    C4 --> C5[CM — Config Management]
    C5 --> C6[SI — System Integrity]
    C6 --> C7[CP — Contingency Planning]
    C7 --> D[Phase 3: Analyze]
    D --> D1[Per-family status rollup]
    D1 --> D2[Audit Blockers → Quick Wins]
    D2 --> D3[Organizational items → questionnaire]
    D3 --> E[Phase 4: Report]
    E --> E1[Markdown report]
    E --> E2[Optional HTML render]
    E1 --> F[Done]

Phase details

Phase 1: Bootstrap (~2 min)

• Human interaction: YES (only phase that needs it)
• Inputs: AWS credentials, target account/region(s), scope
• Outputs: Validated environment config
• Can fail: Yes — credential boundary violation or missing CLI
• Steps:

1. Verify aws --version 2. aws sts get-caller-identity — record ARN, account, region 3. Validate against `credential-boundary.md` — HALT if write-capable 4. Confirm scope with user: account(s), region(s), which families (default = P1 + P2 technical families), GovCloud vs commercial 5. Confirm state CSA (affects Section 5.1 addendum check)

Phase 2: Discover (~10-40 min)

• Human interaction: NO
• Inputs: Bootstrap config
• Outputs: Per-family findings with severity
• Order (by priority and audit impact):

1. IA (P1 — #1 audit finding area) 2. SC (P1 — boundary + encryption) 3. AC (P1 — access control) 4. AU (P2 — auditing) 5. CM (P1 — config management) 6. SI (P1 — flaw remediation) 7. CP (P2 — contingency)

• Execution rules:
• Load each family's check file on demand from references/programmatic-checks/
• Do NOT preload all check files — context blows up on a 7-family scan
• Each check records a result: COMPLIANT / NON_COMPLIANT / NOT_APPLICABLE / UNABLE_TO_ASSESS
• Per-finding severity per `severity-classification.md`
• Emit a short per-family summary before moving to the next family
• If AccessDenied on a check → mark UNABLE_TO_ASSESS and continue (do not halt)

Phase 3: Analyze (~5 min)

• Human interaction: NO
• Inputs: All per-family findings
• Outputs: Gap table, roadmap, questionnaire items
• Steps:

1. Roll up per-family status (Compliant / Substantially Compliant / At Risk / Non-Compliant / Not Assessed) 2. Extract Audit Blockers across all families → top of the remediation roadmap 3. Group remediation into phases: Immediate (0-2 wks), Short-term (2-8 wks), Medium-term (2-6 mo), Long-term (6-12 mo) 4. Surface organizational items (Section 5.1, AT, PE, PS, IR, MA, PL, SA, SR, CA) as questionnaire items for the user

Phase 4: Report (~2 min)

• Human interaction: NO
• Inputs: Analysis output
• Outputs: Markdown report (always), HTML report (on request)
• Generate per `report-template.md`
• Default output dir: cjis-reports/
• HTML render: python3 scripts/generate-html-report.py cjis-reports/cjis-assessment-{date}.md

Assessment modes

Priority-First ordering rationale

The family order in Standard/Full mode is priority-and-audit-heat-weighted:

1. IA (P1) first — #1 audit finding nationwide. MFA gaps are the most common audit failure. 2. SC (P1) — boundary protection + encryption at rest/transit. FIPS compliance is binary. 3. AC (P1) — access control, public exposure, least privilege. 4. AU (P2) — auditing. Without logging, nothing else can be verified at audit. 5. CM (P1) — config management, patching. Pulls EC2/SSM data that can take longest. 6. SI (P1) — flaw remediation, monitoring. Depends on Inspector/GuardDuty state. 7. CP (P2) — contingency planning. Backup verification, least likely to be an Audit Blocker.

This order maximizes value when a scan is interrupted — the highest-risk findings surface first.

Error handling

Multi-account / multi-region

• Multi-account: run bootstrap + discover per account, then merge findings in Phase 3 with a per-account column in the report.
• Multi-region: run discover per region sequentially; most CJIS resources should be in a single region anyway, but global services (IAM, CloudTrail org trails, S3) are assessed once.
• If the user mentions an AWS Organizations structure, ask whether to cover just the CJI OU or all accounts — default to CJI OU only.