Security policy

This policy describes the technical and organisational security measures implemented by AMBASSADIA SARL on the TranscribIA platform (client.transcribia.eu). It falls within the GDPR framework (Article 32 — security of processing) and the essential measures provided for by the NIS 2Directive. It is intended primarily for security officers, IT directors and DPOs of customer organisations as part of their authorisation reviews and risk assessments.

Operational detail — processing register, architecture diagrams, DPA and procedures — is available in the public compliance pack.

1. Security governance

• Designated security contact within AMBASSADIA SARL, a single point of contact for security questions and incident coordination.
• Editorial responsibility for this policy rests with the publisher's management; reviewed at least annually and whenever the scope changes materially.
• Reference framework: GDPR (Art. 32), essential measures under NIS 2, risk-based approach.
• Transparency on certifications: no ISO 27001 or SOC 2 certification is currently held. An independent security audit is planned in 2026 ; the certification process has begun but certification has not been obtained.

2. Identity and access management (IAM)

• API & tokens: authentication through Laravel Sanctum, personal Bearer tokens hashed with SHA-256, with limited lifetime and revocable at any time.
• Passwords: storage using bcrypt (cost factor 12), complexity policy, checking against known compromise lists.
• Two-factor authentication (2FA): TOTP compliant with RFC 6238, mandatory for administration accounts; 2FA secrets encrypted at rest with AES-256-CBC.
• Role-based access control (RBAC): 5 levels of privileges, from read-only user to organisation administrator, applying the principle of least privilege.
• Step-up authentication: password confirmation is required for any destructive or sensitive action (tenant erasure, role changes, full data export).
• Abuse prevention: application rate limiting Laravel on authentication and API endpoints; session expiry.

3. Encryption

• In transit: TLS 1.2 minimum (TLS 1.3 preferred), certificates from Let's Encrypt managed through Nginx Proxy Manager with automatic renewal and HSTS.
• At rest: encryption of volumes and the PostgreSQL database, encryption of uploaded files.
• Application secrets: environment variable isolation; encrypted 2FA secrets AES-256-CBC.
• Backups: encrypted with age (key exchange X25519, encryption ChaCha20-Poly1305).

4. Data protection and multi-tenant isolation

• Strict logical isolation: a separate PostgreSQL schema per organisation (schema-per-tenant model); no query crosses a tenant boundary.
• A configurable retention policy for each organisation, aligned with declared purposes.
• Right to erasure: documented, traceable tenant purge procedure (see Sovereignty & GDPR).
• No data transfers outside the EU by default.

5. Logging and audit

• Audit trail at two levels : tenant-level activity logs (activity_logs) and a central log (public.audit_logs).
• Recording of all sensitive actions: authentication, role changes, exports, erasure, administrator access.
• Scrubbed logging : no personally identifying data or business content is written to server logs.
• Log retention tailored to post-incident investigation needs.

6. Malware protection

• Antivirus scanning of uploads by ClamAV 1.4, signature database updated through freshclam.
• Files detected as infected are blocked and quarantined.
• Behaviour if the engine is unavailable: by design, the service switches to logged fail-open — the file is accepted to avoid blocking the service, but the event is recorded and the file rescanned when the engine returns. This availability trade-off is acknowledged and documented.

7. Vulnerability management and hardening

• Continuous dependency monitoring (composer/npm audit) and application of security patches.
• Application hardening: CSP (Content Security Policy), strict CORS, security headers, principle of least privilege.
• Independent security audit planned in 2026 (including penetration testing within scope).
• Responsible disclosure process: report any vulnerability to contact@transcribia.eu.

8. Security incident management

• Detection: continuous automated monitoring (24/7) with Slack and email notifications for anomalies and security events.
• Assessment & response: handled by the security contact through a containment → eradication → recovery → lessons-learned cycle.
• As a processor, TranscribIA informs the controller without undue delay after becoming aware of a personal data breach. The controller notifies the competent supervisory authority under the conditions of Article 33 of the GDPR, where feasible within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals.
• Notification to affected individuals where the risk is high (GDPR Art. 34).
• Transparent coordination with the customer organisation, as controller, throughout the incident.

9. Business continuity and backups

• Backups encrypted (age) replicated to an EU target through rclone.
• Targets met: RPO 24 h / RTO 4 h.
• Validated DR drill : a restoration exercise has been performed to verify the effectiveness of the recovery plan.
• Documented and maintained business continuity and recovery plan.

10. Supply chain and subprocessors

Subprocessors established in the European Union only, with a Data Processing Agreement (DPA, GDPR Art. 28) in place. No non-EU subprocessors by default.

The named list of subprocessors and their exact scope are set out in the public compliance pack and the downloadable DPA template.

11. SaaS vs on-premise — responsibility model

TranscribIA is available in sovereign SaaS (hosted in France) or on-premise (within the customer's infrastructure). Responsibility for security measures is shared differently depending on the mode:

On-premise, AMBASSADIA provides the application and a hardening guide and remains responsible for application security; the customer is responsible for the hosting infrastructure's security under its own information security policy.