Compliance implementation backlog¶
Status: Engineering implementation complete; external and live-environment work open | Last reviewed: 2026-08-30
This backlog divides the compliance implementation plan into reviewable tasks. Read the plan and the relevant service instructions before taking a task.
The repository implementation covered the policy, persistence, publish/runtime, audit, privacy, encryption, PCI, AI governance, regulated AWS, Helm, supply-chain, database-invariant, and CI work in this backlog. The implementation guide records the resulting paths and activation procedure. Entries below remain useful as design history and acceptance criteria.
Open work now requires one or more of: a live regulated environment, named control owners, provider contracts, customer processor adapters, operating evidence, penetration or recovery exercises, independent assessment, certification, PCI validation, or FedRAMP authorization. The GovCloud tasks remain planning-only and must not be marked deployed.
Execution rules¶
- Use one task per PR unless the task names a coordinated migration. Title it
[<service>] <description>and record the task ID. - Keep every profile claim in
draftuntil the applicable external party validates it. A profile label grants no certification or authorization. - Allocate the next active migration number at implementation time. Follow migration conventions, update
000_full_schema.sql, register the migration inmigrate-city-db.sh, and test idempotency plus RLS. - Read the root and service
CLAUDE.mdfiles before editing. Preserve service-registration, collaboration-shape, payment, and publish-path invariants. - Add deny-path tests. A test suite that proves only allowed behavior cannot validate a compliance gate.
- Update developer docs with each behavior/config/schema/ops change. Update the user guide and
mkdocs.userguide.ymlfor UI changes. - Keep secrets, customer data, audit samples, assessor workpapers, and production evidence out of Git. Commit schemas, templates, hashes, and evidence pointers.
- Complete the task's code tests and its evidence check before marking it done. Record any live-environment check that the local suite cannot perform.
Dependency summary¶
| Foundation | Unlocks |
|---|---|
| G1 boundaries and claims | All profile, infrastructure, and assurance tasks |
| G2 control catalog and G3 data/threat models | Policy schema, data lifecycle, audit, cloud controls |
| PF1–PF3 policy contract and database | Authoring, runtime, deployment ceiling, AI governance |
| AU1–AU3 audit pipeline | Regulated production, PCI validation, federal evidence |
| PR1–PR4 lifecycle | HIPAA/privacy release gate |
| CR1–CR3, KH1–KH3, AW1–AW3, SD1–SD3 | Commercial regulated and specialized boundaries |
| PC1–PC3 | PCI assessor validation |
| AI1–AI3 | ISO 42001 readiness and regulated AI use |
| FR1–FR3 | FedRAMP assessment/authorization work |
Governance and design¶
G1: approve claims and boundaries¶
Depends: none. Addresses: CR-01, CR-14.
Create compliance/decisions/ records for the legal entity, product/service description, target claims, deployment boundaries, data classes, regulatory roles, customer controls, providers, administrators, build/support paths, RTO/RPO, and exception authority. Record exclusions and prohibited marketing language.
Verify: Security, privacy, product, platform, legal, and executive owners approve each record. The commercial, PCI, privacy, and federal diagrams have no unnamed trust boundary or owner.
G2: create the unified control catalog¶
Depends: G1. Addresses: CR-01, CR-14.
Add compliance/controls/catalog.yaml and its schema. Give each control a stable ID, objective, implementation owner, operator, frequency, test, evidence type, customer responsibility, and mappings to all applicable frameworks. Link current authentication/payment controls instead of copying them.
Verify: Schema validation passes; each in-scope framework requirement maps to a control, an accepted gap, or an applicability decision; each control has one accountable owner.
G3: baseline data flows and threat models¶
Depends: G1. Addresses: CR-03, CR-09, CR-10, CR-11, CR-12.
Add versioned flows for text, voice, workflow, knowledge, authentication, payment, observability, archive, support, backup, and AI evaluation paths. Model tenant escape, provider fallback, prompt/data exfiltration, payment leakage, audit loss, deletion failure, privileged administration, build compromise, and federal boundary crossing.
Verify: Trace one synthetic identifier through each store and processor. The resulting inventory names the creator, reader, exporter, retention rule, encryption class, region, and deletion adapter for each copy.
Policy and enforcement foundation¶
PF1: define signed profile contracts¶
Depends: G2, G3. Addresses: CR-01, CR-10, CR-12.
Create compliance/schemas/ plus initial unregulated-v1, commercial-regulated-v1, privacy-regional-v1, pci-segmented-v1, and fedramp-class-d-v1 manifests. Define deployment, data, provider/model, product, security, evidence, exception, review, and expiry fields. Add exact Bedrock API/model/inference-profile/region entries rather than provider-family wildcards. Package RFC 8785-canonical JSON in a DSSE/in-toto envelope, sign it with the release identity, and pin accepted signers plus monotonic revisions.
For Bedrock inference profiles, model both the inference-profile ARN and its foundation-model ARN requirement. Prohibit global inference profiles when residency matters. Require a current source and review date for each eligibility entry.
Verify: scripts/compliance/validate-profiles accepts each committed profile, rejects unknown keys, expired records, wrong signers, replay, and downgrade, and produces stable hashes across repeated runs.
PF2: implement matching TypeScript and Python decision engines¶
Depends: PF1. Addresses: CR-12.
Create shared/compliance-policy/ and libs/compliance/. Both implementations load the same manifest, verify its signature/hash, evaluate deployment/tenant/version/runtime context, and return a structured allow/deny decision with rule IDs. Avoid network calls in the decision path.
Add shared vectors for provider, region, model, data class, recording, export, fallback, payment, guardrail, expired policy, and exception decisions. Keep canonicalization in one published specification and test both runtimes byte for byte.
Verify: Node and Python return identical hashes, rule IDs, and outcomes for every vector. Mutation tests remove a rule or change a model ID and make CI fail.
PF3: add profile, snapshot, and exception schema¶
Depends: PF1. Addresses: CR-01, CR-11, CR-12.
Add immutable compliance_profile_revisions, tenant-scoped tenant_compliance_assignments, and append-only compliance_exceptions. Add profile key/revision/hash/decision columns to agent versions, workflow versions, conversations, workflow executions, archives, and payment sessions. Add Compliance:View and Compliance:Manage permissions.
Enforce one active assignment per tenant/profile dimension, two-person approval for enforce mode, expiry constraints, RLS, and database guards against editing published revisions or approved exceptions. Backfill existing records with unregulated-v1 without making a regulated claim.
Verify: Fresh boot, reapplication, schema drift, RLS, immutable-row, expiry, privilege, and rollback tests pass. Restoring an older database does not assign a stronger profile than its records support.
PF4: enforce policy on every authoring and publish path¶
Depends: PF2, PF3. Addresses: CR-11, CR-12.
Add one shared validator to publishAgentVersion(), workflow publish, management API/MCP publish, capability publish, imports, cloning, and AI generation. Inspect direct stages plus hidden remote-analysis, fallback, tool/MCP, knowledge, telemetry, recording, CCaaS, and payment paths. Store the decision and policy hash inside the publish transaction.
Add admin APIs and settings UI for assignment, posture, validation results, and typed exception requests. Render ineligible providers/models as unavailable and explain the blocking rule. The server remains authoritative.
Verify: Unit tests cover each publish entry point; route-auth audit passes; concurrent profile changes cannot publish against a stale hash; browser tests cover assignment, deny, approved exception, expiry, and republish. Update the developer and user guides.
PF5: enforce policy at session, workflow, and provider invocation¶
Depends: PF2, PF3, PF4. Addresses: CR-10, CR-12.
Verify the pinned decision before conversation/session creation, orchestrator preflight, workflow dispatch, batch execution, tool/MCP invocation, provider construction, and fallback. Add a signed internal compliance context to the voice/workflow contracts; resolve it from trusted database state and deployment identity. Never trust client-supplied SessionConfig.metadata as profile evidence.
Add the gate to preflight.py, service mapping/constructors, async-agent workflow config/execution, and conversation-api session creation. Deny cross-profile fallbacks and emit a sanitized audit decision.
Verify: Start attempts with a stale hash, wrong tenant, wrong region/model, prohibited tool, spoofed metadata, unavailable policy, or external fallback fail before data leaves the boundary. Existing unregulated sessions remain compatible during rollout.
PF6: enforce the deployment ceiling¶
Depends: PF1, PF2. Addresses: CR-10, CR-12.
Generate a signed deployment manifest from Terraform outputs, image digests, and profile inputs. Add regulated Helm overlays and mount the manifest read-only. Each Tier 1/2 service validates profile, partition, account, region, endpoints, enabled features, image digest, and policy hash at startup.
Add values-profile-commercial-regulated.yaml, values-profile-pci-segmented.yaml, and values-profile-fedramp-class-d.yaml. Keep profile overlays composable with agents/workflows/no-SIP product profiles. Prevent a tenant assignment from exceeding the deployment ceiling.
Verify: Rendered-chart tests cover valid combinations; mismatched account, region, hash, signature, or feature causes readiness failure and blocks regulated traffic.
Audit and evidence¶
AU1: create transactional append-only audit events¶
Depends: G2, PF3. Addresses: CR-02.
Add tenant-scoped security_audit_events, security_audit_outbox, checkpoints, and separate mutable projections. Record event ID/sequence, tenant, actor/delegation, action, target, decision/rule, request/trace, result, reason, policy hash, authoritative time, and integrity hash. Exclude content, prompts, secrets, PAN, and unnecessary personal data.
Use database functions/triggers to prevent update/delete and to insert the event/outbox in the same transaction as the protected change. Keep legacy audit_log read-only during migration.
Verify: Rollback removes both business change and event; forced event failure blocks high-risk changes; update/delete attempts fail; tenant isolation and sequence-gap tests pass.
AU2: instrument critical application actions¶
Depends: AU1. Addresses: CR-02, CR-13.
Create TypeScript and Python audit clients that require a transaction or explicit durability class. Cover authentication/authorization, access changes, secrets, provider/model/profile changes, publish/execute, exports, privacy requests, recordings, payment actions, support/admin access, exceptions, keys, and evidence access. Replace writeAuditLog() on critical paths. For external side effects, commit an intent before the call, append its result afterward, and alert on unreconciled intents.
Verify: A control-event matrix maps each action to a test. Fault injection proves required events cannot disappear behind caught exceptions. Existing authentication/payment append-only events reconcile to the unified stream without duplicating PAN or OTP data.
AU3: export, retain, and reconcile audit evidence¶
Depends: AU1, AU2, AW1. Addresses: CR-02, CR-13.
Create apps/audit-exporter/ and its chart. Export ordered event batches to a dedicated KMS key and S3 Object Lock bucket, then to the SIEM. Use idempotent object names, content hashes, checkpoints, dead-letter handling, lag alerts, and a reconciliation job. Separate searchable projections from WORM records.
Verify: Duplicate delivery stays idempotent; a dropped batch, changed object, stalled checkpoint, denied KMS call, or SIEM outage raises an alert. Restore/replay preserves sequence and hash verification. Document retention and evidence access review.
Privacy and data lifecycle¶
PR1: create data and retention catalogs¶
Depends: G3, PF1. Addresses: CR-03.
Define data classes, purposes, residency zones, retention classes, deletion behavior, legal bases/contract roles, and processor destinations in compliance/data/. Add immutable retention-policy revisions and pin them to conversations, workflow executions, recordings, archives, exports, logs, and AI evaluation data at creation.
Verify: CI fails when a schema/store/provider has no catalog entry. Profile tests reject a retention override, region, export, or recording mode outside policy.
PR2: add rights, erasure, and legal-hold records¶
Depends: PR1, AU1. Addresses: CR-03.
Add tenant-scoped data-subject requests, identity-verification state, erasure jobs/targets/receipts, correction/export jobs, opt-out/GPC state, legal holds, and restoration-replay ledger. Expose authenticated admin/management APIs with separate requester, approver, and executor roles.
Verify: RLS, privilege separation, request deadlines, hold precedence, idempotency, retry, appeal/escalation, and append-only receipt tests pass. API documentation and privacy operations docs match the state machine.
PR3: implement service-owned lifecycle adapters¶
Depends: PR2. Addresses: CR-03.
Create apps/privacy-worker/ as an orchestrator with no direct cross-service superuser credentials. Add scoped adapters to conversation-api, ai-manager, async-agent, catalog/search, object storage, archives, caches, and telemetry. Replace direct conversation deletion with a job that deletes database detail, recordings, attachments, archive objects/versions, indexes, caches, and derived content.
Preserve non-content audit receipts. Return 202 Accepted plus job status after the compatibility period.
Verify: Seed a traceable synthetic subject, complete access/correction/export/deletion, and prove absence from each live store and object version. Legal hold blocks deletion; partial failure retries without resurrecting data.
PR4: handle subprocessors and backup restoration¶
Depends: PR3, AW3. Addresses: CR-03, CR-12.
Add processor-adapter contracts for deletion/export receipts and contract deadlines. Record unsupported processors as profile blockers. Write the restore gate that replays tombstones/erasure ledger before traffic resumes, then verifies archives, indexes, caches, and outbound processors.
Verify: Mock processor delay/failure and a point-in-time database/object restore. The system keeps traffic closed until replay/reconciliation completes and emits evidence for exceptions it cannot erase.
Cryptography, identity, and Kubernetes¶
CR1: add cloud-neutral envelope encryption¶
Depends: G3. Addresses: CR-07.
Create a cryptography interface with AWS KMS, GCP KMS, Azure Key Vault, and local-development implementations. Store ciphertext format version, tenant/purpose encryption context, encrypted data key, algorithm, and key reference. Bound plaintext-key cache lifetime and memory; prohibit key or plaintext logging.
Verify: Known-answer, tamper, wrong-tenant/context, rotation, KMS outage, cache expiry, and recovery tests pass. Security review approves algorithms and provider SDK configuration.
CR2: migrate the global master-key data¶
Depends: CR1, PF3, AU1. Addresses: CR-07.
Add dual-read and new-format-only writes for integration/tool credentials and other application ciphertext. Build a resumable, tenant-batched re-encryption job with counts, hashes, dry run, rate limits, rollback window, and audit events. Remove legacy reads only after all environments reconcile.
Verify: Restore a pre-migration backup, run migration twice, rotate a tenant key, and decrypt all expected records. Wrong keys fail without data corruption. Update the key-rotation runbook.
CR3: enforce AWS keys and least-privilege identities¶
Depends: CR1, AW1. Addresses: CR-07, CR-08.
Add separate KMS keys/policies for application data, audit, objects, logs, backups, and secrets as the risk model requires. Pass CMKs to RDS, S3, cache, queues, logs, and backup modules. Replace wildcard IRSA subjects and shared bucket policies with exact service accounts, prefixes, actions, and encryption-context conditions.
Verify: IAM policy tests and Access Analyzer show no unintended cross-service/tenant path. Denied-path tests cover delete, decrypt, wrong prefix, wrong context, wrong region, and cross-account access. Key rotation/recovery tests pass.
KH1: make application containers non-root¶
Depends: G3. Addresses: CR-04.
Give each application image a fixed non-root UID/GID and writable paths. Set base-app defaults for runAsNonRoot, seccomp, dropped capabilities, privilege-escalation denial, read-only root filesystem, and resource bounds. Put media components that need capabilities in a documented exception class; exclude that class from the first federal text-only boundary.
Verify: Image and rendered-chart tests prove application pods meet the restricted policy. Runtime smoke tests cover temporary files, certificates, caches, migrations, code sandboxing, and media exceptions.
KH2: enforce service identity and network segmentation¶
Depends: KH1, PF6. Addresses: CR-04, CR-08.
Enable default-deny NetworkPolicies and strict mesh mTLS for regulated profiles. Replace the mesh authorization rule that permits all with explicit service call graphs. Disable service-account token automount where unused; bind exact service accounts and egress destinations. Isolate admin, payment, audit, privacy, data, and media namespaces.
Verify: Automated connectivity tests prove required edges and deny unlisted cross-namespace, metadata, internet, database, and control-plane paths. Mesh-disabled and sidecar-failure cases remain denied.
KH3: finish chart secrets, health, and disruption controls¶
Depends: KH1. Addresses: CR-04, CR-06.
Move the shared TURN password and remaining plaintext credentials to generated per-environment secrets with rotation. Require startup/readiness/liveness probes, resource requests/limits, HPA where applicable, topology spread, and PDBs for regulated Tier 1 services. Validate External Secrets refresh and failure behavior.
Verify: Secret rotation does not expose values or drop active traffic beyond the approved window. Pod/node/AZ disruption tests meet service objectives; missing probes or plaintext secret values fail chart policy.
AWS platform and secure delivery¶
AW1: build regulated AWS modules and account contracts¶
Depends: G1, G3. Addresses: CR-06, CR-07, CR-08, CR-13.
Create reusable regulated modules for KMS, evidence storage, private endpoints, DNS, logging destinations, backup vaults, and account assertions. Require account/organization IDs, partition, region, tags, log destinations, and CMKs as inputs. Add preconditions that reject public data services, unencrypted resources, broad CIDRs, or destroy-without-recovery defaults.
Verify: Terraform validate/plan and policy tests cover commercial and GovCloud partitions plus intentional negative fixtures. Separate state and deploy roles prevent cross-profile modification.
AW2: implement security logging and detection¶
Depends: AW1. Addresses: CR-13.
Manage or assert organization CloudTrail, AWS Config, GuardDuty, Security Hub, VPC/ELB/WAF/DNS/EKS audit logs, KMS/Secrets events, S3 data events, centralized immutable retention, alert routing, and case ownership. Add WAF/rate controls and private service endpoints; deny uncontrolled egress in regulated profiles.
Verify: A coverage reconciler compares accounts/regions/resources with active trails, rules, sensors, and destinations. Simulated credential misuse, public-resource drift, blocked egress, WAF event, and audit-log interruption create owned cases.
AW3: harden resilient data services and recovery¶
Depends: AW1, CR3. Addresses: CR-06.
Change regulated RDS to Multi-AZ with deletion protection, CMK, log exports, monitoring, maintenance controls, and approved backup retention. Use multi-node encrypted ElastiCache with failover and backups. Add S3 noncurrent-version lifecycle, replication where required, AWS Backup Vault Lock, cross-account recovery, and restore automation.
Verify: AZ failure, database failover, cache failover, object recovery, credential loss, point-in-time restore, and regional/account recovery exercises meet approved RTO/RPO and produce evidence.
SD1: make vulnerability gates full-scope and recurring¶
Depends: G2. Addresses: CR-05.
Turn PR scanning to blocking after a time-bounded baseline burn-down. Scan all source, dependencies, containers, IaC, secrets, nodes/clusters, and exposed applications on change and schedule. Reconcile the asset inventory with scan coverage; define severity/risk deadlines, exception expiry, re-scan, and metrics.
For the federal profile, encode current FedRAMP detection/reporting frequencies from the 2026 vulnerability rules rather than copying legacy monthly assumptions.
Verify: Seed a vulnerable dependency, container package, Terraform rule, leaked test secret, and overdue finding; each makes the proper gate or alert fail. Weekly/monthly jobs prove full inventory coverage.
SD2: add SBOM, provenance, signing, and admission¶
Depends: SD1, PF6. Addresses: CR-05, CR-10.
Generate SPDX or CycloneDX SBOMs for each image, sign image digests and provenance with controlled workload identity, scan promoted digests, and verify signatures/SBOM policy at admission. Pin actions, base images, packages, charts, and Terraform providers; document emergency revocation.
Verify: Unsigned, changed, unscanned, stale, disallowed-license, or critical-vulnerability artifacts cannot enter a regulated cluster. Promotion preserves the same digest and attaches retrievable evidence.
SD3: add infrastructure, application, and resilience security tests¶
Depends: SD1, KH2, AW2. Addresses: CR-04, CR-05, CR-13.
Add Terraform/Helm policy, kubeconform, DAST, API authorization, tenant escape, egress, SSRF, upload, dependency, and restore tests. Schedule independent penetration, cloud configuration, and PCI segmentation tests; track findings through closure.
Verify: CI and scheduled workflows publish signed result manifests. Test fixtures with a broken RLS policy, NetworkPolicy, route wrapper, public bucket, permissive security group, or restoration check fail the expected gate.
PCI boundary¶
PC1: close payment-channel leakage paths¶
Depends: PF4, PF5, AU2. Addresses: CR-09.
Finish the open work in Payments: prevent typed PAN from ordinary chat, complete voice/form handoff, suppress upstream CCaaS recording, handle webhooks/settlement, and scan transcripts/logs/objects for PAN canaries. Route payment entry to the approved capture surface before content reaches models or general storage.
Verify: Browser, voice, DTMF, chat, retry, error, recording, analytics, and support paths prove PAN appears only inside the approved vault/provider boundary. Canary scanning returns no unauthorized copy.
PC2: isolate and harden the vault¶
Depends: KH1, KH2, CR3, AW2, AW3, PC1. Addresses: CR-09.
Place payment-vault in its own account or assessor-approved equivalent boundary, namespace, identities, keys, database role, logs, egress policy, secrets, and deployment pipeline. Enforce one-shot signed sessions, nonce/replay protection, strict CSP/frame ancestry, script integrity/inventory, tokenization, and no PAN persistence.
Verify: Segmentation, replay, browser-script, memory/log, key, failover, and incident tests pass. The general platform cannot query vault secrets, memory, network, or payment-provider credentials.
PC3: complete PCI validation artifacts¶
Depends: PC2, SD3. Addresses: CR-09, CR-14.
Ask the acquirer/QSA to confirm CDE scope and SAQ/ROC path. Collect provider AOCs, diagrams, inventories, responsibility matrix, ASV results where applicable, penetration/segmentation tests, key procedures, training, incident exercise, and control evidence.
Verify: The QSA accepts scope and evidence; the responsible party signs the applicable SAQ/AOC or ROC. Marketing uses the exact validated entity, service, version, and period.
AI governance¶
AI1: add AI use-case inventory and approval¶
Depends: PF3, G2. Addresses: CR-11, CR-14.
Add AI system/use-case records for owner, intended and prohibited use, affected users, data classes, models/providers, tools, autonomy, human oversight, risk tier, impact assessment, transparency, monitoring, and retirement. Require an approved use case and risk tier before a regulated agent/workflow can publish.
Verify: High-risk or incomplete use cases fail publish; version/model/tool changes trigger reassessment under policy; inventory export reconciles with deployed versions and observed provider calls.
AI2: repair and enforce evaluation gates¶
Depends: AI1, PF4, AU2. Addresses: CR-11.
Replace the broken _eval_gate_check dependency on absent eval_runs/eval_results with a complete version-bound evaluation schema and service. Require named suites, dataset versions, evaluator versions, thresholds, safety/security tests, approval, and result hashes. Replace GATE_OVERRIDE: notes with typed, approved, expiring exceptions.
Verify: Fresh schema supports evaluation; empty evaluator lists fail for regulated profiles; results for another agent/version cannot satisfy the gate; changed prompts/models/tools invalidate stale results; override misuse fails and audits.
AI3: apply guardrails, monitoring, and provider lifecycle controls¶
Depends: AI1, AI2, PF5, AW2. Addresses: CR-11, CR-12.
Define risk-tier guardrail and monitoring requirements across all provider paths, including input/output filtering, prompt-injection defense, tool authorization, content/data-loss checks, human escalation, rate/cost bounds, rollback, and AI incident categories. Protect sensitive model-invocation logs with KMS, access limits, and retention; avoid logging raw content unless policy permits it.
Inventory Bedrock Agents Classic usage and stop adding it to new regulated accounts. AWS placed it in maintenance mode. Give AgentCore migration its own plan, and admit AgentCore to a regulated profile only after its exact region/feature assurance scope passes review.
Verify: Red-team and regression suites cover jailbreak, exfiltration, unsafe tool use, hallucination-sensitive flows, fallback, monitoring loss, model change, and human escalation. Alerts link to the pinned use case, version, policy, and evaluation.
FedRAMP High/Class D boundary¶
FR1: make Terraform and artifacts partition-safe¶
Depends: AW1, CR3, SD2. Addresses: CR-10.
Replace hardcoded arn:aws: and commercial endpoints with data.aws_partition, provider-derived suffixes, and explicit availability checks. Build and test images, dependencies, registries, IAM, DNS, certificates, and support access for aws-us-gov. Remove commercial-only integrations from the federal bill of materials.
Verify: Terraform plan and static scans find no standard-partition ARN/endpoint in the federal composition. A clean GovCloud account can obtain artifacts without a hidden commercial runtime dependency.
FR2: deploy and qualify the federal product boundary¶
Depends: PF6, AU3, PR4, CR3, KH1–KH3, AW2–AW3, SD2–SD3, AI3, FR1. Addresses: CR-10.
Create infra/stacks/aws-regulated-govcloud/ and the federal Helm overlay. Start with text workflows/agents and an exact service/model list from the current AWS FedRAMP scope. Enforce FIPS endpoints/modules, private connectivity, federal identity/administration, controlled egress, approved cryptography, and federal incident/backup settings.
Treat voice as a later boundary change. Admit it only after STT, TTS/S2S, telephony, recording, media, model, and support components all have an accepted path. The current Bedrock table does not list Nova Sonic for GovCloud Class D.
Verify: Deploy from clean state; run all profile vectors, functional E2E, crypto/module inventory, egress, recovery, incident, and assessor pre-read tests. No prohibited provider or model can be selected through UI, API, stored config, fallback, or direct SDK call.
FR3: automate federal package and continuous evidence¶
Depends: G2, AU3, AW2, SD1, FR2. Addresses: CR-10, CR-13, CR-14.
Add OSCAL component definitions and generated inventory/control/evidence manifests under compliance/fedramp/. Integrate the GRC/evidence system with configuration, vulnerability, change, incident, access, backup, penetration, and assessment outputs. Implement current FedRAMP continuous monitoring and significant-change workflows.
Verify: The recognized assessor can trace each inherited, provider, customer, and shared control to current evidence. Package generation is reproducible; inventory and scan coverage reconcile; late/missing evidence creates an owned case.
Management systems and assurance¶
OP1: operate the integrated ISMS and AIMS¶
Depends: G1, G2; runs alongside engineering. Addresses: CR-14.
Version policy templates and control procedures under compliance/policies/; operate approvals, training, risks, vendors, objectives, metrics, access reviews, incidents, continuity, privacy, HIPAA, AI, internal audit, management review, corrective action, and exceptions in the approved GRC system. Store only nonsensitive templates and references in Git.
Verify: Each control completes one scheduled cycle with owner/reviewer evidence. Internal audit samples design and operation, records findings, and verifies corrective action.
OP2: complete profile readiness and external assurance¶
Depends: All engineering tasks required by the selected profile, OP1.
Run readiness review, penetration and recovery tests, privacy/HIPAA exercises, PCI assessment, SOC observation, ISO stage audits, CSA submission/attestation, or FedRAMP assessment/authorization as applicable. Freeze the assessed boundary and route changes through significant-change analysis.
Verify: The applicable external party issues the report, certificate, validation, or authorization. Publish a claims register with exact entity, scope, exclusions, period/version, expiration, customer responsibilities, and approved wording.