Bezpieczeństwo / Security — Attestia.eu

Wersją wiążącą jest wersja polska. / The Polish version is legally binding.

Wersja / Version: 1.0-draft Data wejścia w życie / Effective date: 2026-04-01 Ostatnia aktualizacja / Last updated: 2026-04-01 URL publikacji / Published at: attestia.eu/security Dokumenty powiązane / Related documents:

Wersja polska (wiążąca)

1. Nasze podejście do bezpieczeństwa

Attestia jest platformą SaaS dla compliance — a to oznacza, że powierzone nam dane (opisy Systemów AI Organizacji, dokumentacja compliance, Dziennik audytu) stanowią często tajemnicę przedsiębiorstwa. Bezpieczeństwo nie jest dla nas funkcją — jest warunkiem koniecznym prowadzenia tej działalności.

Niniejsza strona opisuje naszą postawę bezpieczeństwa: architekturę, mechanizmy ochronne, procedury reagowania na incydenty oraz kanał odpowiedzialnego zgłaszania podatności. Jest uzupełnieniem Załącznika A do DPA (Środki techniczne i organizacyjne) — tam znajduje się formalna specyfikacja wynikająca z umowy powierzenia.

Określenia pisane wielką literą mają znaczenie nadane im w Regulaminie Attestia.eu.

2. Infrastruktura i dane w UE

| Warstwa | Dostawca | Lokalizacja | Rola | |---|---|---|---| | Baza danych + autentykacja | Supabase (Pty) Ltd | UE — Frankfurt (eu-central-1) | Przechowywanie Kont, Danych Organizacji, Dziennika audytu | | Aplikacja (edge) | Vercel, Inc. | UE — węzły brzegowe (Frankfurt, Paryż) | Renderowanie aplikacji, brak trwałego przechowywania danych | | AI | Microsoft Azure OpenAI | UE — Sweden Central (swedencentral) | Klasyfikacja Ryzyka, generowanie Dokumentów Compliance | | E-mail transakcyjny | Resend, Inc. | US (z SCC) | Wysyłka powiadomień | | Płatności | Stripe, Inc. / Stripe Payments Europe, Ltd. | UE + US (z SCC + DPF) | Obsługa subskrypcji |

Zasada: Dane Organizacji, Dokumenty Compliance i dane przetwarzane przez AI pozostają w granicach UE/EOG. Szczegółowa lista podprocesorów: attestia.eu/subprocessors.

3. Szyfrowanie

3.1. W tranzycie (in transit)

  • TLS 1.3 dla wszystkich połączeń HTTPS (wymuszony na poziomie CDN Vercel).
  • HSTS włączony z flagą includeSubDomains i preload.
  • Słabsze wersje TLS (1.0, 1.1) są odrzucane.
  • Połączenia baza ↔ aplikacja oraz aplikacja ↔ Azure OpenAI są szyfrowane TLS 1.3.

3.2. W spoczynku (at rest)

  • AES-256 na poziomie bazy danych PostgreSQL (Supabase).
  • AES-256 na woluminach Azure (Azure Storage Service Encryption).
  • Klucze zarządzane przez dostawców (Supabase/Azure KMS). Rotacja zgodnie z cyklami dostawców.

3.3. Haseł

  • bcrypt (Supabase Auth, domyślna konfiguracja — cost factor 10+).
  • Minimalne wymagania: 8+ znaków, detekcja haseł z rainbow tables.
  • Nie logujemy haseł w czystej postaci w żadnym etapie przetwarzania.

4. Kontrola dostępu i uwierzytelnianie

| Mechanizm | Szczegóły | |---|---| | Role (RBAC) | 4 role na poziomie Organizacji: Owner, Admin, Member, Viewer | | Row-Level Security (RLS) | Egzekwowana na poziomie bazy danych PostgreSQL — dane Organizacji są izolowane na poziomie zapytań SQL | | Multi-tenancy | Każda Organizacja ma przypisany org_id (JWT claim); wszystkie zapytania filtrowane przez RLS | | Uwierzytelnianie | Email + hasło, OAuth (Google, GitHub), opcjonalne MFA (TOTP) | | MFA | Zalecane dla wszystkich ról; wymagane dla kont administratorów wewnętrznych Attestia | | Sesje | Access token TTL 1h, Refresh token TTL 7 dni, cookies HttpOnly Secure SameSite | | Logowania OAuth | PKCE flow; scope ograniczony do email + profile | | Cross-subdomain cookies | .attestia.eu — wspólne dla attestia.eu i app.attestia.eu, z odpowiednimi flagami | | Brute-force protection | Rate limiting na endpointach auth; detekcja podejrzanych wzorców logowania | | Password reset | Tokeny jednorazowe, ważne 60 min, linkowane przez wiadomość e-mail z Resend |

5. Dziennik audytu (Audit Log)

Zgodnie z art. 18 EU AI Act oraz § 12.4 Regulaminu, Platforma prowadzi niezmienny Dziennik audytu:

  • Hash-chain — każdy wpis zawiera hash SHA-256 poprzedniego wpisu (model łańcucha Merkle-light).
  • Append-only — brak możliwości modyfikacji ani usunięcia wpisów.
  • Zakres — każda istotna operacja compliance (utworzenie/edycja Klasyfikacji, generowanie Dokumentu, akceptacja rekomendacji AI, eksport danych, zmiany ról).
  • Retencja — 10 lat od daty ostatniego wpisu, w formie pseudonimizowanej (identyfikatory Użytkowników i Organizacji zastępowane nieodwracalnymi hashami po rozwiązaniu umowy).
  • Dostęp — tylko dla uprawnionych ról w Organizacji + wewnętrznego zespołu Attestia w trybie break-glass z własnym logiem.

Dziennik audytu jest elementem obrony przed manipulacją historią decyzji compliance i dowodem należytej staranności w przypadku audytu regulatora.

6. Pseudonimizacja przy AI

Opisy Systemów AI wysyłane do Azure OpenAI są pseudonimizowane przed wysyłką:

  • Usuwane: nazwa Organizacji, imiona i nazwiska Użytkowników, adresy e-mail, identyfikatory Konta, dane rozliczeniowe.
  • Zachowywane: treść merytoryczna opisu Systemu AI (niezbędna do klasyfikacji).
  • Odwzorowanie pseudonim → rzeczywisty identyfikator jest przechowywane wyłącznie po stronie Attestia i nie jest wysyłane do AI.

Dzięki temu nawet w scenariuszu kompromitacji Azure OpenAI (pomimo zobowiązań umownych Microsoft) dane Organizacji nie są bezpośrednio atrybuowalne.

Szczegóły: § 7 ust. 5 Regulaminu + sekcja 4.3 Polityki Prywatności + attestia.eu/transparency.

7. Backupy i ciągłość działania

| Element | Konfiguracja | |---|---| | Backupy bazy danych | Automatyczne, codzienne (Supabase) | | Retencja | 30 dni | | Point-in-time recovery (PITR) | Tak — możliwość przywrócenia do dowolnej chwili w oknie 30 dni | | Geo-redundancja | W ramach regionu Frankfurt (AWS eu-central-1 — 3 Availability Zones) | | Testowanie backupów | Planowane kwartalne testy odtworzenia [TODO: harmonogram po launch] | | Disaster Recovery Plan (DRP) | [DO UTWORZENIA PRZED SCALE-UP] — na etapie MVP RPO/RTO są dyktowane przez SLA Supabase |

8. Monitoring i wykrywanie incydentów

  • Sentry — monitoring błędów aplikacji, alerty na anomalie.
  • Supabase logs — logi zapytań bazy danych, detekcja nietypowych wzorców.
  • Vercel analytics — monitoring dostępności (uptime).
  • Alerting — alerty na krytyczne błędy aplikacji, nieautoryzowane próby dostępu do zasobów administracyjnych, podejrzane wzorce API calls.
  • Śledzenie zależności (CVE) — automatyczne skanowanie zależności npm (Dependabot / GitHub Advanced Security) + manualny przegląd alertów.

9. Procedura reagowania na incydenty (Incident Response)

9.1. Klasyfikacja incydentów

| Poziom | Przykład | Czas reakcji | |---|---|---| | P0 — Krytyczny | Wyciek danych, kompromitacja bazy, nieautoryzowany dostęp do Danych Organizacji | < 1 godzina | | P1 — Wysoki | Długotrwała niedostępność Platformy, anomalie w autoryzacji | < 4 godziny | | P2 — Średni | Wyciek informacji nieosobowych, błąd w funkcjonalności compliance | < 24 godziny | | P3 — Niski | Bugi nieimpaktujące bezpieczeństwa | < 5 dni roboczych |

9.2. Tryb zgłaszania naruszeń ochrony danych

W przypadku potwierdzonego lub podejrzewanego naruszenia ochrony danych osobowych:

  1. ≤ 24 godziny od stwierdzenia — powiadomienie Organizacji, której dane zostały dotknięte (art. 4 DPA — Załącznik nr 1 do Regulaminu). Treść powiadomienia: opis charakteru naruszenia, kategorie i przybliżona liczba osób i rekordów, dane kontaktowe, prawdopodobne konsekwencje, zastosowane lub proponowane środki.
  2. ≤ 72 godziny od stwierdzenia — zgłoszenie do Prezesa UODO (art. 33 RODO), jeżeli dotyczy danych, dla których Attestia jest administratorem. Zgłoszenia dokonuje się przez e-PUAP lub system ZSRN.
  3. Bez zbędnej zwłoki — zawiadomienie osób, których dane dotyczą, w przypadku wysokiego ryzyka dla ich praw lub wolności (art. 34 RODO).

Kontakt ws. incydentów bezpieczeństwa: privacy@attestia.eu (docelowo: security@attestia.eu).

10. Zarządzanie podatnościami (Vulnerability Management)

  • Automatyczne aktualizacje zależności — Dependabot skonfigurowany na daily scan.
  • Monitoring CVE — alerty z GitHub Advanced Security + powiadomienia od dostawców infrastruktury (Supabase, Vercel, Azure, Stripe).
  • Priorytetyzacja: CVE wg CVSS Base Score — Critical ≤ 24h, High ≤ 7 dni, Medium ≤ 30 dni.
  • Testy penetracyjne — planowane kwartalnie [TODO: pierwsze testy — Q4 2026].
  • Przegląd kodu — każda zmiana code review przed merge do main; osobny „security review" dla zmian dotyczących autoryzacji, RLS, przetwarzania danych.
  • SAST/DAST — narzędzia do statycznej i dynamicznej analizy kodu są w planach [ROADMAP].

11. Odpowiedzialne zgłaszanie podatności (Responsible Disclosure)

Doceniamy pracę społeczności security. Jeżeli zidentyfikowałeś/-aś potencjalną podatność w Attestia:

11.1. Zasady

  • Zgłaszaj do: privacy@attestia.eu (docelowo: security@attestia.eu) — z prefiksem [SECURITY] w temacie.
  • NIE publikuj szczegółów podatności publicznie przed naszym potwierdzeniem naprawy.
  • NIE eksploatuj podatności poza zakresem koniecznym do jej zademonstrowania.
  • NIE naruszaj prywatności innych Użytkowników — jeśli przypadkowo uzyskałeś/-aś dostęp do cudzych danych, natychmiast zaprzestań i zgłoś nam to.
  • Daj nam czas — standardowy okres naprawy: 90 dni od potwierdzenia (w zależności od krytyczności).

11.2. Co zgłaszać

Wszystko, co ma realny impakt na bezpieczeństwo lub prywatność Użytkowników i Organizacji:

  • Podatności autentykacji/autoryzacji.
  • Naruszenia Row-Level Security / izolacji danych.
  • Injection (SQL, XSS, SSRF, Command Injection, Template Injection).
  • Zdalne wykonanie kodu (RCE).
  • Błędy w implementacji kryptograficznej.
  • Eksfiltracja danych, CSRF krytyczny, Account Takeover.

11.3. Co nie kwalifikuje się

  • Brak nagłówków typu X-Frame-Options / CSP bez demonstracji realnego impaktu.
  • DoS / DDoS bez realnej demonstracji wpływu.
  • Brute-force bez pokazania obejścia rate limitingu.
  • Samoistnie włączony XSS (self-XSS).
  • Social engineering kierowany na pracowników Attestia lub klientów.
  • Brak SPF/DKIM na domenach nie używanych do e-maili transakcyjnych.

11.4. Nasze zobowiązanie

  • Potwierdzenie przyjęcia zgłoszenia: w ciągu 72 godzin (dni robocze).
  • Wstępna ocena: w ciągu 7 dni od potwierdzenia.
  • Status naprawy: komunikowany co najmniej co 14 dni do zamknięcia zgłoszenia.
  • Uznanie (acknowledgement): za zgodą zgłaszającego — umieścimy podziękowanie na hall of fame [PLANOWANE PO LAUNCH].
  • Bug bounty: na etapie MVP nie oferujemy programu finansowego; rozważamy uruchomienie po osiągnięciu stabilności produktu [ROADMAP].

11.5. Zakres (Scope)

| W zakresie | Poza zakresem | |---|---| | attestia.eu (marketing) | Aplikacje innych firm (Supabase, Vercel, Azure, Stripe — zgłaszać bezpośrednio im) | | app.attestia.eu (aplikacja) | Domeny testowe i preview deploys | | API (gdy uruchomione) | E-maile pracowników Attestia | | | Fizyczne obiekty, social engineering |

12. Zgodność i certyfikaty

| Status | Element | |---|---| | ✅ Aktualne | Zgodność z art. 32 RODO (środki techniczne i organizacyjne) | | ✅ Aktualne | Zgodność z art. 28 RODO (DPA) — Załącznik nr 1 do Regulaminu | | ✅ Aktualne | Zgodność z art. 50 EU AI Act (transparency) — attestia.eu/transparency | | ⏳ W planach | SOC 2 Type II — po stabilizacji produkcyjnej (target: 2027) | | ⏳ W planach | ISO/IEC 27001 — po osiągnięciu skali uzasadniającej audyt (target: 2027+) | | ⏳ Monitorowane | NIS2 — Attestia nie kwalifikuje się obecnie jako „essential/important entity", monitorujemy progi sektorowe | | ⏳ Monitorowane | C2PA (oznaczanie treści AI) — wdrożenie po stabilizacji standardu |

13. Szkolenia i kultura bezpieczeństwa

  • Onboarding bezpieczeństwa dla każdego nowego członka zespołu — zasady przetwarzania danych klientów, polityka haseł, zasady korzystania z urządzeń.
  • Przegląd polityk — coroczny.
  • Szkolenia okresowe — dostosowane do ewoluującego krajobrazu zagrożeń (phishing, supply-chain, AI-specific threats).
  • Tajemnica — wszyscy pracownicy i współpracownicy zobowiązani do zachowania tajemnicy (spójnie z § 17 Regulaminu — Poufność).

14. Historia zmian / Changelog

| Data | Wersja | Opis | |---|---|---| | 2026-04-21 | 1.0-draft | Pierwsza wersja |

15. Kontakt

| | | |---|---| | Zgłoszenia bezpieczeństwa | privacy@attestia.eu (docelowo: security@attestia.eu) | | Naruszenia ochrony danych | privacy@attestia.eu | | Pytania ogólne | kontakt@attestia.eu | | Wsparcie techniczne | support@attestia.eu | | Adres pocztowy | Trimalert sp. z o.o., ul. Przasnyska 7/319, 01-756 Warszawa, Polska |

English version (for information)

In case of any discrepancy between the Polish and English versions, the Polish version shall prevail.

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

| Layer | Provider | Location | Role | |---|---|---|---| | Database + authentication | Supabase (Pty) Ltd | EU — Frankfurt (eu-central-1) | Storage of Accounts, Organisation Data, Audit Log | | Application (edge) | Vercel, Inc. | EU — edge nodes (Frankfurt, Paris) | Application rendering, no persistent data | | AI | Microsoft Azure OpenAI | EU — Sweden Central (swedencentral) | Risk Classification, Compliance Document generation | | Transactional email | Resend, Inc. | US (with SCC) | Notifications delivery | | Payments | Stripe, Inc. / Stripe Payments Europe, Ltd. | EU + US (with SCC + DPF) | Subscription processing |

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

| Mechanism | Details | |---|---| | Roles (RBAC) | 4 roles at Organisation level: Owner, Admin, Member, Viewer | | Row-Level Security (RLS) | Enforced at the PostgreSQL layer — Organisation data is isolated at SQL query level | | Multi-tenancy | Each Organisation has an assigned org_id (JWT claim); all queries filtered through RLS | | Authentication | Email + password, OAuth (Google, GitHub), optional MFA (TOTP) | | MFA | Recommended for all roles; required for internal Attestia admin accounts | | Sessions | Access token TTL 1h, Refresh token TTL 7 days, HttpOnly Secure SameSite cookies | | OAuth | PKCE flow; scope limited to email + profile | | Cross-subdomain cookies | .attestia.eu — shared by attestia.eu and app.attestia.eu with appropriate flags | | Brute-force protection | Rate limiting on auth endpoints; detection of suspicious login patterns | | Password reset | Single-use tokens, 60-minute validity, delivered via Resend email |

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

| Item | Configuration | |---|---| | Database backups | Automated, daily (Supabase) | | Retention | 30 days | | Point-in-time recovery (PITR) | Yes — restore to any point within 30-day window | | Geo-redundancy | Within Frankfurt region (AWS eu-central-1 — 3 Availability Zones) | | Backup testing | Planned quarterly restore tests [TODO: schedule post-launch] | | Disaster Recovery Plan (DRP) | [TO BE CREATED BEFORE SCALE-UP] — at MVP stage RPO/RTO are governed by Supabase SLAs |

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

| Level | Example | Response time | |---|---|---| | P0 — Critical | Data breach, database compromise, unauthorised access to Organisation Data | < 1 hour | | P1 — High | Prolonged Platform unavailability, authorisation anomalies | < 4 hours | | P2 — Medium | Non-personal data leak, compliance feature defect | < 24 hours | | P3 — Low | Bugs not impacting security | < 5 business days |

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

| In scope | Out of scope | |---|---| | attestia.eu (marketing) | Third-party applications (Supabase, Vercel, Azure, Stripe — report to them directly) | | app.attestia.eu (application) | Test domains and preview deployments | | API (once exposed) | Attestia employee emails | | | Physical premises, social engineering |

12. Compliance and certifications

| Status | Item | |---|---| | ✅ Current | Compliance with Art. 32 GDPR (technical and organisational measures) | | ✅ Current | Compliance with Art. 28 GDPR (DPA) — Annex 1 to the Terms | | ✅ Current | Compliance with Art. 50 EU AI Act (transparency) — attestia.eu/transparency | | ⏳ Planned | SOC 2 Type II — after production stabilisation (target: 2027) | | ⏳ Planned | ISO/IEC 27001 — once scale warrants audit (target: 2027+) | | ⏳ Monitored | NIS2 — Attestia does not currently qualify as an "essential/important entity"; sector thresholds monitored | | ⏳ Monitored | C2PA (AI content marking) — deployment once the standard stabilises |

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

| Date | Version | Description | |---|---|---| | 2026-04-21 | 1.0-draft | Initial draft |

15. Contact

| | | |---|---| | Security reports | privacy@attestia.eu (future: security@attestia.eu) | | Data breach notifications | privacy@attestia.eu | | General enquiries | kontakt@attestia.eu | | Technical support | support@attestia.eu | | Postal address | Trimalert sp. z o.o., ul. Przasnyska 7/319, 01-756 Warsaw, Poland |