k0nsult.cloud / ai-truth / ipIII / procurement / third-party-risk

Third-Party Risk Evidence Pack (F11) — dowód ryzyka dostawcy

Jedna tabela decision-support zamiast rozproszonych ankiet i PDF-ów: dla każdego dostawcy pokazujemy, czy ma otwarte podatności, czy zgłosił incydent, czy przedstawił dowód naprawy, jaki jest jego SLA remediacji i jaki residual risk pozostaje po mitigacji. To wsparcie decyzji zakupowej — nie ocena zgodności ani zewnętrzna weryfikacja dostawcy. Dane w tabeli poniżej są syntetyczne (przykładowe).

Orchestrator Trust Center Procurement Regulatory Packs Znane ograniczenia Third-Party Risk ← ipIII hub

Po co ta strona. Zespół zakupowy i właściciel ryzyka dostawcy potrzebują jednej odpowiedzi: czy podpisać/przedłużyć umowę z tym dostawcą i pod jakimi warunkami. Ten pakiet zbiera pięć weryfikowalnych sygnałów — podatności, zgłoszenie incydentu, dowód naprawy, SLA remediacji i residual risk — w formie, którą można załączyć do decyzji zakupowej. Zgodnie z doktryną claim ≤ proof: sygnał ma wartość tylko wtedy, gdy jest podparty artefaktem (retest, ticket, evidence-package z sha256). Brak artefaktu = status brak dowodu, nie domysł.

5 sygnałów. Jedna decyzja. Zero domysłów.

Third-Party Risk Evidence Pack to warstwa decyzyjna nad danymi ipIII: import findings z konektorów, powiązanie z incydentem, evidence-package z retestem i chain-of-custody. Zamiast pytać dostawcę „czy jesteście bezpieczni" (ankieta samodeklaracji), pytamy o artefakt: link do retestu, numer zgłoszenia, hash pakietu. Strona jest dziś MVP — logika oceny i tabela działają na danych przykładowych; zaciąganie na żywo z rejestru dostawców jest ROADMAP.

PRZEPŁYW: finding dostawcy→incydent + zgłoszenie→evidence-package (retest)→SLA vs faktyczny czas→residual risk → decyzja

Pięć sygnałów pakietu

1. Podatności

Czy dostawca ma otwarte findings? Liczba wg krytyczności (CVSS/EPSS/KEV, offline hint). Źródło: import z konektorów skanerów.

2. Zgłoszenie incydentu

Czy dostawca zgłosił incydent (numer, data)? Brak zgłoszenia przy znanym zdarzeniu = sygnał ryzyka.

3. Dowód naprawy

Czy istnieje evidence-package z retestem potwierdzającym domknięcie? Hash sha256 + chain-of-custody.

4. SLA remediacji

Deklarowany czas naprawy vs faktyczny czas domknięcia. Przekroczenie = flaga do renegocjacji.

5. Residual risk

Ryzyko pozostałe po mitigacji: co świadomie zaakceptowano, na jaki czas, kto jest właścicielem.

Tabela ryzyka dostawców (dane syntetyczne)

Wpisy poniżej są przykładowe — służą pokazaniu formatu decyzji, nie oceniają realnych podmiotów. Kolumna Decyzja = rekomendacja wsparcia decyzji: OK kontynuuj · warunkowo z remediacją/klauzulą · wstrzymaj do domknięcia. Data snapshotu: 2026-07-05.

Dostawca (przykład)	Podatności	Incydent zgłoszony	Dowód naprawy	SLA remediacji	Residual risk	Decyzja
Vendor Alfa SaaS / hosting	0 krytycznych 2 średnie (otwarte)	TAK INC-2026-041, w terminie	TAK retest + pkg `sha256`	7 dni dekl. / 5 dni fakt. dotrzymany	niski 2 średnie zaakceptowane do Q3	OK
Vendor Beta integrator API	1 wysokie +3 średnie (otwarte)	TAK INC-2026-058, po terminie 3 dni	częściowo retest tylko dla 1 z 4	14 dni dekl. / 21 dni fakt. przekroczony	średni wysokie niedomknięte	warunkowo
Vendor Gamma data processor	2 krytyczne otwarte >30 dni	NIE brak zgłoszenia mimo findingu	brak dowodu brak evidence-package	30 dni dekl. / brak domknięcia przekroczony	wysoki krytyczne bez mitigacji	wstrzymaj
Vendor Delta infra / on-prem	0 otwartych historyczne domknięte	TAK INC-2026-012, w terminie	TAK retest + chain-of-custody	7 dni dekl. / 4 dni fakt. dotrzymany	minimalny	OK
Vendor Epsilon nowy dostawca	brak danych skan nieprzeprowadzony	n/d brak historii	brak dowodu	nieustalony	nieznany wymaga baseline skanu	warunkowo

Jak czytać decyzję

OK — kontynuuj

0 krytycznych, dowód naprawy, SLA dotrzymany

Warunkowo

wymaga remediacji, klauzuli lub baseline skanu

Wstrzymaj

krytyczne otwarte, brak zgłoszenia, brak dowodu

5/5

Sygnały jawne

każda kolumna = weryfikowalny artefakt lub jego brak

Reguła oceny (deterministyczna)

Decyzja wynika z sygnałów, nie z opinii. Uproszczona logika MVP: wstrzymaj gdy jest choć jedna otwarta podatność krytyczna bez mitigacji lub brak zgłoszenia incydentu przy znanym findingu lub brak dowodu naprawy przy przekroczonym SLA. warunkowo gdy występują otwarte wysokie/średnie, częściowy dowód naprawy, przekroczony SLA lub brak baseline (nowy dostawca). OK gdy 0 krytycznych, incydenty zgłoszone w terminie, pełny dowód naprawy i dotrzymany SLA. Progi są konfigurowalne per polityka zakupowa — to ROADMAP.

„Brak dowodu" to nie to samo co „bezpieczny". Jeśli dostawca nie przedstawił retestu ani evidence-package, kolumna dostaje status brak dowodu — nie zakładamy naprawy na słowo. Samodeklaracja z ankiety nie podnosi statusu bez artefaktu. To ta sama doktryna claim ≤ proof, co w reszcie ipIII.

Status funkcji

Element	Co robi	Status
Tabela 5 sygnałów	format decyzji + reguła oceny na danych przykładowych	MVP
Powiązanie finding → incydent → evidence-package	istnieje w warstwie orchestratora ipIII	LIVE (rdzeń)
Zaciąganie na żywo z rejestru dostawców	auto-import statusów per vendor	ROADMAP
Konfigurowalne progi per polityka zakupowa	reguła OK/warunkowo/wstrzymaj jako parametr	ROADMAP
Eksport pakietu do decyzji zakupowej (PDF)	załącznik z `sha256` do dokumentacji vendor-risk	ROADMAP

Granica etyczna i prawna. Third-Party Risk Evidence Pack to wsparcie decyzji zakupowej, nie ocena zgodności, nie akredytacja dostawcy i nie porada prawna. Ocena opiera się na artefaktach dostarczonych przez samego dostawcę lub z autoryzowanych skanów — nie prowadzimy nieautoryzowanej weryfikacji podmiotów trzecich. Kwalifikacja obowiązków umownych i regulacyjnych wymaga przeglądu prawnego. Działania o charakterze testu bezpieczeństwa wyłącznie w granicach pisemnych Rules of Engagement.

Powiązane: sygnały zaufania i dowody warstwy → /trust-center · kontekst zakupowy i onboarding dostawcy → /procurement · mapowanie na obowiązki (DORA/NIS2) → /regulatory-packs · granice dojrzałości → /known-limitations.