IKT-projektstyrning med inbyggd säkerhet 2026

Projektet höll tidplanen, tills revisionen ställde en fråga

Informationssäkerhetschefen på ett snabbväxande betalningsteknikbolag hade goda nyheter till styrelsen. Den nya plattformen för kundintroduktion var klar för lansering. Produktteamet hade levererat mobilupplevelsen, utvecklingsteamet hade integrerat verifiering av digital identitet, juridik hade tecknat avtal med moln- och API-leverantörer och driftorganisationen hade övat produktionssättningsplanen.

Sedan ställde internrevisorn en enkel fråga:

”Visa var säkerhet och integritet beaktades i varje steg av projektet.”

Det blev tyst i projektrummet.

Det fanns en rapport från penetrationstestning, men den hade kommit sent. Det fanns ett molnarkitekturdiagram, men inget underlag som visade att dataflödena hade granskats mot GDPR-principerna. Det fanns ett frågeformulär för leverantörsgranskning, men det var inte kopplat till riskregistret. Det fanns ett ändringsärende för produktionssättningen, men godkännandet nämnde inte påverkan på kritiska tjänster, incidentrapportering, resiliensprovning, kundavisering eller eskalering vid personuppgiftsincident. Det fanns sprintanteckningar, men säkerhetskraven var utspridda över user stories och chattmeddelanden.

Inget framstod som uppenbart vårdslöst. Allt såg ut som ett intensivt modernt IKT-projekt. Men för en finansiell entitet som omfattas av DORA, en SaaS-leverantör som potentiellt omfattas av NIS2 och en personuppgiftsansvarig eller ett personuppgiftsbiträde enligt GDPR var frågan inte längre bara om säkerhet fanns. Frågan var om inbyggd säkerhet kunde styrkas.

Det är 2026 års problem. IKT-projekt bedöms inte längre enbart utifrån leveranshastighet, kostnadskontroll och teknisk kvalitet. De bedöms utifrån styrnings- och revisionsunderlag: riskbedömningar, designbeslut, leverantörsgranskning, underlag från säker utveckling, ändringsgodkännanden, integritetsbeslut, testresultat och ledningens tillsyn.

ISO/IEC 27001:2022 ger organisationer en praktisk ledningssystemstruktur för att lösa detta problem. Den hjälper informationssäkerhetschefer, regelefterlevnadsansvariga, projektsponsorer, dataskyddsombud, arkitekter, upphandlingsteam och revisorer att göra betydande IKT-projekt till försvarbara underlag för inbyggd säkerhet.

Varför IKT-projektstyrning nu är en fråga om regulatoriskt underlag

En molnmigrering, kundportal, betalningsplattform, CRM-implementering, byte av identitetsleverantör, analyspipeline, API-integration, SaaS-arbetsflöde, low-code-applikation eller övergång till hanterad tjänst kan var och en förändra organisationens riskprofil. År 2026 sker dessa förändringar under överlappande skyldigheter.

NIS2 gäller brett för väsentliga och viktiga entiteter inom sektorerna i bilaga I och bilaga II, inklusive digital infrastruktur, leverantörer av hanterade tjänster, leverantörer av hanterade säkerhetstjänster och digitala leverantörer. NIS2 Article 20 gör ledningsorgan ansvariga för att godkänna åtgärder för hantering av cybersäkerhetsrisker och övervaka genomförandet. NIS2 Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder för riskhantering, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker anskaffning, säker utveckling, sårbarhetshantering, effektivitetsbedömning, cyberhygien, kryptografi, åtkomstkontroll, tillgångshantering och säker kommunikation.

DORA gäller finansiella entiteter och fokuserar på digital operativ resiliens. DORA Article 5 lägger ansvaret för IKT-riskhantering på ledningsorganet. DORA Article 6 kräver ett välgrundat, heltäckande och väldokumenterat ramverk för IKT-riskhantering. DORA omfattar även IKT-relaterad incidentrapportering, testning av operativ resiliens, IKT-verksamhetskontinuitet, respons och återställning, delning av information om cyberhot, hantering av IKT-tredjepartsrisk, avtalsarrangemang och tillsyn över kritiska IKT-tredjepartsleverantörer.

GDPR lägger till ansvarsskyldigheten för personuppgifter. GDPR Article 25 kräver inbyggt dataskydd och dataskydd som standard. Personuppgiftsansvariga måste kunna visa efterlevnad av principer som laglighet, korrekthet, transparens, ändamålsbegränsning, uppgiftsminimering, lagringsminimering, riktighet, konfidentialitet och ansvarsskyldighet. När behandlingen sannolikt leder till hög risk kan en konsekvensbedömning avseende dataskydd enligt GDPR Article 35 också krävas.

Den gemensamma nämnaren är underlag. Tillsynsmyndigheter och revisorer frågar inte bara om en plattform var krypterad, patchad, skannad eller testad. De frågar om organisationen kan visa att säkerhet, integritet, leverantörsrisk och resiliens ingick i beslutsfattandet från början.

Det är därför ISO/IEC 27001:2022-baserad projektstyrning är så kraftfull. Den gör det möjligt för organisationen att hantera NIS2, DORA, GDPR, NIST CSF 2.0, avtalsförpliktelser och kundförsäkran genom en repeterbar ISMS-process i stället för flera frikopplade checklistor.

ISO 27001-ryggraden för projektstyrning

ISO/IEC 27001:2022 missförstås ofta som en certifieringsövning. För IKT-projekt är dess operativa värde bredare. Standarden ger en styrningsstruktur för verksamhetsförändring.

Klausulerna 4.1 till 4.4 kräver att organisationer förstår interna och externa frågor, intressenter, rättsliga, regulatoriska och avtalsmässiga krav, ISMS-omfattning, gränssnitt och beroenden. I projekttermer innebär detta att projektbeskrivningen bör identifiera berörda tjänster, kunder, leverantörer, regelverk, verksamhetsprocesser, personuppgifter, kritiska verksamheter och utlagda tjänster.

Klausulerna 5.1 till 5.3 kräver ledningens åtagande, policyanpassning, resurser, integrering i verksamhetsprocesser och tilldelade ansvar. Detta är viktigt eftersom både NIS2 och DORA placerar cybersäkerhet och IKT-risk under ledningsorganets ansvar. Ett projekt som förändrar en kritisk kundplattform kan inte förlita sig på en informell säkerhetskommentar i en chatttråd. Det behöver tydlig ansvarsskyldighet.

Klausulerna 6.1.1 till 6.1.3 kräver en repeterbar process för riskbedömning och riskbehandling, riskkriterier, riskägare, bedömning av konfidentialitet, riktighet och tillgänglighet, riskbehandlingsplaner, tillämpbarhetsförklaring och godkännande av kvarstående risk. Det är här projektrisk blir revisionsbevis.

Klausulerna 7.1 till 7.5 kräver resurser, kompetens, medvetenhet, kommunikation och styrning av dokumenterad information. Det är så projektposter blir tillförlitligt underlag i stället för utspridda artefakter.

Klausul 8.1 kräver operativ planering och styrning, dokumenterad information som visar att processer har genomförts som planerat, styrning av planerade ändringar, granskning av oavsiktliga ändringar, riskreducering av negativa effekter och styrning av externt tillhandahållna processer, produkter eller tjänster som är relevanta för ISMS. Klausulerna 8.2 och 8.3 kräver riskbedömningar och riskbehandling avseende informationssäkerhet vid planerade intervall eller när betydande förändringar sker.

Bilaga A kopplar därefter denna ledningscykel till praktiska kontroller. För inbyggd säkerhet i IKT-projekt är tre ISO/IEC 27001:2022-kontroller i bilaga A centrala:

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap behandlar informationssäkerhet i projektledning som en styrningsfråga för alla typer av projekt, inte bara programvaruutveckling:

”Alla projekt – en migrering av ett marknadssystem, en omlokalisering av lokaler, en omdesign av en verksamhetsprocess, en HR-plattform för introduktion eller till och med en fusion eller ett förvärv – kan påverka informationens konfidentialitet, riktighet eller tillgänglighet. När det sker måste säkerhet ha en plats vid bordet.”

Samma avsnitt fångar den centrala lärdomen för genomförande:

”Målet med denna kontroll är inte att tynga ned projekt med byråkrati. Det är att säkerställa att säkerhet behandlas som en designförutsättning, inte som en testfas.”

Den distinktionen skiljer efterlevnadsteater från försvarbar inbyggd säkerhet.

Hur inbyggd säkerhet ser ut i ett IKT-projekt

Inbyggd säkerhet börjar före den första sprinten, upphandlingsbegäran, arkitekturdiagrammet eller migreringsrunbooken. Den ställer en enkel fråga: vad kan detta projekt förändra i riskbilden?

En praktisk modell för projektstyrning använder sju underlagsgrindar.

Poängen är inte byråkrati. Poängen är att göra säkerhet synlig där projektbeslut faktiskt fattas.

Clarysec Enterprise Informationssäkerhetspolicy uttrycker detta direkt:

”Säkerhetsstyrning ska integreras med företagsstyrning, projektledning, upphandling och rättsliga tillsynsfunktioner för att säkerställa att informationssäkerhet inte isoleras utan är inbyggd i hela verksamhetens beslutsfattande.”

Från avsnittet ”Styrningskrav”, policyklausul 5.5.

Den gör också projektlivscykler till en fråga för genomförande:

”Projektlivscykler (t.ex. säker utveckling, hotmodellering)”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.3.1.1.

Och den anger den revisionsprincip som många organisationer upptäcker för sent:

”Alla införda kontroller ska vara möjliga att granska, stödjas av dokumenterade rutiner och bevarat underlag som visar hur de har fungerat.”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.6.1.

Med andra ord kommer säkerhetsarbete som inte styrs, bevaras och mappas ofta att underkännas vid revision, även om de tekniska teamen har fattat rimliga beslut.

Från hotmodellering till underlag: ett praktiskt fintech-exempel

Tänk dig ett projekt för att lansera en ny EU-kundportal för kundintroduktion hos ett fintechbolag. Portalen samlar in identitetshandlingar, utför biometrisk verifiering via en tredje part, lagrar introduktionsstatus, integrerar med CRM, utlöser kundaviseringar och matar riskpoängsättning.

Ett arbetssätt med inbyggd säkerhet bygger upp underlaget i takt med att projektet fortskrider.

Först öppnas en post för projektsäkerhetsklassificering. Identifiera om projektet påverkar kritiska eller viktiga funktioner, personuppgifter, särskilda kategorier av personuppgifter, autentisering, kundvänd tillgänglighet, outsourcade IKT-tjänster, reglerade rapporteringsprocesser eller kundkommunikation. Enligt GDPR är biometriska uppgifter som används för unik identifiering en särskild kategori av personuppgifter, om inte ett specifikt undantag är tillämpligt. Det höjer omedelbart nivån på den rättsliga analys och de skyddsåtgärder som krävs.

Därefter skapas en projektriskbedömning. Clarysec SME Risk Management Policy gör riskhantering till en del av planeringen, inte till en kvartalsvis kalkylbladsövning:

”1.2 Den säkerställer att riskhantering är en aktiv del av planering, projektgenomförande, leverantörsval och incidenthantering, i linje med ISO 27001, ISO 31000 och tillämpliga regulatoriska krav.”

Från avsnittet ”Syfte”, policyklausul 1.2.

För enterprise-miljöer definierar Clarysec Enterprise Risk Management Policy omfattningen på strategisk, operativ, projekt- och teknisk nivå:

”Den omfattar informationssäkerhetsrisker på strategisk, operativ, projekt- och teknisk nivå och är obligatorisk för all personal, uppdragstagare och tjänsteleverantörer som deltar i aktiviteter inom ledningssystemet för informationssäkerhet.”

Från avsnittet ”Omfattning”, policyklausul 2.3.

För det tredje genomförs en hotmodell innan utvecklingen börjar. Enterprise Secure Development Policy är uttrycklig:

”Alla nya applikationer och större ändringar måste genomgå säkerhetsarkitekturgranskning och hotmodellering innan utvecklingen börjar.”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.1.1.

För introduktionsportalen bör hotmodellen omfatta exponerade gränssnitt, identitetsflöden, privilegiegränser, missbruksfall för API:er, webhook-förfalskning, återspelningsattacker, komprometterade autentiseringsuppgifter, vägar för dataläckage, beroenderisk, loggningskrav, antaganden om säkerhetskopiering, återställningskrav och leverantörens felmoder.

För det fjärde uppdateras integritetsunderlaget. SME Data Protection and Privacy Policy sätter baslinjen:

”5.3.1. Inbyggt dataskydd och dataskydd som standard måste tillämpas i alla nya system och tjänster”

Från avsnittet ”Styrningskrav”, policyklausul 5.3.1.

Projektposten bör innehålla ändamål, rättslig grund, roll som personuppgiftsansvarig eller personuppgiftsbiträde, beslut om uppgiftsminimering, lagringsregler, åtkomstroller, val av kryptering, överväganden om påverkan på registrerade, krav på transparens, villkor för personuppgiftsbiträden och aviseringsvägar vid personuppgiftsincident.

För det femte dokumenteras underlag från säker utveckling. SME Secure Development Policy ger en kortfattad underlagslista som fungerar för små och medelstora team:

”5.3 Den verkställande chefen (GM) måste föra register över: 5.3.1 Alla aktiva programvaruutvecklingsprojekt och ansvariga utvecklare eller leverantörer 5.3.2 Säkerhetschecklistor som används för varje projekt 5.3.3 Genomförda kodgranskningar och de personer som utförde dem 5.3.4 Testresultat före driftsättning 5.3.5 Tredjepartskomponenter och deras tillhörande licens- eller riskstatus”

Från avsnittet ”Styrningskrav”, policyklausul 5.3.

För det sjätte styrs driftsättningen som en ändring. SME Change Management Policy anger:

”1.1 Denna policy säkerställer att alla ändringar av IT-system, konfigurationer, verksamhetsapplikationer eller molntjänster planeras, riskbedöms, testas och godkänns före genomförande.”

Från avsnittet ”Syfte”, policyklausul 1.1.

För introduktionsportalen bör ändringsärendet innehålla berörda tjänster, riskbedömning, testresultat, rollback-plan, övervakningsplan, säkerhetsgodkännanden, integritetsgodkännande, leverantörsberedskap, uppdateringar av incidenteskalering och utlösare för kundkommunikation.

Slutligen mappas skyldigheterna. SME Legal and Regulatory Compliance Policy anger den operativa regeln:

”5.2.2 När ett regelverk gäller flera områden (t.ex. GDPR gäller lagring, säkerhet och integritet) måste detta tydligt mappas i register över regelefterlevnadskrav och utbildningsmaterial.”

Från avsnittet ”Styrningskrav”, policyklausul 5.2.2.

Detta register över regelefterlevnadskrav blir bryggan mellan ISO/IEC 27001:2022-kontroller, åtgärder enligt NIS2 Article 21, DORA:s IKT-riskkrav, GDPR-ansvarsskyldighet och åtaganden i kundavtal.

Mappa ett projektunderlagspaket mot NIS2, DORA, GDPR och NIST CSF 2.0

Den mest effektiva strategin för efterlevnad är inte att duplicera arbete. Den är att mappa ett starkt underlag mot flera skyldigheter.

Zenith Blueprint, i Risk Management-fasen, Step 14, rekommenderar denna typ av korsreferensarbete:

”För varje regelverk, om tillämpligt, kan du skapa en enkel mappningstabell (eventuellt som bilaga i en rapport) som listar regelverkets centrala säkerhetskrav och motsvarande kontroller/policyer i ditt ISMS.”

Den tillägger att detta är användbart eftersom det visar revisorer och bedömare ”att ni inte hanterar säkerhet i ett vakuum, utan är medvetna om den rättsliga kontexten.”

Clarysecs Zenith Controls: The Cross-Compliance Guide stödjer samma integrerade arbetssätt genom att mappa ISO/IEC 27001:2022-kontroller mot andra ramverk, revisionsförväntningar och efterlevnadsbehov. För IKT-projektstyrning beskriver den A.5.8, A.8.25 och A.8.32 som förebyggande kontroller som skyddar konfidentialitet, riktighet och tillgänglighet inom styrning, applikationssäkerhet, ekosystem, skydd samt system- och nätverkssäkerhet.

Tabellen ersätter inte rättslig analys. Den är en accelerator för styrning. Den säkerställer att informationssäkerhetschefen, dataskyddsombudet, projektsponsorn, upphandlingsansvarig, systemägaren och internrevisorn granskar samma underlag.

NIST CSF 2.0 passar också naturligt in i denna modell. Funktionen GOVERN hjälper organisationer att fastställa policyer, roller, riskaptit, tillsyn och rättslig eller avtalsmässig medvetenhet. Funktionerna IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER hjälper team att diskutera tillgångar, leverantörstjänster, åtkomstkontroll, datasäkerhet, plattformssäkerhet, säker programvaruutveckling, övervakning, incidentrespons och återställning på ett gemensamt operativt språk.

En enda ISO 27001-anpassad process med bilaga A.5.8 i centrum kan generera försvarbart underlag för alla dessa förväntningar.

Säker utveckling är bredare än att skriva kod

Många IKT-projekt misslyckas eftersom organisationen behandlar säker utveckling som något endast utvecklare gör. År 2026 omfattar säker utveckling även SaaS-konfiguration, arbetsflödesautomatisering, infrastructure as code, API-integrationer, identitetsregler, molnlandningszoner, analyspipelines, robotic process automation och verksamhetsapplikationer med low-code.

Zenith Blueprint, fasen Controls in Action, Step 20, behandlar ISO/IEC 27002:2022-kontroll 8.25 Secure Development Life Cycle:

”Denna kontroll gäller oavsett om ni skriver egna applikationer, konfigurerar plattformar som ERP- eller CRM-system, anpassar SaaS-arbetsflöden eller hanterar infrastructure-as-code-miljöer.”

Den förklarar också att säkerhetskrav måste ligga bredvid funktionella krav och att hotmodellering hjälper till att identifiera exponerade delar av systemet, riskfyllda användarroller och dataflöden som kräver högre skydd.

För ett modernt projekt kan underlag från säker utveckling omfatta:

• Säkerhetskrav kopplade till verksamhetskrav
• Hotmodell eller säkerhetsarkitekturgranskning
• Checklista för säker kodning eller säker konfiguration
• Poster från kodgranskning eller kollegial granskning
• Komponentförteckning och status för beroenderisk
• Beslut om hemlighetshantering
• Design för åtkomstkontroll och principen om minsta privilegium
• Krav på loggning och övervakning
• Resultat från sårbarhetsskanning och poster över avhjälpande åtgärder
• Säkerhetstestning i förproduktion
• Testning av säkerhetskopiering, återställning och resiliens där relevant
• Godkännande av driftsättning och underlag för rollback

Målet är inte att tvinga varje projekt genom samma tunga process. Målet är proportionalitet. En mindre intern arbetsflödesändring kräver inte samma underlag som en migrering av en central betalningsplattform. Men varje projekt bör klassificeras, riskbedömas och styras utifrån påverkan.

Ändringshantering skyddar projektet från sig självt

Det mest riskfyllda ögonblicket i många projekt är inte design eller kodning. Det är driftsättning.

Ett team kan genomföra hotmodellering, kodgranskning, leverantörsbedömning och integritetsgranskning, men ändå skapa ett avbrott eller en incident genom en forcerad produktionsändring. En debug-flagga är fortfarande aktiverad. En brandväggsregel är bredare än vad som godkänts. Ett migreringsskript kopierar personuppgifter till en icke-produktionsmiljö. En webhook-slutpunkt hos tredje part driftsätts utan autentisering. En loggningsändring registrerar nummer från identitetshandlingar. Ett säkerhetskopieringsjobb misslyckas tyst efter övergången.

Zenith Blueprint, fasen Controls in Action, Step 21, beskriver ISO/IEC 27002:2022-kontroll 8.32 Change Management rakt på sak:

”Förändring är oundviklig, men inom cybersäkerhet är okontrollerad förändring farlig.”

Den fortsätter:

”I grunden är effektiv ändringshantering ett repeterbart arbetsflöde. Det börjar med ett tydligt förslag som beskriver vad som ändras, varför, när och vilka potentiella risker som finns.”

En stark IKT-ändringspost bör besvara:

• Vilket system, vilken tjänst, vilket dataflöde, vilken leverantör eller vilken konfiguration ändras?
• Vilka risker identifierades och vem äger dem?
• Påverkar ändringen personuppgifter, kritiska tjänster, autentisering, loggning, säkerhetskopior eller incidentrespons?
• Vilka säkerhets-, integritets-, resiliens- och leverantörskontroller utfördes?
• Vilka tester slutfördes före driftsättning?
• Vilken övervakning ska bekräfta förväntat beteende?
• Vilken rollback- eller återställningsplan finns?
• Vem godkände kvarstående risk?
• Vilket underlag ska bevaras?

För DORA stödjer detta dokumenterad IKT-riskhantering, resiliens, kontinuitet, incidentklassificering och erfarenhetsåterföring. För NIS2 stödjer det riskhanteringsåtgärder, säker utveckling, incidentförebyggande och kontinuitet. För GDPR hjälper det till att visa att ändringar som påverkar personuppgifter granskades mot principerna om ändamål, minimering, lagring, åtkomst och säkerhet.

Leverantörs- och molnbeslut måste ingå i projektdesignen

I moderna IKT-projekt är det mest riskfyllda designbeslutet ofta att ”köpa” i stället för att ”bygga”. Molntjänster, API-leverantörer, plattformar för identitetsverifiering, betalningsförmedlare, analysleverantörer, leverantörer av hanterade tjänster och leverantörer av hanterade säkerhetstjänster blir en del av riskytan.

NIS2 omfattar uttryckligen säkerhet i leveranskedjan, sårbarheter hos direkta leverantörer och tjänsteleverantörer, leverantörers cybersäkerhetspraxis, rutiner för säker utveckling och resultat från samordnade riskbedömningar av leveranskedjan. DORA går djupare för finansiella entiteter. Förordningen kräver hantering av IKT-tredjepartsrisk som en del av ramverket för IKT-riskhantering, fortsatt ansvar även när IKT-tjänster outsourcas, informationsregister, bedömningar före avtal, analys av koncentrationsrisk, avtalskontroller, revisions- och inspektionsrätt, uppsägningsutlösare och testade exitstrategier för kritiska eller viktiga funktioner.

För introduktionsportalen kan leverantören av biometrisk verifiering inte godkännas enbart för att upphandling gillar priset och API-dokumentationen är bra. Projektet behöver underlag för leverantörsgranskning, behandlingsroll, datalagringsplats, underleverantörer, tillgänglighetsåtaganden, incidentstöd, revisionsrätt, avslutsstöd, genomförbar exit och övervakningsskyldigheter.

I en mogen underlagsmodell ingår leverantörs- och molnbeslut i projektets underlagspaket, inte i en frikopplad leverantörsmapp. När revisorn frågar varför en tredje part accepterades bör svaret omfatta verksamhetsbehov, riskbedömning, avtalsmässiga skyddsåtgärder, dataskyddsgranskning, resilienspåverkan och löpande övervakning.

Hur revisorer granskar underlag för inbyggd säkerhet

Olika revisorer närmar sig samma IKT-projekt från olika perspektiv. En certifieringsrevisor, internrevisor, DORA-granskare, behörig myndighet enligt NIS2, integritetsrevisor, NIST-orienterad bedömare eller COBIT-inriktad revisor kan begära liknande underlag men tolka det olika.

Revisorer vill inte ha ett snyggt presentationsmaterial från projektet. De vill ha spårbarhet. De vill se att krav ledde till risker, risker ledde till kontroller, kontroller ledde till genomförandeunderlag och genomförandet ledde till granskning.

Det är därför Zenith Controls är användbart vid förberedelse inför revision. Det hjälper team att förklara varför bilaga A.5.8, A.8.25 och A.8.32 är förebyggande kontroller som skyddar konfidentialitet, riktighet och tillgänglighet innan förutsägbara fel når produktion.

Clarysecs minsta projektunderlagspaket

Ett starkt underlagspaket för inbyggd säkerhet behöver inte vara enormt. Det behöver vara konsekvent, proportionerligt och mappat.

För ett IKT-projekt med medelhög risk rekommenderar Clarysec vanligtvis följande minsta paket:

1. Post för projektsäkerhetsklassificering
2. Notering om regulatorisk tillämplighet som omfattar NIS2, DORA där relevant, GDPR och avtalsförpliktelser
3. Karta över dataflöden och påverkan på tillgångar
4. Projektriskbedömning och riskbehandlingsplan
5. Hotmodell eller säkerhetsarkitekturgranskning
6. Bedömning av leverantör och molntjänst där tillämpligt
7. Checklista för säker utveckling eller konfiguration
8. Säkerhetstestresultat och underlag för avhjälpande åtgärder
9. Ändringsgodkännande med rollback- och övervakningsplan
10. Post för inbyggt dataskydd, inklusive rättslig grund och lagring när personuppgifter berörs
11. Uppdateringar av incidentrespons och övervakning
12. Efterimplementeringsgranskning och erfarenhetsåterföring
13. Mappning i register över regelefterlevnadskrav till kontroller och skyldigheter

Zenith Blueprint ger logiken i färdplanen. Step 22 för in informationssäkerhet i alla projektsteg. Step 20 bygger in säker utveckling i planering, design, kod, testning och driftsättning. Step 21 gör ändringshantering strukturerad, spårbar och möjlig att granska. Step 14 rekommenderar korsreferenser mot GDPR, NIS2, DORA och andra skyldigheter så att efterlevnadskrav inte faller mellan stolarna.

Policyerna ger operativa regler. Informationssäkerhetspolicy integrerar säkerhet med projektledning, upphandling och rättslig tillsyn. Riskhanteringspolicy gör projektrisker till en del av ISMS-aktiviteter. Policy för säker utveckling kräver hotmodellering. Ändringshanteringspolicy kräver planerade, riskbedömda, testade och godkända ändringar. Policy för dataskydd och integritet kräver inbyggt dataskydd och dataskydd som standard. Policy för rättslig och regulatorisk efterlevnad kräver att regelverk som berör flera områden mappas i registret över regelefterlevnadskrav.

Tillsammans gör dessa verktyg inbyggd säkerhet till en granskningsbar operativ modell i stället för en ambition.

Vanliga felmönster i IKT-projekt

Felen är oftast förutsägbara.

Det första är att säkerhet involveras för sent. Säkerhetsgranskningar sker efter att arkitekturen är fastställd, avtalen är signerade och leveransdatum är offentliga. Då blir säkerhet ett hinder i stället för en designförutsättning.

Det andra är fragmenterat underlag. Projektet har testresultat i ett verktyg, leverantörsgranskning i ett annat, integritetskommentarer i e-post, riskacceptans i en mötesinspelning och ändringsgodkännande i ett ärende. Ingen samlad tråd styrker styrningen.

Det tredje är blindfläckar kring leverantörer. Projektet är beroende av en molntjänst eller API-leverantör, men ingen kontrollerar underleverantörer, datalagringsplats, revisionsrätt, incidentstöd, exitplaner eller koncentrationsrisk.

Det fjärde är ändamålsglidning för integritet. Ett system som byggts för ett ändamål börjar stödja analys, AI-experiment, marknadsexporter eller operativ övervakning utan att rättslig grund, transparens, minimering eller lagring omprövas.

Det femte är ogranskad ändring. En produktionssättning godkänns för funktionalitet men bedöms inte avseende åtkomst, loggning, kryptering, säkerhetskopiering, resiliens, personuppgifter eller rapporteringspåverkan.

Det sjätte är svag ledningstillsyn. Projektrisker med hög påverkan accepteras på för låg nivå, utan underlag som visar att ansvarig riskägare förstod de regulatoriska konsekvenserna.

Dessa problem löses inte genom att köpa ytterligare en skanner. De löses genom att integrera säkerhetsstyrning i hur projekt föreslås, designas, upphandlas, byggs, testas, ändras och granskas.

Vad informationssäkerhetschefen bör ta med sig inför 2026

Inbyggd säkerhet i IKT-projekt är nu en fråga för styrelse, revision och tillsyn. NIS2 gör hantering av cybersäkerhetsrisker till en ledningsfråga. DORA gör IKT-risk, resiliensprovning, incidenthantering och tillsyn över tredje part till en strukturerad skyldighet för finanssektorn. GDPR kräver ansvarsskyldighet för behandling av personuppgifter och lämplig säkerhet. ISO/IEC 27001:2022 ger ledningssystemstrukturen som gör dessa skyldigheter operativa.

För informationssäkerhetschefer är möjligheten att sluta behöva kämpa med projektteam i slutet av leveransen. Placera säkerhet i initiering, krav, design, leverantörsval, utveckling, testning, ändringsgodkännande och efterimplementeringsgranskning.

För regelefterlevnadsansvariga är möjligheten att ersätta utspritt underlag med ett mappat projektunderlagspaket.

För revisorer är möjligheten att granska projektets livscykel, inte bara det färdiga systemet.

För verksamhetsägare är möjligheten snabbare och säkrare leverans. Inbyggd säkerhet minskar omarbete, förebygger överraskningar i efterlevnad, förbättrar leverantörsbeslut och ger ledningen en försvarbar riskberättelse.

Om era IKT-projekt rör sig snabbare än er underlagsmodell, börja med ett pilotprojekt. Använd Clarysecs Zenith Blueprint för att definiera projektsäkerhetsgrindar, tillämpa Clarysecs policyer för riskhantering, säker utveckling, ändringshantering och integritet, och använd Zenith Controls för att mappa ISO/IEC 27001:2022-baserad projektstyrning mot NIS2, DORA, GDPR och NIST CSF 2.0.

Clarysec kan hjälpa er att bygga ett återanvändbart projektunderlagspaket för inbyggd säkerhet, anpassa det till ert ISMS och förbereda det för internrevision, certifieringsrevision, DORA-beredskap, NIS2-styrning och GDPR-ansvarsskyldighet.

Börja med ert nästa betydande IKT-projekt. Om det förändrar system, leverantörer, data, åtkomst, resiliens eller kundförtroende förtjänar det inbyggd säkerhet från dag ett.