Compliance

This document maps Platform-Kernel's technical architecture to regulatory and industry frameworks. All controls listed below are implemented in the codebase at M9 — no planned or aspirational items are included.

important

This document describes technical controls implemented in the Platform-Kernel codebase. It does not constitute legal advice or a certification statement. Engage a qualified auditor for formal compliance attestations.

---

Regulatory Framework Coverage

Framework	Scope	Coverage
GDPR (Regulation EU 2016/679)	EU personal data processing	Implemented
PCI-DSS v4.0	Cardholder data environment (CDE)	Partial (no card PAN storage)
AML/KYC (FATF Recommendations)	Financial tenant identification	Architectural hooks
SOC 2 Type II (AICPA TSC)	Security, Availability, Confidentiality	Implemented
ISO 27001:2022	Information security management	Implemented
OWASP ASVS 4.0	Application security verification	Implemented

---

GDPR

Data Classification

Category	Examples	Storage	Encryption
Personal Data (standard)	Name, email, phone	PostgreSQL	AES-256 at rest
Special Category Data	—	Not stored by default	—
Pseudonymous Data	User UUID, tenant UUID	PostgreSQL, Kafka, ClickHouse	At rest
Audit Logs	Access logs, mutations	ClickHouse	AES-256

Right to Erasure (Article 17)

Platform-Kernel implements GDPR deletion via a crypto-wipe state machine introduced in M9 Phase 4 (feat(gdpr): deletion state machine, 2026-04-19).

Deletion stages:

1. User calls DELETE /api/v1/users/:id (or POST /api/v1/audit/anonymize).
2. IAM marks user as pending_deletion.
3. The GDPR pipeline anonymizes PII fields in PostgreSQL using UPDATE … SET email = sha256(email), name = '[DELETED]'.
4. The ClickHouse audit log anonymizes the user via ReplacingMergeTree FINAL merge — existing rows are overwritten by anonymized replacements.
5. After BILLING_CRYPTO_WIPE_PERIOD_DAYS (default: 30 days), the field-level AES-256 DEK for that user is destroyed in Vault. Data becomes permanently unrecoverable.

Kafka events retention: Audit events on platform.audit.events are retained 30 days (KAFKA_AUDIT_RETENTION_HOURS = 720). After TTL, Kafka removes the events automatically.

S3 (cold audit): Audit cold-tier exports on S3 Glacier must be deleted manually by the Platform Owner as part of the GDPR SAR workflow. The Audit Service export endpoint supports JSON and CSV for SAR fulfillment: GET /api/v1/audit/export.

Data Portability (Article 20)

The Audit Service provides a full data export:

GET /api/v1/audit/export?format=json&userId={id}
Authorization: Bearer {JWT}

Data Minimization

• Notifications store no payload content after delivery — only status, channel, sent_at. Payload TTL: 0 (discarded on queue drain).
• Audit records store the diff field as JSONB. PII in diff is anonymized during the GDPR wipe.
• File storage metadata excludes original filenames for GDPR-flagged tenants (configurable per tenant).

Data Retention Summary

Data Type	Hot Retention	Cold Retention	Deletion
Audit logs (ClickHouse)	90 days	—	GDPR anonymize
Audit logs (S3 Glacier)	—	7 years	Manual by Platform Owner
Notification history	90 days	—	Auto-purge
Soft-deleted files	30 days	—	Auto-purge
Kafka events	7 days (168 h)	—	Kafka auto-expire
Kafka audit events	30 days (720 h)	—	Kafka auto-expire
WAL audit fallback	7 days	—	Auto-replay + purge
Delegation tokens	Up to 7 days	—	Vault TTL

Basis of Processing (Articles 6 and 9)

Platform-Kernel provides no built-in consent collection UI. Module authors are responsible for collecting and recording consent. The Audit primitive (POST /api/v1/audit) records consent events with full tamper-proof history at the ClickHouse layer.

---

PCI-DSS v4.0

Platform-Kernel deliberately does not store, process, or transmit cardholder data (PAN, CVV, expiry). All payment flows delegate to a PCI-certified payment provider (e.g., Stripe) via the Integration Hub. The Billing Service stores only provider-assigned subscription IDs and plan metadata — never raw card data.

Applicable Controls

PCI-DSS Requirement	Implemented Control
Req 2.2 — Secure configuration	golangci-lint v2, hardened Docker images (minimal base), no default credentials
Req 3.4 — Render PAN unreadable	Not applicable — no PAN stored
Req 6.3 — Security patches	Renovate Bot automated dependency updates, SAST via Snyk
Req 6.4 — Web app protection	OpenAPI request validation at Gateway, OWASP ZAP quarterly pen testing
Req 7 — Access control	RBAC (IAM internal/rbac), least-privilege roles per tenant
Req 8 — Authentication	ES256 JWT, Argon2id passwords, TOTP MFA (RFC 6238)
Req 10 — Audit logging	Append-only ClickHouse, dual-write, 7-year cold retention
Req 11 — Security testing	Contract tests (Pact), SAST (Snyk), pen testing (OWASP ZAP + Burp Suite) quarterly
Req 12.3.2 — Risk management	SECURITY.md, architecture threat model documented

---

AML and KYC Hooks

Platform-Kernel provides architectural hooks for Know Your Customer (KYC) and Anti-Money Laundering (AML) workflows without implementing a built-in identity verification provider. Module authors connect third-party KYC providers (e.g., Sumsub, Onfido) via the Integration Hub and record verification results in the Audit Log.

Transaction Monitoring Hooks

The Money Service emits the following Kafka events that AML modules can subscribe to for suspicious activity detection:

Kafka Event	Trigger	Payload
money.wallet.credited	Any credit to any wallet	amount, currency, source, tenantId
money.wallet.debited	Any debit from any wallet	amount, currency, destination, tenantId
money.wallet.transfer	Inter-wallet transfer	fromWalletId, toWalletId, amount

Velocity Controls

The Money Service enforces hard limits that provide baseline velocity controls:

• Max transaction: $100 000 per operation.
• Max balance: $1 000 000 per wallet (Billing plan enforced via BillingService.CheckLimit).
• MONEY_MAX_HOLDS_PER_WALLET = 100 — prevents concurrent hold abuse.

Additional AML velocity rules (daily transaction count, cumulative amounts) must be implemented at the module layer using the Data Primitive.

---

SOC 2 Type II

SOC 2 maps to five Trust Service Criteria (TSC). Controls below are implemented at the kernel layer.

CC6: Logical and Physical Access Controls

Control	Implementation
CC6.1 — Access is restricted to authorized users	RBAC engine (services/iam/internal/rbac/)
CC6.2 — New access requires authorization	Module manifest permission declarations, validated at Module Registry activation
CC6.3 — User access is removed when no longer needed	DELETE /api/v1/users/:id (IAM) triggers GDPR wipe pipeline
CC6.6 — Network access is restricted	mTLS via Istio (service mesh), TLS 1.3 minimum, CORS strict no-wildcard
CC6.7 — Transmission is encrypted	TLS 1.3 for all external traffic, mTLS for service-to-service
CC6.8 — Malware is detected and remediated	ClamAV antivirus on all file uploads, Snyk SCA on all dependencies

CC7: System Operations

Control	Implementation
CC7.1 — Infrastructure is monitored	OTel → VictoriaMetrics, Grafana dashboards
CC7.2 — Security events are identified	slog structured JSON, traceId propagation, Audit Log
CC7.3 — Incidents are evaluated	Alertmanager rules on circuit_breaker_state, error-rate, saturation
CC7.4 — Security incidents are responded to	Runbooks in Self-Hosting docs (backup, DR procedures)

A1: Availability

Control	Implementation
A1.1 — Capacity is managed	k6 load tests (14 000 RPS verified), horizontal scaling via Kubernetes HPA
A1.2 — Environmental protections	Docker Compose health checks, Kubernetes liveness and readiness probes
A1.3 — Recovery is tested	See Backup and Recovery

C1: Confidentiality

Control	Implementation
C1.1 — Confidential information is identified	Data classification (see GDPR section above)
C1.2 — Confidential information is protected	AES-256-GCM field-level encryption (shared/crypto), Envelope Encryption

---

ISO 27001:2022 — Control Mapping

ISO Control	Domain	Implemented By
A.5.15 — Access control	Logical access	RBAC, JWT, RLS
A.8.3 — Information access restriction	Data access	RLS per table, ClickHouse row policies
A.8.5 — Secure authentication	AuthN	Argon2id, ES256, TOTP MFA
A.8.7 — Protection against malware	AV	ClamAV on upload, Snyk on dependencies
A.8.9 — Configuration management	Infra	golangci-lint, markdownlint, Renovate Bot
A.8.12 — Data leakage prevention	Data isolation	Tenant RLS, mTLS, CORS strict
A.8.16 — Monitoring activities	Observability	OTel, VictoriaMetrics, Grafana
A.8.22 — Filtering of web services	API protection	OpenAPI validation, rate limiting
A.8.24 — Use of cryptography	Crypto	AES-256-GCM, TLS 1.3, ES256, Argon2id
A.8.28 — Secure coding	SSDLC	golangci-lint, OWASP ZAP, Pact, Snyk

---

Encryption Summary

Layer	Algorithm	Key Management
Data at rest (PostgreSQL)	AES-256 (TDE)	Infrastructure
Data at rest (S3)	AES-256 SSE-S3	Infrastructure
Data at rest (ClickHouse)	AES-256 encrypted volumes	Infrastructure
Field-level PII	AES-256-GCM	Vault DEK (rotated 90 days)
JWT signing	ES256 (ECDSA P-256)	Vault (secret/platform/iam/jwt-keys)
Password hashing	Argon2id	— (one-way)
MFA secrets	AES-256	Vault (MFA_ENCRYPTION_KEY)
Integration Hub credentials	AES-256-GCM	Vault
Data in transit	TLS 1.3	Vault-managed certificates
Service-to-service	mTLS (TLS 1.3)	Istio (Vault CA)
Key hierarchy	RSA-2048+ (KEK) → FIPS 140-3 Level 3 HSM (Master Key)	Vault + HSM

---

Penetration Testing Schedule

Type	Tool	Frequency
SAST	govulncheck, Snyk Code	Every commit (CI)
SCA	Snyk Open Source, Renovate Bot	Weekly
DAST	OWASP ZAP	Quarterly
Manual Pen Test	Burp Suite Pro	Quarterly
Chaos Engineering	Litmus / Chaos Monkey	Monthly
Fuzz Testing	AFL / libFuzzer	Monthly

---

See Also

• Security Deep Dive — architecture-level security controls
• Vault Setup — key management
• Backup and Recovery — RTO/RPO and DR procedures
• Glossary — term definitions