Zanim dane trafią do ipIII, muszą mieć przypisaną klasę (syntetyczne / zanonimizowane / realne), a klasa determinuje resztę: jak długo dane są przechowywane, kiedy i jak są usuwane, gdzie fizycznie leżą i kto ma do nich dostęp. Ta strona jest warstwą governance nad Data Processing / DPA (rola przetwarzającego, art. 28 RODO) — tam jest umowa i podstawy prawne, tutaj jest operacyjna klasyfikacja i cykl życia danych. Zgodnie z doktryną claim ≤ proof: to, co działa dziś, oznaczamy LIVE; to, co zaplanowane — ROADMAP.
ipIII rozróżnia dane syntetyczne (wygenerowane, bez realnych podmiotów), zanonimizowane / spseudonimizowane (dane pochodzące z realnego kontekstu, z usuniętymi lub zamaskowanymi identyfikatorami) oraz realne (dane produkcyjne odbiorcy, w tym potencjalnie osobowe — wyłącznie za jawną, pisemną zgodą w DPA). Domyślne ustawienie dla PoC i pilotów to dane syntetyczne lub zanonimizowane; dane realne to wyjątek wymagający odrębnej podstawy.
Każdy rekord wchodzący do ipIII (finding, artefakt pentestu, log incydentu, załącznik) jest przypisywany do jednej z trzech klas. Klasyfikacja jest jawna w metadanych rekordu. Data weryfikacji: 2026-07-05.
| Klasa | Definicja | Typowe źródło | Domyślność | Status |
|---|---|---|---|---|
| Syntetyczne | Dane wygenerowane (seed, fixtures, symulacje) — nie odnoszą się do żadnej realnej osoby ani realnego systemu produkcyjnego. | Demo, hackaton, szkolenie agentów, testy integracyjne. | Tak — domyślny tryb pracy poza etapem pilota. | LIVE |
| Zanonimizowane / spseudonimizowane | Dane pochodzące z realnego pentestu lub incydentu, z usuniętymi lub zamaskowanymi identyfikatorami (nazwiska, adresy IP klientów, dane kontaktowe). | Pilot / PoC z partnerem — findings, artefakty skanerów, metadane incydentu. | Tak — domyślny tryb dla pilotów i PoC. | LIVE reguły maskowania |
| Realne (w tym potencjalnie osobowe) | Dane produkcyjne odbiorcy bez anonimizacji — dopuszczalne wyłącznie za jawną, pisemną zgodą w DPA i z określonym, węższym zakresem. | Zaawansowane etapy wdrożenia u partnera, po podpisaniu DPA i uzgodnieniu zakresu. | Nie — wyjątek, nigdy domyślne ustawienie. | za zgodą pisemną |
Okres przechowywania zależy od klasy danych — im bliżej danych realnych, tym krótsze okno i ściślejsza kontrola.
| Klasa | Retencja | Uzasadnienie | Status |
|---|---|---|---|
| Syntetyczne | Czas trwania środowiska demo / hackatonu; może być przechowywane dłużej do celów szkoleniowych i regresji. | Brak ryzyka dla podmiotów danych — nie ma realnych podmiotów. | LIVE |
| Zanonimizowane | Czas trwania PoC / pilota + krótkie okno przejściowe (na retest, eksport evidence-package), następnie usunięcie. | Zasada ograniczenia przechowywania — art. 5 ust. 1 lit. e RODO (nawet po anonimizacji stosujemy ostrożne, krótkie okno). | LIVE okno konfig. w DPA |
| Realne | Minimalny, jawnie określony w DPA okres — najkrótszy uzasadniony celem przetwarzania; brak przechowywania „na zapas". | Minimalizacja + ograniczenie celu — art. 5 ust. 1 lit. b i c RODO; ryzyko rezydualne większe niż dla klas anonimowych. | ustalane w DPA per przypadek |
Usunięcie następuje na koniec ustalonego okresu retencji lub na żądanie administratora (odbiorcy).
Usunięcie rekordów z bazy PostgreSQL na żądanie administratora lub po zakończeniu okresu PoC/pilota, wykonywane operacyjnie przez zespół K0NSULT po potwierdzeniu zakresu z odbiorcą.
Zautomatyzowane egzekwowanie polityki retencji (harmonogram + auto-purge per klasa danych), jawny certyfikat usunięcia jako dowód dla audytora, oraz niezmienny (immutable) log operacji usunięcia. To jeszcze nie jest wdrożone — dziś usunięcie jest procesem manualnym z potwierdzeniem, nie automatem.
Dane są przetwarzane i przechowywane w Unii Europejskiej. Deployment mode opisujemy uczciwie — zobacz też /deployment-modes dla pełnego obrazu wariantów.
| Wariant | Opis | Status |
|---|---|---|
| SaaS UE (współdzielona infrastruktura hostingowa) | Region hostingu w Unii Europejskiej. Brak domyślnego transferu danych poza EOG. Tryb działający dziś dla PoC i pilotów. | LIVE |
| Private tenant / dedykowana instancja UE | Wydzielona instancja per klient, bez współdzielenia bazy z innymi odbiorcami. | ROADMAP |
| VPC / on-premise w infrastrukturze odbiorcy | Wdrożenie w sieci klienta (np. bank SIFI) z pełną kontrolą nad granicą sieciową. | ROADMAP |
Dostęp oparty na rolach (RBAC), zasada najmniejszych uprawnień, logowanie operacji na danych (kto, kiedy, co).
Dziś RBAC działa na poziomie ról funkcjonalnych (np. analityk, admin), nie jest jeszcze granularnie sprzężony z klasą danych (np. automatyczne zawężenie dostępu do danych realnych do węższej grupy niż dane syntetyczne). To rozszerzenie jest zaplanowane, nie wdrożone.
Patrz też /known-limitations — dziś jedna organizacja, brak Row-Level Security per tenant. Istotne dla governance przy wielu odbiorcach na wspólnej instancji.
Ta strona operacjonalizuje zasady opisane w Data Processing / DPA. Poniżej skrócone odniesienie — pełny checklist umowy powierzenia jest na tamtej stronie.
Rola podmiotu przetwarzającego, checklist umowy powierzenia, prawa podmiotów danych.
Szyfrowanie at-rest, tenancy, mTLS — uczciwy rejestr tego, czego jeszcze nie ma.
Warianty wdrożenia — co działa dziś (SaaS UE), co jest planem (private tenant, on-premise).
Punkt wejścia do warstwy zaufania ipIII: bezpieczeństwo, dane, granice etyczne i prawne.
Powiązane: przetwarzanie danych i DPA → /data-processing · granice dojrzałości → /known-limitations · warianty wdrożenia → /deployment-modes.