En kravspecifikation för ett compliance system måste koppla GDPR, Cybersäkerhetslagen och ISO-krav till spårbar, testbar funktionalitet. Det handlar konkret om stöd för DPIA, incidentloggning, leverantörsbedömning och revisionsspår. Utan tydliga acceptanskriterier och klar ansvarsfördelning blir kravspecen ett önsketänkande snarare än ett styrdokument som leverantören faktiskt kan bygga mot.
Kort sagt:
- En kravspecifikation måste koppla GDPR, Cybersäkerhetslagen och ISO-krav till testbara funktioner som DPIA, incidentlogg och leverantörsbedömning.
- Kraven ska vara tydligt spårbara med unika ID:n, kopplas till lagrum och ha mätbara acceptanskriterier för att kunna verifieras vid revision.
- Regulatoriska krav kräver löpande dokumentation av DPIA, konkreta incidentscenarier och scenariotestning för att uppfylla krav på rapportering och transparens.
- Teknisk implementering av krav bör inkludera oföränderlig loggning, API-integrationer, rollbaserad behörighet och exportmöjligheter för att säkerställa spårbarhet.
- Att omsätta kravspecifikationen i praktiken underlättas av plattformar som stödjer DPIA, incidenthantering och automatiserade processer, samt att krav uppdateras i takt med lagändringar.
Innehållsförteckning
- Vad en kravspecifikation bör innehålla: funktionella och icke-funktionella krav
- Regulatoriska krav i Sverige som styr kravspecen: DPIA, Cybersäkerhetslagen och AI-förordningen
- Tekniska och operativa krav: integrationer, loggar, roller och leverantörsbedömning
- Steg för steg: skapa kravspecifikationen med checklista och acceptanskriterier
- Trustview-perspektiv: att förena juridik och teknik i praktiken
- Så kan Trustview hjälpa er omsätta kravspecifikationen i praktiken
- Källor
- Vanliga frågor
Vad en kravspecifikation bör innehålla: funktionella och icke-funktionella krav
En komplett kravspecifikation delar in kraven i två kategorier som båda måste vara mätbara. Funktionella krav beskriver vad systemet ska göra: föra register över behandlingsaktiviteter, stödja konsekvensbedömningar, hantera leverantörsbedömningar och logga incidenter. Icke-funktionella krav beskriver hur väl systemet ska göra det, exempelvis drifttid, svarstider och säkerhetsnivå.
En kravspecifikation fungerar som bindemedel mellan verksamhetens mål och den tekniska leveransen, och bra praxis bygger på unika krav-ID, tydliga acceptanskriterier och en prioriteringsmetod som MoSCoW. Utan den strukturen blir det svårt att senare bevisa att systemet faktiskt levererar det som krävdes.
- Funktionella krav: registerförteckning, DPIA-stöd, leverantörsbedömning och incidentlogg.
- Icke-funktionella krav: säkerhetsnivå, tillgänglighet, prestanda och SLA-villkor.
- Spårbarhet: varje krav får ett unikt ID kopplat till relevant lagrum och till en revisionslogg.
- Acceptanskriterier: mätbara KPI:er som avgör om kravet är uppfyllt, inte bara beskrivet.
Ett krav som “systemet ska vara säkert” går inte att testa. Ett krav som anger exakt vilken kryptering som krävs, vilken återställningstid som gäller vid driftstopp och vilka loggar som ska bevaras går det att testa.
Regulatoriska krav i Sverige som styr kravspecen: DPIA, Cybersäkerhetslagen och AI-förordningen
Den svenska regleringen sätter en lägstanivå för vad kravspecen måste täcka, och tre regelverk är särskilt styrande.
IMY slår fast att en konsekvensbedömning enligt GDPR artikel 35 är obligatorisk när en behandling sannolikt leder till hög risk, och att bedömningen ska vara en löpande, dokumenterad process snarare än en engångsinsats. Det betyder att kravspecen måste innehålla funktionalitet för att uppdatera och spåra DPIA över tid, inte bara skapa den en gång.
Cybersäkerhetslagen införlivar NIS2 i svensk rätt och skärper kraven på incidentrapportering för berörda verksamhetsutövare. Enligt MSB:s material trädde lagen i kraft den 15 januari 2026, och från den 1 juli 2026 rapporteras incidenter till Myndigheten för civilt försvar, NCSC, inom FRA. Kravspecen bör därför formulera konkreta scenariotester, inte bara beskrivande krav.
AI-förordningen ställer separata dokumentations- och transparenskrav på generativ AI och så kallade GPAI-modeller, och DIGG:s riktlinjer visar att ansvaret skiljer sig beroende på om organisationen agerar leverantör eller tillhandahållare.
- DPIA: obligatorisk vid hög risk, ska dokumenteras löpande.
- Cybersäkerhetslagen/NIS2: skärpta rapporteringskrav och ny mottagare för anmälan från sommaren 2026.
- AI-förordningen: särskilda dokumentationskrav beroende på organisationens roll.
Tekniska och operativa krav: integrationer, loggar, roller och leverantörsbedömning
När regelverken är kartlagda ska de omsättas i teknisk precision som en leverantör eller intern utvecklingsavdelning kan bygga mot.
- Integrationer: krav på API, enkel inloggning via SSO eller IdP, och koppling till SIEM-system för säkerhetsövervakning.
- Exportfunktioner: möjlighet att exportera revisionsdata i format som går att granska externt.
- Oföränderlig loggning: en audit trail som inte kan redigeras i efterhand, vilket är avgörande vid en faktisk revision.
- Roller och behörigheter: rollbaserad åtkomst (RBAC) med möjlighet att delegera ansvar och sätta upp attestflöden.
- Incidenthantering: larmfunktion, ärendeflöde och export anpassad för anmälan till NCSC eller IMY.
- Leverantörsbedömning: färdiga mallar, riskklassning och statusuppföljning över tid.
Proffstips: Formulera incidentkravet som ett scenario, exempelvis “visa hur en incidentrapport exporteras till NCSC inom lagstadgad tidsfrist”, istället för en allmän beskrivning av att systemet ska stödja incidenthantering.
En praktisk guide om incidentrapportering beskriver samma princip: tidsfrister och exportformat behöver vara testbara, inte bara dokumenterade i löpande text. ISO/IEC 27001-ramverket ger samtidigt ett bra underlag för att definiera tekniska säkerhetskontroller som mätbara icke-funktionella krav.
Steg för steg: skapa kravspecifikationen med checklista och acceptanskriterier
Att skriva en kravspecifikation är en process i flera steg, inte ett enskilt dokument som skrivs klart på en eftermiddag.
- Kartlägg intressenter och mål. Identifiera vilka roller som berörs: jurister, IT-säkerhet, dataskyddsombud och ledning.
- Gör en regulatorisk kartläggning. Lista vilka regelverk som gäller er verksamhet, inklusive GDPR, Cybersäkerhetslagen och eventuellt AI-förordningen.
- Prioritera kraven med MoSCoW. Dela in i måste, bör, kan och inte nu, så att leverantören vet vad som är förhandlingsbart.
- Definiera acceptanskriterier och testfall. Varje krav ska gå att verifiera med ett konkret test, inte bara en beskrivning.
- Bygg en spårbarhetsmodell. Koppla varje krav-ID till relevant lagrum, tillhörande testfall och revisionsbevis.
- Pilottesta och verifiera. Kör ett verkligt revisionsscenario mot systemet innan ni skriver under kravspecen slutgiltigt.
En metodik för kravhantering understryker att krav aldrig bör behandlas som en engångsaktivitet. Utan digital spårbarhet blir det svårt att bevisa efterlevnad vid en revision flera år senare, vilket gör spårbarhetsmodellen till den enskilt viktigaste delen av arbetet.
- Checklista inför leverans: krav-ID finns för varje punkt, acceptanskriterier är mätbara och ansvarig roll är namngiven.
- Plan för uppdatering: kravspecen revideras när lagstiftningen ändras, inte bara vid systembyte.
Trustview-perspektiv: att förena juridik och teknik i praktiken
Ett compliance system löser aldrig hela uppgiften på egen hand, oavsett hur väl kravspecen är skriven. Plattformar för compliance kan samla registerförteckning, konsekvensbedömningar, leverantörsbedömning och ansvarsfördelning i samma struktur. Det gör det möjligt att koppla varje krav till ett lagrum och ett revisionsbevis på samma sätt som kravspecen bör göra från start.
Men verktyget räcker inte utan processförankring. ISO 37301 betonar att hållbar efterlevnad kräver ledningens engagemang och tydlig rollfördelning, inte bara ett system som samlar data. Organisationer som hoppar över det steget riskerar att ha rätt teknik men fel arbetssätt, vilket gör kravspecens krav på roller och attestflöden lika viktiga som de tekniska integrationerna.
— Jesper
Så kan Trustview hjälpa er omsätta kravspecifikationen i praktiken
Att skriva en kravspecifikation är ett steg, att faktiskt driva den i drift är ett annat. Trustview samlar de funktioner som den här artikeln listar som krav: stöd för DPIA, mallar för leverantörsbedömning, automatiserade register och realtidsrapporter som kan användas som revisionsbevis.
Plattformen kostar från 2 500 kronor per månad, och för organisationer som behöver hjälp att tolka specifika regelkrav finns juridisk rådgivning som tillägg. Boka en demo för att se hur kravspecens punkter om spårbarhet och incidenthantering ser ut i en faktisk plattform, eller läs mer om varför en svensk leverantör kan göra skillnad för tolkningen av svensk lagstiftning.
Källor
För vidare läsning rekommenderas IMY:s vägledning om konsekvensbedömningar, MSB:s material om Cybersäkerhetslagen och anmälningsrutiner, samt SIS:s standard SS-ISO 37301:2021 för ledningssystem kopplade till regelefterlevnad.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
- Hur ska en konsekvensbedömning genomföras? | IMY
- Incidentrapportering och informationsskyldighet (MSB/Rib)
Vanliga frågor
Vad måste en kravspecifikation för compliance innehålla?
Den ska innehålla funktionella krav som registerförteckning, DPIA-stöd och incidentlogg, samt icke-funktionella krav som säkerhet och tillgänglighet. Varje krav behöver ett unikt ID kopplat till lagrum och ett testbart acceptanskriterium.
Hur kopplas GDPR och Cybersäkerhetslagen till systemkraven?
GDPR kräver enligt IMY en löpande dokumenterad konsekvensbedömning vid hög risk, vilket ska synas som funktionalitet i systemet. Cybersäkerhetslagen skärper kraven på incidentrapportering, och från den 1 juli 2026 går anmälan till Myndigheten för civilt försvar, enligt MSB:s material.
Vilka tekniska krav är viktigast för revisionsspårbarhet?
Oföränderlig loggning, så kallad audit trail, är central eftersom den visar att data inte har manipulerats i efterhand. Rollbaserad åtkomst och exportfunktioner för revisionsdata är också avgörande för att snabbt kunna styrka efterlevnad.
Vilken metod används för att prioritera krav i kravspecen?
MoSCoW-metoden, som delar in krav i måste, bör, kan och inte nu, är en vanlig modell enligt Genesis kunskapsbank. Den gör det tydligt för leverantören vilka krav som är förhandlingsbara och vilka som är absoluta.
Vad kostar ett compliance system som Trustview?
Trustview kostar från 2 500 kronor per månad, med möjlighet att lägga till juridisk rådgivning för specifika frågor om kravtolkning. Priset gäller plattformen och kan variera beroende på organisationens behov.
