Compliance

The platform's compliance posture is built into its architecture, not bolted on as a policy layer. Data sovereignty, audit logging, and access control are enforced by the system design — specifically, by the two-layer architecture where customer data lives on isolated data clusters and the platform manages orchestration without storing document content.

This page covers the platform's compliance posture for GDPR, HIPAA, and ISO 27001, with honest details about what is implemented, what is architecturally ready, and what is on the roadmap.

GDPR Compliance

The General Data Protection Regulation governs the processing and storage of personal data for EU residents. The platform addresses GDPR requirements through architectural controls.

Data Residency

Customer data is stored exclusively on data clusters — either Alien-hosted (in the cloud region of your choice) or on your own infrastructure. The platform orchestration layer stores only metadata pointers (dataset names, entry counts, sync status). Document content, embeddings, and processed files never leave the data cluster.

For On-Premise deployments, data residency is absolute: your data stays on your infrastructure, in your data center, in the jurisdiction you control.

Data Type	Where Stored	Can It Leave the Cluster?
Uploaded documents	Data cluster (MinIO)	No
Processed text and figures	Data cluster (MinIO)	No
Vector embeddings	Data cluster (Qdrant)	No
Full-text search indexes	Data cluster (Meilisearch)	No
Entry metadata	Data cluster (PostgreSQL)	Metadata only syncs to platform
User accounts	Platform (PostgreSQL)	N/A — platform data
Audit logs	Platform (PostgreSQL)	N/A — platform data

Right to Deletion

The platform supports complete data deletion through a cascade delete mechanism:

1. When a dataset or entry is deleted, the Data API removes all associated resources:
   • MinIO objects (original files, processed content, figures)
   • Qdrant vectors (all chunks and embeddings for the entry)
   • Meilisearch documents (search index entries)
   • PostgreSQL records (metadata, manifests, change logs)
2. The deletion propagates to the platform via batch sync, removing the metadata pointer
3. Audit logs record the deletion event (who deleted what, when)

Deletion is complete — there is no soft-delete or recycle bin that retains data after deletion is requested.

Audit Trail for Data Access

Every data access is logged:

Log Type	What Is Recorded
Proxy call logs	Every request proxied to a data cluster: user identity, cluster, API path, timestamp, response status, source type (human/worker/MCP)
Execution histories	Data access analytics: what data was accessed, by whom, through which channel
Sync logs	Metadata synchronization events between data clusters and the platform

These logs support GDPR's requirement for demonstrating what personal data was accessed, by whom, and for what purpose.

Data Isolation

Cross-organization data access is prevented at multiple levels:

• Database queries filter by organization_id — every query is scoped
• The authorization policy system checks organization membership before any data access
• Per-tenant namespace isolation prevents cross-tenant data access at the infrastructure level
• The proxy layer enforces cluster status and organization membership before forwarding requests

See Data Sovereignty for the complete isolation model.

HIPAA-Ready Architecture

The Health Insurance Portability and Accountability Act governs the handling of protected health information (PHI). The platform's architecture supports the technical requirements of HIPAA, though formal HIPAA certification involves organizational controls beyond the technology layer.

What the Architecture Provides

Encryption in transit:

• All platform-internal traffic encrypted via mTLS (Istio service mesh)
• Cross-cluster traffic encrypted via mTLS (Skupper tunnels)
• MinIO storage connections encrypted via TLS
• No unencrypted traffic paths exist in the production architecture

Encryption at rest:

• Storage volumes use the cloud provider's encryption-at-rest capabilities
• For On-Premise deployments, encryption at rest depends on your storage configuration

Access controls:

• Role-based access control at the organization level (viewer, writer, owner)
• Per-token abilities for granular API access
• Per-tool RBAC for MCP/AI agent access
• Authorization checks at every service boundary — not just the entry point

Audit logging:

• Every data access is logged with user identity, timestamp, access path, and source type
• Proxy call logs provide a complete record of who accessed what data and when
• Execution histories track data access through AI workflows and MCP agents

Data isolation:

• Per-tenant infrastructure prevents cross-tenant data access
• PHI can be stored on dedicated On-Premise data clusters with physical separation

note

The platform provides a HIPAA-ready architecture — the technical controls for encryption, access control, audit logging, and data isolation are in place. Full HIPAA compliance requires additional organizational measures including a Business Associate Agreement (BAA), formal risk assessment documentation, and specific audit log retention policies. Contact us to discuss HIPAA compliance for your organization.

ISO 27001

ISO 27001 is an international standard for information security management systems. The platform supports ISO 27001 compliance through documented processes, automated controls, and auditable infrastructure management.

Documented Development Processes

All code changes follow a structured workflow:

1. Research — understand existing codebase and constraints before making changes
2. Plan — design the solution with security considerations, testing strategy, and deployment plan
3. Implement — execute following established patterns with code review
4. Validate — verify against requirements with automated tests and security checks

This workflow is enforced through tooling and documented in the repository, providing the "documented processes" that ISO 27001 requires.

GitOps Audit Trail

All infrastructure changes are managed through GitOps:

• Every change is a Git commit — with author, timestamp, description, and review
• ArgoCD enforces the desired state — manual changes to production are automatically reverted
• Deployment history is fully traceable — you can determine exactly what was deployed, when, and by whom
• Rollback is a Git revert — no undocumented manual interventions

This provides a complete audit trail for infrastructure changes without additional tooling.

Automated Security Controls

Control	Implementation
Code review	All changes require merge request approval before deployment
Security scanning	Automated SAST (static analysis) on code changes
Dependency scanning	Automated secret detection in commits
Request validation	CI gates enforce that all API request bodies use validated schemas — preventing injection and data corruption
Branch protection	Protected branches prevent direct pushes to production-affecting code

Compliance Scanning

Automated compliance scanning runs across all repositories, enforcing:

• Branch protection rules are configured
• Code review requirements are set
• Merge request approval templates are in use
• Security scanning jobs are enabled

Data Isolation Mechanisms — Technical Detail

Data isolation is enforced through multiple independent mechanisms. Even if one layer were compromised, the others would prevent cross-tenant data access.

Layer 1: Network Isolation

• Data clusters have no public-facing endpoints
• All external access goes through the authenticated platform proxy
• Per-tenant Skupper connectors route traffic to the correct Data API instance
• Service mesh policies restrict which services can communicate

Layer 2: Authentication and Authorization

• Every request is authenticated at the platform level (OAuth, API token, or service key)
• Authorization checks verify organization membership and role before any data access
• The proxy forwards user identity headers — the Data API knows who is making each request
• Offline or suspended clusters reject all proxy requests

Layer 3: Database and Storage Isolation

• Each tenant has a separate PostgreSQL database with unique credentials
• Each tenant has a separate MinIO bucket with IAM policies
• Each tenant has a separate Qdrant collection with JWT-scoped access
• Each tenant has separate Meilisearch indexes with scoped API keys
• There is no shared data space between tenants

Layer 4: Audit and Monitoring

• Every data access is logged with user identity, timestamp, and access path
• Proxy call logs distinguish between human, worker, and MCP access
• Operator heartbeats report infrastructure health and tenant status
• Batch sync logs track metadata synchronization events

Access Control Layers

Access control operates at every level of the stack:

The 4-layer security model ensures no single layer is relied upon exclusively:

No single layer is relied upon exclusively. A failure at any layer is caught by the next.

On-Premise for Maximum Compliance

For organizations with the strictest compliance requirements, On-Premise deployment provides maximum control:

Requirement	How On-Premise Addresses It
Physical data sovereignty	Data clusters run on your hardware, in your data center
Jurisdiction control	You choose where data is stored — country, region, facility
Network control	Only outbound HTTPS connections required; no inbound exposure
Access control	You control who has physical and logical access to the infrastructure
Audit	Kubernetes audit logs, storage access logs, and network logs are on your infrastructure
Backup control	You configure and manage backup strategies to your requirements

On-Premise deployments use the same platform features — the difference is that data never leaves your physical control. The platform communicates with your data cluster through encrypted mTLS tunnels, and you can terminate the connection at any time by shutting down the Skupper tunnel.

Compliance Roadmap

The following summarizes the platform's current compliance posture and planned improvements:

Standard	Current Status	Details
GDPR	Architecturally compliant	Data sovereignty, right to deletion, audit trails, data isolation all implemented
HIPAA	Architecture ready	Encryption, access controls, and audit logging in place. BAA and formal documentation in progress
ISO 27001	Controls implemented	Documented processes, GitOps audit trail, automated security scanning, compliance scanning
SOC 2	Planned	Many controls are already in place through ISO 27001 alignment; formal audit planned

tip

If your organization has specific compliance requirements — industry regulations, government standards, or internal security policies — contact us. The On-Premise deployment model and the platform's layered security architecture can be adapted to meet specific regulatory needs.

Next Steps

• Security Model — Authentication, authorization, and network security details
• Data Sovereignty — How data isolation is enforced across both hosting modes
• Deployment Model — Alien Hosted vs On-Premise comparison
• Infrastructure — Kubernetes orchestration and storage systems