Artikler, ud fra vores egne data

CRA artikel 13 for en softwarefabrikant: de femogtyve stykker i rækkefølge, hvilke er jeres, hvilke er Kommissionens, og en tjekliste efter rolle

Artikel 13 i Cyber Resilience Act er fabrikantens artikel: femogtyve stykker fra de væsentlige krav i stk. 1 til Kommissionens beføjelser i stk. 25. Enogtyve af dem er pligter, en softwarefabrikant bærer, fra produktrisikovurderingen og omhuen med komponenter til supportperioden, det centrale kontaktpunkt, den tekniske dokumentation opbevaret i ti år, de korrigerende foranstaltninger og hvad der skal gøres før en indstilling af driften; to er muligheder, to tilhører Kommissionen og myndighederne. Artikel 14 tilføjer anmeldelsesfristerne, artikel 19 og 20 importørens og distributørens pligter, artikel 24 forvalterens, og bilag I de krav, produktet skal opfylde. En gratis side viser hver række, der binder jeres rolle, med Tidendes ord på seks sprog, med en status pr. række.

13. september 2026

Dataforordningen for en SaaS-virksomhed: skiftepligterne siden den 12. september 2025, de ni kontraktvilkår, afskaffelsen af skiftegebyrer, og hvad en dataindehaver skylder

Forordning (EU) 2023/2854 har fundet anvendelse siden den 12. september 2025, og en virksomhed, der sælger hostet software, er efter den en udbyder af en databehandlingstjeneste, uanset størrelse. Kapitel VI får den til at fjerne enhver hindring for, at en kunde skifter udbyder eller flytter til egen infrastruktur: en skriftlig kontrakt med de ni vilkår i artikel 25, stk. 2, en opsigelsesfrist på højst to måneder, en overgangsperiode på højst 30 kalenderdage, en hentningsperiode på mindst 30 kalenderdage, sletning derefter, et onlineregister over de eksporterbare data, åbne grænseflader uden gebyr, en angivelse på webstedet af den jurisdiktion, infrastrukturen er underlagt, og skiftegebyrer, der er omkostningsbaserede nu og forbudte fra den 12. januar 2027. En virksomhed, hvis produkt er et forbundet produkt eller en relateret tjeneste, er også dataindehaver efter kapitel II, med adgang gennem design for produkter bragt i omsætning efter den 12. september 2026. Forordningens 96 rækker, der binder hver rolle, er et datasæt på seks sprog.

13. september 2026

ISO 27001-informationssikkerhedspolitikken: hvad punkt 5.2 kræver, de ni afsnit i en kort politik, de fejl en auditor påpeger, og en side, der skriver den

Punkt 5.2 beder topledelsen om én politik, der passer til virksomhedens formål, bærer sikkerhedsmålene eller rammen for at sætte dem, forpligter sig til de gældende krav og til at forbedre systemet, og er dokumenteret, kommunikeret og tilgængelig for de parter, der har brug for den. Det er syv ting, og ingen af dem er et sideantal. En god politik for en softwarevirksomhed fylder to sider i ni afsnit: formål, omfang, hvorfor sikkerhed betyder noget her, forpligtelser, mål, roller, emnepolitikkerne under den, overholdelse, og kommunikation og gennemgang. De fejl, en auditor påpeger, er skabelonen med en anden virksomheds navn, de tredive sider, ingen har læst, den manglende godkendelse, mål ingen kan måle, og en politik ingen ny medarbejder har set. En gratis side skriver politikken ud fra ti svar på seks sprog.

13. september 2026

ISO 27001-ledelsens evaluering: de syv input i punkt 9.3 som dagsorden, de fire tendenser, de to output, hvad referatet skal vise, og en side, der skriver det

Punkt 9.3 lader topledelsen evaluere ledelsessystemet med planlagte intervaller mod syv input: handlingerne fra den forrige evaluering, ændringer i de eksterne og interne forhold, ændringer i det, interessenterne har brug for og forventer, præstationsfeedbacken med dens fire tendenser (afvigelser og korrigerende handlinger, overvågning og måling, auditresultater, målene), feedback fra interessenter, risikovurderingen og behandlingsplanen og forbedringsmulighederne. Output er to: beslutninger om løbende forbedring og alle ændringer, systemet har brug for, opbevaret som dokumenteret information. Det referat, en auditor anerkender, viser hvert overvejet input og hver truffet beslutning, med en ejer og en dato på hver handling. En gratis side skriver referatet i punktets rækkefølge ud fra mødets fakta, tallene og det, der blev sagt.

13. september 2026

ISO 27001-registreringen af korrigerende handling: hvad punkt 10.2 kræver efter en afvigelse, de syv afsnit en auditor anerkender, de fejl der genåbner en konstatering, og en side der skriver den

Punkt 10.2 er det, der sker med en afvigelse, når den er fundet: korrigere den og håndtere det, den forårsagede, finde årsagen, spørge om det samme problem findes andre steder, handle så den ikke gentager sig, kontrollere at handlingen virkede, ændre ledelsessystemet dér, hvor årsagen lå, og opbevare afvigelsen, handlingerne og deres resultater som dokumenteret information. En registrering, en auditor anerkender, har syv afsnit i den rækkefølge, holder korrektionen adskilt fra den korrigerende handling og forbliver åben, indtil kontrollen viser, at handlingen virkede. En gratis side skriver registreringen ud fra konstateringen, korrektionen, årsagen, handlingen med ejer og dato og effektivitetskontrollen.

13. september 2026

ISO 27001-risikovurderingen for en softwarevirksomhed: hvad punkt 6.1.2 kræver, en fempunktsmetode, startrisiciene og en side, der skriver registret og behandlingsplanen

Punkt 6.1.2 foreskriver ikke en metode; det foreskriver, hvad metoden skal frembringe: kriterier for at acceptere risici og for at vurdere dem, en identifikation af informationssikkerhedsrisiciene, en analyse af deres konsekvenser og sandsynlighed, en evaluering mod kriterierne og gentagelige, sammenlignelige resultater. Punkt 6.1.3 kræver dernæst behandlingsmulighederne, foranstaltningerne, sammenligningen med anneks A, erklæringen om anvendelighed og planen. For en softwarevirksomhed er risiciene i vidt omfang kendt før den første workshop: kompromitterede loginoplysninger, en mistet bærbar, et nedbrud hos cloudleverandøren, en backup, der ikke kan gendannes, en fratrådt medarbejder med åben adgang, en sårbarhed leveret i egen kode. En fempunktsskala for sandsynlighed og konsekvens, produktet som niveau, en accepttærskel, behandlingsmuligheden og foranstaltningerne for hver risiko over den, og en gratis side, der skriver registret og planen på seks sprog.

13. september 2026

ISO 42001-AI-politikken for en softwarevirksomhed: hvad punkt 5.2 kræver, de ti afsnit, de pligter i AI-forordningen den nævner, de fejl en auditor påpeger, og en side, der skriver den

Punkt 5.2 i ISO/IEC 42001 beder topledelsen om en AI-politik, der passer til det, virksomheden bruger AI til, giver rammen for AI-målene, forpligter sig til de gældende krav og til at forbedre systemet, er dokumenteret, kommunikeret og tilgængelig, og siger, hvordan den står ved siden af de andre politikker. Tre foranstaltninger i anneks A, A.2.2, A.2.3 og A.2.4, kræver politikken, dens afstemning med de andre politikker og dens gennemgang. En kort AI-politik for en softwarevirksomhed fylder ti afsnit: formål, omfang, holdning, de udelukkede anvendelser, ansvar, mål, de gældende krav, de andre politikker, kommunikation og gennemgang. Afsnittet om kravene er dér, hvor AI-forordningen træder ind: kompetencepligten i artikel 4, gennemsigtighedspligterne i artikel 50, hvor virksomheden genererer indhold, og en registreret højrisikoafgørelse pr. system, som politikken selv aldrig påstår. En gratis side skriver politikken ud fra elleve svar på seks sprog.

13. september 2026

ISO 42001-konsekvensvurderingen af et AI-system: hvad punkt 6.1.4 kræver, de tre niveauer af konsekvenser, hvor den møder AI-forordningen, de fejl en auditor påpeger, og en side der skriver den

Punkt 6.1.4 i ISO/IEC 42001 lader virksomheden vurdere, hvad hvert AI-system kan gøre ved de enkeltpersoner og grupper, det berører, og ved samfundet, opbevare resultatet som dokumenteret information og handle på det gennem systemets livscyklus; punkt 8.4 udfører processen, og fire foranstaltninger i bilag A kræver processen, opbevaringen, skaden på enkeltpersoner og grupper og skaden ud over brugerne. Det er den registrering, standarden har, og ISO 27001 ikke har. En vurdering, en auditor anerkender, nævner formålet og det forudsigelige misbrug, menneskene, konsekvenserne på de tre niveauer med hver en sandsynlighed og en alvor, fordelene, foranstaltningerne, et resultat og en dato for genvurdering; efter AI-forordningen er den input til konsekvensanalysen vedrørende grundlæggende rettigheder efter artikel 27 og det sted, hvor virksomheden registrerer sin egen læsning af systemet. En gratis side skriver den for ét system.

13. september 2026

NIS2-hændelsesfristen for en softwarevirksomhed: den tidlige varsling efter 24 timer, underretningen efter 72 timer, den endelige rapport efter en måned, hvad der gør en hændelse væsentlig for en cloududbyder, og en side, der skriver de tre rapporter

Artikel 23, stk. 4, i NIS2 lader tre frister løbe fra det øjeblik, en væsentlig eller vigtig enhed får kendskab til en væsentlig hændelse: en tidlig varsling inden for 24 timer, en hændelsesunderretning inden for 72 og en endelig rapport inden for en måned efter den underretning, med en foreløbig rapport på anmodning og en fremskridtsrapport, hvor hændelsen stadig er i gang. For en udbyder af cloudcomputingtjenester siger gennemførelsesforordning (EU) 2024/2690, hvornår en hændelse er væsentlig: et direkte økonomisk tab på over 500 000 EUR eller 5 % af omsætningen, alt efter hvad der er lavest, en tjeneste, der er fuldstændig utilgængelig i mere end 30 minutter, en tilgængelighed, der er begrænset for mere end 5 % eller 1 million af dens brugere i Unionen i mere end en time, eller en formodet ondsindet kompromittering af data. Hvad hver rapport indeholder, hvilken CSIRT den går til, og en gratis side, der beregner fristerne og skriver alle tre på seks sprog.

13. september 2026

AI-færdigheder efter artikel 4 i AI-forordningen, som omskrevet den 27. juli 2026: hvad »træffe foranstaltninger« betyder, hvem den dækker, hvad den ikke kræver, og den registrering, der skal føres

Artikel 4 har gjaldt for enhver udbyder og idriftsætter af et AI-system siden den 2. februar 2025. Den digitale omnibus omskrev den: foranstaltninger til at støtte udviklingen af AI-færdigheder, under hensyntagen til folks viden og konteksten, og, med de ord forordningen nu bruger, ingen pligt til at garantere et specifikt niveau af AI-færdigheder hos nogen enkeltperson. Kommissionen skal offentliggøre praktiske eksempler og AI-udvalget fælles mål. Hvad artiklen beder om, hvorfor den ikke har sin egen bøde i artikel 99, hvordan ISO 42001's kompetence- og bevidsthedsklausuler frembringer registreringen, og et program på én side.

12. september 2026

AI-forordningen efter den digitale omnibus: de datoer, der ændrede sig den 27. juli 2026, og hvilke ISO 42001-foranstaltninger der leverer beviset for de tretten aspekter i artikel 17 og artikel 9 til 15

Forordning (EU) 2026/1744, undertegnet den 8. juli 2026, offentliggjort den 24. juli, i kraft den 27. juli, flyttede AI-forordningens højrisikodatoer til den 2. december 2027 for systemer i bilag III og den 2. august 2028 for systemer i bilag I, omskrev AI-færdigheder til en pligt til at træffe foranstaltninger og gjorde planen for overvågning efter omsætningen til en del af den tekniske dokumentation. Det meste, der ranker, giver stadig de gamle datoer. Datoerne som ændret, hvad der ellers ændrede sig for en udbyder, og vores kortlægning af de tretten aspekter i artikel 17's kvalitetsstyringssystem, artikel 9 til 15, 72 og 73 og operatørpligterne i artikel 4 og 26 til anneks A-foranstaltningerne i ISO/IEC 42001, med det, forordningen beder om, og standarden ikke leverer.

12. september 2026

AI-forordningen for en softwarevirksomhed: hvilken rolle I har, hvad der gælder for alle, hvad der kun gælder for en højrisikoudbyder, SMV-reglerne og de ændrede datoer

En softwarevirksomhed møder AI-forordningen i en af seks roller, og det meste af forordningen gælder kun for to af dem. Hvad der overhovedet tæller som et AI-system, hvorfor det at levere en leverandørs model under eget navn gør jer til udbyder, de tre pligter, enhver virksomhed har haft siden 2025 og 2026 (AI-færdigheder, forbuddene, gennemsigtighed), de to veje til højrisiko og hvad hver rolle så skylder fra den 2. december 2027, linjen for modeller til almen brug, de SMV- og små midcap-regler, den digitale omnibus udvidede, og én tabel over hvem der skylder hvad fra hvornår. Læst fra de to forordninger på CELLAR den 12. september 2026.

12. september 2026

Artikel 50 i AI-forordningen for en virksomhed, der leverer eller bruger generativ AI: de fire gennemsigtighedsforpligtelser, der har været gældende siden den 2. august 2026, overgangen til den 2. december 2026, praksiskodeksen og EU-ikonet

Artikel 50 er den forpligtelse i AI-forordningen, der når en virksomhed, uanset om dens system er højrisiko eller ej: fortælle folk, at de taler med en AI, mærke genereret indhold, så maskiner kan opdage det, oplyse om deepfakes og AI-skrevne tekster om spørgsmål af offentlig interesse, underrette personer, der udsættes for følelsesgenkendelse. Den har været gældende siden den 2. august 2026, den digitale omnibus lod den stå uændret og gav udbydere af generative systemer, der allerede er i omsætning, frist til den 2. december 2026 for mærkningspligten. De fire stykker i rækkefølge, hvem der er udbyder, og hvem der er idriftsætter for hvert, Kommissionens praksiskodeks af 10. juni 2026 med dens tolagsmærkning og dens AI-ikon, bøden og den registrering, et ISO 42001-system fører.

12. september 2026

De ni steder, hvor din bankkundes IKT-risikorammeværk rækker ind i dit produkt, RTS 2024/1774: slutdatoer for support, sårbarhedsrapporter og sporing af biblioteker, indstillinger den ikke må omgå, kildekode testet før produktion, navngivne konti til dine medarbejdere, og dine hændelser som dens alarmer

Delegeret forordning (EU) 2024/1774, i kraft siden den 15. juli 2024, fastsætter det IKT-risikostyringsrammeværk, hver finansiel enhed kører under DORA, og ni af dens artikler nævner tredjepartsudbyderen af IKT-tjenester. Læst fra leverandørens side: aktivfortegnelsen, der registrerer slutdatoerne for din support (artikel 4), sårbarhedsproceduren, der kontrollerer, at du håndterer og rapporterer sårbarheder, og sporer tredjepartsbibliotekerne i dit produkt (artikel 10), proceduren for data- og systemsikkerhed, der fordeler roller mellem dig og kunden og beder om foranstaltninger på din infrastruktur (artikel 11), krypterede forbindelser over tredjeparters netværk (artikel 13), kildekode fra udbydere analyseret og testet før produktion (artikel 16), en entydig konto til hver af dine medarbejdere med adgang (artikel 20), dine hændelsesunderretninger som en af dens detektionskilder (artikel 23), kontinuitetstest, der omfatter din tjeneste og din insolvens (artikel 25 og 26). Med det, et ISO 27001-system allerede besvarer.

12. september 2026

De ti foranstaltninger i NIS2 artikel 21(2) som tjekliste: hvert litra citeret, forordningens afsnit bag det, og de ISO 27001-foranstaltninger, der allerede frembringer dem

Artikel 21(2) opregner ti foranstaltninger, enhver væsentlig og vigtig enhed skal træffe, fra politikker for risikoanalyse til multifaktorautentificering. For cloud-, managed service- og de andre digitale udbydere udfolder gennemførelsesforordning 2024/2690 hver af dem i 13 afsnit skrevet ud fra ISO/IEC 27001 og 27002. Én tabel: de ti litraer, som direktivet formulerer dem, de afsnit, der udfolder hvert, og de ISO 27001-punkter og bilag A-foranstaltninger, der frembringer beviserne, med de to steder, et ISMS ikke når.

12. september 2026

Din banks DORA-leverandørpolitik, RTS 2024/1773: de seks due diligence-spørgsmål, de fem kilder til sikkerhed, de otte betingelser for at acceptere dit ISO 27001-certifikat i stedet for en revision, og de fem rapporter, du kommer til at skylde

Hver finansiel enhed i Unionen har en skriftlig politik for sine kontrakter om IKT-tjenester, der understøtter kritiske eller vigtige funktioner, og delegeret forordning (EU) 2024/1773 siger, hvad den politik skal indeholde, i kraft siden den 15. juli 2024. Læst fra leverandørens side: de seks ting, kunden vurderer om dig, før den underskriver (artikel 6), de fem kilder til sikkerhed, den må bruge, og de otte betingelser, hvorunder den må støtte sig til dine certificeringer eller revisionsrapporter i stedet for selv at revidere dig (artikel 8), nøgleindikatorerne, bøderne og de fem slags rapporter, kontrakten vil kræve (artikel 9), og den exitplan, den skal teste (artikel 10). Med det, et ISO 27001-certifikat besvarer, og det, det ikke gør.

12. september 2026

DORA for en softwareleverandør: kontraktklausulerne efter artikel 30, som din bankkunde sender, informationsregistret, du kommer til at stå i, og hvad ISO 27001 allerede besvarer

Siden den 17. januar 2025 styrer enhver bank, forsikringsselskab, investeringsselskab og betalingsinstitut i Unionen sine softwareleverandører efter forordning (EU) 2022/2554, DORA. Leverandøren er ikke reguleret; kontrakten er. Artikel 30 opregner ni klausuler, som enhver kontrakt om IKT-tjenester skal indeholde, og seks mere, når tjenesten understøtter en kritisk eller vigtig funktion: lokationer, tilbagelevering af data, hændelsesbistand til en forud fastsat pris, samarbejde med kundens myndigheder, opsigelsesvarsler, revisionsrettigheder, exitstrategier. Hver klausul læst fra forordningen, det informationsregister, kunden indgiver årligt, de tre delegerede retsakter bag, og for hvilke af klausulerne et ISO 27001-system allerede frembringer beviset.

12. september 2026

DORA's nitten typer af IKT-tjenester, S01 til S19: hvilken et SaaS-produkt er, hvad registret over oplysninger fastholder om den, og hvorfor én kontrakt kan blive flere rækker

Hver IKT-tjeneste, som en bank, et forsikringsselskab eller et betalingsinstitut køber, registreres i dets register over oplysninger under en af nitten koder, S01 til S19, fra bilag III til gennemførelsesforordning (EU) 2024/2956. Et hostet produkt er S19, installeret software S13, en administreret tjeneste S14, et datafeed S05, og kunden indberetter én række pr. tjeneste og funktion, så én kontrakt kan blive til flere. De nitten typer med forordningens egne beskrivelser, kolonnen der bærer koden, hvad kunden skal registrere ved siden af, og hvorfor den kode, du giver én kunde, skal passe til den, du giver den næste.

12. september 2026

Underleverandører under DORA, RTS 2025/532: de tolv vilkår, din kontrakt bærer, når du giver en kritisk tjeneste i underentreprise, de ti betingelser, din kunde tjekker først, og varslet, før du skifter underleverandør

Siden den 22. juli 2025 må en finansiel enhed kun lade sin softwareleverandør give en tjeneste, der understøtter en kritisk eller vigtig funktion, i underentreprise på betingelserne i delegeret forordning (EU) 2025/532. Ti betingelser, kunden vurderer før underskrift, fra din evne til at identificere hver underleverandør til om underleverandøren giver de samme revisionsrettigheder; tolv vilkår, kontrakten derefter bærer, fra dit ansvar for underleverandørens tjeneste til kundens ret til at opsige; et varsel, hvor du ikke må skifte underleverandør, før kunden har godkendt eller undladt at gøre indsigelse; og tre tilfælde, hvor kunden må opsige. Læst i EU-Tidende, med det, registret over oplysninger fastholder om kæden, og det, et ISO 27001-leverandørregister allerede besvarer.

12. september 2026

EU-overensstemmelseserklæringen under CRA: bilag V punkt for punkt, den forenklede form og et udfyldt eksempel

Artikel 28 pålægger fabrikanten at udfærdige en EU-overensstemmelseserklæring, før produktet bringes i omsætning, efter modellen i bilag V, og artikel 28(4) gør underskriften til den handling, hvormed fabrikanten påtager sig ansvaret for produktet. De otte punkter i bilag V, den forenklede form på én sætning i bilag VI, reglerne omkring den (sprog, den enkelte erklæring, produktfamilier, 10 års opbevaring), et udfyldt eksempel, og hvad en manglende eller forkert erklæring koster efter artikel 58 og artikel 64.

12. september 2026

GDPR-anmodningen fra en registreret for en softwarevirksomhed: måneden i artikel 12, stk. 3, de otte oplysninger i et indsigtssvar, de to yderligere måneder og en side, der beregner fristen

En anmodning efter artikel 15 til 22 besvares uden unødig forsinkelse og senest en måned efter modtagelsen (artikel 12, stk. 3); fristen udløber på samme dato i den følgende måned eller på dens sidste dag; to yderligere måneder er til rådighed, når anmodningerne er komplekse eller talrige, og den registrerede underrettes inden for den første måned; et afslag bærer sine grunde og retsmidlerne inden for samme måned (12, stk. 4); svaret er gratis, medmindre anmodningen er åbenbart grundløs eller overdreven, og virksomheden bærer bevisbyrden for det (12, stk. 5). En indsigtsanmodning besvares med en kopi af oplysningerne og de otte oplysninger i artikel 15, stk. 1, litra a) til h), fra formålene til de automatiske afgørelser. Læst mod kataloget, med en gratis side, der beregner fristen og skriver svaret på seks sprog.

12. september 2026

GDPR-databehandleraftalen for en SaaS-virksomhed: de otte vilkår i artikel 28, stk. 3, som ethvert kundetillæg bærer, den pligt de fleste glemmer, og hvad der står ved siden af under DORA

En SaaS-virksomhed underskriver den samme kontrakt med hver kunde, den behandler oplysninger for, og artikel 28, stk. 3, fastsætter dens indhold: genstand og varighed, de otte tilsagn fra dokumenteret instruks til revisioner, og databehandlerens pligt til at gøre opmærksom på en instruks, der overtræder forordningen. Hvad hvert vilkår betyder for en softwareleverandør, reglen om underdatabehandlere i artikel 28, stk. 2 og 4, Kommissionens standardkontraktbestemmelser fra 2021, ansvaret efter artikel 82 og bødeloftet efter artikel 83, og den DORA-klausul i artikel 30, en bankkunde sender ved siden af hvert vilkår. Med den gratis tjekliste, der læser de to tillæg som ét.

12. september 2026

GDPR for en softwarevirksomhed: dataansvarlig for egne data, databehandler for kunderne, og de fem forpligtelser, der afhænger af størrelse og data

Forordning (EU) 2016/679 når enhver softwarevirksomhed, så spørgsmålet er, hvilke forpligtelser der gælder. De to roller pr. behandling (artikel 4), fortegnelsen over behandlingsaktiviteter, som undtagelsen ved 250 personer aldrig fritager et produkt i brug for (artikel 30), rådgiveren (artikel 37), konsekvensanalysen (artikel 35), repræsentanten for en virksomhed uden for Unionen (artikel 27), overførselsgrundlagene (kapitel V), fristerne på 72 timer og en måned, og hvad ISO 27701 frembringer for hver af dem. Læst i EU-Tidende, med den gratis bestemmelse, der skriver det ned.

12. september 2026

GDPR-fortegnelsen over behandlingsaktiviteter for en softwarevirksomhed: de syv felter i artikel 30, stk. 1, de fire i artikel 30, stk. 2, hvorfor undtagelsen ved 250 personer aldrig gælder, og en side, der skriver den

Artikel 30 er den ene GDPR-forpligtelse, som enhver anden henviser tilbage til, og den, som de fleste softwarevirksomheder tror, undtagelsen ved 250 personer fritager dem for. Det gør den ikke: artikel 30, stk. 5, ophæver undtagelsen for enhver behandling, der ikke er lejlighedsvis, og et produkt i brug behandler hver dag. De syv felter i en dataansvarligs fortegnelse og de fire i en databehandlers, læst i EU-Tidende, hvad hvert felt er til, den ISO 27701-foranstaltning, der dokumenterer det, og den gratis side, der skriver fortegnelsen én aktivitet ad gangen.

12. september 2026

GDPR-fristen på 72 timer for en softwarevirksomhed: hvornår kendskab starter den, hvad anmeldelsen indeholder, databehandlerens egen frist, og NIS2-, CRA- og DORA-fristerne ved siden af

Artikel 33 giver en dataansvarlig 72 timer fra kendskab til et brud på persondatasikkerheden til at anmelde det til tilsynsmyndigheden, og de fleste virksomheder får starten, indholdet eller rollen forkert. Hvornår kendskab begynder efter Databeskyttelsesrådets retningslinjer og betragtning 87, de fire indhold i artikel 33, stk. 3, faserne i artikel 33, stk. 4, reglen om begrundelse for forsinkelse, databehandlerens pligt til at underrette den dataansvarlige uden unødig forsinkelse, underretningen af de registrerede efter artikel 34 og dens tre undtagelser, og de NIS2-, CRA- og DORA-frister, en softwarevirksomhed kan have løbende fra samme tidspunkt. Med den gratis side, der beregner fristen og skriver anmeldelsen.

12. september 2026

GDPR-konsekvensanalysen for en softwarevirksomhed: de tre tilfælde i artikel 35, stk. 3, de ni kriterier bag dem, de fire elementer i artikel 35, stk. 7, og en side, der skriver den

Artikel 35 kræver en konsekvensanalyse vedrørende databeskyttelse før enhver behandling, der sandsynligvis vil indebære en høj risiko, og nævner tre tilfælde, hvor den under alle omstændigheder er påkrævet. Hvilke produktfunktioner falder ind under dem, de ni kriterier, tilsynsmyndighederne anvender, og reglen om, at to af dem som regel betyder en analyse, de lister, myndighederne offentliggør efter artikel 35, stk. 4 og 5, de fire elementer, analysen skal indeholde, databeskyttelsesrådgiverens råd og de registreredes synspunkter, den forudgående høring efter artikel 36 med dens otte uger, og gennemgangen, når risikoen ændrer sig. Med den gratis side, der afgør, om en er påkrævet, og skriver den.

12. september 2026

GDPR-overførsler til tredjelande for en softwarevirksomhed: de 17 afgørelser om tilstrækkelighed, de fire SCC-moduler, hvad en amerikansk, britisk eller indisk underdatabehandler skal bruge, og en side, der vælger mekanismen

Enhver hostingudbyder, supportfunktion, ethvert analyseværktøj og enhver lønservice uden for EØS er en overførsel efter kapitel V. Kommissionens liste over afgørelser om tilstrækkelighed, læst den 12. september 2026, rummer 17 poster: 16 lande og territorier, fra Andorra til Uruguay, og Den Europæiske Patentorganisation, med Det Forenede Kongerige fornyet i december 2025, Brasilien tilføjet i januar 2026 og USA kun dækket for virksomheder certificeret under Data Privacy Framework. Alt andet kræver standardkontraktbestemmelserne i afgørelse (EU) 2021/914, hvis fire moduler følger eksportørens og importørens roller, med vurderingen af lokal ret efter bestemmelse 14 før den første overførsel; undtagelserne i artikel 49 er til den enkeltstående lejlighed, aldrig til et produkt i brug. Læst mod kataloget, med en gratis side, der vælger mekanismen og skriver den.

12. september 2026

GDPR-privatlivspolitikken for en softwarevirksomhed: de tolv oplysninger i artikel 13, de tretten i artikel 14, tidspunktet for hver, og en side, der skriver den

En privatlivspolitik er ikke en genre; det er en liste. Artikel 13 nævner tolv oplysninger, en dataansvarlig giver på det tidspunkt, personoplysningerne indsamles hos personen, seks i alle tilfælde og seks yderligere for en rimelig og gennemsigtig behandling, og artikel 14 nævner tretten for oplysninger indhentet andetsteds, givet inden for en rimelig frist og senest inden for en måned, med fire undtagelser. For en softwarevirksomhed er syv af dem allerede kolonner i dens fortegnelse over behandlingsaktiviteter. Hver oplysning, som EU-Tidende formulerer den, tidspunktet, hvor den gives, de to tilfælde, hvor den ikke skyldes, og en gratis side, der skriver politikken ud fra svarene på seks sprog.

12. september 2026

GDPR-repræsentanten efter artikel 27 for en softwarevirksomhed uden for EU: hvem der skal udpege en, de tre betingelser for undtagelsen, og hvor navnet skal stå

En softwarevirksomhed uden etablering i Unionen, hvis produkt bruges af mennesker i den, er omfattet af forordningen efter artikel 3, stk. 2, og skal skriftligt udpege en repræsentant i Unionen (artikel 27, stk. 1), etableret i en medlemsstat, hvor dens brugere er (27, stk. 3), bemyndiget til at blive kontaktet af tilsynsmyndigheder og registrerede (27, stk. 4), og uden at det skærmer mod skridt mod virksomheden selv (27, stk. 5). Undtagelsen i artikel 27, stk. 2, litra a), har tre betingelser, der alle skal være opfyldt, og et produkt i brug fejler på den første. Hvor repræsentantens navn skal stå: privatlivspolitikken (artikel 13, stk. 1, litra a)), fortegnelsen over behandlingsaktiviteter (artikel 30, stk. 1, litra a)) og den fortegnelse, repræsentanten selv fører. Bødeniveauet er artikel 83, stk. 4. En gratis side afgør det ud fra to spørgsmål.

12. september 2026

Harmoniserede standarder til CRA: hvad standardiseringsanmodning M/606 beder om, hvornår, og hvad en fabrikant har i dag

Artikel 27 giver en overensstemmelsesformodning til produkter, der følger harmoniserede standarder offentliggjort i Den Europæiske Unions Tidende. Den 3. februar 2025 bad Kommissionen CEN, CENELEC og ETSI om 41 af dem med frister fra den 30. august 2026 til den 30. oktober 2027; de tre accepterede den 3. april 2025. Den 12. september 2026 har Kommissionens indeks over harmoniserede standarder stadig ingen post for forordningen, hvilket for et klasse I-produkt betyder, at der ikke er nogen vej til egenvurdering efter artikel 32(2). Hvad der blev bedt om, datoerne, og hvad man bygger efter i mellemtiden.

12. september 2026

Hvad en idriftsætter af et højrisiko-AI-system skylder efter artikel 26 i AI-forordningen: de tolv stykker i rækkefølge, konsekvensanalysen efter artikel 27, hvornår I bliver udbyder, og de registreringer et ISO 42001-system fører

De fleste virksomheder møder AI-forordningen som idriftsættere: de køber eller licenserer et system, en anden har bygget, og anvender det under eget ansvar. For et højrisikosystem står pligterne i artikel 26, tolv stykker, uændrede af den digitale omnibus, gældende fra den 2. december 2027 for systemer i bilag III. Hvert stykke læst i rækkefølge, konsekvensanalysen vedrørende grundlæggende rettigheder efter artikel 27 og hvem der bærer den, de tre måder en idriftsætter bliver udbyder på efter artikel 25, retten til forklaring efter artikel 86, loftet i artikel 99, og den ISO 42001-foranstaltning, der frembringer hver registrering.

12. september 2026

Hvad en ISO 9001-certificering koster: de auditdage, IAF MD 5 fastsætter efter antal ansatte, dagsprisen, treårstotalen, og hvorfor det er en tredjedel af ISO 27001

Certificeringsorganer offentliggør ikke priser, men auditdagene er ikke deres mening: IAF MD 5 fastsætter dem efter antallet af personer i anvendelsesområdet, 1,5 dag op til fem personer, 3 for 16 til 25, 7 for 86 til 125, og akkrediteringsorganet holder certificeringsorganet op på tabellen. Gang med en dagspris på 1.200 til 1.800 euro, læg to overvågningsaudits på omkring en tredjedel hver til, og du har dit tal, før nogen giver dig et tilbud. Regnet igennem for seks virksomhedsstørrelser, med ISO 27001-dagene ved siden af, hvad der flytter tallet op eller ned, og hvad du ellers betaler.

12. september 2026

Hvilken GDPR-tilsynsmyndighed er jeres: hovedvirksomheden, den ledende myndighed efter artikel 56, de lokale sager og Rådets 30 myndigheder

En softwarevirksomhed med kunder i flere medlemsstater har én tilsynsmyndighed for sin grænseoverskridende behandling: myndigheden for dens hovedvirksomhed, den ledende tilsynsmyndighed efter artikel 56, stk. 1, dens eneste kontaktpunkt efter artikel 56, stk. 6. Hvor den er, hvad hovedvirksomheden betyder for en dataansvarlig og for en databehandler (artikel 4, nr. 16), hvornår en anden myndighed beholder en lokal sag (artikel 56, stk. 2), hvad en virksomhed uden etablering i Unionen får i stedet (artikel 27, betragtning 122), og hvor anmeldelsen af et brud inden for 72 timer går hen (artikel 33, stk. 1). Med de 27 myndigheder og de tre fra EØS, som Det Europæiske Databeskyttelsesråd opfører sine medlemmer, læst den 12. september 2026.

12. september 2026

ISO 27001-erklæringen om anvendelighed for en softwarevirksomhed: de 93 foranstaltninger, de fire kolonner i punkt 6.1.3 d), de udelukkelser, en auditor accepterer, og en side, der skriver den

Erklæringen om anvendelighed er det ene ISO 27001-dokument, en auditor læser før alt andet, og punkt 6.1.3 d) gør den til fire spørgsmål pr. foranstaltning: er den nødvendig, hvorfor er den medtaget, er den implementeret, og hvorfor udelades en foranstaltning i anneks A. For en softwarevirksomhed uden egne kontorer og med en hostet stak sorterer de 93 foranstaltninger i 2022-udgaven sig i dem, der gælder fuldt ud, den håndfuld, der ærligt er udelukket, og de delvist implementerede, der afgør auditens fund. Hvad hver kolonne betyder, de udelukkelser, en auditor accepterer, og dem, han aldrig gør, hvordan erklæringen følger risikobehandlingsplanen, og en gratis side, der skriver den på seks sprog med statusserne i adressen.

12. september 2026

ISO 27001-omfangserklæringen: hvorfor et certifikat, der siger hovedkontor, ikke dækker din SaaS, hvad afsnit 4.3 beder om, hvad en køber under DORA tjekker, og tre omfangserklæringer, der består

Omfangserklæringen er certifikatets grænse, og købere læser den nu op mod en forordning: en finansiel kunde må kun støtte sig til dit ISO 27001-certifikat i stedet for at revidere dig, hvis dets omfang dækker de systemer, kunden er afhængig af. Hvad afsnit 4.3 i ISO/IEC 27001:2022 kræver, hvad ISO/IEC 17021-1 lader certifikatet vise, den overvågningscyklus, der afgør, om det er aktuelt, den udløbne frist for 2013-udgaven, én omfangserklæring, der dumper, og tre, der består for et softwarefirma, og hvordan grænsefladerne til din cloududbyder bliver inden for omfanget, mens udbyderen bliver udenfor.

12. september 2026

ISO/IEC 27701:2025 for en softwarevirksomhed: den selvstændige privatlivsstandard, dens 78 foranstaltninger, hvad et ISO 27001-system allerede dækker, og de GDPR-artikler, hver foranstaltning dokumenterer

Anden udgave af ISO/IEC 27701, udgivet i oktober 2025, er ikke længere en udvidelse af ISO 27001: den er en ledelsessystemstandard i sig selv, med kapitel 4 til 10 og ét bilag A med 78 foranstaltninger, 31 for PII-dataansvarlige, 18 for PII-databehandlere og 29 informationssikkerhedsforanstaltninger for begge. Læst række for række for en softwarevirksomhed: hvilke af de 103 krav et kørende ISO 27001-system allerede halvt dækker, og hvad 27701 kræver derudover, de 33 privatlivskrav, som ingen sikkerhedsforanstaltning frembringer, og de 32 GDPR-artikler, foranstaltningerne dokumenterer, fra fortegnelsen over behandlingsaktiviteter til brudfristen på 72 timer. StandardOS' læsning, med standardens tekst dér, hvor den er.

12. september 2026

ISO 9001 for en softwarevirksomhed: hvad punkt 8 betyder, når produktet er kode, underpunkt for underpunkt

Punkt 4 til 7, 9 og 10 i ISO 9001:2015 er det ledelsessystemskelet, en ISO 27001-virksomhed allerede kører. Punkt 8, Drift, er det, der er skrevet til fabrikker og servicedeske, og det, en softwarevirksomhed skal oversætte. Hvad hvert underpunkt er, når produktet er software: gennemgang af krav, før man forpligter sig (8.2), udviklingslivscyklussen som design og udvikling (8.3), cloududbydere og afhængigheder som eksterne leverandører (8.4), udrulning, sporbarhed, kundedata og support som produktion og levering af ydelser (8.5), frigivelsesporten (8.6), og fejl og hændelser som afvigende output (8.7). Med de steder, hvor Cyber Resilience Act beder om de samme registreringer.

12. september 2026

Hvilke EU-lande nævner ISO 9001 i offentlige udbud: 4.897 tyske bekendtgørelser, 4.743 rumænske, og hver tiende rumænske nævner den

Over 365 dage optræder ISO 9001 i 16.356 TED-bekendtgørelser fra indkøbere i EU-27, 1,87% af alt, de offentliggjorde, og fem gange de 3.361, der nævner ISO 27001. Tyskland og Rumænien står for 59% af omtalerne; Rumænien nævner den i 10,48% af sine bekendtgørelser, Bulgarien i 7,34%, Ungarn i 7,02%; Frankrig, Spanien og Italien nævner den knap nok. Og 1.475 bekendtgørelser nævner begge standarder, 44% af hver omtale af ISO 27001. Tabellen efter land, overlappet og forespørgslen til at køre dem igen.

12. september 2026

Kræver ISO 9001:2015 en kvalitetshåndbog? Hvad punkt 7.5 beder om i stedet, de 21 steder standarden nævner dokumenteret information, og hvad en håndbog er til i dag

ISO 9001:2008 krævede en kvalitetshåndbog; ISO 9001:2015 gør det ikke og siger det i sit anneks A. Det, den kræver, er dokumenteret information: fem ting at vedligeholde (anvendelsesområdet, procesinformationen, kvalitetspolitikken, målene, den operationelle planlægning) og seksten slags registreringer at opbevare, hver nævnt ved punkt. Hvad punkt 7.5 beder om af hvert dokument, hvorfor en håndbog stadig er det rigtige sted for kortet over systemet, og hvad der skal i den. Med antallet af EU-udbudsbekendtgørelser, der bad om ISO 9001 i det seneste år, 17.076, fem gange ISO 27001.

12. september 2026

Kvalitetspolitikken efter ISO 9001: de fire ting, punkt 5.2 kræver, de tre ting, der skal ske med den, og et eksempel på én side

Punkt 5.2 i ISO 9001:2015 er kort og præcist. Topledelsen fastlægger en kvalitetspolitik, der passer til organisationens formål og kontekst og understøtter dens strategi, giver en ramme for kvalitetsmålene og forpligter sig til at opfylde gældende krav og til løbende forbedring (5.2.1). Politikken vedligeholdes derefter som dokumenteret information, kommunikeres, forstås og anvendes i organisationen og gøres tilgængelig for interesserede parter (5.2.2). Hvad hvert af de syv krav betyder for en side tekst, de afvigelser, auditorer skriver op, hvordan den samme politik tjener ISO 27001, og et eksempel på én side med vores egne ord.

12. september 2026

Ledelsens evaluering efter ISO 9001: de 13 input og 3 output i punkt 9.3 som dagsorden, hvor hvert input kommer fra, og hvad referatet skal vise

Punkt 9.3 i ISO 9001:2015 er det ene møde, standarden skriver dagsordenen for. Topledelsen evaluerer kvalitetsledelsessystemet med planlagte mellemrum for egnethed, tilstrækkelighed, effektivitet og overensstemmelse med strategien (9.3.1); tager tretten input i betragtning, fra status på sidste gangs handlinger til eksterne leverandørers præstation (9.3.2); og beslutter om forbedring, ændringer af systemet og ressourcer (9.3.3), med resultaterne opbevaret som dokumenteret information. Dagsordenen, registreringen bag hvert input, hvad referatet skal vise, og hvordan det samme møde tjener ISO 27001 og, for NIS2-enheder, den årlige gennemgang af politikken, som gennemførelsesforordningen kræver.

12. september 2026

Når dit nedbrud bliver din bankkundes større hændelse: DORA's seks kriterier, tærsklen på to timers nedetid i RTS 2024/1772, fristerne på fire timer, 24 timer, 72 timer og én måned i RTS 2025/301, og de fakta, din kunde får brug for fra dig

En finansiel enhed skal indberette en større IKT-relateret hændelse til sin tilsynsmyndighed inden for fire timer efter klassificeringen og senest 24 timer efter, at den blev bekendt med den, følge op inden for 72 timer og afslutte inden for én måned. Om et nedbrud hos dens softwareleverandør er større, afgøres af seks kriterier og tærsklerne i delegeret forordning (EU) 2024/1772: mere end to timers nedetid for en tjeneste, der understøtter en kritisk eller vigtig funktion, mere end 24 timers varighed, mere end 10 procent af kunderne, to eller flere medlemsstater, datatab, 100 000 euro. Hvad hver indberetning skal indeholde efter delegeret forordning (EU) 2025/301, hvilke af de fakta kun leverandøren har, og hvad klausulen om bistand ved hændelser i artikel 30, stk. 2, litra f), gør det til. Læst i EU-Tidende.

12. september 2026

NIS2 artikel 20 for bestyrelsen: hvad ledelsesorganet skal godkende, føre tilsyn med og lære, de tolv steder gennemførelsesforordningen nævner det, og hvad ansvar betyder

Artikel 20 i NIS2 pålægger ledelsesorganet i en væsentlig eller vigtig enhed at godkende foranstaltningerne til styring af cybersikkerhedsrisici, føre tilsyn med gennemførelsen, kunne gøres ansvarligt for enhedens overtrædelser af artikel 21, og følge kurser. Gennemførelsesforordning 2024/2690 nævner derefter ledelsesorganet tolv steder i sit bilag: en dateret godkendelse af politikken, en årlig gennemgang, en direkte rapporteringslinje, accept af resterende risici, rapportering om overholdelse, et bevidstgørelsesprogram. Hvert af de tolv som registrering, den klausul i ISO 27001, der allerede frembringer den, og hvad artikel 32 og artikel 34 siger om, hvordan ansvar ser ud.

12. september 2026

NIS2 for en SaaS-virksomhed: I er en udbyder af cloudcomputingtjenester, og det følger af det

Direktivets betragtning 33 nævner software som en service blandt cloudtjenestemodellerne, så en SaaS-virksomhed af mellemstor størrelse eller større er en enhed efter NIS2 som udbyder af cloudcomputingtjenester: vigtig under tærsklerne for mellemstore virksomheder, væsentlig over dem. Det, der følger, i den rækkefølge, det kommer: staten for jeres hovedforretningssted, registret, I skulle være i senest den 17. januar 2025, foranstaltningerne i gennemførelsesforordning 2024/2690, de fire hændelsestærskler i dens artikel 7 og urene i artikel 23, og grænsen mellem alt dette og CRA.

12. september 2026

NIS2 for managed service providers og MSSP'er: en enhed efter bilag I per definition, og den leverandør, hver kundes due diligence lander på

Artikel 6(39) gør enhver, der installerer, administrerer, driver eller vedligeholder IKT for kunder, på stedet eller på afstand, til udbyder af administrerede tjenester, og artikel 6(40) gør dem, der hjælper med styring af cybersikkerhedsrisici, til MSSP'er. Begge er typer i bilag I: vigtige ved mellemstor størrelse, væsentlige over tærsklerne, under hovedforretningsstedets lov, i ENISA's register, umiddelbart under gennemførelsesforordning 2024/2690, med de fire hændelsestærskler i dens artikel 10. Og betragtning 86 beder enhver væsentlig og vigtig kunde om at udvise øget omhu ved valget af jer.

12. september 2026

NIS2 for onlinemarkedspladser, søgemaskiner og sociale netværk: de digitale udbydere i bilag II, og hvorfor de aldrig er væsentlige i kraft af størrelse

Tre definitioner lånt fra tre andre retsakter afgør, om en platform er en digital udbyder efter NIS2: en markedsplads, hvor forbrugere indgår fjernsalgsaftaler, en søgemaskine, der søger på principielt alle websteder, en platform, hvor slutbrugere kommer i forbindelse og deler. Omfattet fra mellemstor størrelse, vigtige efter artikel 3(2), hvor store de end er, under hovedforretningsstedets lov, i ENISA's register, under gennemførelsesforordning 2024/2690 med egne hændelsestærskler i artikel 11 til 13: ingen 30-minuttersregel, en andel af brugerne i stedet.

12. september 2026

NIS2-gennemførelsen, stat for stat: hvad Kommissionens eget register viser

Ikke et advokatfirmas tracker: de nationale foranstaltninger, som medlemsstaterne har meddelt Kommissionen som gennemførelse af direktiv (EU) 2022/2555, læst hos Publikationskontoret den 12. september 2026. 25 af de 27 stater har meddelt mindst én, 303 foranstaltninger i alt; Spanien og Irland ingen; Frankrig 15 tekster, alle ældre end direktivet. Den retsakt, hver stat kalder sin NIS2-lov, hvornår den trådte i kraft, og hvad en softwarevirksomhed gør med svaret.

12. september 2026

NIS2-registrering: de to lister, du kan stå på, hvad du indgiver, hvornår og til hvem (artikel 3(4) og artikel 27)

NIS2 har to registreringer, ikke én. Hver væsentlig og vigtig enhed indgiver fire oplysninger til sin kompetente myndighed, så medlemsstaten kan udarbejde sin liste senest den 17. april 2025 (artikel 3(3) og (4)), med ændringer meddelt inden to uger. Elleve typer digitale enheder, blandt dem cloududbydere og udbydere af administrerede tjenester, indgiver desuden seks oplysninger senest den 17. januar 2025 til ENISA's register (artikel 27), med ændringer inden tre måneder. Hvilken stat der modtager dem (artikel 26), hvad de to lister er til, hvad registrering ikke afgør, og den registrering, der skal opbevares.

12. september 2026

Sådan tjekker du, om et ISO 9001-certifikat er ægte: hvad et certifikat skal vise, tre tjek på ti minutter, og de 27 akkrediteringsregistre

ISO certificerer ikke virksomheder og fører intet register over dem, så et certifikat er kun så godt som det organ, der udstedte det, og akkrediteringen bag det organ. Hvad ISO/IEC 17021-1 får et certifikat til at vise, de tre tjek (certificeringsorganet er akkrediteret til ISO 9001, certifikatet er gyldigt, anvendelsesområdet dækker det, du køber), de 27 nationale akkrediteringsregistre med links, hvorfor et certificeringsorgan i en anden EU-stat er lige så godt som ét i din egen, og hvorfor det billige ikke-akkrediterede certifikat koster mere i sidste ende.

12. september 2026

Trusselsbaserede penetrationstest under DORA, fra leverandørens side: hvornår din bankkundes red team må ind i dine produktionssystemer, testen på 12 uger i RTS 2025/1190, den fælles test, du kan køre i stedet, og hvad kontrakten allerede siger

Artikel 26 i DORA lader de største finansielle enheder køre en trusselsbaseret penetrationstest på produktionssystemer mindst hvert 3. år, som dækker de kritiske eller vigtige funktioner, de har udliciteret, og artikel 30, stk. 3, litra d), sætter leverandørens deltagelse i kontrakten. Delegeret forordning (EU) 2025/1190, i kraft siden den 8. juli 2025, fastsætter mekanikken: et kontrolteam, der kan omfatte dine medarbejdere, et blue team, der ikke må vide noget, en aktiv red team-fase på mindst 12 uger, en gennemspilning og purple teaming inden for 10 uger efter dens afslutning, en afhjælpningsplan inden for 8 uger. Artikel 26, stk. 4, lader en leverandør, hvis andre kunder ville lide skade, kontrahere direkte med en ekstern tester og køre én fælles test for flere finansielle enheder. Hvad leverandøren skriver under på, hvad den må afvise, og hvad et ISO 27001-system allerede rummer. Læst i EU-Tidende.

12. september 2026

Væsentlig eller vigtig under NIS2: størrelsesreglen, de størrelsesuafhængige regler og de syv måder at være væsentlig på

Om NIS2 rammer en virksomhed, er artikel 2; om den er væsentlig eller vigtig, er artikel 3; og forskellen er forudgående tilsyn, et højere bødeloft og en strengere læsning af alt andet. De to artikler citeret, størrelsesklasserne i henstilling 2003/361/EF, som de faktisk tælles, reglerne, der ser bort fra størrelse, og de tilfælde, en softwarevirksomhed får galt: en cloududbyder med 40 ansatte, en stor maskinproducent, en registrator, en virksomhed uden for Unionen.

12. september 2026

CRA bilag I: de 22 væsentlige krav, som tjekliste

Bilag I til Cyber Resilience Act er det, jeres produkt skal opfylde fra den 11. december 2027, og det, den tekniske dokumentation skal vise. Del I er 14 produktkrav, 13 af dem \"hvor det er relevant\" på grundlag af jeres risikovurdering; del II er 8 krav til håndtering af sårbarheder, som altid gælder. Her er de som én tabel, med hvad hvert krav beder om, og om I må udelukke det.

11. september 2026

CRA-cybersikkerhedsrisikovurderingen: hvad artikel 13 faktisk kræver, og det ene resultat, den skal levere

Artikel 13, stk. 2 til 4, i Cyber Resilience Act gør risikovurderingen til det dokument, alle andre CRA-pligter hænger på. Den skal analysere risici ud fra det tilsigtede formål, den forventelige brug og brugsbetingelserne over den forventede brugstid; angive om og hvordan hvert krav i del I, punkt 2, gælder; sige hvordan del I, punkt 1, og del II anvendes; være dokumenteret, holdt ajour over supportperioden og indgå i den tekniske dokumentation, med en klar begrundelse for hvert udeladt krav. De fire stykker, og en struktur på én side, der opfylder dem.

11. september 2026

CRA eller NIS2: Hvilken gælder for en softwarevirksomhed, og kan det være begge?

Cyber Resilience Act regulerer produkter, der bringes i omsætning; NIS2 regulerer enheder, der leverer tjenester. En softwarevirksomhed kan være under den ene, den anden, begge eller ingen, og svaret afhænger af to spørgsmål: Bringer I et produkt i omsætning, og er I en mellemstor eller større enhed i en opført sektor. Datoerne, anmeldelsesurene, bøderne og beslutningstabellen, fra de to tekster.

11. september 2026

Cyber Resilience Act for en lille softwarefabrikant, i tolv trin

Alt, hvad en virksomhed på ti personer, der leverer installeret software eller en enhed, skal gøre efter CRA, i den rækkefølge, det skal gøres: fastlæggelsen af anvendelsesområdet, trinnet, CSIRT'et og håndhæveren, den anmeldelsesprocedure, der har gjaldt siden den 11. september 2026, derefter den tekniske dokumentation, de 22 krav, SBOM'en, supportperioden, CE-mærkningen og erklæringen med frist den 11. december 2027. Hvert trin med sin artikel og den tekst, der forklarer det.

11. september 2026

Den politik for koordineret offentliggørelse af sårbarheder, som CRA kræver: tre bestemmelser, og en politik på én side, der opfylder dem

Bilag I, del II, punkt 5, i Cyber Resilience Act kræver, at enhver omfattet fabrikant indfører og håndhæver en politik for koordineret offentliggørelse af sårbarheder. Artikel 13, stk. 17, kræver ét kontaktpunkt til indberetninger, som er let at finde og ikke begrænset til automatiserede værktøjer; bilag II, punkt 2, kræver kontaktpunktet og politikkens placering i brugeroplysningerne; bilag VII, punkt 2, litra b, sætter begge dele i den tekniske dokumentation. Hvad hver bestemmelse beder om, hvad en politik skal sige, og hvad den ikke må love.

11. september 2026

Er dit produkt omfattet af Cyber Resilience Act? Hvor SaaS står

Det hyppigste CRA-spørgsmål er ikke, hvordan man anmelder, men om forordningen overhovedet gælder for jer. Ren software as a service er udenfor og under NIS2; installeret og downloadet software er indenfor; fjernbehandling, som et produkt ikke kan fungere uden, er indenfor igen. Fastlæggelsen er jeres at træffe og dokumentere. Her er teksten, der afgør den.

11. september 2026

Er dit produkt vigtigt eller kritisk efter Cyber Resilience Act? Bilag III og IV i fuld længde

Når et produkt er omfattet af CRA, er det standard, vigtigt (klasse I eller II) eller kritisk, og trinnet afgør, om I selv må vurdere eller skal bruge et bemyndiget organ. Her er de 19, 4 og 3 kategorier ordret fra EU-Tidende, hvad hvert trin ændrer efter artikel 32, og det ene, trinnet ikke ændrer.

11. september 2026

Er jeres open source-projekt \"kommercielt\" under CRA? Kommissionens syv tests, med dens eksempler

CRA når kun fri og open source-software, hvor den leveres som led i en kommerciel aktivitet, og forordningen overlader \"kommerciel\" til to betragtninger. Kommissionens vejledning af 27. juli 2026, afsnit 3, gør dem til syv tests: en pris, en betalt udgave eller open core, at tjene penge på andre tjenester eller personoplysninger, supporttjenester, donationer, sponsorering og almennyttig status, med 22 eksempler. Hvor en maintainer, en open core-virksomhed og en fond hver især lander, og hvad en pull request gør jer til.

11. september 2026

EU's eget CRA-maskineri den dag, pligten begyndte: 0 bemyndigede organer, 0 harmoniserede standarder, 7 ud af 27 håndhævere

Cyber Resilience Act beder fabrikanter om at være klar. Her er, hvor klar de institutioner, den afhænger af, var den 11. og 12. september 2026, læst i Kommissionens egne registre: intet overensstemmelsesvurderingsorgan bemyndiget under CRA, ingen harmoniseret standard offentliggjort i EU-Tidende, syv medlemsstater med en registreret markedsovervågningsmyndighed, tretten med en bemyndigende myndighed, og listen over koordinerende CSIRT'er offentliggjort dagen før, hvor to stater nævner en anden myndighed end deres nationale CSIRT. Hvad det betyder for en fabrikant med et klasse I-produkt, og hvad der skal noteres.

11. september 2026

Gælder CRA for open source-software? Tre tilfælde, og den lette ordning for forvaltere

Cyber Resilience Act når fri og open source-software kun, når den leveres som led i en kommerciel aktivitet. Et projekt, der ikke monetariseres, er ude. En virksomhed, der leverer et produkt bygget på open source-komponenter, er fabrikant af det produkt. Og fonde og virksomheder, der understøtter open source-produkter til kommerciel brug, er \"forvaltere af open source-software\" efter artikel 24: en cybersikkerhedspolitik, samarbejde med myndigheder og en indsnævret anmeldelsespligt, uden CE-mærkning og uden teknisk dokumentation. Betragtningerne og artiklen, citeret.

11. september 2026

Hvad CRA kræver af importører og distributører, og hvornår den gør dem til fabrikant

Hvis I videresælger software eller enheder ind i EU i stedet for at bygge dem, giver artikel 19 og 20 i Cyber Resilience Act jer en tjekliste at gennemgå, før produktet kommer til salg, en pligt til at give sårbarheder videre til fabrikanten, en pligt til at underrette myndighederne om væsentlige risici og ti års opbevaring. Artikel 21 gør jer til fabrikant, i det øjeblik I sælger under eget mærke eller ændrer produktet væsentligt. Pligterne, fra teksten.

11. september 2026

Hvad CRA kræver af jer for jeres afhængigheder: fornøden omhu, indberetning opstrøms og kendte udnyttelige sårbarheder, efter Kommissionens vejledning

Et softwareprodukt er mest andres kode. CRA gør fabrikanten ansvarlig for produktet som helhed og giver den tre pligter over for komponenterne i det: fornøden omhu efter artikel 13(5), indberetning af sårbarheder opstrøms og deling af rettelser efter artikel 13(6), og at bringe produktet i omsætning uden kendte udnyttelige sårbarheder. Kommissionens vejledning af 27. juli 2026, afsnit 3.4, 7.3 og 9.2, siger, hvad hver kræver, og hvad den ikke kræver: ingen dobbelte indberetninger, ingen pligt til at få jeres rettelse merget, og en definition af \"kendt\", der omfatter CVE-databasen og nyhederne.

11. september 2026

Hvad der hører til i den tekniske dokumentation efter CRA: bilag VII, punkt for punkt

Fra den 11. december 2027 skal ethvert produkt med digitale elementer, der bringes i omsætning på EU-markedet, have teknisk dokumentation før omsætningen, opbevaret i ti år eller supportperioden, alt efter hvad der er længst. Bilag VII siger i otte punkter, hvad den indeholder. Her er de, hvad hvert punkt faktisk beder om, de fire dokumenter, som del II i bilag I forudsætter, og hvor længe I beholder den.

11. september 2026

Hvad I skal anmelde efter CRA: de to udløsere, som forordningen definerer dem

Artikel 14 har to udløsere, og begge er defineret i teksten. En aktivt udnyttet sårbarhed er en, for hvilken der foreligger pålidelige beviser for, at en ondsindet aktør har udnyttet den i et system uden ejerens tilladelse (artikel 3, nr. 42). En alvorlig hændelse er en, der påvirker eller kan påvirke produktets evne til at beskytte følsomme data eller funktioner, eller som fører eller kan føre til ondsindet kode i produktet eller i en brugers systemer (artikel 14, stk. 5). Hvad der er inde, hvad der er ude, og pligten til at informere brugerne, der følger med begge.

11. september 2026

Hvem håndhæver Cyber Resilience Act i din medlemsstat? 7 ud af 27 har sagt det

CRA håndhæves nationalt af en markedsovervågningsmyndighed, som hver medlemsstat udpeger og registrerer hos Kommissionen. Den 11. september 2026, den dag anmeldelsespligten begyndte at gælde, havde syv stater registreret én. Her er registret, stat for stat, inklusive de tyve, der ikke har, og hvad det betyder for en lille fabrikant, der spørger, hvem der kommer og banker på.

11. september 2026

Hvilke dele af jeres backend ligger inden for CRA? Fjerndatabehandling, efter Kommissionens vejledning

Et produkt med digitale elementer omfatter sine fjerndatabehandlingsløsninger, og forordningen definerer dem i én sætning. Kommissionens vejledning af 27. juli 2026 gør den sætning til to kumulative tests, en afgrænsningsregel, en liste over det, der aldrig er med (CI/CD, HR, CRM, telemetri, websteder), tilfældene SaaS, PaaS og IaaS og et gennemregnet eksempel med mobilbank. For en softwarevirksomhed med en app og en sky er dette grænsen.

11. september 2026

Hvilken opdatering bringer jeres eksisterende software ind under CRA? Væsentlige ændringer, efter Kommissionens vejledning

Software bragt i omsætning før den 11. december 2027 forbliver uden for CRA's design- og overensstemmelsespligter, indtil den ændres væsentligt. Kommissionens vejledning af 27. juli 2026 siger i punkt 103 til 113 og 122 til 124, hvad det betyder for en softwareopdatering, med elleve gennemregnede eksempler: en risiko, der ikke står i jeres risikovurdering, ikke størrelsen af diffen. Sikkerhedsopdateringer er som regel ude; et \"husk mig\"-felt kan være inde. Hvad der skal skrives ind i hver udgivelse, og hvad den første væsentlige ændring udløser og ikke udløser.

11. september 2026

Hvilket CSIRT anmelder du til under CRA artikel 14? Alle 27 koordinatorer, som ENISA anfører dem

Enhver guide til Cyber Resilience Acts anmeldelsespligt siger \"anmeld til jeres nationale CSIRT\" og stopper der. Siden den 10. september 2026 offentliggør ENISA det CSIRT, der er udpeget som koordinator, for hver af de 27 medlemsstater. Her er listen, reglen, der afgør staten, og de to stater, hvor koordinatoren ikke er det nationale CSIRT.

11. september 2026

Hvor lang er supportperioden efter CRA? Mindst fem år, og tre andre ure, der hænger på den

Artikel 13, stk. 8, i Cyber Resilience Act kræver en supportperiode på mindst fem år, eller den forventede brugstid hvis den er kortere, hvor sårbarheder håndteres. Slutdatoen skal vises ved købet, mindst måned og år. Sikkerhedsopdateringer skal forblive tilgængelige i ti år eller supportperioden. Og den tekniske dokumentation, erklæringen og brugeroplysningerne opbevares lige så længe. De fire ure, fra teksten.

11. september 2026

Hvornår er software \"bragt i omsætning\" efter CRA, og hvilken af jeres builds er et produkt? Vejledningens regel for selvstændig software

Alt i CRA hænger på en dato og et navneord: den dato, et produkt bringes i omsætning, og om det, I udgiver, overhovedet er et produkt. For selvstændig software besvarer Kommissionens vejledning af 27. juli 2026 begge dele i punkt 13 til 21: En version bringes i omsætning én gang, når den første gang udbydes, og hver senere download tæller fra den dag; builds pr. operativsystem og funktionspakker er særskilte produkter; en webapp brugt i en browser er ikke et produkt, en browserudvidelse eller en installeret klient er. Hvad det betyder for den 11. december 2027, for betaer og for gamle versioner, I lader ligge online.

11. september 2026

Hvornår starter CRA's 24-timers ur? \"At få kendskab\", efter Kommissionens vejledning

De 24 og 72 timer løber fra det øjeblik, fabrikanten \"får kendskab\", og forordningen siger aldrig, hvad det betyder. Kommissionens vejledning af 27. juli 2026 gør det, i punkt 211 til 218: en rimelig grad af sikkerhed efter en indledende vurdering, overtaget ord for ord fra NIS2-gennemførelsesforordningen og GDPR-retningslinjerne om databrud. Hvad det gør en kundemail, en scanneralarm, en listet CVE i en komponent, en bug bounty-zero-day og en sårbarhed, I kendte før den 11. september, til.

11. september 2026

Sådan indgiver du en CRA-anmeldelse på ENISA's fælles anmeldelsesplatform, efter dens egen manual

Platformen åbnede den 11. september 2026 på portal.cra-srp.enisa.europa.eu. Hvem der kan logge ind, hvilken koordinator du vælger, hvad hver af de tre indgivelser spørger om, hvad platformens egen tæller regner forkert, og hvornår du må bede om udsat videregivelse. Læst i ENISA's vejledninger, FAQ, ordliste og vilkår, ikke i et resumé af dem.

11. september 2026

Kræver CRA en SBOM? Ja, og her står præcis, hvad den siger

Bilag I, del II, punkt 1 i Cyber Resilience Act kræver en softwarestykliste i et almindeligt anvendt, maskinlæsbart format, der mindst dækker afhængighederne på øverste niveau. Den hører til i den tekniske dokumentation, den offentliggøres ikke, og en markedsovervågningsmyndighed kan bede om den på begrundet anmodning. De tre sætninger, der afgør det, og hvad de lader stå åbent.

11. september 2026

NIS2 eller CRA: hvilket hændelsesur løber for en softwarevirksomhed, og hvad gør en hændelse 'væsentlig'

Begge love giver jer 24 timer, 72 timer og en måned, og begge starter uret, når I 'får kendskab'. Næsten alt andet er forskelligt: hvad der udløser det, hvem der modtager det, på hvilken platform, og hvad der tæller. NIS2 artikel 23 og gennemførelsesforordning 2024/2690 for virksomheden, der driver en cloudtjeneste; CRA artikel 14 for virksomheden, der leverer et produkt; begge for virksomheden, der gør begge dele. Tærsklerne, kriterium for kriterium, og én procedure, der opfylder begge.

11. september 2026

Selvvurdering efter CRA: hvad modul A faktisk kræver, fra bilag VIII og Kommissionens FAQ

De fleste softwareprodukter vil aldrig se et bemyndiget organ. De bruger modul A, proceduren for intern kontrol i bilag VIII, og \"selvvurdering\" er det ord, alle bruger om den uden at sige, hvad den indeholder. Bilag VIII, del I, er fem punkter; Kommissionens FAQ tilføjer listen over aktiviteter, det faktum, at ingen testmetode er foreskrevet, hvor et softwareprodukt bærer sin CE-mærkning, de to former for overensstemmelseserklæringen og tidsplanen for de harmoniserede standarder, der afgør, hvornår selvvurdering holder op med at betyde \"direkte mod bilag I\".

11. september 2026

Skal software CE-mærkes efter CRA? Ja, og artikel 30 siger, hvor mærket skal sidde

Fra den 11. december 2027 kræves der CE-mærkning på ethvert produkt med digitale elementer, der bringes i omsætning på EU-markedet, software inklusive. For software sættes mærket på EU-overensstemmelseserklæringen eller på det websted, der ledsager produktet, før det bringes i omsætning. Hvad mærket hævder, hvem der må anbringe det, hvornår et bemyndiget organs nummer føjes til, og hvad erklæringen bag det skal indeholde.

11. september 2026

Standard, vigtigt eller kritisk: de 26 tekniske beskrivelser i gennemførelsesforordning 2025/2392 og kernefunktionalitetstesten

Bilag III og IV til CRA nævner 26 produktkategorier på én linje hver. Kommissionens gennemførelsesforordning (EU) 2025/2392, i kraft siden den 21. december 2025, beskriver hver af dem teknisk, og Kommissionens vejledning af 27. juli 2026 siger, hvordan man klassificerer efter dem: efter produktets kernefunktionalitet, ikke efter hvad det også gør eller integrerer. Alle 26 beskrivelser ordret, vejledningens seks regler med dens eksempler (SOAR er ikke SIEM, en logviser er ikke SIEM, en router med firewall er en router), og hvad klassificeringen ændrer.

11. september 2026

Uret for den endelige CRA-rapport starter ikke, når I får kendskab

De fleste fremstillinger af artikel 14 i Cyber Resilience Act giver tre frister fra ét startpunkt: 24 timer, 72 timer, 14 dage. De to første løber fra kendskab. Den tredje gør ikke, og for en sårbarhed er dens anker en dato, der måske ikke findes endnu. Her står, hvad forordningen siger, stykke for stykke.

11. september 2026

Bøder under Cyber Resilience Act: hvad en lille producent reelt er udsat for

CRA fastsætter tre bødeniveauer, op til 15 millioner EUR eller 2,5 % af den globale omsætning. Her er, hvilke forpligtelser der ligger i hvilket niveau, hvem der håndhæver, og de to steder, hvor forordningen nævner små producenter.

8. september 2026

Hvilke EU-lande nævner ISO 27001 i offentlige udbud: 1.548 tyske bekendtgørelser, 829 polske, og Grækenland har den højeste andel

Over 365 dage optræder ISO 27001 i 3.415 TED-bekendtgørelser. Tyskland og Polen står for 70 % af dem, Grækenland nævner den i 2 % af alt, det køber, og Frankrig, Spanien og Italien nævner den knap nok. Her er tabellen, forespørgslen og hvad tallene betyder.

3. september 2026

Sådan besvarer I et sikkerhedsspørgeskema ud fra jeres ISO 27001 ISMS: 30 spørgsmålsemner kortlagt til de foranstaltninger i Bilag A, der besvarer dem

Næsten hvert sikkerhedsspørgeskema, en europæisk virksomhed modtager, spørger om de samme 30 emner. Her er kortlægningen fra hvert emne til de ISO 27001-foranstaltninger i Bilag A, det reelt handler om, og de fire registreringer, hvert svar bør bære.

3. september 2026

Bedste ISO 27001 compliance-software: hvad I skal spørge om, før I sammenligner funktioner

Antal integrationer er lette at sammenligne og afgør sjældent en audit. Her er de spørgsmål, der gør, herunder det ene, de fleste leverandører ikke vil besvare skriftligt.

20. august 2026

Billigste ISO 27001-certificering: sådan sammenligner I tilbud uden at købe et værdiløst certifikat

Tilbud fra certificeringsorganer varierer, men auditordagene bag dem er fastlagt af ISO/IEC 27006 Bilag B. Her er, hvordan I læser et tilbud, og den ene kontrol, der betyder mere end prisen.

20. august 2026

Den billigste vej til ISO 27001, og den del, I ikke kan gøre billigere

Det meste af et ISO 27001-budget er auditordage, og de fastlægges af en offentliggjort tabel frem for ved forhandling. Her er, hvad der faktisk rykker ved tallet, og hvad der ikke gør.

20. august 2026

Implementer ISO 27001 uden konsulenter: hvad I påtager jer, og hvad de fik pengene for

Det er fuldt ud muligt at blive certificeret uden en konsulent. Det er værd at vide først, hvad I selv optager, og hvilke dele der reelt har gavn af en, der har siddet på den anden side af bordet.

20. august 2026

ISO 27001-tjekliste, afsnit for afsnit

En tjekliste, der følger standardens egen struktur: afsnit 4 til 10 og hvad hvert af dem kræver, at I kan vise, plus det, Bilag A lægger til.

20. august 2026

ISO 27001 vs. NIS2: hvad certifikatet dækker, og hvad det ikke dækker

NIS2 er lov, og ISO 27001 er en certificerbar standard, så de er ikke alternativer. Her er, hvor et eksisterende ISMS opfylder direktivets krav, og de to steder, hvor det ikke gør.

20. august 2026

ISO 42001-certificering: hvad det er, og om det er for tidligt

ISO/IEC 42001 er standarden for AI-ledelsessystemer. Her er, hvad den kræver, hvordan den hænger sammen med en eksisterende ISO 27001, og en ærlig læsning af den aktuelle efterspørgsel.

20. august 2026

Omkostninger ved implementering af ISO 27001: tallet over tre år, ikke den første faktura

Certificering kører i en treårig cyklus med overvågningsaudits hvert år. At budgettere alene med den første audit er den mest almindelige måde, totalen overrasker på.

20. august 2026

Omkostninger ved ISO 27001-certificering for en virksomhed, efter antal medarbejdere

Auditordagene kommer fra tabellen i ISO/IEC 27006 Bilag B, så certificeringsomkostningerne følger antallet af medarbejdere mere end branchen. Her er regnestykket, og de poster, folk glemmer.

20. august 2026

Sådan får en virksomhed ISO 27001-certificering, i den rækkefølge det faktisk sker

Vejen fra ingenting til et certifikat, hvad der sker ved trin 1 og trin 2, og de registreringer en auditor spørger efter på hvert punkt.

20. august 2026

Hvor mange auditordage en ISO 27001-certificering tager, efter antal medarbejdere

Certificeringsorganer offentliggør ikke priser, men auditdagene er fastlagt af ISO/IEC 27006 Bilag B. Her er regnestykket, der omsætter jeres antal medarbejdere til et tal, før nogen giver jer et tilbud.

11. august 2026

ISO 27001 vs. SOC 2 i Europa: hvad købere faktisk spørger efter

Sælger I i Europa, så få ISO 27001: EU-udbud nævnte den 3.408 gange på et år, mod 104 for SOC 2. Sælger I til amerikanske kunder, er det omvendt. Tallene, den offentlige TED-forespørgsel til at køre dem igen, og hvornår I skal have begge.

11. august 2026