Jedno miejsce, w którym dział zakupów, security review i risk otrzymują odpowiedzi na typowe pytania zakupowe: dane, retencja, region, dostęp, szyfrowanie. Format zbliżony do CAIQ / SIG-lite. Doktryna claim ≤ proof: przy każdej pozycji jawnie oznaczamy, co dziś działa LIVE, a co jest jeszcze ROADMAP (m.in. OIDC, mTLS, szyfrowanie at-rest zarządzane po naszej stronie). To wsparcie procesu zakupowego, nie oświadczenie o zgodności.
ipIII jest dziś dowodliwym MVP warstwy evidence (import → incydent → evidence-package → retest → close, z JWT/RBAC/audit na żywej PostgreSQL). Poniższe odpowiedzi opisują obecny stan MVP, nie docelowy profil enterprise. Tam, gdzie kontrola jest zaplanowana lecz jeszcze niewdrożona — piszemy ROADMAP, nie LIVE.
Skrócony kwestionariusz w układzie domen kontrolnych. Kolumna Stan: LIVE = działa i ma dowód · ROADMAP = zaplanowane, jeszcze niewdrożone · proces = kontrola organizacyjna/proceduralna. Data weryfikacji: 2026-07-05.
| ID | Domena | Pytanie | Odpowiedź (MVP) | Stan |
|---|---|---|---|---|
| IAM-01 | Tożsamość i dostęp | Czy dostęp jest uwierzytelniany i autoryzowany rolami? | JWT + RBAC (role/uprawnienia) na żywej PostgreSQL; audit-log operacji. | LIVE |
| IAM-02 | Tożsamość i dostęp | Czy wspieracie SSO / federację tożsamości (OIDC)? | Dziś konta seedowane lokalnie. OIDC / SSO (Keycloak / JWKS, authorization-code flow) w planie. | ROADMAP |
| IAM-03 | Tożsamość i dostęp | Czy jest MFA i centralny provisioning/deprovisioning? | Zależne od zewnętrznego IdP — wejdzie wraz z OIDC. Dziś: brak centralnego provisioningu. | ROADMAP |
| CRY-01 | Szyfrowanie — transport | Czy dane w tranzycie są szyfrowane? | TLS jednostronny na warstwie hostingu (styk klient–API). | LIVE |
| CRY-02 | Szyfrowanie — transport | Czy wspieracie mTLS (wzajemne uwierzytelnianie TLS)? | mTLS na bramie API + certyfikaty klienckie dla konektorów — zaplanowane, jeszcze niewdrożone. | ROADMAP |
| CRY-03 | Szyfrowanie — at-rest | Czy dane w spoczynku są szyfrowane pod Waszą kontrolą kluczy? | Dziś opieramy się o szyfrowanie dysku po stronie dostawcy hostingu. Zarządzane at-rest z własnym KMS/rotacją kluczy — w planie. | ROADMAP |
| INT-01 | Integralność dowodów | Czy pakiety dowodowe mają kontrolę integralności? | Evidence-package/board-pack z sha256 i chain-of-custody w DB (manifest + hash). |
LIVE |
| INT-02 | Integralność dowodów | Czy pakiety mają podpis kwalifikowany / znacznik czasu? | Podpis PAdES + znacznik czasu TSA (RFC 3161) w planie; dziś tylko hash integralności. | ROADMAP |
| LOG-01 | Logi i audyt | Czy operacje są logowane w sposób umożliwiający audyt? | Audit-log operacji (kto/co/kiedy) na żywej PostgreSQL, część przepływu import→close. | LIVE |
| TEN-01 | Izolacja | Czy instancja jest wielodostępna (multi-tenant) z izolacją danych? | Dziś jedna organizacja. Tenant scoping + Row-Level Security (RLS) w PostgreSQL — w planie. | ROADMAP |
| BCR-01 | Ciągłość / backup | Czy są kopie zapasowe i plan odtworzenia? | Kopie zależne od dostawcy hostingu bazy. Udokumentowany RPO/RTO i testy odtworzenia — w planie. | ROADMAP |
| VUL-01 | Podatności | Czy dane o podatnościach (CVE/CVSS/EPSS/KEV) są aktualne? | Wzbogacanie offline (hinty z seedu przy imporcie). Online lookup NVD / CISA KEV / EPSS — w planie. | ROADMAP |
| SEC-01 | Testy bezpieczeństwa | Jaki jest zakres testów AI-security / areny? | Wyłącznie defensywnie, na danych syntetycznych, po pisemnych Rules of Engagement. Bez payloadów i instrukcji ataku. | proces |
| LEG-01 | Zgodność / prawo | Czy narzędzie zastępuje ocenę prawną obowiązków? | Nie. Legal Trigger Engine to wsparcie decyzji (decision support); terminy DORA/NIS2/RODO/AI Act orientacyjne, przegląd radcy przed wysyłką. | proces |
Najczęstsze pytania działu zakupów i security review, zebrane w kartach. Wszystko opisuje bieżący stan MVP.
Findings ze skanerów (Burp/ZAP/Nessus/CSV), metadane incydentów, pakiety dowodowe. W MVP demonstracyjnie na danych syntetycznych.
Szczegóły → /data-processing.
Rekordy incydentów i evidence trzymane w PostgreSQL na czas obsługi sprawy. Konfigurowalne okno retencji i automatyczne usuwanie — ROADMAP.
Deployment w regionie ustalanym per wdrożenie. Umowne zobowiązania co do rezydencji danych i wybór regionu — ROADMAP.
Dostęp rolowy (RBAC) z audit-logiem — LIVE. SSO/OIDC i centralny provisioning — ROADMAP.
Transport: TLS jednostronny LIVE. mTLS i at-rest zarządzane po naszej stronie — ROADMAP.
Hosting bazy i aplikacji u dostawcy chmurowego. Utrzymywana lista poddostawców (subprocessors) z powiadomieniem o zmianach — ROADMAP.
Kanał zgłoszeń przez /zglos. Umowne SLA na powiadomienie o incydencie — ROADMAP.
Nie posiadamy formalnych atestów zewnętrznych. Publikujemy dowody techniczne (kod+test+endpoint) i jawny rejestr luk → /known-limitations.
Skrócona ocena ryzyka dostawcy dla risk review. Każda pozycja z jawnym stanem i ścieżką domknięcia. P0 = wymagane przed wdrożeniem enterprise · P1 = wymagane dla banku/partnera, nie blokuje PoC/pilota.
| Obszar ryzyka | Stan MVP | Wektor ryzyka | Ścieżka domknięcia | Priorytet |
|---|---|---|---|---|
| Tożsamość (SSO/OIDC) | ROADMAP | Brak federacji tożsamości i centralnego (de)provisioningu. | Keycloak / JWKS + OIDC authorization-code flow. | P0 |
| Transport (mTLS) | ROADMAP | Brak wzajemnego uwierzytelniania TLS na styku integracji. | mTLS na bramie API + certyfikaty klienckie konektorów. | P0 |
| Szyfrowanie at-rest | ROADMAP | Klucze at-rest nie są dziś zarządzane po naszej stronie. | Własny KMS + rotacja kluczy + polityka szyfrowania. | P1 |
| Wielodostępność (tenancy) | ROADMAP | Jedna organizacja; brak izolacji danych per klient. | Tenant scoping + Row-Level Security w PostgreSQL. | P1 |
| Formalny dowód (PAdES/TSA) | ROADMAP | Hash dowodzi niezmienności, ale nie jest podpisem kwalifikowanym. | PAdES + znacznik czasu TSA (RFC 3161). | P1 |
| Rezydencja / retencja danych | ROADMAP | Brak umownego zobowiązania co do regionu i okna retencji. | Konfigurowalna retencja + wybór regionu w umowie. | P1 |
| Ciągłość (backup/RPO/RTO) | ROADMAP | Brak udokumentowanych i testowanych parametrów odtworzenia. | Polityka backupu + test odtworzenia + RPO/RTO. | P1 |
| Warstwa evidence (rdzeń) | LIVE | Ograniczona do MVP; nie profil enterprise. | Import→incydent→evidence→retest→close z JWT/RBAC/audit. | stabilne |
Powiązane: przegląd zaufania i dowodów → /trust-center · jawny rejestr luk → /known-limitations · przetwarzanie danych → /data-processing · gotowość enterprise → /enterprise-readiness.