Ett GRC-system fungerar för en seriös organisation först när det klarar centrala krav: kontrollmappning mot standarder, historiserade audit-loggar, tydlig hostingort och smidig integration med SSO. Stöd för ISO/IEC 27001, NIS2 och DORA avgör ofta om du kan visa bevis för tillsynen. Vi på Evertrust kombinerar rådgivning med plattformen Trustview.
Kort sagt:
- Be leverantören visa hur en kontroll kopplas till flera standarder och hur samma bevis återanvänds, samt begär en konkret export under demonstrationen.
- Kräv ändringsloggar som visar vem som ändrade vad och när, och kontrollera att vanliga administratörer inte kan redigera eller radera historiken.
- Om verksamheten omfattas av NIS2 eller DORA, kontrollera att systemet kopplar riskbehandling, incidentrapporter och leverantörsavtal till ansvariga och dokumenterade exitplaner.
- Begär skriftligt besked om var data lagras och vilka underleverantörer som får åtkomst, och testa en läsbar export i öppet format redan under piloten.
- En pilot tar ofta några veckor, men kostnaden påverkas främst av anpassningar, integrationer, datamigrering och konsulttid; fastställ därför godkännandekrav före start och inför systemet stegvis.
Innehållsförteckning
- Vilka funktioner måste ett GRC-system ha?
- Hur påverkar NIS2, DORA och ISO 27001 kraven?
- Vilka tekniska krav ska du ställa på hosting, loggar och exit?
- Hur väl måste systemet integreras och skala?
- Hur går en implementering till och vad kostar den?
- Vilka frågor ska du ställa under upphandling och demo?
- Så prioriterar vi i praktiken
- Hur hanterar systemet användarroller och behörigheter?
- Vilken automatisering och vilka arbetsflöden sparar mest tid?
- Vad bedömer vi är viktigast att få rätt först?
- Så kan vi stödja urval och implementation
- Vanliga frågor
- Källor
Vilka funktioner måste ett GRC-system ha?
Ett system som bara samlar dokument räcker inte. Du behöver funktioner som knyter ihop styrning, risk och efterlevnad i det dagliga arbetet, så att samma underlag kan användas flera gånger.
- Riskregister: mallar för riskbedömning, tydliga ägare och en direkt koppling mellan varje risk och dess åtgärdsplan.
- Kontrollkatalog med multistandardmappning: en kontroll ska kunna kopplas till flera regelverk samtidigt, så att samma bevis återanvänds i stället för att tas fram på nytt för varje revision.
- Policy- och dokumenthantering: versionshistorik, godkännandeflöden och tydlig information om vem som godkände vad och när.
- Incidenthantering: spårbar registrering från upptäckt till avslut, med koppling till de rapporteringsprocesser som gäller för er verksamhet.
- Ledningsrapporter och dashboards: översikter som styrelsen faktiskt läser, med status på risker, avvikelser och kontrollernas mognad.
Fråga alltid hur funktionerna hänger ihop. Ett riskregister som inte pekar mot kontroller och incidenter blir snabbt ett fristående kalkylblad. Be leverantören visa en risk som följs hela vägen: från identifiering via kontroll och åtgärd till rapport. Om kedjan bryts på vägen kommer ni att fylla luckorna manuellt, och det är precis den typen av arbete ett GRC-system ska ta bort.
Hur påverkar NIS2, DORA och ISO 27001 kraven?
Regelverken bestämmer vilken typ av bevis systemet måste kunna producera. Därför är standardstöd ett urvalskriterium och inte en bonus. ENISA:s tekniska vägledning rekommenderar att organisationer kräver mappning av kontroller mot etablerade standarder som ISO/IEC 27001:2022 och NIST CSF 2.0, eftersom det underlättar rapportering till tillsynsmyndigheter.
Den tekniska bilden preciseras i genomförandeförordning 2024/2690, som tar upp policykrav för riskhantering, incidenthantering, leverantörssäkerhet, kryptografi och åtkomstkontroll. Systemet bör därför kunna lagra och koppla just dessa områden. ISO 27001 används dessutom ofta som frivillig standard i många sektorer, vilket framgår av ENISA:s översikt om revision av säkerhetsåtgärder.
Det här bör systemet hjälpa dig visa:
- policyer med tydlig version och godkännande
- riskbehandlingsplaner kopplade till identifierade risker
- incidentrapporter med tidsstämplar och ansvariga
- avtal och exitplaner för kritiska leverantörer, något DORA lägger särskild vikt vid
Vill du se hur tidsplanen kan se ut för ledningen finns vår guide om NIS2-kraven och ledningens nästa steg. För finanssektorn är DORA, testning och motståndskraft ett naturligt nästa steg.
Vilka tekniska krav ska du ställa på hosting, loggar och exit?
Här skiljer sig system som ser bra ut i en demo från system som håller vid en granskning. Tillsynen vill kunna följa en händelse bakåt i tiden, och då måste tekniken stå på egna ben.
- Datasuveränitet: be om skriftlig information om var data lagras och behandlas, och vilka underleverantörer som har åtkomst.
- Historiserade audit-loggar: varje ändring ska spara vem som gjorde den, när och vad som ändrades. Loggarna ska inte kunna redigeras av vanliga administratörer.
- Kryptering: data ska skyddas både i vila och under överföring, och privilegierade konton ska hanteras med särskild kontroll.
- Exit: testade exportfunktioner, migrationsstöd och tydliga kommersiella villkor för uttag av data. Kravet kommer från DORA:s syn på kontrakt och exitstrategier för molntjänster.
Leverantörskedjan väger tungt. ENISA beskriver i sina goda exempel för leveranskedjans cybersäkerhet hur strategisk leverantörshantering, kontinuerlig riskbedömning och dokumenterade avtal hör ihop. Läs också vår genomgång av tredjepartsrisker i GRC.
Proffstips: Begär en riktig dataexport i ett öppet format redan under pilotfasen. Ett system som är svårt att lämna är ett system ni riskerar att fastna i.
Hur väl måste systemet integreras och skala?
Ett GRC-system lever eller dör med användningen. Om det kräver dubbelregistrering mot era övriga system kommer folk att undvika det.
- Integrationer: API och SSO är grundkrav. Kontrollera även koppling mot katalogtjänst, SIEM, CMDB och HR-system, så att användare, tillgångar och händelser inte matas in för hand.
- Adoption: ett enkelt gränssnitt, rollbaserad åtkomst och utbildningsmaterial som verkligen finns på plats avgör hur många som använder systemet efter den första tiden.
- Skalbarhet: systemet ska fungera i en pilot med ett fåtal användare och i full drift med flera avdelningar, utan att allt behöver byggas om. Fråga hur nya enheter, regelverk och kontrollramverk läggs till.
Frågor om dataflöden mellan system bör också prövas ur ett dataskyddsperspektiv. Ett användbart exempel på hur sådana frågor kan ställas finns i verifierande frågor för ett GDPR-kompatibelt CRM, som går att låna idéer från även när det gäller GRC.
Hur går en implementering till och vad kostar den?
Tidsåtgången beror på omfattning, men förloppet följer oftast samma ordning.
- Pilot: ofta några veckor, med ett begränsat område och tydliga mål.
- Konfiguration: roller, kontrollkatalog, riskskalor och rapportmallar anpassas.
- Migrering: befintliga risker, policyer och bevis flyttas över och rensas.
- Utbildning: användare och ägare får genomgång av sina egna uppgifter.
- Driftstart: stegvis lansering, avdelning för avdelning.
Kostnaden styrs framför allt av anpassningar, integrationer, datamigrering och extern konsulttid. Sätt därför acceptanskriterier innan ni startar: vad måste fungera för att piloten räknas som godkänd? Stegvis lansering ger dig chansen att rätta till brister medan antalet användare ännu är litet. Ett praktiskt stöd för upplägget finns i vår guide till ISMS-implementering för beslutsfattare.
Vilka frågor ska du ställa under upphandling och demo?
Gå in med en lista och be om bevis, inte löften. Det som visas live väger tyngre än det som står i en broschyr.
- Visa hur en kontroll mappas mot flera standarder och hur samma bevis återanvänds. Be om ett konkret exempel och en exportfil.
- Visa audit-loggen för en ändrad policy, med ansvarig person och tidpunkt.
- Genomför en dataexport under demon och kontrollera att filen går att läsa utan leverantörens verktyg.
- Anslut SSO och gör ett API-anrop mot en testmiljö.
- Be om uppgifter om SLA, supportnivåer, utbildningspaket och dokumentation, och kräv att de skrivs in i offerten.
- Fråga var data lagras och vilka underleverantörer som finns.
Proffstips: Skicka kravlistan till alla leverantörer i förväg och be om skriftliga svar. Jämförbara svar gör urvalet mycket enklare och sparar tid i beslutsgruppen.
Behöver ni hjälp att formulera kraven kan vår riskanalys för informationssäkerhet med mall vara en bra utgångspunkt.
Så prioriterar vi i praktiken
Börja med de regelverk som faktiskt gäller er, till exempel GDPR, ISO/IEC 27001 och NIS2 eller DORA, och bygg kontrollmappningen runt dem först. Resten kan komma i nästa steg. När rådgivning och plattform arbetar tillsammans kan våra jurister och specialister tolka kravet medan plattformen stödjer compliance-arbetet. Involvera tidigt styrelse eller ledning, IT, juridik, dataskyddsombud och säkerhetsteam. Utan dem blir systemet ett verktyg som ingen äger.
Hur hanterar systemet användarroller och behörigheter?
Behörighetsstyrning är ett av de mest underskattade kraven. I ett GRC-system ligger känslig information: oavslutade risker, incidenter och svagheter i kontroller. Fel person med fel åtkomst kan skapa större skada än den risk som beskrivs.
Kräv rollbaserad åtkomst där rättigheter följer uppgiften och inte personen. En riskägare ska se och uppdatera sina egna risker, en revisor ska ha läsrätt utan möjlighet att ändra, och en administratör ska inte kunna radera historik. Principen om minsta möjliga behörighet bör gå att konfigurera, och systemet ska kunna separera uppgifter så att den som godkänner inte är samma person som skapar.
Kontrollera även att behörigheter kan ges per enhet, land eller avdelning om ni är en större organisation. Be att få se en rapport över vem som har åtkomst till vad, och hur ofta behörigheter omprövas. Kopplingen till er katalogtjänst är viktig: när någon byter roll eller slutar ska åtkomsten följa med automatiskt, annars växer behörigheterna i tysthet. Se till att alla ändringar av roller och rättigheter också hamnar i audit-loggen, eftersom tillsynen ofta frågar efter just detta. Frågor om vem som ansvarar för vad hänger nära ihop med dataskyddsombudets ansvar, som är bra att läsa när ni fördelar roller.
Vilken automatisering och vilka arbetsflöden sparar mest tid?
Automatisering är värd sitt pris när den tar bort rutinarbete som annars glöms bort. Det gäller påminnelser, godkännanden och uppföljning, och mindre de avancerade funktionerna som mest ser bra ut i en presentation.
Titta först på arbetsflöden för det som återkommer: periodisk granskning av policyer, uppföljning av åtgärder med förfallodatum, årliga riskbedömningar och leverantörsutvärderingar. Systemet ska kunna skicka påminnelser, eskalera när något försenas och föra över godkännanden till rätt person utan att någon behöver skriva ett mejl.
Nästa nivå är att bevis samlas automatiskt. Om en kontroll kräver att en loggfil, ett certifikat eller en rapport finns på plats ska systemet kunna hämta eller påminna om det, så att underlaget är färskt när revisorn frågar. Det minskar den klassiska veckan av panikinsamling före en granskning.
Var samtidigt kritisk. Ett arbetsflöde som är för stelt tvingar användarna att hitta kringvägar. Be om möjlighet att själva justera flöden utan att anlita leverantören för varje ändring, och testa att ett flöde går att pausa och ändra mitt i en pågående process. Bra automatisering hjälper dig att följa processen. Dålig automatisering gör den bara svårare att ändra.
Vad bedömer vi är viktigast att få rätt först?
Den vanligaste missen är att välja efter funktionslistor. Nästan alla system kan visa ett riskregister och en dashboard. Skillnaden syns först när någon frågar efter bevis: går det att visa vem som beslutade vad, varför, och vad som hände sedan?
Därför bör du vända på upphandlingen. Börja med de viktigaste frågorna som en tillsynsmyndighet eller revisor faktiskt kommer att ställa, och kräv att systemet kan besvara dem live. Allt annat är sekundärt. Räkna också med att verktyget aldrig räddar en organisation som saknar ägarskap. Ett system utan utsedda ansvariga blir snabbt ett arkiv.
Den mest överskattade funktionen är den snygga dashboarden. Den imponerar på demodagen men säger lite om efterlevnad. Den mest underskattade är exit: att veta att du kan lämna ger dig förhandlingskraft och trygghet. Lägg därför energin på kontrollmappning, loggar och dataexport först, och på ytan sist.
— Jesper
Så kan vi stödja urval och implementation
Vi hjälper dig att gå från kravlista till fungerande bevisföring. Tillsammans med plattformen Trustview erbjuder vi rådgivning kring hur du kan visa att kraven är uppfyllda.
- Gap-analyser och konsekvensbedömningar (DPIA) som visar var luckorna finns
- Interim compliance officer och dataskyddsombud när ni saknar egen resurs
- Trustview för hantering av regelefterlevnad
Boka rådgivning och konsulttjänster, så går vi igenom era krav tillsammans.
Vanliga frågor
Vad står GRC för?
GRC står för Governance, Risk och Compliance, alltså styrning, riskhantering och regelefterlevnad. Tanken är att hantera dessa tre områden samlat i stället för i separata silos. Läs mer i vår guide om vad GRC är.
Vad gör en GRC-specialist?
En GRC-specialist översätter regelverk och risker till rutiner, kontroller och bevis som organisationen kan följa. Rollen innebär ofta att driva riskbedömningar, samordna internt arbete inför granskningar och rapportera till ledningen. Många organisationer tar in extern hjälp när kompetensen saknas.
Vilka krav är viktigast när jag väljer GRC-system?
De viktigaste kraven är kontrollmappning mot de standarder ni omfattas av, historiserade audit-loggar, tydlig hostingort och testad dataexport. Därefter kommer integration med SSO och API samt användbarhet, eftersom ett system som ingen använder inte ger något bevisvärde.
Behöver ett GRC-system stödja NIS2 och DORA?
Det beror på vilka regelverk er verksamhet omfattas av. Om ni gör det bör systemet kunna visa riskhantering, incidentrapportering, leverantörsstyrning och exitplaner på ett spårbart sätt. Kontrollera stödet genom att be om konkreta exempel under demon.
Hur lång tid tar det att införa ett GRC-system?
Tiden varierar med omfattning och integrationer. En pilot brukar ta några veckor, och därefter följer konfiguration, migrering, utbildning och stegvis driftstart. Tydliga acceptanskriterier gör att du kan avgöra när varje steg är klart.
