Bortom frågeformuläret: CISO:ns definitiva guide till revision av högriskleverantörer för NIS2 och DORA

Rapporten landade på CISO:n Maria Valens skrivbord med en dämpad duns som snarare kändes som en larmsignal. Det var förhandsbedömningen inför deras kommande granskning av DORA-efterlevnad, och en rad var markerad i skarpt rött: ”Otillräcklig säkerhetsverifiering för kritisk tredjepartsleverantör, CloudSphere.”

CloudSphere var inte vilken leverantör som helst. De var ryggraden i företagets nya digitala bankplattform och hanterade miljontals transaktioner varje dag. Maria hade deras ISO/IEC 27001:2022-certifikat arkiverat. Hon hade deras ifyllda säkerhetsfrågeformulär, ett omfattande dokument med 200 frågor. Men förhandsgranskarna signalerade att checkbox-baserad efterlevnad inte längre räckte för en högriskleverantör som dessutom var kritisk. Spelplanen hade förändrats.

När både NIS2-direktivet och Digital Operational Resilience Act (DORA) nu är fullt tillämpliga ser tillsynsmyndigheterna bortom pappersspåret. De kräver konkret bevismaterial för leverantörsgranskning, kontinuerlig övervakning och robust styrning av hela leveranskedjan. Marias utmaning är densamma som CISO:er överallt ställs inför: hur går man bortom frågeformuläret för att verkligen revidera och säkra sina mest kritiska leverantörer? Det kräver ett strategiskt skifte från passiv validering till aktiv, evidensbaserad säkerhetsverifiering.

Bristen i det statiska frågeformuläret i en dynamisk värld

Under många år har säkerhetsfrågeformuläret varit hörnstenen i tredjepartsriskhantering. Men det är en statisk ögonblicksbild i ett dynamiskt hotlandskap. En leverantörs riskprofil är inte fast; den förändras med varje nytt hot, varje systemändring och varje underleverantör som leverantören anlitar. Att enbart förlita sig på självintyg för en kritisk leverantör som CloudSphere är som att navigera genom en storm med fjolårets väderkarta.

NIS2-direktivet kräver uttryckligen en riskbaserad ansats, där säkerhetsåtgärder ska stå i proportion till de faktiska riskerna. Det innebär att ett generiskt frågeformulär i grunden inte är förenligt med moderna regulatoriska förväntningar. Tiden då ett certifikat eller en ifylld checklista kunde ersätta bevismaterial är förbi. Den verkliga risken finns bortom pappersspåret.

Här blir en strukturerad, livscykelbaserad ansats nödvändig. Det handlar inte om att överge frågeformulären, utan om att komplettera dem med djupare och mer inträngande verifiering för de leverantörer som verkligen har betydelse. Detta är den grundläggande principen i Clarysecs policy för leverantörs- och tredjepartssäkerhet. Ett av de grundläggande målen är att:

”Kräva formell leverantörsgranskning och dokumenterade riskbedömningar innan nya leverantörer anlitas eller högriskavtal om tjänster förnyas.”

• Från avsnittet ”Mål”, policyklausul 3.3

Denna klausul flyttar fokus från en enkel kontroll till en formell prövning, ett avgörande första steg för att bygga ett försvarbart program som håller för regulatorisk granskning.

Leverantörsrisk enligt NIS2 och DORA: de nya förväntningarna

Både NIS2 och DORA kräver att organisationer systematiskt identifierar, bedömer och kontinuerligt övervakar risker i hela sitt leverantörslandskap. De gör leverantörshantering till mer än en upphandlingsfråga: den blir en central pelare i operativ resiliens och informationssäkerhet.

Det nya regulatoriska klimatet kräver tydliga ramverk som är nära mappade mot etablerade standarder som ISO/IEC 27001:2022. Här är en övergripande sammanfattning av vad dessa ramverk förväntar sig av ert program för leverantörsstyrning:

Ett robust program för leverantörsrevision behöver inte uppfinnas från grunden. Ramverket ISO/IEC 27001:2022, särskilt kontrollerna i Annex A, ger en stark struktur. På Clarysec vägleder vi kunder i att bygga sitt program kring tre sammanlänkade kontroller som tillsammans bildar en fullständig livscykel för leverantörsstyrning.

Bygg ett försvarbart revisionsramverk: livscykeln i ISO 27001:2022

För att bygga ett program som uppfyller tillsynsmyndigheternas krav behöver ni en strukturerad ansats grundad i en globalt erkänd standard. Leverantörssäkerhetskontrollerna i ISO/IEC 27001:2022 ger en livscykel för hantering av tredjepartsrisker från start till avslut. Låt oss se hur Maria kan använda denna livscykel för att bygga en försvarbar revisionsplan för CloudSphere.

Steg 1: Grunden – informationssäkerhet i leverantörsrelationer (5.19)

Kontroll 5.19 är den strategiska utgångspunkten. Den kräver att ni etablerar formella processer för att identifiera, bedöma och hantera informationssäkerhetsrisker kopplade till hela ert leverantörsekosystem. Det är här ni definierar vad ”hög risk” betyder för er organisation och fastställer spelreglerna.

Clarysecs Zenith Controls: The Cross-Compliance Guide ger en detaljerad genomgång av 5.19 och visar dess roll som nav för leverantörsstyrning. Kontrollen är nära kopplad till relaterade kontroller, såsom 5.21 (informationssäkerhet i IKT-leveranskedjan), som omfattar hårdvaru- och programvarukomponenter, och 5.14 (informationsöverföring), som styr säkert datautbyte. Det går inte att hantera en leverantörsrelation effektivt utan att också kontrollera den teknik leverantören tillhandahåller och de data ni delar.

För Maria innebär detta att revisionen av CloudSphere måste gå bortom deras övergripande säkerhetsläge som företag och granska säkerheten i den faktiska plattform de levererar. Guiden Zenith Controls lyfter fram att ett starkt genomförande av 5.19 direkt stödjer efterlevnad av centrala regelverk:

• NIS2 (Article 21(2)(d)): Ålägger organisationer att hantera risker i leveranskedjan som en central del av säkerhetsramverket.
• DORA (Articles 28–30): Kräver ett robust ramverk för IKT-tredjepartsriskhantering, inklusive klassificering av kritikalitet och leverantörsgranskning före avtal.
• GDPR (Article 28): Kräver att personuppgiftsansvariga endast anlitar personuppgiftsbiträden som ger tillräckliga garantier för dataskydd.

Denna kontroll kräver riskklassificering av leverantörer, löpande övervakning och snabb indragning av behörigheter. Syftet är att säkerställa att säkerhet integreras i leverantörens livscykel, inte läggs till i efterhand.

Steg 2: Tillämpningen – hantering av informationssäkerhet i leverantörsavtal (5.20)

Ett säkerhetskrav som inte finns i avtalet är bara en rekommendation. Kontroll 5.20 är där styrning blir avtalsmässigt bindande. För en högriskleverantör är avtalet ert mest kraftfulla revisionsverktyg.

Som Zenith Controls betonar måste dessa avtal vara uttryckliga. Otydliga löften om ”branschledande säkerhet” saknar värde. För en leverantör som CloudSphere måste Maria verifiera att avtalet innehåller specifika och mätbara klausuler som ger hennes organisation faktisk tillsyn:

• Revisionsrätt: En klausul som uttryckligen ger hennes organisation rätt att genomföra tekniska bedömningar, granska bevismaterial eller anlita en tredje part för att genomföra revision för organisationens räkning.
• Tidsfrister för incidentanmälan: Specifika och skarpa tidsfrister, exempelvis inom 24 timmar efter upptäckt, för att underrätta hennes organisation om en säkerhetsincident, inte bara en vag formulering om ”utan onödigt dröjsmål”.
• Hantering av underleverantörer och fjärdeparter: En klausul som kräver att leverantören tillämpar samma säkerhetsstandarder på sina egna kritiska underleverantörer och underrättar hennes organisation om ändringar. Detta är avgörande för att hantera nedströmsrisk.
• Säker exitstrategi: Tydliga skyldigheter för återlämnande eller certifierad förstöring av data när avtalet upphör.

DORA är särskilt detaljerad här. Article 30 anger obligatoriska avtalsbestämmelser, inklusive obehindrad åtkomst för revisorer och tillsynsmyndigheter, specifika uppgifter om driftplatser och heltäckande exitstrategier. Revisorer kommer att göra urval av avtal med högriskleverantörer och kontrollera dessa klausuler direkt.

Steg 3: Den kontinuerliga loopen – övervakning, granskning och ändringshantering av leverantörstjänster (5.22)

Den sista delen av livscykeln är kontroll 5.22, som omvandlar tillsyn över leverantörer från en punktinsats till en kontinuerlig process. En revision ska inte vara en överraskningshändelse, utan en valideringspunkt i en löpande och transparent relation.

Det är här många organisationer brister. De får avtalet undertecknat och arkiverar det. Men för högriskleverantörer börjar det verkliga arbetet efter introduktionen. Guiden Zenith Controls kopplar 5.22 till kritiska operativa processer som 8.8 (hantering av tekniska sårbarheter) och 5.29 (informationssäkerhet vid störning). Det innebär att effektiv övervakning omfattar betydligt mer än ett årligt granskningsmöte. Den inkluderar:

• Granskning av tredjepartsunderlag: Aktiv inhämtning och analys av leverantörens SOC 2 Type II-rapporter, resultat från ISO 27001-uppföljningsrevision eller sammanfattningar av penetrationstester. Nyckeln är att granska avvikelserna och följa upp deras åtgärdande.
• Övervakning av incidenter: Uppföljning av offentligt rapporterade intrång eller säkerhetsincidenter som berör leverantören och formell bedömning av den potentiella påverkan på organisationen.
• Hantering av ändringar: Införande av en process där varje väsentlig ändring i leverantörens tjänst, såsom en ny datacenterplats eller en ny kritisk underleverantör, automatiskt utlöser en förnyad riskbedömning.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap ger praktisk vägledning om detta, särskilt i steg 24, som omfattar underleverantörsrisk. Den rekommenderar:

”För varje kritisk leverantör, identifiera om leverantören använder underleverantörer eller underbiträden som kan få åtkomst till era data eller system. Dokumentera hur era informationssäkerhetskrav förs vidare till dessa parter … Där det är möjligt, begär en lista över centrala underleverantörer och säkerställ att er revisionsrätt eller rätt att inhämta säkerhetsverifiering även gäller dem.”

Detta är en avgörande punkt för Maria. Använder CloudSphere en tredjepartsleverantör för dataanalys? Driftas deras infrastruktur i ett stort publikt moln? Dessa nedströmsberoenden utgör en betydande, ofta osynlig, risk som revisionen måste synliggöra.

Från teori till handling: Marias praktiska revisionsplan för CloudSphere

Med denna ISO 27001:2022-livscykel som grund tar Marias team fram en ny revisionsplan för CloudSphere som går långt bortom frågeformuläret och visar den mogna, riskbaserade styrning som tillsynsmyndigheter kräver.

1. Avtalsgranskning: De börjar med att mappa det befintliga CloudSphere-avtalet mot DORA Article 30 och bästa praxis för kontroll 5.20. De tar fram en rapport över efterlevnadsluckor som underlag för nästa förnyelsecykel och för att prioritera områden i den aktuella revisionen.

2. Riktad begäran om bevismaterial: I stället för ett generiskt frågeformulär skickar de en formell begäran om specifikt bevismaterial, inklusive:

   • Den senaste SOC 2 Type II-rapporten och en sammanfattning av hur samtliga noterade avvikelser har åtgärdats.
   • Ledningssammanfattningen av det senaste externa penetrationstestet.
   • En fullständig lista över alla underleverantörer, inklusive fjärdeparter, som kommer att behandla eller få åtkomst till deras data.
   • Bevis för att säkerhetskraven har förts vidare avtalsmässigt till dessa underleverantörer.
   • Loggar eller rapporter som visar att kritiska sårbarheter, exempelvis Log4j och MOVEit, har patchats i tid under de senaste sex månaderna.

3. Teknisk validering: De åberopar sin klausul om revisionsrätt för att boka en teknisk fördjupningssession med CloudSpheres säkerhetsteam. Agendan fokuserar på deras åtgärdsplaner för incidenthantering, verktyg för hantering av säkerhetsläget i molnmiljöer (CSPM) och kontroller för att förhindra dataläckage.

4. Formell undantagshantering: Om CloudSphere motsätter sig att tillhandahålla visst bevismaterial är Maria förberedd. Organisationens styrningsprocess, definierad i policy för leverantörs- och tredjepartssäkerhet, är tydlig:

”Högriskundantag, exempelvis leverantörer som hanterar reglerade data eller stödjer kritiska system, ska godkännas av CISO, juridik och upphandlingsledning samt registreras i ISMS-undantagsregistret.”

• Från avsnittet ”Riskbehandling och undantag”, policyklausul 7.3

Detta säkerställer att en vägran att lämna bevismaterial inte bara ignoreras, utan blir föremål för formell riskacceptans på organisationens högsta nivåer, en process som revisorer respekterar.

Revisorns perspektiv: vad olika revisorer kommer att kräva

För att bygga ett verkligt resilient program måste ni tänka som en revisor. Olika revisionsramverk har olika perspektiv, och förmågan att förutse deras frågor är avgörande för framgång. Här är en samlad bild av vad olika revisorer skulle kräva vid granskning av ert program för leverantörsstyrning:

Detta flerdimensionella perspektiv visar att ett robust program inte handlar om att uppfylla en enda standard, utan om att bygga ett heltäckande styrningsramverk som genererar det bevismaterial som krävs för att uppfylla dem alla.

Kritiska fallgropar: där leverantörsrevisioner misslyckas

Många program för tillsyn över leverantörer brister på grund av vanliga och undvikbara misstag. Var särskilt uppmärksam på dessa kritiska fallgropar:

• Revision som en händelse: Att förlita sig på engångsrevisioner vid introduktion eller förnyelse i stället för att införa kontinuerlig övervakning.
• Certifieringssjälvgodhet: Att acceptera ett ISO- eller SOC 2-certifikat utan att granska rapportens detaljer, omfattning och avvikelser.
• Otydliga avtal: Att inte inkludera uttryckliga och bindande avtalsklausuler om revisionsrätt, incidentanmälan och datahantering.
• Bristfällig registerhantering: Att inte kunna ta fram en fullständig och riskklassificerad förteckning över alla leverantörer och de data de har åtkomst till.
• Ignorerad nedströmsrisk: Att inte identifiera och hantera risker som uppstår genom leverantörens egna kritiska underleverantörer, det vill säga fjärdepartsrisk.
• Overifierad sårbarhetshantering: Att lita på att en leverantör patchar kritiska sårbarheter utan att begära bevismaterial.

Praktisk checklista för revision av högriskleverantörer

Använd denna checklista, anpassad från Zenith Blueprint, för att säkerställa att revisionsprocessen för varje högriskleverantör är grundlig och försvarbar.

Slutsats: bygg en resilient och försvarbar leveranskedja

Tiden för checkbox-baserad efterlevnad för kritiska leverantörer är över. Den intensiva granskningen från regelverk som NIS2 och DORA kräver ett grundläggande skifte mot en modell för kontinuerlig, evidensbaserad säkerhetsverifiering. CISO:er som Maria måste driva arbetet med att föra sina organisationer bortom det statiska frågeformuläret.

Genom att bygga ett program på den beprövade livscykeln i ISO/IEC 27001:2022-kontroller skapar ni ett ramverk som inte bara uppfyller kraven utan också är genuint effektivt för att minska risk. Det innebär att behandla leverantörssäkerhet som en strategisk disciplin, införa bindande krav i avtal och upprätthålla vaksam tillsyn under hela relationen.

Er organisations säkerhet är bara så stark som den svagaste länken, och i dagens sammanlänkade ekosystem finns den länken ofta hos en tredje part. Det är dags att återta kontrollen.

Redo att gå bortom frågeformuläret?

Clarysecs integrerade verktygspaket ger den grund ni behöver för att bygga ett leverantörsriskhanteringsprogram i världsklass som håller för alla revisioner.

• Ladda ner våra policymallar: Inför ett robust styrningsramverk med vår företagsanpassade policy för leverantörs- och tredjepartssäkerhet och dess motsvarighet för små och medelstora företag.
• Följ Zenith Blueprint: Använd vår Zenith Blueprint: An Auditor’s 30-Step Roadmap för att införa och revidera ett ISMS som uppfyller kraven, med särskilda steg för att behärska leverantörsrisk.
• Utnyttja Zenith Controls: Begär en demo av vår Zenith Controls: The Cross-Compliance Guide för att mappa leverantörskontroller mot NIS2, DORA, GDPR, NIST med mera och säkerställa att er revisionsplan är heltäckande och försvarbar.