Säkerhetskravsstyrd programvaruupphandling 2026

Det är tisdagsmorgon i början av 2026 och Maria, informationssäkerhetschef på ett snabbt växande europeiskt betalningsföretag, presenterar för styrelsen. Den sista punkten på agendan borde vara rutin: godkännande av en ny AI-driven plattform för bedrägeridetektering. Leverantören har en imponerande demo, en tidsbegränsad rabatt, en ensidig säkerhetsöversikt och ett standardavtal.

Sedan börjar frågorna.

VD:n frågar: “Hur vet vi att den här plattformen är säker? Våra kunder inom finansiella tjänster efterfrågar underlag för efterlevnad av DORA, och den här leverantören blir en del av vår kritiska infrastruktur.”

Juridikfunktionen frågar om personuppgiftsbiträdesavtalet (DPA) är klart, var EU-kunddata ska behandlas och om underbiträden har redovisats. Ansvarig för operativ resiliens frågar om exitplanering, export av säkerhetskopior och kontinuitet för kritiska funktioner. Produktens säkerhetsingenjör efterfrågar sårbarhetsrapportering, underlag för patchning och en SBOM eller motsvarande uttalande om komponenttransparens. Upphandling ställer frågan som gör leverantörsrisk dyr: “Kan vi godkänna nu och samla in dokumenten efter signering?”

Det är ögonblicket då modern programvaruupphandling antingen blir en kontroll eller en framtida incidentrapport.

År 2026 kan säker programvaruupphandling inte bygga på välvilja efter avtalstecknande. Säkerhet i leveranskedjan enligt NIS2, IKT-tredjepartsrisk enligt DORA, ansvarsskyldighet för personuppgiftsbiträden enligt GDPR och produktssäkerhetsförväntningar enligt Cyber Resilience Act har flyttat leverantörssäkring till själva upphandlingsbeslutet. Köpare behöver säkerhetskravsstyrd programvaruupphandling, där kunden definierar säkerhetsunderlag, avtalsklausuler, införandegrindar och operativa ansvar innan köp.

För Clarysec-kunder är svaret inte ännu ett kalkylblad som dör i e-posttråden. Det är ett upphandlingskontrollsystem som är anpassat till ISO/IEC 27001:2022 och mappat genom Clarysec-policyer, Zenith Blueprint: en 30-stegs färdplan för revisorer och Zenith Controls, så att varje programvaru- eller SaaS-köp får ett försvarbart spår från verksamhetsbehov till beslut om leverantörsrisk.

Säkerhetskravsstyrning är den nya kontrollen för programvaruupphandling

Säkerhet genom design diskuteras oftast från leverantörssidan. Säkerhetskravsstyrning är köparsidans disciplin: organisationen avstår från att köpa programvara om leverantören inte kan visa att säkerhet, dataskydd, resiliens, sårbarhetshantering och revisionsbarhet är inbyggda i erbjudandet.

Det förändrar inköpsdialogen. I stället för att fråga “Har ni säkerhet?” ställer upphandling skarpare frågor:

• Vilka data kommer ni att behandla, var och i vilken rättslig roll?
• Vilken verksamhetsfunktion blir beroende av er, och hur kritisk är den?
• Vilket underlag visar att era kontroller fungerar, inte bara att de är dokumenterade?
• Vilka tidsfrister för incidentanmälan åtar ni er?
• Vilket underlag för sårbarhetsrapportering, patchning, SBOM eller VEX kan ni tillhandahålla?
• Vilka underleverantörer eller underbiträden kommer att beröra våra data eller vår tjänst?
• Kan vi revidera, inspektera eller begära underlag under avtalsperioden?
• Vad händer vid uppsägning, migrering, personuppgiftsincident, insolvens eller begäran från tillsynsmyndighet?

ISO/IEC 27001:2022 ger ledningssystemets ryggrad för denna förflyttning. Avsnitt 4 kräver att organisationen förstår kontext, intressenter och ISMS-omfattning, inklusive externa regulatoriska krav och leverantörskrav. Avsnitt 5 gör leverantörsrisk till ett ansvar för ledarskap och styrning. Avsnitt 6 kräver riskbedömning, riskbehandling, val av kontroller, en tillämplighetsförklaring (Statement of Applicability) och beslut om kvarstående risk. Avsnitt 8 kräver kontrollerad drift av processer, inklusive externt tillhandahållna processer. Avsnitt 9 kräver övervakning, internrevision och ledningens genomgång.

Det innebär att programvaruupphandling inte bara är ett kommersiellt arbetsflöde. Den blir en styrd och revisionsbar ISMS-process. Tillsynsmyndigheter och revisorer frågar allt oftare varför en organisation accepterade en leverantör innan den förstod risken. Säkerhetskravsstyrd upphandling ger ett tydligt svar: risken bedömdes, behandlades, avtalsreglerades och tilldelades ansvar innan beroendet skapades.

Varför NIS2, DORA, GDPR och CRA möts vid leverantörsvalet

Marias styrelse ställer rätt frågor eftersom en enda programvaruleverantör kan utlösa flera skyldigheter samtidigt.

NIS2 gäller utifrån sektor, storlek och kritikalitet, där Annex I och Annex II för in många digitala, finansiella, infrastrukturbaserade, hanterade tjänsteorganisationer och molnberoende organisationer i tillämpningsområdet. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive säkerhet i leveranskedjan, säker anskaffning, säker utveckling och säkert underhåll, sårbarhetshantering, åtkomstkontroll, policy för tillgångshantering, kontinuitet, incidenthantering och bedömning av kontrolleffektivitet. Article 21(3) kräver särskild uppmärksamhet på direkta leverantörers sårbarheter och leverantörers cybersäkerhetspraxis. Article 23 skapar stegvisa förväntningar på rapportering av betydande incidenter, inklusive tidig varning inom 24 timmar och avisering inom 72 timmar.

DORA gäller från den 17 januari 2025 för finansiella entiteter inom tillämpningsområdet. Förordningen skapar enhetliga krav på IKT-riskhantering, rapportering av IKT-relaterade incidenter, testning av digital operativ resiliens och IKT-tredjepartsriskhantering. DORA är särskilt styrande för upphandling. Finansiella entiteter behöver strategier för IKT-tredjepartsrisk, register över IKT-tjänstearrangemang, leverantörsgranskning, analys av koncentrationsrisk, skriftliga avtal med bestämmelser om säkerhet och resiliens, revisionsrätt och åtkomsträtt, samverkansskyldigheter, rätt att säga upp avtalet och exitplaner. Articles 28 och 30 är centrala för IKT-tredjepartsrisk och avtalskontroller, medan Articles 17 till 23 formar incidenthantering och rapportering.

GDPR lägger till en grind för personuppgiftsbiträdets ansvarsskyldighet. Articles 5, 28, 32, 33 och 34 kräver ansvarsskyldighet, biträdesavtal, lämplig säkerhet, samverkan vid incidentanmälan och hantering av påverkan på registrerade. En SaaS-leverantör som behandlar personuppgifter är inte bara en leverantör. Den blir en del av den personuppgiftsansvariges efterlevnadsläge. DPA, tekniska och organisatoriska åtgärder, lista över underbiträden, skyddsåtgärder vid överföring, bevaranderegler och raderingsskyldigheter måste förstås innan behandlingen inleds.

CRA-förväntningar lägger till produktförsäkran. Även när köparen inte är tillverkaren bör upphandlingsteam kräva underlag för säker utveckling, sårbarhetshantering, produktsupport, säkerhetsuppdateringar, samordnad sårbarhetsrapportering och komponenttransparens, till exempel en SBOM eller motsvarande uttalande. Dessa krav hör hemma i anbudsförfrågningar (RFP), säkerhetsbilagor och acceptansgrindar.

Det gemensamma temat är enkelt: den köpande organisationen måste veta vad den köper, vilken risk den för in och vilket underlag den kan ta fram när tillsynsmyndigheter, kunder eller revisorer frågar.

ISO 27001-kontrollstrukturen för leverantörssäkring

Den mest effektiva modellen för säkerhetskravsstyrd upphandling är inte regelverk för regelverk. Den utgår från kontroller. Clarysec använder ISO/IEC 27001:2022 som ISMS-struktur, med stöd av kontrollvägledning i ISO/IEC 27002:2022 och korsmappning för regelefterlevnad i Zenith Controls.

I Zenith Controls förankras leverantörssäkring kring ISO/IEC 27002:2022-kontrollerna 5.19, 5.20 och 5.21. De är inte isolerade punkter i en checklista. De bildar en upphandlingslivscykel.

Zenith Controls mappar dessa ISO-kontroller mot regulatoriska förväntningar och revisionsförväntningar. Det skapar inte separata proprietära kontroller som kallas Zenith Controls. Det hjälper team att förstå hur ISO/IEC 27002:2022-kontroller stöder NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT-orienterad säkerhetsförsäkran.

Det stödjande kontrollnätverket är också viktigt. Leverantörssäkring kopplas till policy för tillgångshantering, åtkomstkontroll, molnsäkerhet, sårbarhetshantering, loggning, incidenthantering, IKT-beredskap för verksamhetskontinuitet, säker utveckling, applikationssäkerhet, konfigurationshantering, säkerhetskopiering, redundans, efterlevnad av rättsliga krav, dataskydd, ändringshantering och oberoende granskning. Upphandling samordnar processen, men riskägarskap måste omfatta verksamhetsägaren, informationssäkerhet, juridik, dataskydd, IT, ekonomi och tjänsteägaren.

Clarysecs policygrindar före signering

Clarysecs policymodell flyttar medvetet leverantörssäkring uppströms. Det starkaste språket finns där det hör hemma: innan avtal tecknas, innan molnabonnemang aktiveras och innan data delas.

SME-versionen av Clarysecs policy för leverantörssäkerhet och tredjepartssäkerhet anger:

Bedöm och dokumentera leverantörsrisker innan avtal tecknas eller åtkomst beviljas.

Detta kommer från avsnittet “Mål”, policyklausul 3.3. Klausulen är kort eftersom kontrollavsikten inte är förhandlingsbar: ingen riskbedömning, inget avtal, ingen åtkomst.

För företagsmiljöer förstärker Clarysecs policy för leverantörssäkerhet och tredjepartssäkerhet grinden före avtal:

Alla nya leverantörer ska genomgå en dokumenterad säkerhetsbedömning innan avtal ingås.

Detta kommer från avsnittet “Krav för genomförande av policyn”, policyklausul 6.1.1. Samma policy anger även “revisionsrätt, rätt att inspektera och rätt att begära säkerhetsunderlag” i avsnittet “Styrningskrav”, policyklausul 5.3.4.

För köp av molntjänster och SaaS lägger SME-versionen av Policy för användning av molntjänster till en praktisk godkännandegrind:

All användning av molntjänster ska granskas och godkännas av verkställande chef (GM) innan genomförande eller abonnemang.

Detta kommer från avsnittet “Styrningskrav”, policyklausul 5.1. I en liten organisation kan detta godkännande motsvara en styrgrupp för molntjänster. I en större organisation blir det ett arbetsflöde mellan upphandling, säkerhet, dataskydd och arkitektur. Företagsversionen av Policy för användning av molntjänster stöder även avtalskrav för molntjänster, inklusive verkställbara avtalsvillkor i CSP-avtal.

För programvaruanskaffning är företagsversionen av Policy för applikationssäkerhetskrav tydlig:

Programvaruanskaffning eller outsourcingarrangemang ska inkludera säkerhetskrav i RFP:er, avtal och SLA:er, inklusive bestämmelser om tidslinjer för åtgärdande av sårbarheter och tredjepartsrevisionsrätt.

Detta kommer från avsnittet “Styrningskrav”, policyklausul 5.4. Observera ordningen: RFP:er, avtal och SLA:er. Säkerhet kommer in redan i marknadsdialogen, inte som en bilaga efter tilldelning.

För GDPR-driven upphandling kräver Clarysecs SME-version av Policy för rättslig och regulatorisk efterlevnad:

Klausuler i personuppgiftsbiträdesavtal (DPA) eller likvärdiga avtalsvillkor ska avtalas innan personuppgifter eller känsliga data delas.

Detta kommer från avsnittet “Krav för genomförande av policyn”, policyklausul 6.3.2. Det förebygger ett av de vanligaste felen vid introduktion av SaaS: att personuppgifter laddas upp i ett verktyg innan biträdesvillkor, skyldigheter vid personuppgiftsincident och villkor för underbiträden är avtalade.

För leverantörers applikationssäkerhet kräver SME-versionen av Policy för applikationssäkerhetskrav att upphandling ska:

ange skyldigheter för sårbarhetsrapportering, svarstider och patchning.

Detta kommer från avsnittet “Styrningskrav”, policyklausul 5.3.2. Den anger också:

GM ska begära dokumentation eller certifieringar (t.ex. SOC 2, ISO 27001, säkerhetstestrapporter) som underlag för leverantörens efterlevnad, där så är tillämpligt.

Detta kommer från avsnittet “Krav för genomförande av policyn”, policyklausul 6.3.2. Nyckelordet är underlag. Säkerhetskravsstyrd upphandling bygger inte på förtroendeuttalanden. Den bygger på granskningsbara artefakter.

Upphandlingsgrinden i Zenith Blueprint

Zenith Blueprint behandlar leverantörssäkerhet som en operativ kontroll, inte som en upphandlingsslogan. I fasen Controls in Action omfattar Step 23 organisatoriska kontroller 5.19 till 5.37, inklusive informationssäkerhet i leverantörsrelationer.

Blueprint förklarar:

Det börjar med leverantörsklassificering. Alla leverantörer medför inte samma risk. En städtjänst kan ha fysisk åtkomst till kontor, men inte till nätverk. Ett företag som utför penetrationstestning eller en molndriftleverantör kan däremot ha djup teknisk åtkomst till själva kärnan i er infrastruktur. Klassificeringen bör beakta om leverantören hanterar eller behandlar er information direkt, om den tillhandahåller infrastruktur eller plattformar som ni använder, om den förvaltar eller underhåller system för er räkning och om en kompromettering av leverantören kan påverka era mål för konfidentialitet, riktighet eller tillgänglighet.

För kontroll 5.20 är Blueprint direkt:

Centrala områden som normalt hanteras i leverantörsavtal omfattar sekretesskyldigheter, ansvar för åtkomstkontroll, tekniska och organisatoriska åtgärder för dataskydd, kryptering, säker överföring, säkerhetskopiering och tillgänglighetsåtaganden, tidsfrister och protokoll för incidentrapportering, revisionsrätt inklusive frekvens, omfattning och åtkomst till relevant underlag, kontroller för underleverantörer samt bestämmelser vid avtalets upphörande, såsom återlämning eller förstöring av data, återställning av tillgångar och avaktivering av konton.

Den drar slutsatsen att kontroll 5.20 är “er sista möjlighet till förhandlingsstyrka” och “hör hemma vid upphandlingsgrinden”. När avtalet är undertecknat minskar förhandlingsutrymmet. Före signering kan underlag och skyldigheter göras till villkor för köpet.

För outsourcad utveckling tillför fasen Controls in Action, Step 21, kontroll 8.30, ytterligare ett upphandlingskrav. Blueprint anger:

Kärnan i denna kontroll är principen att säkerhet ska vara ett avtalskrav, inte en muntlig förväntan.

Outsourcade team bör uppfylla samma standarder för säker utveckling som interna team, inklusive statisk analys (SAST), kollegial granskning, kryptering, MFA till kodarkiv och insyn i kod, arkitekturbeslut, sårbarheter, ändringsbegäranden, CI/CD-loggar och skanningsresultat.

Bygg en säkerhetskravsstyrd RFP-grind på en eftermiddag

Anta att er organisation vill köpa en plattform för kundanalys. Den ska ta in kundidentifierare, beteendehändelser, supportmetadata och transaktionsreferenser. Verksamhetsägaren vill ha ett snabbt godkännande. Säkerhetsteamet har en vecka.

Börja med en post för upphandlingsgrinden med policy för leverantörssäkerhet och tredjepartssäkerhet, Policy för applikationssäkerhetskrav, Policy för användning av molntjänster, Policy för rättslig och regulatorisk efterlevnad och Step 23 i Zenith Blueprint som källdokument.

Bifoga ett säkerhetskravsstyrt frågeformulär till anbudsförfrågan. Undvik generiska frågor som “Krypterar ni data?” Ställ underlagsdrivna frågor:

1. Tillhandahåll aktuell oberoende rapport om säkerhetsförsäkran, certifikat eller likvärdigt kontrollunderlag.
2. Identifiera driftplatser, alternativ för datalagringsplats, platser för säkerhetskopiering och platser för supportåtkomst.
3. Tillhandahåll DPA, lista över underbiträden och aviseringsprocess för ändringar av underbiträden.
4. Bekräfta tidsfrister för incidentanmälan, inklusive stöd för 24-timmars tidig varning där NIS2-arbetsflöden kan utlösas och stöd för etappvis rapportering för DORA-reglerade kunder.
5. Tillhandahåll policy för sårbarhetsrapportering, SLA:er för patchning per allvarlighetsgrad och underlag för aktuell styrning av åtgärdande av sårbarheter.
6. Tillhandahåll produktsäkerhetsunderlag, till exempel beskrivning av säker utvecklingslivscykel, sammanfattning av penetrationstestning, SBOM eller uttalande om komponenttransparens samt supportperiod för säkerhetsuppdateringar.
7. Bekräfta MFA, principen om minsta privilegium, loggning, övervakning av administrativ åtkomst och kundens rätt att genomföra revision eller begära underlag.
8. Beskriv export, radering, återlämning, stöd vid uppsägning och övergångsbistånd.
9. Lista väsentliga underleverantörer och IKT-beroenden som stöder tjänsten.
10. Bekräfta om kunddata används för träning, analys, produktförbättring eller utveckling av AI-modeller, och identifiera rättslig grund eller modell för instruktion från personuppgiftsansvarig till personuppgiftsbiträde.

Poängsätt sedan leverantören före förhandling.

Uppdatera slutligen riskregistret och tillämplighetsförklaringen (Statement of Applicability). Riskbehandlingsposten bör visa varför ISO/IEC 27002:2022-kontrollerna 5.19, 5.20 och 5.21 är tillämpliga, vilka avtalsmässiga och tekniska krav som valdes, vem som äger kvarstående risk och vilken övervakningsfrekvens som gäller. Om verksamheten vill gå vidare trots brister ska en formell riskacceptans registreras med utgångsdatum, kompenserande kontroller och godkännande från högsta ledningen.

Avtalsklausuler som gör reglering till bindande skyldigheter

Säkerhetsförväntningar måste bli avtalsåtaganden. Ett certifikat kan vara användbart, men det besvarar sällan alla frågor om er exakta tjänst, datalagringsplats, underleverantörer, supportmodell, incidentåtaganden eller exiträttigheter.

Denna tabell är den praktiska bryggan mellan rättsliga skyldigheter och upphandlingsarbete. Den hjälper också juridik, säkerhet och upphandling att förhandla utifrån samma kontrollbaslinje.

Korsmappning för regelefterlevnad: en leverantörsakt, många skyldigheter

Fördelen med att använda ISO/IEC 27001:2022 som ryggrad är att en och samma leverantörsakt kan stödja flera regulatoriska dialoger.

NIST CSF 2.0 är användbart som kommunikationslager. Funktionen GOVERN betonar medvetenhet om rättsliga, regulatoriska, avtalsmässiga, integritetsrelaterade och beroenderelaterade förhållanden. Resultaten inom GV.SC för leveranskedjan kräver riskhanteringsprocesser för leveranskedjan, leverantörsroller, prioritering av leverantörer efter kritikalitet, avtalskrav, leverantörsgranskning, övervakning, incidentplanering och uppsägningsplanering.

Det mappar tydligt mot Step 23 i Zenith Blueprint och ISO/IEC 27002:2022-kontrollerna 5.19 till 5.21 som de mappas i Zenith Controls. Det ger också styrelser ett språk de förstår: nuläge, målläge, gap, risk, åtgärd, ägare och datum.

Vad revisorer kommer att fråga

En stark säkerhetskravsstyrd upphandlingsprocess bör hålla för olika revisionsperspektiv.

En ISO/IEC 27001:2022-revisor börjar med ISMS-kontext och omfattning. Revisorn frågar om leverantörsgränssnitt och beroenden ingår, om intressentkrav omfattar NIS2, DORA, GDPR och kundavtal, och om leverantörsrisker bedöms konsekvent enligt riskmetodiken. Revisorn följer spåret vidare till riskbehandling, tillämplighetsförklaring (Statement of Applicability), leverantörskontroller, operativt underlag, internrevision och ledningens genomgång.

En DORA-granskare fokuserar på IKT-stödda verksamhetsfunktioner, kritiska eller viktiga funktioner, register över tredjepartsberoenden, avtalsklausuler, revisionsrätt och åtkomsträtt, incidentsamverkan, resiliensövningar, exitstrategier och koncentrationsrisk. Om en SaaS stöder en kritisk eller viktig funktion räcker inte ett lättviktigt leverantörsfrågeformulär.

En NIS2-myndighet frågar hur organisationen bedömde leverantörers cybersäkerhetspraxis, direkta leverantörers sårbarheter, stöd för incidentanmälan, kontinuitetsberoenden och beslut om säker anskaffning. Den kommer att testa om leverantörssäkringen stöder organisationens egna skyldigheter enligt Article 21 och Article 23.

En GDPR-granskare frågar om rollerna som personuppgiftsansvarig och personuppgiftsbiträde var förstådda innan behandlingen började, om ett DPA eller likvärdiga villkor avtalades innan data delades, om underbiträden redovisades, om säkerhetsåtgärderna var lämpliga, om samverkan vid personuppgiftsincident är avtalad och om återlämning eller radering av data är möjlig att göra gällande.

En revisor enligt COBIT 2019 eller ISACA-praxis fokuserar på styrning och ansvarsskyldighet: vem godkände leverantören, vilken risk som accepterades, om policykrav följdes, om undantag följs upp och om nytta, risk och resurser balanserades.

Ert underlagspaket bör innehålla leverantörsklassificering, verksamhetsägarens godkännande, riskbedömning, säkerhetskrav i anbudsförfrågan, leverantörssvar, DPA, säkerhetsbilaga, SLA, revisionsrätt, register över underbiträden, åtaganden för sårbarheter, incidentklausuler, underlag om molnplats, underlag för loggning och kryptering, exitvillkor, omprövningsposter, undantag och mappning mot tillämplighetsförklaringen (Statement of Applicability).

Vanliga felmönster vid programvaruköp

Det första felet är att behandla upphandling som ett kommersiellt arbetsflöde och säkerhet som ett tekniskt arbetsflöde. När säkerhet får avtalet har verksamheten redan gjort ett psykologiskt åtagande, införandedatumet har kommunicerats och förhandlingsutrymmet är svagt.

Det andra felet är att ersätta underlag med symboler. En leverantör lämnar ett certifikat, och köparen antar att det besvarar alla frågor. Certifiering kan hjälpa, men den omfattar kanske inte exakt produkt, driftregion, supportmodell, underleverantörskedja, incidentåtaganden, användning av AI-data eller exitkrav.

Det tredje felet är att missa nedströmsrisk. En SaaS-leverantör kan vara beroende av molndrift, analysverktyg, supportplattformar, offshoreteam för utveckling, AI-modellleverantörer och betalningsförmedlare. ISO/IEC 27002:2022-kontroll 5.21 kräver uppmärksamhet på IKT-leveranskedjan bakom den direkta leverantören. Enligt DORA kopplas detta till underleverantörer och koncentrationsrisk. Enligt GDPR kopplas det till underbiträden. Enligt NIS2 kopplas det till direkta leverantörers sårbarheter och leverantörers cybersäkerhetspraxis.

Det fjärde felet är svagt incidentspråk. Ett avtal som säger att “leverantören ska underrätta kunden skyndsamt” kanske inte stöder NIS2:s tidiga varning, DORA:s etappvisa rapportering, kundkommunikation eller intern eskalering. Incidentklausuler behöver tidsramar, utlösande händelser, kontaktpunkter, samverkansskyldigheter och underlagsskyldigheter.

Det femte felet är oklara exiträttigheter. Om en leverantör blir osäker, inte uppfyller krav, förvärvas, blir insolvent eller inte längre passar strategiskt behöver köparen export, radering, övergångsstöd, avaktivering av konton och intyg om förstöring. Exit är inte en juridisk eftertanke. Det är en resilienskontroll.

Från upphandlingsgrind till levande leverantörssäkring

Säkerhetskravsstyrd upphandling slutar inte vid signering. En mogen leverantörslivscykel enligt Clarysec-modell har fem steg.

För högriskleverantörer bör övervakning omfatta uppdatering av underlag, säkerhetsgranskningsmöten, deltagande i skrivbordsövningar för incidenter, åtkomstgranskning, sårbarhets- och patchrapportering, granskning av tjänsteförändringar och uppdateringar av underbiträden. För leverantörer med lägre risk kan årlig granskning räcka. Skalbarhet enligt ISO 27001, proportionalitet enligt NIS2 och proportionalitet enligt DORA stöder alla anpassning, men anpassningen måste motiveras och dokumenteras.

Nästa steg med Clarysec

Nästa riskfyllda SaaS-köp väntar inte på en perfekt omdesign av styrningen. Börja med nästa upphandlingsbegäran.

Använd Zenith Blueprint: en 30-stegs färdplan för revisorer för att införa Step 23-kontroller för leverantörsrelationer och Step 21-kontroller för outsourcad utveckling. Använd Zenith Controls för att mappa ISO/IEC 27002:2022-kontrollerna 5.19, 5.20 och 5.21 mot NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT-orienterade revisionsförväntningar. Använd Clarysecs policybibliotek, inklusive policy för leverantörssäkerhet och tredjepartssäkerhet, Policy för applikationssäkerhetskrav, Policy för användning av molntjänster och Policy för rättslig och regulatorisk efterlevnad, för att göra grinden bindande.

Innan nästa avtal undertecknas ska leverantörsklassificering, säkerhetsunderlag, DPA-beredskap, incidentåtaganden, sårbarhetshantering, transparens om underleverantörer, revisionsrätt och exitvillkor krävas.

Det är säkerhetskravsstyrd upphandling. Det är så informationssäkerhetschefer omvandlar regulatoriskt tryck till inköpsstyrka. Det är så chefer för regelefterlevnad omvandlar överlappande skyldigheter till en enda underlagsakt. Det är så revisorer ser att leverantörsrisk beaktades innan beroendet skapades. Och det är så verksamhetsägare kan köpa programvara snabbare utan att ärva ohanterad risk.

Redo att göra nästa programvaruköp till en revisionsbar kontroll? Utforska Clarysecs integrerade policysvit, ladda ned Zenith Blueprint, granska Zenith Controls eller boka en demo för att bygga ett säkerhetskravsstyrt upphandlingsprogram som håller för NIS2, DORA, GDPR, CRA-förväntningar och verklig revision.