Dane PII (verified_data)

Pole verified_data w odpowiedzi GET /verifications/{id}/result zawiera zweryfikowane dane osobowe (PII - Personally Identifiable Information). Ta strona opisuje jak je obsługiwać zgodnie z prawem.

Struktura verified_data

Zawartość verified_data zależy od dostawcy weryfikacji. Typowe pola:

Pole	Typ	Dostępność
first_name	string	Wszyscy dostawcy
last_name	string	Wszyscy dostawcy
pesel	string	mObywatel, częściowo bank_transfer
id_document_number	string	mObywatel
id_document_type	string	mObywatel (id_card, passport)
date_of_birth	string (date)	mObywatel
nationality	string (ISO 3166)	mObywatel
iban	string	bank_transfer
bank_name	string	bank_transfer

Przykład - bank_transfer

{
  "first_name": "Jan",
  "last_name": "Kowalski",
  "iban": "PL61109010140000071219812874",
  "bank_name": "Santander Bank Polska"
}

Przykład - mObywatel

{
  "first_name": "Jan",
  "last_name": "Kowalski",
  "pesel": "90010112345",
  "id_document_number": "ABC123456",
  "id_document_type": "id_card",
  "date_of_birth": "1990-01-01",
  "nationality": "PL"
}

Bezpieczeństwo po stronie HUB

DPay Web EID przechowuje wszystkie pola verified_data zaszyfrowane w bazie:

• Algorytm: AES-256-GCM (szyfrowanie symetryczne z autentykacją)
• Zarządzanie kluczami: klucze rotowane regularnie, przechowywane w HSM/KMS
• Dostęp: tylko przez API z autoryzacją Bearer token

Wymogi RODO

Zgodność z RODO

Otrzymując i przechowując dane PII, stajesz się administratorem danych osobowych w rozumieniu RODO. Musisz spełnić wymogi prawne:

Co musisz zapewnić

1. Podstawa prawna przetwarzania - zgoda klienta, umowa lub uzasadniony interes
2. Klauzula informacyjna - poinformuj klienta jakie dane zbierasz, w jakim celu i jak długo
3. Cel ograniczony - zbieraj tylko te dane, które są niezbędne (data minimization)
4. Bezpieczne przechowywanie - szyfrowanie at-rest i in-transit po Twojej stronie
5. Retencja - usuwaj dane po ustaniu celu przetwarzania
6. Prawo do bycia zapomnianym - umożliw klientowi usunięcie jego danych
7. Prawo dostępu - umożliw klientowi pobranie swoich danych
8. Audit log - zapisuj kto, kiedy i w jakim celu uzyskał dostęp do danych
9. DPIA (Data Protection Impact Assessment) - dla operacji wysokiego ryzyka
10. Zgłaszanie naruszeń - 72h na zgłoszenie incydentu do UODO

Dobre praktyki

• Szyfrowanie at-rest - przechowuj verified_data w bazie zaszyfrowane (np. PostgreSQL pgcrypto, MySQL AES_ENCRYPT)
• Pseudonimizacja - jeśli możesz, używaj tylko hashy/maskingu zamiast pełnych wartości (np. PESEL jako SHA-256 z saltem)
• Minimalizacja - nie przechowuj verified_data po zakończeniu KYC, zachowaj tylko fakt zweryfikowania
• Tokenizacja - generuj wewnętrzny token customer_id zamiast operować na PESEL
• Access control - tylko uprawnieni pracownicy mają dostęp do PII (RBAC)
• Audit log - loguj każdy dostęp do danych klienta z user_id, timestamp, IP

Przykład - bezpieczne przechowywanie w PHP

<?php
function storeVerifiedData(string $sessionId, array $verifiedData): void
{
    $key = base64_decode(getenv('PII_ENCRYPTION_KEY')); // 32 bytes
    $iv = random_bytes(12); // GCM nonce

    $plaintext = json_encode($verifiedData, JSON_THROW_ON_ERROR);

    $tag = '';
    $ciphertext = openssl_encrypt(
        $plaintext,
        'aes-256-gcm',
        $key,
        OPENSSL_RAW_DATA,
        $iv,
        $tag
    );

    $stored = base64_encode($iv . $tag . $ciphertext);

    $stmt = $pdo->prepare(
        'INSERT INTO kyc_results (session_id, encrypted_data, created_at)
         VALUES (?, ?, NOW())'
    );
    $stmt->execute([$sessionId, $stored]);

    // Audit log
    auditLog('store_pii', ['session_id' => $sessionId, 'user' => currentUser()]);
}

Retencja danych

Rekomendowana retencja verified_data po Twojej stronie:

Cel	Czas retencji	Uzasadnienie
KYC ustawowe (banki, fintech)	5 lat od zakończenia relacji	Ustawa AML
KYC podstawowe (e-commerce premium)	2 lata	Cele dowodowe
Weryfikacja jednorazowa	Po zakończeniu sesji	Zasada minimalizacji

Po upływie czasu retencji usuń dane lub zanonimizuj je nieodwracalnie.