Compliance
Audience
PLANA staff, customer CTOs, legal counsel, prospective customers' procurement teams.
PLANA operates as a B2B SaaS in the EU. The compliance posture below reflects what we actually do today, not aspirational targets.
Regulatory landscape we operate under
| Regulation | Scope | Status |
|---|---|---|
| GDPR (EU 2016/679) | Personal data of EU subjects | Compliant; DPA on file with every customer |
| Bulgarian Personal Data Protection Act | Bulgarian PII handling | Aligned with GDPR; same controls |
| Bulgarian Tax Code | Customer-side, but our software produces required reports | NPR / VIES / Intrastat exports built into PLANA Business Cloud |
| PSD2 (EU 2015/2366) | Open banking via Berlin Group | TPP-certified for read-only AISP role; not a PISP (no payment initiation) |
| NIS2 (EU 2022/2555) | Cyber-resilience for essential services | Aligning; our customer base does not yet trigger mandatory scope |
| eIDAS (EU 910/2014) | Electronic identification + qualified seals | Used: QSEALC for PSD2 request signing |
Data residency
| Data | Location |
|---|---|
| Customer business data (Odoo DBs, filestore, attachments) | Exoscale bg-sof-1 — Sofia, Bulgaria |
| Backups | Exoscale SOS bg-sof-1 — same region |
| Authentication data (Authentik users, sessions, MFA secrets) | pg01 in Sofia |
| Email metadata (Mailu) | Hetzner Falkenstein (DE) — EU, but not Bulgaria |
| AI agent inference | Anthropic API (US) — see LLM data handling below |
| Backup encryption keys | Exoscale-managed (server-side encryption); the data is also encrypted by us before upload |
All primary data stays in the EU. The Mailu email box is in Germany; emails sent or received by PLANA's plana.solutions accounts transit the Hetzner box.
GDPR — what we do
Lawful basis
For each category of personal data, we document the lawful basis:
| Data | Basis |
|---|---|
| Customer business records (employee data, customer data inside the tenant) | Customer is the controller; PLANA is the processor under the DPA |
Customer's own account on pulse-account (email, name) | Contract |
| Workspace audit logs | Legitimate interest (security, debugging) |
| Marketing emails to leads | Consent (opt-in form on planapulse.ai) |
| Backups | Necessary for service continuity (controller's instruction) |
DPA
Every customer signs a Data Processing Agreement before going live. The DPA template is at legal/dpa-template.md in infra and is updated when our processing changes. Standard contractual clauses (SCCs) are attached as Annex II for any sub-processor that touches EU subject data.
Sub-processors
| Sub-processor | Purpose | DPA in place |
|---|---|---|
| Exoscale (Switzerland) | Cloud hosting | Yes |
| Hetzner (Germany) | Email box for plana.solutions | Yes |
| Anthropic (US) | LLM inference for BOS agents | Yes; SCCs Annex II |
| Stripe (Ireland) | Payment processing | Yes |
| The 10 PSD2 banks | Banking data on customer instruction | Customer is the consent grantor |
The full list is shared with customers on request and updated when sub-processors change. Customers are notified of changes 30 days in advance.
Subject rights
A customer (or one of their end-users) exercising a GDPR subject right:
| Right | Procedure |
|---|---|
| Access (Art. 15) | Customer exports their data from the tenant Odoo via standard CSV / Excel export; PLANA exports the platform-side data (account record, sessions, audit logs) on request — typically 5 business days |
| Rectification (Art. 16) | Edit in the tenant; PLANA-side edits via support ticket |
| Erasure (Art. 17) | Delete the user in tenant; PLANA deletes platform records (account, sessions, audit logs older than 90 days) within 30 days |
| Portability (Art. 20) | Same CSV export as Access |
| Objection (Art. 21) | Disable marketing emails (one-click unsubscribe) |
| Restrict processing (Art. 18) | Customer's choice; we honour and document |
| Lodge a complaint | Bulgarian CPDP — kzld.bg |
Retention
| Data | Retention |
|---|---|
| Tenant Odoo records | Customer's choice, governed by their own retention policy |
| Daily backups (per tier) | Starter 30d / Pro 90d / Enterprise 1y |
| Authentication audit logs | 90 days in Loki |
Workspace API key audit (PLANA:executions) | 30 days in Redis |
| Stripe transaction records | 7 years (Bulgarian tax retention) |
| Marketing email opt-ins/outs | Indefinite (consent record) |
| Cancelled tenant data after off-boarding | Deleted after 30-day grace period; backups retained per the tier; SOS backups manually deleted after retention window |
PSD2
PLANA is registered as a TPP (Third-Party Provider) with the Bulgarian National Bank for the AISP role (Account Information Service Provider). We do NOT operate as a PISP (Payment Initiation) — we do not initiate payments on behalf of customers.
What we do:
- Read account balances and transactions with customer consent
- Display them in BOS and import them as bank statements into the tenant's accounting app
- Refresh consents per each bank's SCA cadence
What we do NOT do:
- Initiate transfers
- Hold customer funds
- Issue payment cards
The qualified certificates (QWAC + QSEALC) used in mTLS handshakes with the banks are renewed annually; the procedure is in infra/docs/runbooks/tpp-cert-renewal.md.
LLM data handling
When a customer chats with a BOS agent, the conversation is sent to Anthropic's API (api.anthropic.com). What gets sent:
- The user's chat message
- The chat history (recent turns)
- Tool definitions (function schemas — public, not sensitive)
- Tool results (which can include customer business data)
What Anthropic does with it:
- Generates a response
- Per the Anthropic Commercial Terms, customer data is not used to train Anthropic's models when using the API (vs. the chat product)
- Logs are retained per Anthropic's policy
What we have done to limit exposure:
- The tool layer only fetches the data the question actually needs (a cashflow question retrieves cash movements, not every record in the tenant)
- Sensitive fields (passwords, API keys, social security numbers, IBANs in full) are redacted before being sent to the model where the tool knows the field is sensitive
- The Anthropic-side audit log is owned by PLANA's Anthropic account; we can request log purging if a customer requests it
- For customers whose policy forbids US-side LLM processing, we offer an Enterprise tier with on-premise LLM via OpenRouter or a local model; this is a manual configuration today
Customers are informed of the LLM data flow at sign-up and in their DPA.
Audit logs
Every Kubernetes API write is captured by an in-cluster ValidatingAdmissionWebhook and shipped to Loki:
- Who made the call (Kubernetes user / SA)
- What resource changed
- What the diff was
- When
Retention: 90 days. Customers can request an audit excerpt covering actions on their tenant resources.
Incidents
We define an incident as anything that:
- Breaches the confidentiality of customer data
- Causes >1 hour of unplanned downtime
- Triggers a regulatory notification requirement (GDPR Art. 33 — 72-hour rule)
Incident response is documented in Operations → Incident postmortems. Post-mortem is published internally; customers affected by a P0 receive a detailed report.
Penetration testing
We commission an annual external pen-test of the platform. The most recent report is on file with PLANA Digital and shared with customers under NDA. Findings are tracked to closure and re-tested.
Certifications
| Certification | Status |
|---|---|
| ISO 27001 | Not certified; controls aligned with the standard, certification on the 2027 roadmap |
| SOC 2 Type II | Not pursued; not in customer demand today |
| GDPR | Compliant (self-assessed); DPA + ROPA in place |
| PSD2 TPP (AISP) | Certified by the Bulgarian National Bank |
Where to read more
- Threat model — what we defend against
- Network policies — segmentation details
- Secrets management — how we handle creds
- Audit logging — what we log and where
- Data residency — the policy view