Dla dostawców OEM/Tier1/Tier2/Tier3 pytanie o TISAX pada regularnie w kwestionariuszach zakupowych. Ta strona to szkielet decision-support: jak dane i procesy klasy ipIII odnoszą się do poziomów potrzeby ochrony i obszarów katalogu VDA ISA, które kontrole ipIII mają dziś dowód, a które są luką. To mapowanie, nie ocena TISAX i nie porada prawna.
TISAX to mechanizm wymiany wyników oceny bezpieczeństwa informacji między firmami łańcucha dostaw motoryzacyjnego — bez ujawniania szczegółów wszystkim naraz, przez portal ENX. Poniżej: dla kogo jest TISAX, jak klasyfikujemy ipIII wobec poziomów potrzeby ochrony, mapowanie 16 obszarów kontrolnych na moduły ipIII oraz uczciwy podział na to, co dziś działa, a co jest planem.
Standard wymiany wyników oceny bezpieczeństwa informacji dla branży motoryzacyjnej, oparty na wspólnym katalogu pytań (VDA ISA) i zarządzany przez ENX Association. Wynik oceny jest udostępniany przez portal ENX wybranym partnerom (OEM, Tier1, Tier2/3), zamiast powtarzania osobnych kwestionariuszy dla każdego klienta.
Katalog kontrolny (VDA Information Security Assessment) obejmujący obszary: Information Security (organizacja, IAM, IT security, incydenty, ciągłość), Prototype Protection (ochrona prototypów) i Data Protection (dane osobowe, powiązane z RODO).
Dostawcy OEM/Tier1/Tier2/Tier3 przetwarzający dane klienta motoryzacyjnego wysokiej wrażliwości: R&D, ceny, architektury, dane produkcyjne, prototypy. Jeśli ipIII trafia do łańcucha dostaw automotive, kontrahent zwykle zapyta o TISAX wprost.
AL1 (samoocena) do AL3 (ocena z dowodami, wywiadami i weryfikacją na miejscu lub zdalnie, przez dostawcę audytu). Wyższy poziom potrzeby ochrony danych zwykle wymaga AL3.
TISAX nie mapuje 1:1 nazw klas typu „ipIII" — ocenia poziom potrzeby ochrony informacji i dobiera moduły. Poniższa tabela to założenie robocze K0NSULT, nie decyzja wiążąca: ostateczną klasyfikację ustala właściciel danych (data owner) po stronie klienta/kontrahenta.
| Charakterystyka danych ipIII | Poziom potrzeby ochrony TISAX | Uwaga |
|---|---|---|
| ipIII bez prototypów i bez danych osobowych | High albo Very High protection needs | Zależnie od realnej szkody biznesowej przy ujawnieniu. |
| ipIII = dane krytyczne OEM/R&D/strategiczne | Very High protection needs | Domyślne, ostrożne założenie dla klasy ipIII. |
| ipIII zawiera dane prototypowe | + moduł Prototype Protection | Dodatkowy zestaw pytań/kontroli. |
| ipIII zawiera dane osobowe | + moduł Data Protection | Powiązanie z obowiązkami RODO — patrz /rodo-pack. |
| Kontrahent wymaga przeglądu przez stronę trzecią | zwykle Assessment Level 3 (AL3) | Wymaga dowodów, wywiadów i weryfikacji przez akredytowanego dostawcę audytu. |
RAMKA/ZAŁOŻENIE Powyższe jest interpretacją roboczą na potrzeby planowania, nie wynikiem oceny. Jeśli właściciel danych wykaże mniejszy wpływ, poziom można obniżyć do „High".
16 obszarów kontrolnych. Kolumna „Stan wewnętrzny ipIII" opisuje dowód, jaki mamy dziś (kod/test/endpoint) — zgodnie z rejestrem znanych ograniczeń. Data weryfikacji: 2026-07-09.
| Wymóg ipIII | Obszar VDA ISA | Stan wewnętrzny ipIII | Status |
|---|---|---|---|
| Klasyfikacja danych ipIII | Information Security Policies and Organisation | Klasyfikacja opisana koncepcyjnie w dokumentacji; brak spisanej, zatwierdzonej polityki klasyfikacji i macierzy klas. | GAP |
| Właściciel danych | ISMS governance | Brak formalnego rejestru aktywów z przypisanym data ownerem i RACI. | GAP |
| Need-to-know | Identity & Access Management | Role/uprawnienia egzekwowane technicznie w JWT+RBAC na API (LIVE); brak formalnej polityki need-to-know i cyklicznego przeglądu dostępów. | częściowo |
| MFA dla dostępu | IAM / IT Security | Uwierzytelnianie dziś to JWT lokalny; brak MFA i federacji z zewnętrznym IdP (OIDC/JWKS). | ROADMAP (P0) |
| Szyfrowanie w tranzycie | IT Security | TLS dziedziczony z warstwy hostingu; brak mTLS (wzajemnego uwierzytelniania TLS) na styku integracji. | częściowo |
| Szyfrowanie w spoczynku | IT Security | Brak potwierdzonej, udokumentowanej polityki KMS/HSM i szyfrowania dysków/backupu specyficznej dla ipIII. | GAP |
| Segmentacja środowisk ipIII | IT Security / Network Security | Dziś jedna organizacja, brak izolacji wielodostępnej (multi-tenant) i brak dokumentacji segmentacji sieci. | GAP |
| Logowanie dostępu | IT Security / Monitoring | Audit-log działa na żywej PostgreSQL, powiązany z JWT/RBAC (LIVE); brak sformalizowanej polityki retencji i harmonogramu przeglądu logów. | częściowo |
| DLP / kontrola eksportu | IT Security / Compliance | Brak reguł DLP/CASB i blokad eksportu danych ipIII. | GAP |
| Zarządzanie podatnościami | IT Security | Wzbogacanie CVE→CVSS/EPSS/KEV działa offline z seedu (LIVE Fala 1); brak online lookupu w czasie rzeczywistym i formalnych SLA łatania. | częściowo |
| Secure development | IT Security | Brak udokumentowanego SAST/DAST/SBOM jako formalnego procesu przy dostawie do klienta automotive. | GAP |
| Dostęp dostawców | Supplier Relationships | Brak formalnego rejestru dostawców, NDA szablonowych pod TISAX i oceny ryzyka podwykonawców. | GAP |
| Incydenty ipIII | Incident Management | Ścieżka incydent → evidence-package → retest → close działa na produkcji z audit-logiem (LIVE). | LIVE |
| Backup i odtwarzanie | BCM / IT Security | Brak udokumentowanego, przetestowanego planu ciągłości/DR (RPO/RTO) specyficznego dla platformy ipIII. | GAP |
| Fizyczna ochrona nośników | Physical Security | Dziedziczona od dostawcy chmury (odpowiedzialność współdzielona); brak własnej ewidencji/niszczenia nośników. | dziedziczone od dostawcy |
| Szkolenia użytkowników | HR Security | Brak sformalizowanego programu szkoleń i testów phishingowych. | GAP |
| Przegląd wewnętrzny i CAPA | Compliance | Wewnętrzny rejestr znanych ograniczeń istnieje jawnie (/known-limitations); brak formalnego cyklu przeglądu przez osobę niezależną od operacji. | częściowo |
RAMKA/NORMA Powyższe mapowanie opisuje publicznie znaną strukturę katalogu VDA ISA — nie jest to lista pytań ani wynik żadnej oceny.
Poniższy profil to propozycja techniczna do przeglądu przez data ownera, nie deklaracja gotowego wyniku. Docelowy Assessment Level i moduły dodatkowe zależą od realnej zawartości danych klienta.
ipIII -> TISAX (rekomendacja robocza):
module: Information Security
protection_need: very_high # domyślnie ostrożnie; do weryfikacji przez data ownera
assessment_level: AL3 # wymaga akredytowanego dostawcy audytu (ENX)
add_on:
Prototype Protection: jesli dane prototypowe
Data Protection: jesli dane osobowe (patrz /rodo-pack)
User -> SSO/MFA -> PAM/JIT access -> segmented ipIII zone -> encrypted storage/KMS -> logging/SIEM -> DLP/CASB -> backup immutable
Rekomendowane kontrole docelowe (cel architektoniczny), z uczciwym stanem dzisiejszym:
| Kontrola docelowa | Stan dziś |
|---|---|
| Zero standing privilege dla adminów (PAM/JIT) | GAP — brak PAM/JIT; dostęp administracyjny bez wygasających uprawnień na żądanie. |
| MFA + conditional access dla każdego dostępu ipIII | ROADMAP (P0) — patrz sekcja 3, wiersz MFA. |
| Szyfrowanie AES-256 / TLS 1.2+ | częściowo potwierdzone — TLS z warstwy hostingu; brak formalnej dokumentacji szyfrowania w spoczynku. |
| Centralne logi z retencją min. 6–12 miesięcy | częściowo — audit-log LIVE technicznie; polityka retencji niesformalizowana. |
| Cykliczny przegląd (ponowna weryfikacja) dostępów co 3–6 miesięcy | GAP — brak sformalizowanego harmonogramu przeglądu uprawnień. |
| Dostęp dostawców przez kontrolowany bastion/VPN/ZTNA | GAP — brak dedykowanej bramy dostępowej dla stron trzecich. |
| Kontrola lokalnego kopiowania (DLP), wyjątki tylko za zgodą data ownera | GAP — brak mechanizmu DLP. |
| Element | Status | Uwaga |
|---|---|---|
| Mapa klasyfikacji ipIII → poziom potrzeby ochrony | MVP | Rekomendacja robocza do przeglądu przez data ownera. |
| Mapowanie 16 obszarów VDA ISA → moduł ipIII | MVP | Szkielet referencyjny; część wierszy z dowodem LIVE, część GAP. |
| IAM techniczny (JWT+RBAC) i audit-log | LIVE | Działa na żywej PostgreSQL; brak formalnej polityki need-to-know. |
| Incydent → evidence-package → retest → close | LIVE | Ten sam rdzeń evidence co w innych mapowaniach compliance. |
| MFA / OIDC / federacja tożsamości | ROADMAP (P0) | Zależność wspólna z ISO/SOC2, patrz /known-limitations. |
| Polityki ISMS, rejestr dostawców, DLP, DR | GAP | Praca dokumentacyjna/organizacyjna po stronie właściciela procesu, nie automatyzacja roju. |
| Ocena TISAX / label TISAX | wymaga dostawcy audytu | Wyłącznie akredytowany dostawca audytu zarejestrowany na portalu ENX. |
Powiązane: katalog pakietów regulacyjnych → /regulatory-packs · mapa gotowości ISO/SOC2 → /iso-soc2-readiness · mapowanie dowód → kontrola ram → /control-mapping · pełny rejestr znanych ograniczeń → /known-limitations · pakiet RODO → /rodo-pack.