Security — Attestia.eu

The Polish version is legally binding. In case of any discrepancy between the Polish and English versions, the Polish version shall prevail. The English version is provided for information.

Version: 1.0 Effective date: 2026-04-22 Last updated: 2026-04-22 Related documents:

• Annex A to the DPA (Technical and Organisational Measures) — attestia.eu/terms
• Privacy Policy section 11 (Data Security) — attestia.eu/privacy
• Privacy Policy section 12 (Data Breach Notification) — attestia.eu/privacy

1. Our approach to security

Attestia is a SaaS platform for compliance — which means the data we are entrusted with (Organisation AI System descriptions, compliance documentation, Audit Log) often constitutes trade secrets. Security is not a feature for us — it is a precondition of doing this business.

This page describes our security posture: architecture, protective mechanisms, incident response procedures and the responsible disclosure channel. It complements Annex A to the DPA (Technical and Organisational Measures) — which contains the formal specification flowing from the processing agreement.

Capitalised terms have the meaning given in the Attestia.eu Terms of Service.

2. Infrastructure and data in the EU

Principle: Organisation Data, Compliance Documents and AI-processed data remain within EU/EEA. Full sub-processor list: attestia.eu/subprocessors.

3. Encryption

3.1. In transit

• TLS 1.3 for all HTTPS connections (enforced at the Vercel CDN layer).
• HSTS enabled with includeSubDomains and preload.
• Weaker TLS versions (1.0, 1.1) are rejected.
• Database ↔ application and application ↔ Azure OpenAI connections are encrypted with TLS 1.3.

3.2. At rest

• AES-256 at the PostgreSQL (Supabase) database layer.
• AES-256 at Azure Storage Service Encryption.
• Keys managed by providers (Supabase/Azure KMS). Rotation follows provider cycles.

3.3. Passwords

• bcrypt (Supabase Auth default — cost factor 10+).
• Minimum requirements: 8+ characters, rainbow-table detection.
• We do not log passwords in plaintext at any stage.

4. Access control and authentication

5. Audit Log

In line with Art. 18 EU AI Act and § 12.4 of the Terms, the Platform maintains an immutable Audit Log:

• Hash-chain — every entry contains the SHA-256 hash of the previous entry (Merkle-light chain).
• Append-only — entries cannot be modified or deleted.
• Scope — every material compliance operation (creation/edit of a Classification, Document generation, acceptance of an AI recommendation, data export, role changes).
• Retention — 10 years from the last entry, in pseudonymised form (User and Organisation identifiers replaced with irreversible hashes after contract termination).
• Access — only authorised roles within the Organisation + internal Attestia team in break-glass mode with its own log.

The Audit Log defends against manipulation of compliance decision history and serves as evidence of due diligence during regulatory audits.

6. Pseudonymisation for AI

AI System descriptions sent to Azure OpenAI are pseudonymised before dispatch:

• Removed: Organisation name, User first and last names, email addresses, Account identifiers, billing data.
• Retained: substantive AI System description content (required for classification).
• The pseudonym → real identifier mapping is stored only on Attestia's side and never sent to AI.

This way, even in the scenario of an Azure OpenAI compromise (despite Microsoft's contractual commitments), Organisation data is not directly attributable.

Details: § 7(5) of the Terms + section 4.3 of the Privacy Policy + attestia.eu/transparency.

7. Backups and business continuity

8. Monitoring and incident detection

• Sentry — application error monitoring, anomaly alerts.
• Supabase logs — database query logs, detection of unusual patterns.
• Vercel analytics — availability (uptime) monitoring.
• Alerting — alerts on critical application errors, unauthorised admin-resource access attempts, suspicious API call patterns.
• Dependency tracking (CVE) — automated npm dependency scanning (Dependabot / GitHub Advanced Security) + manual alert review.

9. Incident Response

9.1. Incident classification

9.2. Data breach notification procedure

In the event of a confirmed or suspected personal data breach:

1. ≤ 24 hours from discovery — notification to the affected Organisation (Art. 4 of the DPA — Annex 1 to the Terms). Content: description of the breach nature, categories and approximate number of data subjects and records, contact details, likely consequences, applied or proposed measures.
2. ≤ 72 hours from discovery — notification to the President of UODO (Art. 33 GDPR), where the breach concerns data for which Attestia is the controller. Submitted via e-PUAP or the ZSRN system.
3. Without undue delay — notification to affected data subjects where there is a high risk to their rights or freedoms (Art. 34 GDPR).

Security-incident contact: privacy@attestia.eu (future: security@attestia.eu).

10. Vulnerability management

• Automated dependency updates — Dependabot configured for daily scan.
• CVE monitoring — GitHub Advanced Security alerts + provider notifications (Supabase, Vercel, Azure, Stripe).
• Prioritisation: CVE by CVSS Base Score — Critical ≤ 24h, High ≤ 7 days, Medium ≤ 30 days.
• Penetration testing — planned quarterly [TODO: first round — Q4 2026].
• Code review — every change code-reviewed before merge to main; separate "security review" for changes affecting authorisation, RLS, data processing.
• SAST/DAST — static and dynamic code analysis tooling on the roadmap [ROADMAP].

11. Responsible Disclosure

We appreciate the work of the security community. If you have identified a potential vulnerability in Attestia:

11.1. Rules

• Report to: privacy@attestia.eu (future: security@attestia.eu) — with [SECURITY] in the subject.
• Do NOT publish vulnerability details publicly before we confirm remediation.
• Do NOT exploit the vulnerability beyond what is necessary to demonstrate it.
• Do NOT violate others' privacy — if you accidentally access third-party data, stop immediately and report to us.
• Give us time — standard remediation window: 90 days from confirmation (depending on severity).

11.2. What to report

Anything with real impact on User/Organisation security or privacy:

• Authentication/authorisation vulnerabilities.
• Row-Level Security / data isolation breaches.
• Injection (SQL, XSS, SSRF, Command Injection, Template Injection).
• Remote code execution (RCE).
• Cryptographic implementation errors.
• Data exfiltration, critical CSRF, Account Takeover.

11.3. What does not qualify

• Missing X-Frame-Options / CSP headers without demonstrated real-world impact.
• DoS / DDoS without demonstrated impact.
• Brute-force without rate-limiting bypass.
• Self-XSS.
• Social engineering targeted at Attestia staff or customers.
• Missing SPF/DKIM on domains not used for transactional email.

11.4. Our commitment

• Acknowledgement: within 72 hours (business days).
• Initial assessment: within 7 days of acknowledgement.
• Fix status: communicated at least every 14 days until closure.
• Credit: with reporter's consent — we will list the acknowledgement on our hall of fame [PLANNED POST-LAUNCH].
• Bug bounty: not offered at MVP stage; we are considering a financial programme after product stabilisation [ROADMAP].

11.5. Scope

12. Compliance and certifications

13. Training and security culture

• Security onboarding for every new team member — customer data handling, password policy, device usage rules.
• Policy review — annual.
• Periodic training — adapted to the evolving threat landscape (phishing, supply-chain, AI-specific threats).
• Confidentiality — all staff and contractors bound by confidentiality (aligned with § 17 of the Terms — Confidentiality).

14. Changelog

15. Contact