Secure-by-demand ved anskaffelse af software i 2026

Det er tirsdag morgen i begyndelsen af 2026, og Maria, CISO i en hurtigt voksende europæisk betalingsvirksomhed, præsenterer for bestyrelsen. Det sidste punkt på dagsordenen burde være rutine: godkendelse af en ny AI-drevet platform til svigdetektion. Leverandøren har en imponerende demo, en tidsbegrænset rabat, en sikkerhedsoversigt på én side og en standardkontrakt.

Så begynder spørgsmålene.

CEO’en spørger: “Hvordan ved vi, at denne platform er sikker? Vores kunder inden for finansielle tjenester efterspørger DORA-dokumentation for compliance, og denne leverandør bliver en del af vores kritiske infrastruktur.”

Juridisk afdeling spørger, om databehandleraftalen er klar, hvor EU-kundedata vil blive behandlet, og om underdatabehandlere er oplyst. Den ansvarlige for operationel robusthed spørger til exit-planlægning, eksport af sikkerhedskopier og forretningskontinuitet for kritiske funktioner. Produktsikkerhedsingeniøren efterspørger offentliggørelse af sårbarheder, dokumentation for patching og en SBOM eller tilsvarende erklæring om komponentgennemsigtighed. Indkøb stiller det spørgsmål, der gør leverandørrisiko dyr: “Kan vi godkende nu og indsamle dokumenterne efter underskrift?”

Det er dér, moderne anskaffelse af software enten bliver en kontrol eller en fremtidig hændelsesrapport.

I 2026 kan sikker anskaffelse af software ikke baseres på goodwill efter kontraktindgåelse. NIS2-krav om sikkerhed i forsyningskæden, DORA-styring af IKT-tredjepartsrisici, GDPR-ansvarlighed for databehandlere og Cyber Resilience Act-forventninger til produktsikkerhed har flyttet leverandørassurance ind i anskaffelsesbeslutningen. Købere har brug for secure-by-demand ved anskaffelse af software, hvor kunden definerer sikkerhedsbevismateriale, kontraktklausuler, onboarding-gates og driftsmæssige ansvarsområder før køb.

For Clarysec-kunder er svaret ikke endnu et regneark, der går tabt i e-mails. Det er et anskaffelseskontrolsystem tilpasset ISO/IEC 27001:2022, mappet gennem Clarysec-politikker, Zenith Blueprint: en revisors 30-trins køreplan og Zenith Controls, så hvert software- eller SaaS-køb har et revisionsmæssigt forsvarligt spor fra forretningsbehov til beslutning om leverandørrisiko.

Secure-by-demand er den nye kontrol for anskaffelse af software

Secure-by-design omtales normalt fra leverandørsiden. Secure-by-demand er disciplinen på købersiden: Organisationen afviser at købe software, medmindre leverandøren kan dokumentere, at sikkerhed, databeskyttelse, robusthed, sårbarhedshåndtering og revisionsbarhed er indbygget i tilbuddet.

Det ændrer købsdialogen. I stedet for at spørge: “Har I sikkerhed?” stiller indkøb mere præcise spørgsmål:

• Hvilke data vil I behandle, hvor og i hvilken juridisk rolle?
• Hvilken forretningsfunktion bliver afhængig af jer, og hvor kritisk er den?
• Hvilket bevismateriale dokumenterer, at jeres kontroller fungerer, og ikke kun at de er dokumenteret?
• Hvilke frister for hændelsesunderretning vil I forpligte jer til?
• Hvilken dokumentation for offentliggørelse af sårbarheder, patching, SBOM eller VEX kan I levere?
• Hvilke underleverandører eller underdatabehandlere får adgang til vores data eller tjeneste?
• Kan vi revidere, inspicere eller anmode om bevismateriale i kontraktperioden?
• Hvad sker der ved ophør, migrering, brud, insolvens eller forespørgsel fra en tilsynsmyndighed?

ISO/IEC 27001:2022 giver ledelsessystemets rygrad til dette skifte. Klausul 4 kræver, at organisationen forstår kontekst, interessenter og ISMS-omfang, herunder eksterne regulatoriske krav og leverandørkrav. Klausul 5 gør leverandørrisiko til et ledelses- og governanceansvar. Klausul 6 kræver risikovurdering, risikobehandling, kontroludvælgelse, en anvendelseserklæring og beslutninger om restrisiko. Klausul 8 kræver kontrolleret drift af processer, herunder eksternt leverede processer. Klausul 9 kræver overvågning, intern audit og ledelsens gennemgang.

Det betyder, at anskaffelse af software ikke kun er en kommerciel arbejdsgang. Den bliver en driftet og revisionsbar ISMS-proces. Tilsynsmyndigheder og revisorer spørger i stigende grad, hvorfor en organisation accepterede en leverandør, før den forstod risikoen. Secure-by-demand-anskaffelse giver et klart svar: Risikoen blev vurderet, behandlet, kontraktreguleret og tildelt en ansvarlig, før afhængigheden blev etableret.

Hvorfor NIS2, DORA, GDPR og CRA mødes ved leverandørvalg

Marias bestyrelse stiller de rigtige spørgsmål, fordi én enkelt softwareleverandør kan udløse flere forpligtelser på samme tid.

NIS2 finder anvendelse efter sektor, størrelse og kritikalitet, hvor Annex I og Annex II bringer mange digitale, finansielle, infrastrukturbaserede, managed service- og cloudafhængige organisationer ind i anvendelsesområdet. Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder sikkerhed i forsyningskæden, sikker anskaffelse, sikker udvikling og vedligeholdelse, sårbarhedshåndtering, adgangsstyring, politik for styring af aktiver, forretningskontinuitet, håndtering af hændelser og vurdering af kontroleffektivitet. Article 21(3) kræver specifikt opmærksomhed på direkte leverandørers sårbarheder og leverandørers cybersikkerhedspraksis. Article 23 fastsætter forventninger til trinvis rapportering af væsentlige hændelser, herunder tidlig varsling inden for 24 timer og underretning inden for 72 timer.

DORA gælder fra 17. januar 2025 for finansielle enheder inden for anvendelsesområdet. Forordningen fastsætter ensartede krav til styring af IKT-risiko, rapportering af IKT-relaterede hændelser, test af digital operationel robusthed og styring af IKT-tredjepartsrisici. DORA er særligt præskriptiv for anskaffelser. Finansielle enheder har brug for strategier for IKT-tredjepartsrisiko, registre over IKT-tjenestearrangementer, due diligence, analyse af koncentrationsrisiko, skriftlige kontrakter med sikkerheds- og robusthedsbestemmelser, revisions- og adgangsrettigheder, samarbejdsforpligtelser, opsigelsesrettigheder og exit-planer. Article 28 og Article 30 er centrale for IKT-tredjepartsrisiko og kontraktlige kontroller, mens Article 17 til Article 23 former hændelsesstyring og rapportering.

GDPR tilføjer en gate for databehandleransvarlighed. Article 5, Article 28, Article 32, Article 33 og Article 34 kræver ansvarlighed, databehandlerkontrakter, passende sikkerhed, samarbejde om underretning ved brud og håndtering af konsekvenser for registrerede. En SaaS-leverandør, der behandler personoplysninger, er ikke blot en leverandør. Leverandøren bliver en del af den dataansvarliges complianceprofil. DPA’en, tekniske og organisatoriske foranstaltninger, liste over underdatabehandlere, fornødne garantier ved overførsel, opbevaringsregler og sletteforpligtelser skal være forstået, før behandlingen begynder.

CRA-forventninger tilføjer produktassurance. Selv hvor køberen ikke er producenten, bør indkøbsteams kræve dokumentation for sikker udvikling, sårbarhedshåndtering, produktsupport, sikkerhedsopdateringer, koordineret offentliggørelse af sårbarheder og komponentgennemsigtighed, f.eks. en SBOM eller tilsvarende erklæring. Disse krav hører hjemme i RFP’er, sikkerhedsbilag og accept-gates.

Det fælles tema er enkelt: Den købende organisation skal vide, hvad den køber, hvilken risiko den importerer, og hvilket bevismateriale den kan fremlægge, når tilsynsmyndigheder, kunder eller revisorer spørger.

ISO 27001-kontrolrygraden for leverandørassurance

Den mest effektive secure-by-demand-model for anskaffelse er ikke regulering for reguleringens skyld. Den er kontrolbaseret. Clarysec bruger ISO/IEC 27001:2022 som ISMS-rygrad, understøttet af kontrolvejledning i ISO/IEC 27002:2022 og tværgående compliancemapping i Zenith Controls.

I Zenith Controls er leverandørassurance forankret omkring ISO/IEC 27002:2022-kontrollerne 5.19, 5.20 og 5.21. Det er ikke isolerede tjeklistepunkter. De udgør en anskaffelseslivscyklus.

Zenith Controls mapper disse ISO-kontroller på tværs af regulatoriske forventninger og revisionsforventninger. Det skaber ikke særskilte proprietære kontroller kaldet Zenith Controls. Det hjælper teams med at forstå, hvordan ISO/IEC 27002:2022-kontroller understøtter NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT-orienteret assurance.

Det understøttende kontrolnetværk er også vigtigt. Leverandørassurance er forbundet med politik for styring af aktiver, adgangsstyring, cloudsikkerhed, sårbarhedsstyring, logning, hændelsesstyring, IKT-beredskab for forretningskontinuitet, sikker udvikling, applikationssikkerhed, konfigurationsstyring, backup, redundans, juridisk compliance, databeskyttelse, ændringsstyring og uafhængig gennemgang. Indkøb koordinerer processen, men risikoejerskab skal omfatte forretningsejeren, informationssikkerhed, juridisk afdeling, databeskyttelse, IT, økonomi og serviceejeren.

Clarysec-politik-gates før underskrift

Clarysecs politikmodel flytter bevidst leverandørassurance opstrøms. Det stærkeste sprog står dér, hvor det hører hjemme: før aftaler underskrives, før cloudabonnementer aktiveres, og før data deles.

SMV-versionen af Clarysecs Politik for tredjeparts- og leverandørsikkerhed angiver:

Vurder og dokumentér leverandørrisici, før aftaler underskrives, eller adgang gives.

Dette kommer fra afsnittet “Mål”, politikklausul 3.3. Klausulen er kort, fordi kontrolformålet ikke kan forhandles: ingen risikovurdering, ingen kontrakt, ingen adgang.

For enterprise-miljøer forstærker Clarysecs Politik for tredjeparts- og leverandørsikkerhed gaten før kontraktindgåelse:

Alle nye leverandører skal gennemgå en dokumenteret sikkerhedsvurdering før kontraktindgåelse.

Dette kommer fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1. Samme politik identificerer også “Revisionsrettigheder til at revidere, inspicere og anmode om sikkerhedsbevismateriale” i afsnittet “Styringskrav”, politikklausul 5.3.4.

Ved køb af cloud og SaaS tilføjer SMV-versionen af Politik for brug af cloudtjenester en praktisk godkendelsesgate:

Al brug af cloudtjenester skal gennemgås og godkendes af direktøren (GM) før implementering eller abonnement.

Dette kommer fra afsnittet “Styringskrav”, politikklausul 5.1. I en lille organisation kan denne godkendelse svare til et cloudstyringsudvalg. I en enterprise-organisation bliver det en arbejdsgang på tværs af indkøb, sikkerhed, databeskyttelse og arkitektur. Enterprise-versionen af Politik for brug af cloudtjenester understøtter også kontraktlige cloudkrav, herunder håndhævelige bestemmelser i CSP-kontrakter.

Ved anskaffelse af software er enterprise-versionen af Politik for krav til applikationssikkerhed eksplicit:

Anskaffelse af software eller outsourcingaftaler skal indeholde sikkerhedskrav i RFP’er, kontrakter og SLA’er, herunder bestemmelser om frister for afhjælpning af sårbarheder og tredjeparts revisionsrettigheder.

Dette kommer fra afsnittet “Styringskrav”, politikklausul 5.4. Bemærk rækkefølgen: RFP’er, kontrakter og SLA’er. Sikkerhed optræder allerede i markedsdialogen, ikke som et bilag efter tildeling.

Ved GDPR-drevet anskaffelse kræver Clarysecs SMV-version af Politik for juridisk og regulatorisk efterlevelse:

Databehandleraftaleklausuler eller tilsvarende kontraktvilkår skal være aftalt, før personoplysninger eller følsomme data deles.

Dette kommer fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.2. Det forebygger en af de mest almindelige fejl ved SaaS-onboarding: at uploade personoplysninger til et værktøj, før databehandlervilkår, brudforpligtelser og betingelser for underdatabehandlere er aftalt.

For leverandørers applikationssikkerhed kræver SMV-versionen af Politik for krav til applikationssikkerhed, at indkøb:

specificerer forpligtelser vedrørende offentliggørelse af sårbarheder, svartider og patching.

Dette er fra afsnittet “Styringskrav”, politikklausul 5.3.2. Den angiver også:

GM skal anmode om dokumentation eller certificeringer (f.eks. SOC 2, ISO 27001, sikkerhedstestrapporter) som dokumentation for leverandørens efterlevelse, hvor det er relevant.

Dette kommer fra afsnittet “Krav til implementering af politikken”, politikklausul 6.3.2. Nøgleordet er bevismateriale. Secure-by-demand-anskaffelse er ikke baseret på tillidserklæringer. Den er baseret på artefakter, der kan gennemgås.

Zenith Blueprint-anskaffelsesgaten

Zenith Blueprint behandler leverandørsikkerhed som en driftet kontrol, ikke som et indkøbsslogan. I fasen Controls in Action dækker Step 23 organisatoriske kontroller 5.19 til 5.37, herunder informationssikkerhed i leverandørrelationer.

Blueprint forklarer:

Det starter med leverandørklassificering. Ikke alle leverandører indebærer samme risiko. En rengøringsleverandør kan have fysisk adgang til kontorer, men ikke til netværk. Et penetrationstestfirma eller en cloududbyder kan derimod have dyb teknisk adgang til selve kernen af jeres infrastruktur. Klassificeringen bør tage højde for, om leverandøren håndterer eller behandler jeres oplysninger direkte, om leverandøren leverer infrastruktur eller platforme, som I driver på, om leverandøren administrerer eller vedligeholder systemer på jeres vegne, og om en kompromittering af leverandøren kan påvirke jeres mål for fortrolighed, integritet eller tilgængelighed.

For kontrol 5.20 er Blueprint direkte:

Centrale områder, der typisk behandles i leverandøraftaler, omfatter fortrolighedsforpligtelser; ansvar for adgangsstyring; tekniske og organisatoriske foranstaltninger for databeskyttelse, kryptering, sikker transmission, backup og tilgængelighedsforpligtelser; tidsfrister og protokoller for hændelsesrapportering; revisionsret, herunder frekvens, omfang og adgang til relevant bevismateriale; underleverandørkontroller; samt bestemmelser ved kontraktophør, såsom returnering eller destruktion af data, genoprettelse af aktiver og deaktivering af konti.

Den konkluderer, at kontrol 5.20 er “jeres sidste løftestang” og “hører hjemme ved anskaffelsesgaten”. Når kontrakten er underskrevet, falder forhandlingsstyrken. Før underskrift kan bevismateriale og forpligtelser gøres til købsbetingelser.

For outsourcet udvikling tilføjer fasen Controls in Action, Step 21, kontrol 8.30, endnu et anskaffelseskrav. Blueprint angiver:

Kernen i denne kontrol er princippet om, at sikkerhed skal være et kontraktligt krav, ikke en mundtlig forventning.

Outsourcede teams bør opfylde de samme standarder for sikker udvikling som interne teams, herunder statisk analyse, peer review, kryptering, MFA til repositories og indsigt i kode, arkitekturbeslutninger, sårbarheder, ændringsanmodninger, CI/CD-logfiler og scanningsresultater.

Byg en secure-by-demand RFP-gate på én eftermiddag

Antag, at din organisation ønsker en kundeanalyseplatform. Den vil indsamle kundeidentifikatorer, adfærdshændelser, supportmetadata og transaktionsreferencer. Forretningsejeren ønsker hurtig godkendelse. Sikkerhedsteamet har én uge.

Start med en anskaffelsesgate-registrering med Politik for tredjeparts- og leverandørsikkerhed, Politik for krav til applikationssikkerhed, Politik for brug af cloudtjenester, Politik for juridisk og regulatorisk efterlevelse og Step 23 i Zenith Blueprint som kildedokumenter.

Vedlæg et secure-by-demand-spørgeskema til RFP’en. Undgå generiske spørgsmål som “Krypterer I data?” Stil bevisdrevne spørgsmål:

1. Fremlæg jeres aktuelle uafhængige rapport om sikkerhedsassurance, certifikat eller tilsvarende kontrolbevismateriale.
2. Identificér hostinglokationer, muligheder for dataresidens, backuplokationer og lokationer for supportadgang.
3. Fremlæg DPA’en, listen over underdatabehandlere og underretningsprocessen for ændringer i underdatabehandlere.
4. Bekræft frister for hændelsesunderretning, herunder support til tidlig varsling inden for 24 timer, hvor NIS2-arbejdsgange kan blive udløst, og support til faseopdelt rapportering for DORA-regulerede kunder.
5. Fremlæg politik for offentliggørelse af sårbarheder, patch-SLA’er efter alvorlighed og dokumentation for nyere governance for afhjælpning af sårbarheder.
6. Fremlæg bevismateriale for produktsikkerhed, såsom beskrivelse af sikker udviklingslivscyklus, sammenfatning af penetrationstest, SBOM eller erklæring om komponentgennemsigtighed og supportperiode for sikkerhedsopdateringer.
7. Bekræft MFA, mindst mulige rettigheder, logning, overvågning af administrativ adgang og kundens ret til revision eller anmodning om bevismateriale.
8. Beskriv eksport, sletning, returnering, support ved ophør og bistand ved overgang.
9. Angiv væsentlige underleverandører og IKT-afhængigheder, der understøtter tjenesten.
10. Bekræft, om kundedata anvendes til træning, analyse, produktforbedring eller udvikling af AI-modeller, og identificér behandlingsgrundlag eller modellen for databehandlerinstruks.

Score derefter leverandøren før forhandling.

Opdater til sidst risikoregisteret og anvendelseserklæringen. Registreringen af risikobehandling bør vise, hvorfor ISO/IEC 27002:2022-kontrollerne 5.19, 5.20 og 5.21 gælder, hvilke kontraktlige og tekniske krav der blev valgt, hvem der ejer restrisikoen, og hvilken overvågningskadence der gælder. Hvis forretningen ønsker at fortsætte trods mangler, skal der anvendes en formel registrering af risikoaccept med udløbsdato, kompenserende kontroller og ledelsesgodkendelse.

Kontraktklausuler, der omsætter regulering til håndhævelige forpligtelser

Sikkerhedsforventninger skal blive til kontraktlige forpligtelser. Et certifikat kan være nyttigt, men det besvarer sjældent alle spørgsmål om netop jeres tjeneste, datalokation, underleverandører, supportmodel, hændelsesforpligtelser eller exit-rettigheder.

Denne tabel er den praktiske bro mellem retlige forpligtelser og indkøbsarbejdet. Den hjælper også juridisk afdeling, sikkerhed og indkøb med at forhandle ud fra samme kontrolbaseline.

Tværgående compliancemapping: én leverandørfil, mange forpligtelser

Fordelen ved at bruge ISO/IEC 27001:2022 som rygrad er, at én leverandørassurance-fil kan understøtte flere regulatoriske dialoger.

NIST CSF 2.0 er nyttig som kommunikationslag. GOVERN-funktionen fremhæver bevidsthed om retlige, regulatoriske, kontraktlige, databeskyttelses- og afhængighedsforhold. GV.SC-resultaterne for forsyningskæden kræver processer for styring af forsyningskæderisiko, leverandørroller, prioritering af leverandører efter kritikalitet, kontraktlige krav, due diligence, overvågning, hændelsesplanlægning og planlægning ved ophør.

Det mapper rent til Step 23 i Zenith Blueprint og ISO/IEC 27002:2022-kontrollerne 5.19 til 5.21 som mappet i Zenith Controls. Det giver også bestyrelser et sprog, de forstår: aktuel tilstand, måltilstand, gap, risiko, handling, ejer og dato.

Hvad revisorer vil spørge om

En stærk secure-by-demand-anskaffelsesproces bør kunne modstå forskellige revisionsvinkler.

En ISO/IEC 27001:2022-revisor vil starte med ISMS-kontekst og -omfang. Revisoren vil spørge, om leverandørgrænseflader og afhængigheder er inkluderet, om krav fra interessenter omfatter NIS2, DORA, GDPR og kundekontrakter, og om leverandørrisici vurderes konsekvent efter risikometodikken. Revisoren vil følge sporet ind i risikobehandling, anvendelseserklæring, leverandørkontroller, driftsbevismateriale, intern audit og ledelsens gennemgang.

En DORA-gennemgang vil fokusere på IKT-understøttede forretningsfunktioner, kritiske eller vigtige funktioner, registreringer af tredjepartsafhængigheder, kontraktklausuler, revisions- og adgangsrettigheder, hændelsessamarbejde, robusthedstest, exitstrategier og koncentrationsrisiko. Hvis en SaaS understøtter en kritisk eller vigtig funktion, er et letvægtsleverandørspørgeskema ikke nok.

En NIS2-myndighed vil spørge, hvordan organisationen vurderede leverandørers cybersikkerhedspraksis, direkte leverandørers sårbarheder, support til hændelsesunderretning, afhængigheder for forretningskontinuitet og beslutninger om sikker anskaffelse. Den vil teste, om leverandørassurance understøtter organisationens egne forpligtelser efter Article 21 og Article 23.

En GDPR-gennemgang vil spørge, om roller som dataansvarlig og databehandler var forstået, før behandlingen begyndte, om en DPA eller tilsvarende vilkår var aftalt, før data blev delt, om underdatabehandlere var oplyst, om sikkerhedsforanstaltninger var passende, om samarbejde ved brud er kontraktligt reguleret, og om returnering eller sletning af data kan håndhæves.

En COBIT 2019- eller ISACA-inspireret revisor vil fokusere på governance og ansvarlighed: hvem godkendte leverandøren, hvilken risiko blev accepteret, om politikkrav blev fulgt, om undtagelser spores, og om gevinster, risiko og ressourcer blev afbalanceret.

Jeres bevispakke bør omfatte leverandørklassificering, godkendelse fra forretningsejer, risikovurdering, RFP-sikkerhedskrav, leverandørsvar, DPA, sikkerhedsbilag, SLA, revisionsrettigheder, register over underdatabehandlere, sårbarhedsforpligtelser, hændelsesklausuler, bevismateriale for cloudlokation, bevismateriale for logning og kryptering, exit-vilkår, revurderingsregistreringer, undtagelser og mapping til anvendelseserklæringen.

Almindelige fejlmønstre ved softwarekøb

Den første fejl er at behandle indkøb som en kommerciel arbejdsgang og sikkerhed som en teknisk arbejdsgang. Når sikkerhedsteamet modtager kontrakten, har forretningen allerede forpligtet sig psykologisk, implementeringsdatoen er annonceret, og forhandlingsstyrken er svag.

Den anden fejl er substitution af bevismateriale. En leverandør fremlægger et certifikat, og køberen antager, at det besvarer alle spørgsmål. Certificering kan hjælpe, men den dækker muligvis ikke det konkrete produkt, hostingregionen, supportmodellen, underleverandørkæden, hændelsesforpligtelser, AI-databrug eller exit-krav.

Den tredje fejl er manglende synlighed over underliggende risiko. En SaaS-leverandør kan være afhængig af cloudhosting, analyseværktøjer, supportplatforme, offshore-teams, AI-modeludbydere og betalingsformidlere. ISO/IEC 27002:2022-kontrol 5.21 kræver opmærksomhed på IKT-forsyningskæden bag den direkte leverandør. Under DORA er dette forbundet med underleverancer og koncentrationsrisiko. Under GDPR er det forbundet med underdatabehandlere. Under NIS2 er det forbundet med direkte leverandørers sårbarheder og leverandørers cybersikkerhedspraksis.

Den fjerde fejl er svagt hændelsessprog. En kontrakt, der siger, at “leverandøren underretter kunden straks”, understøtter muligvis ikke NIS2-tidlig varsling, DORA-faseopdelt rapportering, kundekommunikation eller intern eskalering. Hændelsesklausuler kræver tidsfrister, udløsende forhold, kontaktpunkter, samarbejdsforpligtelser og bevisforpligtelser.

Den femte fejl er uklare exit-rettigheder. Hvis en leverandør bliver usikker, ikke-compliant, opkøbt, insolvent eller strategisk uegnet, har køberen brug for eksport, sletning, overgangssupport, kontodeaktivering og dokumentation for destruktion. Exit er ikke en juridisk eftertanke. Det er en robusthedskontrol.

Fra anskaffelsesgate til levende leverandørassurance

Secure-by-demand-anskaffelse slutter ikke ved underskrift. En moden Clarysec-lignende leverandørlivscyklus har fem faser.

For højrisikoleverandører bør overvågning omfatte opdatering af bevismateriale, møder om sikkerhedsgennemgang, deltagelse i tabletop-øvelser for hændelser, gennemgang af adgangsrettigheder, sårbarheds- og patchrapportering, gennemgang af serviceændringer og opdateringer om underdatabehandlere. For leverandører med lavere risiko kan en årlig gennemgang være tilstrækkelig. ISO 27001-skalerbarhed, NIS2-proportionalitet og DORA-proportionalitet understøtter alle tilpasning, men tilpasningen skal begrundes og dokumenteres.

Næste skridt med Clarysec

Det næste risikofyldte SaaS-køb venter ikke på et perfekt redesign af governance. Start med den næste indkøbsanmodning.

Brug Zenith Blueprint: en revisors 30-trins køreplan til at implementere Step 23-kontroller for leverandørrelationer og Step 21-kontroller for outsourcet udvikling. Brug Zenith Controls til at mappe ISO/IEC 27002:2022-kontrollerne 5.19, 5.20 og 5.21 på tværs af NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT-orienterede revisionsforventninger. Brug Clarysecs politikbibliotek, herunder Politik for tredjeparts- og leverandørsikkerhed, Politik for krav til applikationssikkerhed, Politik for brug af cloudtjenester og Politik for juridisk og regulatorisk efterlevelse, til at gøre gaten håndhævelig.

Før den næste kontrakt underskrives, skal der kræves leverandørklassificering, sikkerhedsbevismateriale, DPA-beredskab, hændelsesforpligtelser, sårbarhedshåndtering, gennemsigtighed om underleverandører, revisionsrettigheder og exit-vilkår.

Det er secure-by-demand-anskaffelse. Det er sådan CISO’er omsætter regulatorisk pres til købsstyrke. Det er sådan compliance-ansvarlige omsætter overlappende forpligtelser til én bevisfil. Det er sådan revisorer kan se, at leverandørrisiko blev vurderet, før afhængigheden blev etableret. Og det er sådan forretningsejere køber software hurtigere uden at overtage ustyret risiko.

Klar til at gøre jeres næste softwarekøb til en revisionsklar kontrol? Udforsk Clarysecs integrerede politikpakke, download Zenith Blueprint, gennemgå Zenith Controls, eller planlæg en demo for at opbygge et secure-by-demand-anskaffelsesprogram, der kan modstå NIS2, DORA, GDPR, CRA-forventninger og reel revisorkontrol.