This is the summary of the technical and organisational measures applied by AIRON TEAM SL under Art. 32 GDPR. It is written to be verifiable: it describes what is running today and openly declares what is not. We claim nothing we cannot demonstrate.
1. Where the data lives
The application server, the relational database, the vector store and the cache all sit on a server in Frankfurt am Main (Germany, European Union). The databases are not exposed to the internet: they listen only on the server’s local interface. Embeddings of indexed documents are generated with Google Cloud Vertex AI in Frankfurt (europe-west3), so document content does not leave the EU to be vectorised. The one material processing outside the EU is language-model inference: see the sub-processor list.
2. Encryption
- In transit: TLS 1.2 and 1.3 on every public endpoint, with HSTS enabled.
- Secrets: connector credentials and OAuth tokens encrypted in the database.
- Backups: encrypted before they leave the machine.
3. Access control
- Default deny: roles and permissions evaluated on every operation; what is not granted is denied.
- Tenant segregation applied in enforcing mode, not observation mode.
- Fail-closed document search: if the per-account filter cannot be applied, the query returns nothing. We prefer an empty result to the wrong one.
- Granular permissions per agent and per connector within each account.
- Multi-factor authentication: available optionally since September 2026.
4. Traceability
A working audit log records actions and access per account and is kept for 3 years. Every data export and every deletion leaves an entry. AI transparency events are recorded as regulatory evidence.
5. Backups and recovery
- Nightly, daily runs, encrypted and sent to a remote destination off the server.
- Retention of 30 days.
- Restore tested, with a successful result — not merely planned.
- A consequence worth stating plainly: deleted data remains in the backups until they expire. Deletion is effective at retention period + 30 days.
6. Control over outbound messages
What AIRON starts on its own (replies to incoming emails, steps of automated flows and publications) is never sent to a third party without explicit approval by a person: it can be blocked, but not left on automatic. What a person asks the Assistant directly (in the panel or over WhatsApp) requires approval by default when it goes to third parties, has tax relevance or spends money (emails, invoices, ads, publications); the account administrator can change this behaviour tool by tool, and the Alegra invoice always requires approval. Approval uses a mechanism that prevents double sending and approvals on stale versions, and it is recorded.
7. Hardening and operations
- Automatic blocking of addresses attempting repeated logins, escalating for repeat offenders.
- Automatic renewal of the TLS certificates for all domains.
- A public vulnerability disclosure channel with binding response times.
- Breach procedure: notice to the customer controller without undue delay, aiming not to exceed 48 hours.
8. What we do NOT have (stated openly)
- No ISO 27001 or SOC 2 certification. The route to verification is the direct audit provided for in the data processing agreement.
- No third-party penetration test carried out so far.
- Multi-factor authentication is optional, not mandatory across all accounts.
A complete internal list of known gaps and their remediation plan exists. Customers and prospective customers can request it, under a confidentiality undertaking, at security@airon.team. We would rather hand it over than let anyone believe it does not exist.
Data usage and retention periods are in the platform privacy policy.