
En kund inom fordonsindustrin ber om ett TISAX-resultat. Innan ni fördelar uppgifter, fastställ vilka bedömningsmål och platser kunden förväntar sig att se. Den begäran avgör vilket försäkringsarbete ni behöver organisera: system, fysiska miljöer, ansvariga team och belägg.
TISAX är en mekanism för bedömning och utbyte som administreras av ENX och som använder VDA Information Security Assessment (ISA). Den ger bedömningsresultat och etiketter (labels) enligt sina regler, inte ett certifikat i ISO:s mening. För en CTO innebär förberedelserna att koppla kundens förväntningar till införda kontroller – inte bara att fylla i ett frågeformulär.
Begäranden kan komma från en fordonstillverkare (OEM) eller en annan leverantör. Fråga efter exakta mål, förväntade etiketter, nödvändig tidpunkt och vilka platser som måste omfattas. Bekräfta vilka juridiska personer som deltar och om ingenjörskontor, produktionsanläggningar, distansarbetsupplägg och stödtjänster påverkar avgränsningen.
Bedömningsmålen avgör vilka krav som är relevanta och vilket djup försäkran ska ha. Informationssäkerhet, prototypskydd och dataskydd är viktiga dimensioner, men de ersätter inte valet av de specifika målen i ENX:s aktuella vägledning.
Bedömningsnivåerna beskriver granskningens djup:
Använd ENX:s information och deltagarvägledning för TISAX för att bekräfta tillämpliga mål, bedömningsupplägg och ISA-version. Registrera omfånget och välj en auktoriserad bedömningsleverantör genom den lämpliga processen. Diskutera förutsättningar och tillgänglighet tidigt; en tidsfrist från kunden är inget garanterat bedömningsdatum.
Leveransen är en beskrivning av omfånget med kundens godkännandekriterier, platser, mål, beroenden, ägare och det överenskomna bedömningsupplägget. Undvik både onödig utvidgning av omfånget och undantag som utelämnar tjänster som stöder skyddad information.
Fyll i den tillämpliga självbedömningen utifrån faktiska arbetssätt. Där ett krav har en målsatt mognadsnivå, förklara hur ert genomförande stöder svaret i stället för att sätta en poäng utifrån att en policy finns.
Använd ett arbetsregister med krav, beskrivning av genomförandet, ägare, plats, referens till belägg, lucka och korrigerande åtgärd. Fördela granskningsansvar såväl som leveransansvar: någon bör ifrågasätta om beläggen bevisar påståendet.
Följ konfidentiella ritningar, källkod, specifikationer och kunddata från mottagande genom samarbete, lagring, leverans och avyttring. Kontrollera klassificering, behörigheter, extern delning, privilegierad åtkomst, skydd av slutenheter, loggning, återställning av säkerhetskopior och incidenthantering.
En godkänd process för utbyte av ritningar bör till exempel ange tillåten kanal, behöriga mottagare, åtkomstens utgång och ansvaret för att ta bort inaktuell åtkomst. En policy som förbjuder offentliga länkar är ett svagt belägg om projektteamen fortfarande använder dem.
Utvärdera även externa leverantörer. Dokumentera vilka tjänster som stöder omfånget, vem som administrerar dem, vilka avtalsmässiga säkerhetsförväntningar som gäller och vilka belägg ni kan få fram. Att outsourca en tjänst tar inte bort ert behov av att förstå dess kontroller.
Centrala policyer kan stödja flera platser, men varje plats behöver belägg för genomförandet. Koppla åtkomstregler till passerbehörigheter, besöksregister, eskortrutiner och borttagning av åtkomst när personal slutar.
Där prototypskydd är tillämpligt, granska hanteringsmiljön: begränsade zoner, insyn utifrån, fotograferingsbegränsningar, transport, tillfällig förvaring och godkänd kassering. Identifiera ansvarig personal och dokumentera överlämningar där det är lämpligt. Digitala åtkomstloggar ensamma visar inte kontroll över en fysisk komponent.
HR bör stödja introduktion, sekretessåtaganden, rollspecifik utbildning och samordning vid avgångar. Inköp, fastighet och utveckling behöver uttryckliga uppgifter i stället för en allmän instruktion att ”stödja IT”.
Där mål för dataskydd är tillämpliga, bedöm den relevanta behandlingen och det avtalsmässiga ansvaret. Ett TISAX-resultat fastställer inte efterlevnad av GDPR; de rättsliga skyldigheterna beror fortfarande på er roll och era behandlingsaktiviteter.
Beläggen bör fastställa vad som hände, var, när och under vems ansvar. Som en praktisk rekommendation, använd följande distinktioner när ni granskar beredskapen:
| Påstående | Användbara belägg | Vanlig svaghet |
|---|---|---|
| Åtkomst godkänns och granskas | Godkännanden, exporter av behörigheter, genomförda granskningar | Policy utan dokumentation av granskningar |
| Besökare kontrolleras | Lokal rutin och stickprov ur besöksregistret | Huvudkontorets register visas upp för varje plats |
| Återställning fungerar | Dokumentation av återställningstest, resultat, uppföljande åtgärder | Enbart konfigurationen för säkerhetskopiering |
| Hanteringen av prototyper är kontrollerad | Zonregler, behörigheter, överlämningsdokumentation | Tekniska loggar utan belägg för fysisk hantering |
Dokumentera datum för beläggen, källsystem, platser och granskare. Bevara historiska poster där det behövs för att förklara drift och förändringar. En gammal skärmdump är inte automatiskt värdelös, men den kan inte fastställa dagens konfiguration utan stödjande sammanhang.
Håll konfidentiella bedömningsbelägg åtkomstkontrollerade. Undvik att samla in onödiga kundkonstruktioner eller personuppgifter när en maskerad post kan visa kontrollen.
Börja med återkommande uppgifter som har tydliga indata och utdata: exporter av behörigheter, uppdateringar av tillgångsförteckningen, utbildningsregister, påminnelser om granskning och kontroller av hur aktuella beläggen är. Dokumentera den manuella processen först så att automatiseringen inte bara återskapar ett oklart arbetsflöde snabbare.
För varje automatiserad insamling, ange källa, omfång, frekvens, felhantering och granskningsansvarig. Testa om exporterna omfattar varje relevant plats och kontotyp. Ett lyckat insamlingsjobb kan ändå utelämna konsulters identiteter eller ett separat förvaltat fabriksnätverk.
När ni utvärderar verktyg, testa spårbarhet för belägg, platsspecifikt ägarskap, versionshantering, granskningsbeslut och hur användbara exporterna är. Fråga separat hur belägg för prototyper representeras; en mappning för informationssäkerhet fastställer inte fysiskt prototypskydd. Anta inte att ett verktygs utdataformat godtas utan att ni har diskuterat förväntningarna på belägg med bedömaren.
Anta, som illustration, att en leverantör driver ett ingenjörskontor och en prototypverkstad. Kunden begär mål som omfattar konfidentiell utvecklingsinformation och prototypskydd på båda platserna.
Utvecklingsteamet identifierar konstruktionsarkivet och utbytestjänsten. Fastighetsfunktionen kartlägger åtkomst till verkstaden och hanteringen av besökare. En granskning visar att behörigheterna till arkivet granskas centralt, men att åtkomsten till verkstaden fortfarande omfattar två medarbetare som har bytt tjänst.
Den korrigerande åtgärden tar bort dessa behörigheter, utser en lokal granskare och dokumenterar datum för nästa granskning. Beläggen omfattar åtkomstposter före och efter, beslutet om godkännande och verkstadens uppdaterade rutin. Självbedömningens svar hänvisar till dessa poster och identifierar den berörda platsen. Det gör iakttagelsen, åtgärden och genomförandet spårbara utan att den centrala policyn behandlas som bevis för båda platserna.
Öva inför bedömningen på att ta fram belägg tillsammans med kontrollägarna och kom överens om vem som hanterar iakttagelser. Följ korrigerande åtgärder genom genomförande och förnyad bedömning enligt leverantörens process. Bekräfta hur resultaten ska delas med den begärande kunden inom ENX:s regler. TISAX-etiketter har i regel en giltighetstid på tre år; upprätthåll kontrollerna och beakta förändringar i omfånget mellan bedömningarna.
Secani erbjuder en sammankopplad arbetsyta för krav, ägare, uppgifter och belägg. Teamen kan koppla platsspecifika poster till kontroller, följa luckor och bevara mänskliga granskningsbeslut. Strukturerade revisionsförberedelser hjälper till att återanvända gemensamt arbete utan att förlora det lokala sammanhanget.
Börja med de mål som kunden har begärt, välj sedan ett kritiskt informationsflöde och följ de poster som visar dess skydd på varje plats som ingår.
Secani kopplar samman omfattningar, bevis, uppgifter och AI-agenter i en gemensam arbetsyta.
Förstå C5:s omfattning, rapporttyper, kundens ansvar och de underlag som molnleverantörer behöver hålla sammankopplade.
Ställ praktiska frågor om kvalifikationer, branscherfarenhet, förväntningar på belägg, tidsplanering, oberoende och den totala kostnaden för bedömningen.
Läs ISO-certifikat och SOC 2-rapporter i sitt sammanhang: omfång, period, undantag, kundens ansvar och underlag om åtgärder.