k0nsult.cloud / ai-truth / ipIII / procurement / vendor-risk
Vendor Risk Pack — K0NSULT jako dostawca (CAIQ/SIG-lite)
Kiedy bank, ubezpieczyciel lub dział procurement ocenia K0NSULT jako dostawcę ipIII, dostaje zwykle długi
kwestionariusz w stylu CAIQ (Consensus Assessment Initiative Questionnaire, CSA) albo SIG-Lite
(Standardized Information Gathering, Shared Assessments). Ta strona to uporządkowany pakiet odpowiedzi wzorcowych
na najczęstsze pytania z tych kwestionariuszy — postawa bezpieczeństwa, kontrola dostępu, ciągłość działania,
reagowanie na incydenty, subprocesorzy i zależności. To przyspieszenie intake'u due diligence, nie zastąpienie
właściwego, podpisanego kwestionariusza — ten wymaga przeglądu zespołu bezpieczeństwa i prawnego K0NSULT przed wysyłką
do konkretnego kontrahenta.
Po co ta strona i czym różni się od Third-Party Risk.
Third-Party Risk Evidence Pack ocenia
naszych dostawców
(perspektywa K0NSULT jako kupującego). Ta strona jest lustrzana: odpowiada na pytania, które
my dostajemy
od banków, ubezpieczycieli i zespołów procurement, gdy K0NSULT jest ocenianym dostawcą ipIII. Zgodnie z doktryną
claim ≤ proof: każda odpowiedź ma status —
LIVE (działa i ma dowód
kod/test/endpoint, patrz
roadmapa dev),
ROADMAP
(planowane, jeszcze nie działa) albo
wymaga człowieka (dokument prawny/rejestr,
który musi potwierdzić zespół prawny/DPO przed wysyłką do kontrahenta).
10 domen kwestionariusza. Jedna odpowiedź na każdą. Zero domysłów.
Pakiet pokrywa domeny typowe dla CAIQ v4 / SIG-Lite: governance, ochrona danych, kontrola dostępu, bezpieczeństwo
aplikacji (SDLC), ciągłość działania i DR, reagowanie na incydenty, subprocesorzy/supply chain, mapowanie regulacyjne,
bezpieczeństwo infrastruktury/hostingu oraz bezpieczeństwo kadrowe. Odpowiedzi poniżej to wzorzec gotowy do
dostosowania per kontrahent — nie podpisany, gotowy do wysyłki formularz.
PRZEPŁYW:
bank/procurement wysyła CAIQ/SIG→zespół sec+legal K0NSULT weryfikuje pakiet wzorcowy→dostosowanie do NDA/scope→podpis i wysyłka→evidence-package jako załącznik
1. Organizacja i governance bezpieczeństwa
| Pytanie (CAIQ/SIG-lite) | Odpowiedź K0NSULT | Status |
|---|
| Czy istnieje udokumentowana polityka bezpieczeństwa informacji? |
Doktryna claim ≤ proof jako zasada nadrzędna; polityki szczegółowe (klasyfikacja danych, retencja,
zarządzanie incydentem) w trakcie formalizacji do jednego rejestru. |
częściowo |
| Czy wyznaczono właściciela ryzyka bezpieczeństwa / odpowiedzialną rolę? |
Tak, na poziomie zespołu produktowego ipIII. Formalna rola CISO/Security Officer z odrębnym raportowaniem
do zarządu — poza obecnym zakresem MVP. |
ROADMAP |
| Czy przeprowadzany jest niezależny audyt bezpieczeństwa (SOC 2 / ISO 27001)? |
Nie posiadamy dziś certyfikatu SOC 2 ani ISO 27001. Nie deklarujemy zgodności, której nie potwierdził
akredytowany audytor zewnętrzny — to wymaga zlecenia niezależnej jednostce certyfikującej. |
wymaga człowieka (audytor zewn.) |
2. Ochrona danych i szyfrowanie
| Pytanie | Odpowiedź K0NSULT | Status |
|---|
| Czy dane są szyfrowane w tranzycie? |
Tak — TLS na warstwie hostingu dla ruchu klient→API. Wzajemne uwierzytelnianie TLS (mTLS) między
klientem a API oraz między usługami — patrz ograniczenie „Transport" (P0). |
LIVE (TLS) / ROADMAP (mTLS) |
| Czy dane są szyfrowane w spoczynku (at rest)? |
Szyfrowanie na poziomie wolumenu bazy danych zależne od konfiguracji dostawcy hostingu (managed PostgreSQL).
Szyfrowanie na poziomie kolumny dla pól wrażliwych — nie wdrożone. |
częściowo |
| Czy evidence-package (dowody) ma zabezpieczoną integralność? |
Tak — sha256 pakietu + chain-of-custody w bazie. Kwalifikowany podpis elektroniczny (PAdES)
i znacznik czasu TSA — jeszcze nie wdrożone, patrz known-limitations. |
LIVE (hash) / ROADMAP (PAdES/TSA) |
| Gdzie fizycznie przetwarzane są dane (rezydencja danych)? |
Region EU u dostawcy hostingu. Wybór/gwarancja konkretnego regionu per klient (data residency contract clause)
— element umowny, wymaga ustaleń z zespołem prawnym per kontrakt. |
wymaga człowieka (kontrakt) |
3. Kontrola dostępu i tożsamość
| Pytanie | Odpowiedź K0NSULT | Status |
|---|
| Czy stosowana jest kontrola dostępu oparta na rolach (RBAC)? |
Tak — JWT + RBAC + audit log na żywej instancji PostgreSQL, potwierdzone testami integracyjnymi. |
LIVE |
| Czy wspierane jest logowanie federacyjne (SSO/OIDC) i MFA wymuszane centralnie? |
Nie dziś. JWT wystawiany lokalnie, konta seedowane — brak integracji z zewnętrznym IdP (Keycloak/OIDC).
To ograniczenie P0, patrz known-limitations. |
ROADMAP (P0) |
| Czy prowadzony jest przegląd uprawnień (access review) i deprovisioning? |
Proces manualny na obecnym etapie; automatyczny cykl przeglądu i deprovisioningu powiązany z IdP — planowany
wraz z wdrożeniem OIDC. |
ROADMAP |
| Czy każda akcja jest rejestrowana w logu audytowym? |
Tak — audit log dla operacji na incydentach/evidence-package w warstwie orchestratora. |
LIVE |
4. Bezpieczeństwo aplikacji i SDLC
| Pytanie | Odpowiedź K0NSULT | Status |
|---|
| Czy stosowany jest bezpieczny cykl wytwarzania oprogramowania (SDLC)? |
Testy jednostkowe i integracyjne przed publikacją funkcji (patrz liczby na roadmapie dev); formalny,
udokumentowany proces SDLC (threat modeling, code review policy jako wymóg formalny) — w trakcie formalizacji. |
częściowo |
| Czy przeprowadzane są testy penetracyjne produktu przez stronę trzecią? |
Nie posiadamy dziś raportu z niezależnego testu penetracyjnego ipIII jako produktu. Konektory ipIII
przyjmują wyniki testów pentesterów (Burp/ZAP/Nessus) jako dane wejściowe — to inna funkcja niż
pentest samego ipIII. |
brak dowodu / wymaga zlecenia zewn. |
| Czy istnieje program zgłaszania podatności (VDP/bug bounty)? |
Tak, na poziomie strony/programu — patrz /disclosure i
/bug-bounty. Status i zakres tych programów opisany na dedykowanych stronach. |
patrz strona źródłowa |
5. Ciągłość działania i disaster recovery
| Pytanie | Odpowiedź K0NSULT | Status |
|---|
| Czy istnieje udokumentowany plan ciągłości działania (BCP/DRP)? |
Szkielet planu i procedury odtworzeniowe (rollback planu backendu) — istnieją jako runbook wewnętrzny.
Formalny, testowany BCP/DRP z określonym RTO/RPO per usługa — do dopracowania. |
częściowo |
| Jaki jest deklarowany RTO/RPO? |
Brak dziś formalnie zatwierdzonych i przetestowanych wartości RTO/RPO dla ipIII jako usługi. Deklaracja
konkretnych liczb bez testu odtworzeniowego byłaby obietnicą bez dowodu. |
brak dowodu |
| Czy wykonywane są kopie zapasowe bazy danych? |
Tak — kopie zapasowe na poziomie managed PostgreSQL u dostawcy hostingu. Test przywracania z kopii
(restore drill) w harmonogramie regularnym — do wdrożenia. |
częściowo |
6. Reagowanie na incydenty i powiadamianie o naruszeniach
| Pytanie | Odpowiedź K0NSULT | Status |
|---|
| Czy istnieje proces reagowania na incydenty bezpieczeństwa? |
Tak — pełny cykl import findings → incydent → evidence-package (retest) → close, z audit logiem.
To jest rdzeń funkcji ipIII, nie tylko deklaracja procesu. |
LIVE |
| Jaki jest deklarowany czas powiadomienia klienta o naruszeniu danych? |
Konkretny SLA powiadomienia (np. 72h zgodnie z RODO/DORA) do ustalenia i zapisania w umowie/DPA per
kontrahent — to zobowiązanie kontraktowe, nie funkcja techniczna. |
wymaga człowieka (kontrakt/DPA) |
| Czy Legal Trigger Engine automatycznie generuje powiadomienia do organów? |
Legal Trigger Engine wskazuje potencjalne obowiązki (DORA/NIS2/RODO/AI Act) i wspiera decyzję — nie wysyła
automatycznie powiadomień do regulatora. Każdy draft wymaga przeglądu prawnego przed wysyłką. |
LIVE (decision-support) |
7. Subprocesorzy i łańcuch dostaw (fourth-party)
Poniższy rejestr kategorii subprocesorów jest szkieletem wzorcowym — konkretne nazwy, zakresy
przetwarzania i lokalizacje muszą zostać potwierdzone i utrzymywane w aktualnym rejestrze przez zespół prawny/DPO
K0NSULT przed dołączeniem do odpowiedzi wysyłanej realnemu kontrahentowi (bankowi, ubezpieczycielowi). Nie jest to
finalna lista podlegająca DPA.
| Kategoria | Rola w łańcuchu | Rodzaj danych | Status potwierdzenia |
|---|
| Hosting / infrastruktura chmurowa |
Uruchamia aplikację i bazę danych (managed compute + PostgreSQL), region EU. |
Dane operacyjne, findings, evidence-package. |
do potwierdzenia w rejestrze DPO |
| Rejestrator domeny / DNS |
Utrzymanie domeny i wpisów DNS dla usługi. |
Dane techniczne (bez danych klienta). |
do potwierdzenia w rejestrze DPO |
| Komunikacja e-mail / powiadomienia |
Wysyłka powiadomień operacyjnych (np. potwierdzenia, alerty). |
Adresy e-mail kontaktów, treść powiadomień. |
do potwierdzenia w rejestrze DPO |
| Monitoring / logi operacyjne |
Zbieranie logów aplikacyjnych na potrzeby diagnostyki i audytu. |
Logi techniczne, metadane zapytań. |
ROADMAP (docelowa separacja per tenant) |
Dlaczego nie podajemy tu nazw handlowych wprost jako gotowej odpowiedzi audytowej. Rejestr subprocesorów
dołączany do realnej odpowiedzi CAIQ/SIG lub jako aneks DPA jest dokumentem, za który odpowiada zespół prawny/DPO —
musi być aktualny na dzień wysyłki i zweryfikowany pod kątem konkretnej umowy z konkretnym kontrahentem. Publikowanie
tu sztywnej listy groziłoby rozjazdem między stroną a stanem faktycznym umów. Kategorie powyżej pokazują strukturę,
nie finalną treść.
8. Mapowanie regulacyjne (DORA / NIS2 / RODO / AI Act)
| Pytanie | Odpowiedź K0NSULT | Status |
|---|
| Czy K0NSULT jako dostawca ICT wspiera obowiązki DORA banku-klienta (rejestr dostawców, testy odporności)? |
ipIII dostarcza dane wejściowe (evidence-package, mapowanie incydent→obowiązek) wspierające rejestr DORA
klienta. Nie wypełniamy za klienta jego rejestru dostawców krytycznych — to obowiązek instytucji finansowej. |
LIVE (dane wejściowe) |
| Czy K0NSULT gwarantuje zgodność produktu z konkretną regulacją? |
Nie. ipIII to warstwa decision-support — pomaga wykazać należytą staranność i przygotować dowody,
nie zastępuje oceny prawnej ani certyfikacji zgodności. |
zawsze decision-support |
| Czy istnieje mapowanie AI Act dla funkcji opartych o modele AI w ipIII? |
Tak, patrz playbook AI Act i strony klasyfikacji ryzyka AI w portalu. Klasyfikacja finalna wymaga
każdorazowo przeglądu prawnego per zastosowanie. |
patrz strona źródłowa |
9. Bezpieczeństwo infrastruktury i fizyczne
| Pytanie | Odpowiedź K0NSULT | Status |
|---|
| Czy infrastruktura jest wielodostępna (multi-tenant) z izolacją klientów? |
Nie dziś — jedna organizacja, brak tenant scoping i Row-Level Security. To ograniczenie P1, patrz
known-limitations. |
ROADMAP (P1) |
| Jakie tryby wdrożenia są dostępne (SaaS / private tenant / on-prem)? |
Dziś: SaaS współdzielone (EU), pojedyncza organizacja. Private tenant / dedykowany VPC / on-prem —
planowane, nie wdrożone. Nie oferujemy dziś on-prem jako gotowej opcji. |
LIVE (SaaS EU) / ROADMAP (private tenant/VPC/on-prem) |
| Czy stosowana jest ochrona zabezpieczeń fizycznych centrum danych? |
Odpowiedzialność dostawcy hostingu (managed cloud) — nie posiadamy własnej fizycznej serwerowni. Poziom
zabezpieczeń fizycznych dziedziczony po dostawcy infrastruktury, do potwierdzenia w jego dokumentacji. |
dziedziczone od dostawcy hostingu |
10. Bezpieczeństwo kadrowe (HR security)
| Pytanie | Odpowiedź K0NSULT | Status |
|---|
| Czy pracownicy/współpracownicy z dostępem do danych przechodzą szkolenie z bezpieczeństwa? |
Program formalnego, cyklicznego szkolenia security awareness z rejestrem ukończeń — w trakcie budowy. |
ROADMAP |
| Czy podpisywane są umowy o poufności (NDA) z osobami mającymi dostęp do danych klienta? |
Tak, na poziomie umów indywidualnych/kontraktowych. Wzór NDA jako dokument prawny — wymaga przygotowania
i akceptacji przez prawnika przed użyciem w konkretnej relacji. |
wymaga człowieka (prawnik) |
| Czy stosowana jest zasada najmniejszych uprawnień (least privilege) dla dostępu wewnętrznego? |
Tak na poziomie RBAC systemowego (LIVE). Formalna polityka least-privilege dla dostępu administracyjnego
do infrastruktury (poza aplikacją) — do udokumentowania. |
częściowo |
Skrót pokrycia pakietu
10
domen kwestionariusza
wzorowane na CAIQ v4 / SIG-Lite
30
pytań wzorcowych
3 na domenę, odpowiedź + status
częściowo/ROADMAP
większość odpowiedzi
uczciwie: MVP, nie enterprise-grade
6
pozycji „wymaga człowieka"
audytor/prawnik/DPO przed wysyłką
Jak korzystać z tego pakietu
To wzorzec, nie gotowa odpowiedź do podpisu. Zespół procurement/security kontrahenta zwykle wysyła własny
formularz (CAIQ, SIG-Lite, SIG-Core lub ankietę wewnętrzną). Ten pakiet pozwala szybko zmapować odpowiedzi na
standardowe pytania i pokazać, gdzie są mocne strony (evidence-package, JWT/RBAC/audit, Legal Trigger Engine),
a gdzie realne luki (SSO/OIDC, mTLS, multi-tenant, PAdES/TSA — patrz
known-limitations).
Przed wysyłką do konkretnego banku/ubezpieczyciela: (1) dopasowanie do jego formularza, (2) przegląd prawny treści
dot. DPA/subprocesorów, (3) podpis osoby uprawnionej po stronie K0NSULT.
Dlaczego tyle pozycji ma status ROADMAP. ipIII jest dowodliwym MVP warstwy evidence, nie systemem
enterprise-grade z pełnym zestawem certyfikacji. Ten pakiet mówi to wprost, zamiast odpowiadać „tak" na każde
pytanie kwestionariusza — to samo w sobie jest sygnałem dojrzałości dla ocenianego banku/audytora.
Status funkcji tej strony
| Element | Co robi | Status |
|---|
| Pakiet 10 domen × 3 pytania wzorcowe | statyczny wzorzec odpowiedzi + status per pozycja | MVP (statyczny) |
| Generowanie odpowiedzi per format kontrahenta (CAIQ v4 pełny / SIG-Core) | auto-mapowanie na formularz zewnętrzny | ROADMAP |
| Rejestr subprocesorów utrzymywany na żywo (DPO) | lista z datą ostatniej weryfikacji, gotowa do aneksu DPA | ROADMAP |
Eksport pakietu jako podpisany PDF z sha256 | załącznik do odpowiedzi na zapytanie ofertowe | ROADMAP |
Granica etyczna i prawna. Ten pakiet to wsparcie decyzji i przyspieszenie intake'u due diligence —
nie certyfikat, nie oświadczenie prawne ani wynik niezależnego audytu. Pozycje oznaczone
wymaga człowieka (SOC 2/ISO, DPA, NDA, rejestr subprocesorów, klauzule
kontraktowe RTO/RPO/powiadomienia o naruszeniu) muszą zostać przygotowane lub potwierdzone przez zespół prawny/DPO
K0NSULT przed przekazaniem realnemu kontrahentowi. Nie jest to porada prawna.
Powiązane: ocena naszych dostawców → /third-party-risk ·
sygnały zaufania i dowody warstwy → /trust-center ·
kontekst zakupowy i onboarding → /procurement ·
mapowanie na obowiązki (DORA/NIS2) → /regulatory-packs ·
granice dojrzałości ipIII → /known-limitations.