Mange teams kæmper med at få styr på krav, når både produkter og organisationen er omfattet af flere regelsæt, kundekrav og sikkerhedsstandarder. Resultatet bliver ofte parallelle spor, dobbelt dokumentation og kontrolhuller, der først opdages ved audit eller efter en hændelse.
I denne artikel får du en praktisk sammenligning af kravtyper (produktkrav vs organisationskrav), hvordan de overlapper, og hvordan du kan mappe dem til ISO 27001-kontroller. Du får også en konkret tilgang til at etablere et “one program”-setup, hvor governance, risikostyring og dokumentation hænger sammen på tværs.
Hvad menes der med produktkrav og organisationskrav, og hvorfor betyder det noget?
En enkel definition: Produktkrav er krav, der knytter sig til et specifikt produkt eller en tjeneste (fx en platform, et IoT-produkt eller en app), mens organisationskrav retter sig mod virksomheden som helhed (fx politikker, roller, processer og styring). Det betyder noget, fordi kravene typisk har forskellige ejere, bevismateriale og levetid, men alligevel skal kunne fungere sammen i drift.
Nøglen er at forstå, at produktkrav ofte er tekniske og implementeringsnære, mens organisationskrav er styrings- og procesnære. Begge typer ender dog med at skulle kunne dokumenteres, testes og forbedres løbende.
Sådan adskiller kravtyperne sig i praksis
Produktkrav: “Hvad er bygget ind i løsningen?”
Produktkrav handler typisk om sikkerhedsegenskaber, konfigurationer, udviklingsprocesser og løbende vedligehold. Eksempler er sårbarhedshåndtering, sikker standardkonfiguration, sikker opdateringsmekanisme, logging, kryptering og adgangskontrol i selve produktet. Beviset kan være kode, pipelines, testresultater, arkitekturdiagrammer og driftsovervågning.
Organisationskrav: “Hvordan styres sikkerheden på tværs?”
Organisationskrav handler om governance: risikostyring, politikker, uddannelse, leverandørstyring, incident response, interne audits og ledelsens opfølgning. Beviset er ofte beslutningsspor, referater, politikker, risikovurderinger, træningslog og leverandøraftaler. Her er fokus på konsistens og gentagelighed.
Mini-konklusion: Når du ved, om et krav er produkt- eller organisationsdrevet, bliver det lettere at placere ejerskab og skabe det rigtige auditspor.
Hvor overlapper kravene, og hvor opstår de typiske gråzoner?
Overlap opstår, når et organisationskrav kræver, at produktet gør noget konkret, eller når et produktkrav kun kan opfyldes gennem styring. Logging er et klassisk eksempel: Produktet skal generere logs korrekt, men organisationen skal definere logpolitik, retention, adgang og review. Det samme gælder sårbarhedshåndtering: produktteamet skal rette og udgive patches, men organisationen skal definere prioritetsregler, SLA’er og acceptkriterier.
En praktisk måde at se overlap på er at skelne mellem: (1) styring af krav, (2) implementering, (3) verifikation, og (4) driftsovervågning. I gråzoner kan ansvar nemt blive delt uden at være tydeligt, og så ender man med enten dobbeltarbejde eller ingen ejer.
- Access management: politik og roller (organisation) + RBAC/SSO i produktet (produkt)
- Incident response: playbooks (organisation) + alarmer/telemetri (produkt)
- Backup og recovery: strategi og RTO/RPO (organisation) + teknisk restore-test (produkt)
- Kryptering: krav til nøgler og governance (organisation) + implementering i databaser og trafik (produkt)
- Leverandører: due diligence (organisation) + dependency management i build (produkt)
- Change management: godkendelser (organisation) + CI/CD kontroller (produkt)
Faldgrube: At behandle overlap som “nogens ansvar” uden at definere en fælles kontrolbeskrivelse. Løsningen er at skrive kontroller som end-to-end krav med både proces og teknisk evidens.
Mapping til ISO 27001: Tænk i kontroller, ikke i dokumenter
ISO 27001 giver et kontrolleret sprog til at samle mange krav. Pointen er ikke at kopiere standarden ind i en wiki, men at bruge den som struktur til mapping og evidens. Start med at vælge et kontrol-katalog (typisk Annex A fra ISO 27001:2022), og map produkt- og organisationskrav til de samme kontroller, så du får ét “kontrolbibliotek”.
Eksempler på mapping, der ofte giver mening
Produktnære emner lander ofte i kontroller om secure development, tekniske beskyttelser og logging, mens organisationskrav lander i governance, risikostyring og leverandørstyring. Men mapping er sjældent 1:1; ofte er der én kontrol med flere evidenskilder.
- Policy og governance: informationssikkerhedspolitik, roller, ledelsesopfølgning
- Risk management: metode, risikoregister, behandling og accept
- Asset management: inventory, dataklassifikation, ejerskab
- Identity and access: provisioning, MFA, privilegerede konti, review
- Logging og monitoring: logkilder, alarmer, reviewfrekvens, retention
- Secure development: krav, code review, SAST/DAST, release gates
Mini-konklusion: Mapping virker bedst, når du beskriver kontroller som adfærd og bevis, ikke som en bunke dokumenter.
“One program”-setup: Én kontrolmodel, flere compliance-drivere
Et “one program” betyder, at du har én samlet sikkerheds- og compliance-ramme, som kan dække flere lovkrav og standarder. I praksis bygger du et fælles kontrolbibliotek, et fælles risikoregister og en fælles evidensmodel, mens du stadig kan rapportere særskilt til forskellige interessenter. Hvis du fx arbejder med både produkt- og organisationskrav, kan du holde dem sammen ved at lade ISO 27001-kontroller være “rygraden” og tilføje tags for relevante regulatoriske drivere og kundekrav.
Det er netop her, at sammenligninger mellem regelsæt bliver relevante, fx når teams prøver at forstå forskellen på produktrettede og organisatoriske forventninger i CRA vs NIS2 uden at miste overblikket over deres samlede kontrolmiljø.
Designprincipper for et robust program
Princip 1: Én kontrolbeskrivelse per kontrol, men flere evidensartefakter. Princip 2: Samme risikomodel på tværs, så produkt- og organisationsrisici kan prioriteres sammen. Princip 3: Standardiseret evidens, så audits bliver en verifikation af drift, ikke et jagtprojekt.
Mini-konklusion: Når kontrollerne er fælles, kan du skifte “rapporteringsoverbygning” uden at genopfinde programmet.
Sådan bygger du et kontrolbibliotek, der dækker både produkt og organisation
Kontrolbiblioteket er din centrale oversættelsesmaskine fra krav til handling. Start med at definere en skabelon for hver kontrol: formål, scope, ansvarlig, frekvens, evidens og tests. Tilføj derefter felter til mapping, fx ISO-kontrolreference, interne politikreferencer og “driver-tags” (lov/kontrakt/kunde). Dermed kan du filtrere kontroller efter behov, uden at ændre indholdet.
En enkel praksis er at skrive kontroller i et “krav-sprog”, der kan forstås af både teknik og governance. Undgå vage formuleringer som “sikre passende beskyttelse”. Skriv i stedet: “Alle produktionssystemer sender sikkerhedslogs til centralt system, og alarmer for kritiske hændelser triageres inden for X timer”.
- Ejer: navngiven rolle (ikke et teamnavn)
- Scope: hvilke systemer/produkter og hvilke datatyper
- Procedure: hvad gør man, og hvornår
- Evidens: logs, tickets, rapporter, konfigurationer
- Test: hvordan du kontrollerer, at det virker
Faldgrube: At gøre kontrolbiblioteket til et skrivebordsprodukt. Løsningen er at koble kontroller til konkrete systemer og automatiseret evidens, hvor det er muligt.
Risikostyring som bro mellem produkt og organisation
Risikostyring er ofte det sted, hvor produkt og organisation kan mødes uden diskussion om ejerskab. Organisatorisk risikostyring sætter rammerne, men produktteams leverer de tekniske behandlinger. En god praksis er at have ét fælles risikoregister med tydelig “risk owner”, men med separate felter for teknisk kontrol, proceskontrol og residual risiko.
Hvordan ser en praktisk risikocadence ud?
Kør en fast rytme: månedlig review af åbne produkt-sårbarheder og top-risici, kvartalsvis ledelsesrapportering, og ad hoc vurderinger ved større releases. Brug samme skala for sandsynlighed og konsekvens, så du kan prioritere på tværs af områder. Det vigtigste er at knytte risici til kontroller: hvis en risiko behandles, skal det kunne ses som en forbedring i kontrolmiljøet.
Mini-konklusion: Ét risikoregister reducerer “compliance-teater”, fordi prioritering bliver transparent og sporbar.
Hvad koster det, og hvordan estimerer du indsatsen realistisk?
Omkostningen afhænger primært af modenhed, systemlandskab og hvor meget du kan automatisere evidens. Mange undervurderer især tid til afklaring af scope, dataflows og ansvar. Et “one program” kan virke større i opstarten, men reducerer typisk driftsomkostninger, fordi du slipper for parallelle audits og dobbeltarbejde.
Som tommelfingerregel kan du estimere i tre lag: (1) etablering af governance og kontrolbibliotek, (2) implementering af manglende kontroller i produkter og processer, og (3) drift, test og forbedring. Hvis du allerede har ISO-lignende styring, er layer 2 ofte den store post; hvis du har stærk engineering men svag governance, er layer 1 typisk den dyre.
Bedste praksis: Start med en gap-analyse mod et minimumssæt kontroller, og planlæg iterativt, så du kan vise fremdrift hver 4–6 uge.
Typiske fejl og hvordan du undgår dem i et “one program”-setup
De mest almindelige fejl handler sjældent om manglende vilje, men om forkert struktur. En fejl er at mappe krav direkte til teams i stedet for til kontroller, hvilket gør programmet skrøbeligt ved omorganisering. En anden er at samle evidens “ved behov” i stedet for at designe løbende evidensopsamling.
Konkrete modtræk, der virker
Hold det enkelt, men stramt: Definér kontrol-ejere, brug standardiserede evidenspakker, og sæt minimumsfrekvenser for test. Sørg for, at produktkrav er indbygget i udviklingsflowet (Definition of Done, release gates), så compliance bliver en del af leverancen frem for en separat aktivitet. Brug pragmatiske KPI’er: patch-tider, adgangsreviews gennemført, restore-tests bestået, og antal kritiske findings over tid.
Faldgrube: At tro, at et værktøj løser mapping. Værktøjer kan hjælpe, men den afgørende værdi ligger i klare kontroltekster og realistiske testmetoder.
Mini-konklusion: Når du standardiserer kontroller og evidens, bliver compliance et driftsdisciplin frem for et auditprojekt.
Fra teori til handling: En 30-dages plan, der skaber momentum
Hvis du vil i gang uden at drukne i detaljer, så planlæg den første måned som et design- og pilotforløb. Målet er at få et fungerende kontrolbibliotek, et lille sæt prioriterede kontroller i drift og en enkel rapportering.
- Uge 1: Fastlæg scope, kritiske produkter, data og interessenter; vælg ISO 27001 som kontrolrygrad
- Uge 2: Byg kontrolbibliotekets skabelon; skriv 15–25 kernekontroller og udpeg ejere
- Uge 3: Map topkrav til kontroller; definér evidens og test for hver kontrol; pilotér på ét produkt
- Uge 4: Kør første kontroltest; luk de største gaps; etabler månedlig cadance og ledelsesrapport
Nøglen er at få et lille, men ægte program i drift hurtigt, og derefter udvide. Når du kan demonstrere, at kontroller testes, og at findings lukkes systematisk, har du fundamentet for at håndtere både produkt- og organisationskrav i én samlet struktur.