feat(assurance): establish enterprise security, privacy, and compliance baseline

[szmyty]

Summary

Establish an enterprise-ready security, privacy, identity, governance, and assurance baseline within Empathy that future Ego Hygiene repositories and deployable products can inherit.

This issue intentionally combines the underlying capabilities needed to support:

• SOC 2 Type II readiness
• role-based access control (RBAC)
• HIPAA and business associate agreement (BAA) readiness
• single sign-on (SSO) and SCIM provisioning
• GDPR readiness
• security audit logs
• CCPA readiness
• data residency
• EU–US Data Privacy Framework (DPF) support
• white-labeling

The implementation must distinguish reusable technical controls from organization-specific operations, contracts, legal determinations, deployment decisions, and independent audits.

Guiding principles

• Build one coherent security and privacy foundation and map it to multiple frameworks.
• Use secure, private, least-privilege defaults.
• Deny access by default and enforce authorization server-side.
• Treat health, journal, reflection, identity, and mental-health-adjacent data as highly sensitive.
• Keep regulated or sensitive content out of logs, telemetry, prompts, fixtures, and generated reports by default.
• Make controls, evidence, exceptions, and ownership machine-readable where practical.
• Preserve portability across hosting providers and identity vendors.
• Do not claim that a repository, feature, or deployment is certified or compliant without the required legal and independent validation.
• Incubate the baseline in Empathy while preserving clear future ownership boundaries for Aether, Relay, Realm, Observatory, Identity, and other holons.

Non-goals

• Declaring Empathy, Ego Hygiene, or any deployment SOC 2 certified.
• Representing that HIPAA, GDPR, CCPA, or DPF obligations are satisfied solely by merging code.
• Offering or signing a BAA through this repository.
• Replacing qualified legal counsel, a privacy professional, or an independent SOC auditor.
• Hard-coding the baseline to a single cloud, identity provider, policy engine, or monitoring vendor.

Workstream 1: assurance model and applicability

• Define a bounded assurance/compliance baseline and its ownership model.
• Create an applicability registry for each framework and capability.
• Distinguish statuses such as:
  • not applicable
  • planned
  • technically supported
  • deployment configured
  • operationally verified
  • independently attested
• Create stable control identifiers and control-family metadata.
• Map shared controls to SOC 2, HIPAA, GDPR, CCPA, and DPF expectations.
• Record control owners, evidence sources, review cadence, exceptions, and residual risk.
• Add explicit language preventing unsupported compliance or certification claims.
• Document anticipated extraction and ownership boundaries across the Ego Hygiene architecture.

Workstream 2: tenant, identity, and authorization foundation

• Define canonical tenant, organization, user, group, role, permission, resource, and service-account contracts.
• Define stable permission identifiers and resource scopes.
• Provide default roles such as owner, administrator, maintainer, member, viewer, and auditor.
• Implement deny-by-default authorization and least privilege.
• Enforce tenant isolation and server-side authorization.
• Support role inheritance and future custom roles without weakening default boundaries.
• Model separation-of-duty constraints for sensitive operations.
• Define break-glass access with strict controls, expiration, and auditability.
• Add privilege-escalation, confused-deputy, and cross-tenant isolation tests.
• Keep the policy layer adaptable to internal logic, OPA, Cedar, OpenFGA, or another future engine.

Workstream 3: SSO and SCIM

• Define pluggable OpenID Connect and SAML SSO contracts.
• Support tenant-specific identity-provider configuration.
• Require domain verification before domain-based identity routing.
• Define just-in-time provisioning as an explicit, configurable policy.
• Define identity-provider group-to-role mappings.
• Support tenant-level SSO enforcement and controlled recovery.
• Define SCIM 2.0 User and Group resources and endpoints.
• Support create, update, suspend, reactivate, delete, and reconciliation behavior.
• Require idempotent provisioning operations.
• Scope and rotate SCIM credentials.
• Test deprovisioning and privilege removal as security-critical paths.
• Emit authentication, federation, provisioning, and administrative audit events.

Workstream 4: audit logging and evidence

• Define a versioned canonical audit-event schema.
• Include actor, action, target, tenant, environment, timestamp, outcome, reason, correlation identifiers, and authentication context.
• Separate audit records from application/debug logs.
• Prevent secrets, PHI, sensitive journal content, access tokens, and unnecessary personal data from entering audit events.
• Provide append-only storage semantics and tamper-evidence options.
• Enforce tenant isolation for audit access.
• Log access to and export of the audit log itself.
• Support configurable retention, search, export, webhooks, and SIEM integration.
• Define clock-synchronization and ordering expectations.
• Test that security-sensitive mutations always emit the required audit events.
• Feed appropriate evidence summaries into repository intelligence without publishing sensitive details.

Workstream 5: privacy and data lifecycle

• Create a personal-data inventory and processing-activity model.
• Record controller/processor roles, purposes, lawful bases, retention, recipients, subprocessors, and transfer mechanisms.
• Define data classification, including highly sensitive and health-adjacent information.
• Minimize collection and make optional telemetry opt-in where appropriate.
• Define privacy-notice and collection-notice templates.
• Support consent records and consent withdrawal where consent is the processing basis.
• Implement or specify access, export, correction, deletion, restriction, and objection workflows.
• Propagate deletion through primary storage, indexes, caches, derived data, and backups according to documented policy.
• Define configurable retention schedules and legal-hold exceptions.
• Add subprocessor inventory and change-notification hooks.
• Add Data Protection Impact Assessment and transfer assessment templates.
• Define privacy incident and breach-response procedures.
• Test privacy-request authorization, completeness, idempotency, and timing evidence.

Workstream 6: GDPR and CCPA profiles

• Map the shared privacy foundation to GDPR requirements.
• Include safeguards for special-category data and high-risk processing.
• Define DPO and DPIA applicability decision records.
• Document international-transfer mechanisms and processor obligations.
• Map the shared privacy foundation to CCPA/CPRA requirements.
• Support “Do Not Sell or Share” and limit-use semantics where applicable.
• Honor Global Privacy Control or equivalent recognized opt-out signals where required.
• Support authorized-agent and request-verification workflows without excessive data collection.
• Produce evidence of request receipt, verification, disposition, and completion.
• Keep jurisdiction-specific policy separate from reusable privacy mechanisms.

Workstream 7: HIPAA and BAA readiness profile

• Define an optional regulated-data or PHI-aware deployment profile.
• Map administrative, physical, and technical safeguard responsibilities.
• Require encryption in transit and at rest for regulated data.
• Require unique identities, access controls, auditability, backup, recovery, and availability safeguards.
• Prohibit PHI from logs, analytics, model prompts, development fixtures, and reports unless explicitly approved and protected.
• Define vendor and subprocessor BAA-capability metadata.
• Reject incompatible services when the regulated-data profile is enabled.
• Create a provider/customer responsibility matrix.
• Add security risk assessment, incident response, termination, export, and secure-deletion templates.
• Clearly state that technical readiness does not itself establish HIPAA compliance or create a BAA.

Workstream 8: SOC 2 Type II readiness

• Map controls to the applicable Trust Services Criteria.
• Define evidence sources for security, availability, processing integrity, confidentiality, and privacy as selected.
• Automate repository evidence for reviews, changes, CI, dependencies, vulnerabilities, secrets, releases, and exceptions.
• Define operational evidence requirements for access reviews, onboarding/offboarding, incidents, backups, recovery tests, vendors, and training.
• Add change-management, incident-response, risk-management, business-continuity, and vendor-management policy templates.
• Create evidence-period snapshots and exportable auditor packages.
• Track control design separately from operating effectiveness.
• Use “SOC 2 ready” or similarly qualified wording only when supported; reserve attestation claims for an issued auditor report.

Workstream 9: data residency and international transfers

• Define tenant-selectable regional deployment metadata.
• Distinguish storage residency, processing residency, support access, backups, disaster recovery, and subprocessors.
• Define region-aware databases, object storage, queues, indexes, caches, logs, analytics, jobs, and encryption keys.
• Prevent unintended cross-region replication and processing.
• Support controlled regional migration with evidence and rollback.
• Validate residency configuration during deployment and continuously where practical.
• Record the transfer mechanism used by each relevant subprocessor.
• Support DPF participant metadata and verification records.
• Support Standard Contractual Clauses and transfer assessments as alternative mechanisms.
• Document that DPF participation requires eligible US organizational self-certification, public commitments, recourse procedures, and recurring maintenance outside the repository.

Workstream 10: white-labeling

• Define tenant branding configuration for names, logos, emblems, colors, typography, icons, favicons, manifests, and social previews.
• Integrate generated assets with the Identity holon.
• Support verified custom domains.
• Support branded email, support, and public metadata.
• Allow configurable legal and privacy links without obscuring the actual service provider or required notices.
• Preserve security-critical and trust-critical messaging across themes.
• Add accessibility, contrast, asset, and configuration validation.
• Keep branding configuration isolated from authorization and security policy.

Cross-cutting engineering requirements

• Define versioned schemas and migration behavior.
• Provide secure reference implementations where appropriate.
• Provide adapters and interfaces where deployment-specific choices belong elsewhere.
• Add unit, integration, contract, negative-path, and tenant-isolation tests.
• Add threat models for identity, authorization, privacy requests, audit logs, provisioning, regional isolation, and administrative access.
• Add secret-management and key-rotation requirements.
• Add privacy-preserving observability requirements.
• Generate human-readable documentation from machine-readable control metadata where practical.
• Surface non-sensitive posture and evidence freshness in repository intelligence.
• Document local-development behavior without weakening production requirements.
• Ensure example data and fixtures are synthetic.

Architectural ownership guidance

During incubation, Empathy may hold the integrated reference implementation. Preserve likely future ownership:

• Aether: policies, contracts, schemas, control vocabulary, agent guidance, and architectural decisions.
• Relay: reusable CI, evidence collection, validation, and release automation.
• Realm: deployment profiles, secrets integration, regional infrastructure, backup, recovery, and runtime safeguards.
• Observatory: organization-level posture, evidence freshness, risk, and compliance reporting.
• Identity: visual identity generation and white-label asset contracts.
• Empathy: integration baseline, reference implementation, examples, and conformance tests.

Documentation and references

• Add an implementation architecture document.
• Add framework applicability and claim-language guidance.
• Add a shared-responsibility model.
• Add deployment checklists for standard, enterprise, regional, and regulated-data profiles.
• Add incident, privacy-request, access-review, and evidence-collection runbooks.
• Link to authoritative AICPA, HHS, NIST, European Commission, CPPA, IETF, and US Department of Commerce sources.
• Record decisions as ADRs where architectural commitments are made.

Acceptance criteria

• A coherent baseline architecture exists instead of unrelated framework-specific checklists.
• Every control has an owner, applicability state, implementation status, evidence expectation, and review cadence.
• RBAC, audit logging, privacy lifecycle, and tenant isolation are treated as foundational shared capabilities.
• SSO and SCIM have vendor-neutral contracts and security-focused test coverage.
• Regional and regulated-data profiles fail closed when requirements are unmet.
• White-labeling cannot alter security policy or hide required legal/provider information.
• Repository intelligence can display non-sensitive readiness and evidence freshness.
• Documentation clearly differentiates technical support, configured deployment, operational verification, legal applicability, contractual commitments, and independent attestation.
• No automated badge or documentation makes an unsupported certification or compliance claim.
• Remaining external work for legal counsel, auditors, contracts, production operations, and organizational certification is explicitly documented.

Suggested delivery approach

Treat this issue as an epic and implement it through small, reviewable pull requests:

1. Assurance model, applicability registry, and architecture.
2. Tenant identity and RBAC contracts.
3. Canonical audit-event and evidence foundation.
4. Privacy inventory, retention, export, and deletion contracts.
5. SSO and SCIM integration contracts.
6. GDPR and CCPA profiles.
7. HIPAA/BAA readiness profile.
8. Data residency and international-transfer profiles.
9. White-label integration.
10. SOC 2 readiness mappings, evidence packaging, documentation, and dashboard integration.

The first pull request should establish terminology, boundaries, schemas, ownership, and claim-language rules before implementing framework-specific behavior.

[szmyty]

Captured organization-portfolio expansion

Outcome

Expand the existing enterprise assurance issue so Empathy continuously proves the integrated behavior of Holon, Aether, Relay, Egolint, Realm, Mantle, Identity, and Mindgarden.

Acceptance criteria

• Create at least one disposable repository fixture per repository class
• Test create, verify, upgrade, override, and rollback paths
• Publish a capability/maturity matrix with durable evidence
• Separate universal contract failures from specialist component failures

Dependencies

HOL-02, AET-04, REL-01, EGO-01

Source and decisions

• Portfolio ID: EMP-07
• Priority: P1
• Dependency wave: 2 - Golden path
• Source: empathy audit PDF; architecture package
• Assignee: szmyty

This scope expands the existing issue and intentionally avoids creating a duplicate.

[szmyty]

Cross-repository follow-up — public trust/policy/security publication batch

The August 22, 2026 site-policy/security backlog has now been decomposed into owning repositories rather than expanding this assurance epic further.

Policy and site publication

• egohygiene/hygiene#17 — canonical applicability-driven public-site legal, privacy, accessibility, trust, editorial, community, commerce, and AI-reference publication profile
• egohygiene/holon#11 — reusable site surfaces/rendering for that profile
• egohygiene/relay#21 — policy/trust conformance validation
• egohygiene/relay#22 — reusable web accessibility testing/evidence profiles
• egohygiene/pace#7 — fleet rollout/reconciliation

Trust and assurance evidence

• egohygiene/observatory#4 — evidence-backed public Trust Center read model
• egohygiene/relay#18 — SAST profiles
• egohygiene/relay#19 — safe authorized DAST profiles
• egohygiene/relay#20 — authorized attack-surface management discovery/evidence

Commerce-specific applicability

• egohygiene/store#12 — billing, AML, KYC, and regulated-flow applicability

These issues should consume the assurance/applicability/control semantics established here rather than redefining enterprise compliance. This issue remains the integrated reference/incubation epic for the underlying security/privacy/compliance capabilities; the linked issues own reusable organization-level publication, CI evidence, fleet adoption, and public projection.

Key invariant: generated policies, scanners, and Trust Center pages must never be treated as proof of legal compliance or independent certification.