Cross-standard control gap register¶
Status: Current | Last reviewed: 2026-08-30
This register turns the standards readiness review into actionable engineering and governance findings. Read it when you prioritize remediation, define a regulated deployment profile, or assemble assurance evidence.
Rating and status¶
| Rating | Meaning |
|---|---|
| Critical | Prevents a regulated profile or exposes sensitive data to unacceptable risk. Resolve before placing the affected data in scope. |
| High | Prevents a defensible external claim or leaves a major control objective unevidenced. |
| Medium | Weakens repeatability, resilience, or evidence but can follow the profile blockers. |
The engineering status records repository remediation. It does not close deployment, policy, contract, operating-evidence, or external-assurance work. The detailed evidence paragraphs preserve the original review finding; the status column and implementation guide record the current engineering result.
Prioritized register¶
| ID | Rating | Engineering status | Finding | Affected scopes |
|---|---|---|---|---|
| CR-01 | Critical | External work open | Approved claims, named people, contracts, and customer responsibility decisions still require accountable leadership. A validated role-based catalog and boundary guides now exist. | All |
| CR-02 | Critical | Implemented; live evidence open | Hash-chained tenant audit events, immutable database guards, operational audit bridging, chain verification, leased delivery, and WORM export are implemented. | All |
| CR-03 | Critical | Partial; processor and restore work open | The rights state machine, HMAC subject lookup, legal holds, database deletion, exact object-version deletion, and tombstones are implemented. External processors, derived stores, and post-restore replay remain environment duties. | GDPR, CCPA, HIPAA, SOC 2, ISO 27001 |
| CR-04 | Critical | Implemented; runtime evidence open | The regulated chart enforces restricted security contexts, resource bounds, strict mTLS, authorization policy, default-deny networking, and dedicated identities. | All technical scopes |
| CR-05 | Critical | Mixed; live enforcement open | CI now emits SBOM and provenance, signs images, and includes a compliance gate. Repository variables, branch protection, recurring scans, admission, SLAs, and independent tests require live setup and evidence. | All, especially PCI and FedRAMP |
| CR-06 | Critical | Implemented; deployment and recovery evidence open | A separate regulated AWS stack now uses resilient data tiers, protected backups, keys, endpoints, logging, detections, alarms, and a verified deployment ceiling. | SOC 2 availability, HIPAA, PCI, FedRAMP, ISO 27001 |
| CR-07 | High | Implemented; key-operation evidence open | Regulated secrets use fresh KMS data keys, exact purpose contexts, AAD, FIPS SDK selection, least-privilege roles, and a legacy migration path. | All confidentiality/privacy scopes |
| CR-08 | High | Implemented; access review open | Exact namespace and service-account IRSA trust plus per-workload bucket, key, model, and action policies replace wildcard trust in the regulated stack. | All technical scopes |
| CR-09 | Critical | Technical boundary implemented; assessor work open | The vault, capture diversion, recording suppression, tokenization, settlement evidence, database guards, and dedicated identity are implemented. PCI scope and external validation remain open. | PCI DSS |
| CR-10 | Critical | Planned only | Partition-aware infrastructure, a FIPS GovCloud ceiling, exact model allowlist, and a disabled planning overlay exist. No GovCloud deployment, package, assessment, authorization, or continuous-monitoring operation exists. | FedRAMP High |
| CR-11 | High | Implemented; AIMS operation open | Inventory, impact levels, risk assessment, exact-artifact evaluations, independent expiring approvals, guardrails, and publish/runtime evidence pins are implemented. | ISO 42001, SOC 2, GDPR, CCPA, FedRAMP |
| CR-12 | Critical | Implemented; eligibility review open | Signed, expiring, default-deny profiles run in matching TypeScript and Python engines at authoring, publish, startup, provider, and fallback boundaries. | HIPAA, GDPR, PCI, FedRAMP, CCPA, ISO 42001 |
| CR-13 | High | Implemented in IaC; operations evidence open | The regulated stack configures cloud audit, configuration monitoring, threat detection, flow logs, WORM evidence, alarms, and resilient storage. Live alert, investigation, and restoration results remain open. | All technical scopes |
| CR-14 | High | External work open | The control catalog defines role owners and evidence cadence, but the organization must operate policies, training, risk, internal audit, management review, and corrective action. | SOC 2, HIPAA, GDPR, CCPA, CSA STAR, ISO 27001, ISO 42001, FedRAMP |
Finding details¶
CR-01: define boundaries and ownership¶
Original review evidence. The repository describes EKS deployment, multi-tenant application architecture, and capability-specific controls, but it does not define the legal entity, system boundary, service commitments, data categories, regulatory roles, inherited controls, customer controls, or named owners for any proposed claim.
Required result. Approve separate commercial regulated, PCI, privacy-regional, and FedRAMP profiles. For each one, maintain a system description, asset and data inventory, diagrams, applicability decisions, control matrix, RACI, evidence calendar, exceptions, and customer responsibility matrix.
Closure evidence. Executive-approved scope; current inventory and flows; assigned control owners; cross-framework control map; quarterly scope review.
CR-02: make audit evidence complete and tamper-evident¶
Original review evidence. writeAuditLog() writes outside the primary transaction and swallows failures so the user action can succeed. The audit_log schema lacks a direct tenant_id and append-only database protection; edit sessions update existing details. Authentication and payment event tables use stronger append-only patterns, but they do not cover general administrative, data, AI, provider, export, or configuration actions.
Required result. Define auditable events and required fields; record tenant, actor, delegated identity, source, target, before/after reference, reason, request/trace, result, and authoritative time. Export to access-controlled immutable/WORM storage, detect gaps, synchronize clocks, restrict readers, alert on high-risk actions, and apply documented retention. Fail closed where the risk assessment requires it.
Closure evidence. Schema and threat-model review; append-only controls; completeness/reconciliation tests; log-access reviews; retention policy; alert and investigation samples.
CR-03: implement the complete data lifecycle¶
Original review evidence. Conversation deletion removes the database conversation, while data model and core infrastructure describe recordings, archives, search, and object storage outside that row. Secret storage states that transcripts are plaintext at the application layer. No complete DSAR, correction, portability, opt-out/GPC, processor deletion, or legal-hold workflow is evidenced.
Required result. Maintain a data-category inventory and retention schedule. Build idempotent rights and erasure orchestration across PostgreSQL, Redis, RabbitMQ, S3 versions, archives, search, telemetry, backups, integrations, and subprocessors, with exception/legal-hold decisions. Default retention instead of relying on tenant opt-in configuration.
Closure evidence. End-to-end access/correction/deletion/opt-out tests; object and processor receipts; backup handling; request metrics; approved notices and schedules; DPIA/risk assessment where applicable.
The implemented privacy workflow is documented in Privacy-rights operations. The broader store-redaction design remains in Layered PII/PHI protection, layer L3.
CR-04: harden every workload¶
Original review evidence. Chart audit records no pod/container securityContext, root-by-default application workloads, and a shared plaintext TURN password. It also records missing probes and a non-TLS development database path. Networking makes east-west controls depend on optional service-mesh policy when NetworkPolicies are disabled.
Required result. Enforce non-root execution, read-only root filesystems, dropped capabilities, seccomp, privilege-escalation denial, resource bounds, signed minimal images, admission policy, namespace/service-account isolation, default-deny network policy, and managed unique credentials. Treat mesh identity and Kubernetes network policy as complementary controls.
Closure evidence. Policy-as-code tests on rendered regulated charts; runtime conformance scan; credential rotation record; segmentation test; exception register.
CR-05: enforce vulnerability management¶
Original review evidence. Security scanning describes informational PR scanning of changed services, no enforced gate, no scheduled scans, unavailable SARIF visibility, and uncertain registry scanning coverage.
Required result. Scan the full source, dependencies, containers, IaC, secrets, hosts/nodes, clusters, and exposed applications on change and on schedule. Establish authenticated testing where appropriate, external scanning for PCI scope, current threat feeds, risk-based deadlines that meet applicable federal requirements, exception approval, re-scan verification, and executive metrics.
Closure evidence. Enforced pipeline results; recurring scan history; asset coverage reconciliation; tickets and SLA reports; independent penetration and segmentation results; approved exceptions.
CR-06: build a resilient regulated baseline¶
Original review evidence. The AWS production stack configures a single-AZ RDS instance and a single Redis cache node. The RDS module defaults to seven-day backups and does not establish the full regulated requirements for deletion protection, log exports, monitoring, or tested recovery.
Required result. Define service objectives and failure assumptions. Use multi-AZ data tiers, protected and encrypted backups, cross-account/region recovery as required, queue and object durability, autoscaling, controlled maintenance, capacity monitoring, contingency access, and tested restore/failover procedures.
Closure evidence. Approved BIA and RTO/RPO; architecture test; restoration and failover results; backup reconciliation; capacity and availability reports; corrective actions.
CR-07: strengthen cryptographic governance¶
Original review evidence. Secret storage derives application encryption from a global MASTER_ENCRYPTION_KEY. The production stack does not pass customer-managed KMS keys into all supported storage modules, so important paths use provider-managed encryption defaults.
Required result. Inventory every cryptographic use. Separate keys by environment, service, tenant/risk boundary, and data purpose where justified. Use KMS/HSM-backed envelope encryption, least-privilege key policy, controlled rotation and deletion, dual control where required, FIPS-validated modules in the federal boundary, and tested recovery.
Closure evidence. Crypto standard and inventory; key diagrams/policies; rotation and recovery tests; access logs/reviews; cryptographic module validation evidence for the selected boundary.
CR-08: narrow workload identity and data permissions¶
Original review evidence. The AWS production stack trusts wildcard service-account names for S3 access and grants shared access across application buckets. Bedrock access uses a broad provider-family wildcard rather than the model versions allowed by a regulated profile.
Required result. Issue one identity per workload, bind exact namespace/service-account subjects, scope data by bucket/prefix/action, separate read/write/delete, add permission boundaries and organization controls, restrict model and region, and run continuous analysis of unused or public/cross-account access.
Closure evidence. Reviewed IAM graph; automated least-privilege tests; quarterly access certifications; Access Analyzer findings; denied-path tests; emergency-access review.
CR-09: finish and validate the PCI boundary¶
Original review evidence. Payments lists unfinished prevention for typed card numbers in chat, voice-to-form synchronization, webhooks/settlement, and upstream CCaaS recording suppression. It also identifies SAQ, ASV, penetration, key, provider-AOC, and training work outside the repository.
Required result. Complete those controls, remove PAN from all non-vault channels, validate browser/script controls, isolate the vault and identities, confirm retention and logging, and ask the acquirer/QSA to determine scope and validation method.
Closure evidence. QSA-approved flows and scope; provider AOCs; applicable SAQ/AOC or ROC; ASV and penetration results; segmentation test; key ceremony; training and incident exercise.
Recording suppression and secure-capture diversion are implemented in the payment path. Layered PII/PHI protection retains the broader layers L1 and L3 design.
CR-10: create a real FedRAMP High/Class D product¶
Original review evidence. Current Terraform contains commercial arn:aws: resources and the production example targets commercial AWS. No GovCloud boundary, exact service/model allowlist, federal configuration baseline, FIPS validation evidence, SSP, assessment artifacts, POA&M, or continuous-monitoring operation is present.
Required result. Build the separate profile described in the standards readiness review. Resolve the exact approved services, features, Bedrock model IDs, media path, dependencies, personnel, support, build, and interconnections before promising functional equivalence.
Closure evidence. Deployed GovCloud boundary; complete package and control evidence; independent assessment; authorization decision; monthly/annual continuous-monitoring submissions and POA&M governance.
CR-11: establish lifecycle AI governance¶
Original review evidence. Agent and workflow versions provide traceability, and selected Bedrock agent modes expose guardrail configuration. The reviewed repository does not establish a complete AI-system inventory, intended-use and prohibited-use review, impact/risk tiers, evaluation corpus and thresholds, model-change process, universal guardrails, human oversight testing, or AI incident operation. Evaluation-gate behavior permits empty evaluator lists and a notes-based override path that needs formal authorization and evidence controls.
Required result. Establish an ISO 42001-aligned AIMS integrated with the ISMS. Gate each use case and material change on risk/impact, data suitability, supplier/model review, security and safety evaluation, accessibility/fairness needs, human oversight, rollback, monitoring, transparency, and incident response. Require access-controlled, expiring overrides with a recorded reason.
Closure evidence. AI inventory and ownership; approved intended uses; impact/risk records; data/model cards; evaluation and red-team results; approvals/overrides; monitoring and incident evidence; internal audit and management review.
CR-12: enforce provider eligibility¶
Original review evidence. The provider catalog supports multiple commercial AI, speech, translation, telephony, and observability vendors. Eligibility differs by service, feature, model, region, contract, and data path; configuration currently provides flexibility rather than a compliance allowlist.
Required result. Resolve a signed, versioned policy at publish time and again at runtime. Deny providers, model IDs, regions, endpoints, data categories, tools, logging, caching, and fallback routes outside the tenant profile. Default to no fallback across compliance boundaries.
Closure evidence. Machine-readable profiles; negative tests; provider contracts and current assurance reports; subprocessor and region inventory; runtime drift alerts; quarterly scope verification.
The data-path enforcement point now validates compliance profiles at authoring, publish, preflight, runtime, and provider construction. Layered PII/PHI protection describes the wider L0 and L4 model.
CR-13: demonstrate security operations¶
Original review evidence. Observability provides telemetry hooks but delegates aggregation to the deployed platform. The reviewed infrastructure does not demonstrate the complete account/organization-level trail, configuration, threat-detection, network-flow, WAF, immutable retention, alert, on-call, investigation, or restoration configuration.
Required result. Define the cloud landing-zone controls and evidence whether TrueServe or the customer operates them. Centralize immutable logs, detect configuration and identity drift, monitor threats and egress, test alert-to-case flow, maintain forensic readiness, and exercise regulatory/customer notification timelines.
Closure evidence. Logging/control coverage map; retention and access tests; alert samples; incident tickets and tabletop; cloud configuration reports; restoration evidence; customer responsibility matrix.
CR-14: operate the management systems¶
Original review evidence. Technical documentation does not prove board/executive oversight, policy approval, enterprise risk treatment, workforce screening/training, supplier governance, internal audit, management review, corrective action, or continual improvement.
Required result. Implement one integrated management system that supports security, privacy, HIPAA, AI, PCI, and federal overlays. Avoid nine independent control programs; retain framework-specific evidence and decision rights where required.
Closure evidence. Approved policies; risk registers and treatment; objectives/metrics; competence records; supplier reviews; internal audits; management reviews; corrective actions; external assurance reports and certificates.
Evidence-quality rules¶
- Link every claim to the deployed resource, configuration, contract, record, or test result that proves it.
- Record owner, collection method, frequency, population, sample, time period, reviewer, and exception.
- Prefer machine-generated, immutable evidence, but test the collector and preserve human approvals where judgment matters.
- Separate design evidence from operating evidence. A Terraform default or handbook statement does not prove the running environment.
- Reconfirm provider and model scope at deployment and periodically; cloud assurance catalogs change.
- Keep customer-responsible controls explicit in contracts and deployment handoff material.