Fråga tre personer vad en kontroll är och du får tre svar. En kallar hela ramverket för en kontroll, en annan menar verktyget som upprätthåller en policy, och en tredje pekar på en skärmdump. Den förvirringen är själva anledningen till att så många efterlevnadsprogram kör fast. Orden ramverk, kontroll och bevis beskriver tre olika saker, och när du väl ser hur de hänger ihop blir hela programmet enklare att driva.
Det här inlägget definierar varje begrepp rakt på sak och visar hur de passar ihop. Om du bygger ditt första program, eller ärvde ett som vilar på kalkylark, är det här tankemodellen som håller det från att kollapsa under sin egen tyngd.
Ett ramverk är en uppsättning krav
Ett ramverk är en publicerad uppsättning krav som du åtar dig att uppfylla. SOC 2 Type II, ISO 27001, GDPR, NIS2 och DORA är alla ramverk. Vart och ett bryts ner i enskilda krav: ISO 27001 har sina åtgärder i bilaga A, SOC 2 har sina trust services-kriterier, NIS2 har sina åtgärder för riskhantering.
Ett ramverk talar om vad som är bra. Det talar inte om hur du tar dig dit, och det utför inget av arbetet. Se det som kursplanen inför en tenta. Det bestämmer frågorna du får, men att klara provet är upp till dig.
De flesta växande företag bär till slut fler än ett ramverk samtidigt. Du börjar med SOC 2 för att dina kunder frågar efter det, lägger till ISO 27001 för europeiska köpare, och sedan landar NIS2 eller DORA på dig på grund av branschen du säljer till. Varje ramverk kommer med sitt eget språk och sin egen revisor, och det är där överlappsproblemet börjar.
En kontroll är något du gör
En kontroll är en åtgärd eller ett skydd som du inför för att uppfylla ett eller flera krav. Kontrollerna är det faktiska arbetet i ditt program:
- att gå igenom vem som har åtkomst till produktion varje kvartal
- att kryptera data i vila och under överföring
- att göra bakgrundskontroller och säkerhetsutbildning vid onboarding
- att säkerhetskopiera system och testa att kopiorna går att återställa
- att kräva kodgranskning innan något släpps
En kontroll är en vana, inte ett dokument. Policyn som säger att "vi går igenom åtkomst varje kvartal" är inte kontrollen. Kontrollen är att genomgången faktiskt sker, enligt schema, med någon som är ansvarig för den. Ramverk beskriver utfall; kontroller är hur du åstadkommer dem.
Bevis är kvitto på att kontrollen kördes
Bevis är noteringen som visar att en kontroll faktiskt hände. Det är skillnaden mellan att säga att du går igenom åtkomst och att kunna bevisa att du gjorde det förra kvartalet.
Bevis tar många former:
- en export av åtkomstgenomgången, som visar vem som kontrollerade vad och när
- ett ärende som dokumenterar en offboarding, med tidsstämplar
- en skärmdump av en krypteringsinställning
- en signerad och daterad policy
- en loggpost, en rapport om genomförd utbildning, en ändringsnotering
Revisorer bedömer inte avsikter. De ber om bevis, och de kontrollerar att det täcker revisionsperioden och stämmer med kontrollen det ska stödja. Inget bevis betyder att kontrollen i praktiken inte hände, oavsett hur verklig den kändes för stunden.
En kontroll, flera ramverk
Här är insikten som förändrar hur du driver ett program: förhållandet mellan kontroller och krav är många-till-många. En enda kontroll uppfyller oftast krav i flera ramverk på en gång.
Ta kvartalsvisa åtkomstgenomgångar. Den enda kontrollen kopplas till ett kriterium om logisk åtkomst i SOC 2, en åtgärd om åtkomsträttigheter i ISO 27001 bilaga A, och ett krav på åtkomsthantering i NIS2. Samma genomgång, tre ramverk, tre krav uppfyllda. Kryptering i vila kopplas till krav i nästan varje ramverk du rör. Säkerhetsutbildning gör det också.
Team som missar det här bygger till slut parallella program, ett per ramverk, vart och ett med sitt eget kalkylark och sin egen bevismapp. De gör samma åtkomstgenomgång tre gånger, eller värre, de gör den en gång och kopierar beviset till tre ställen för hand, där det glider isär. Överlappet som borde spara dig arbete blir dubbelarbete och inkonsekvens i stället.
Lösningen är att hantera kontrollerna en gång och koppla var och en till varje krav den uppfyller, i varje ramverk. Då gör du arbetet en enda gång och det räknas överallt där det gäller.
Koppla kontroller till krav, inte ramverk till mappar
När du lägger till ett nytt ramverk, bygg inte om ditt program. Koppla de nya kraven till kontrollerna du redan kör. De flesta är redan täckta, och luckorna som återstår är ditt egentliga arbete.
Därför brister programmen vid bevisen
Ramverk är stabila. Kontroller håller mestadels när de väl är utformade. Bevisen är där programmen tyst faller isär, och det är värt att förstå varför.
Bevis är färskvara. En kontroll som kördes förra kvartalet behöver nytt kvitto det här kvartalet. En åtkomstgenomgång från januari täcker inte en revisionsperiod som slutar i december. Så bevis är inget du samlar in en gång; det är något du måste fortsätta samla in, i den takt varje kontroll kräver, för alltid.
Det är många små, återkommande uppgifter, och de är lätta att tappa. Någon gör åtkomstgenomgången men glömmer att spara exporten. Offboardingen sker i en chattråd som ingen hittar sex månader senare. Skärmdumpen bevisar att inställningen var rätt i mars men säger inget om i dag. När revisorn kommer var kontrollen verklig men beviset saknas, och ett saknat bevis läses precis som en saknad kontroll.
Kalkylark gör det värre. De håller reda på att en kontroll finns, men de kan inte rymma beviset, påminna någon om att förnya det, eller visa vilka krav som skulle fallera om ett bevis blev inaktuellt. Så programmet ser friskt ut ända fram till revisionen, då alla luckor dyker upp på en gång.
Så kopplar OptiTech ihop de tre
OptiTech modellerar ramverk, kontroller och bevis som sammankopplade poster i stället för separata dokument. I OptiTech Console är varje ramverks krav strukturerade poster, varje kontroll är en post du äger, och varje bevis kopplas till kontrollen det stödjer.
Eftersom posterna är länkade blir kopplingen många-till-många verklig i stället för teoretisk. Du definierar en kontroll en gång, kopplar den till varje krav den uppfyller i SOC 2, ISO 27001, GDPR, NIS2 och DORA, och fäster bevis vid den på ett ställe. Det enda beviset stödjer sedan varje krav kontrollen täcker. Förnya åtkomstgenomgången en gång och varje ramverk som är beroende av den uppdateras samtidigt.
Console håller även koll på takten. Varje kontroll vet hur ofta dess bevis behöver förnyas och flaggar vad som snart förfaller innan det blir inaktuellt, så att bevisinsamling blir rutin i stället för en stress inför revisionen. När ett krav i ett ramverk saknar kopplad kontroll, eller en kontroll saknar aktuellt bevis, ser du luckan direkt i stället för att upptäcka den i revisionsrummet.
Samma sammankopplade poster matar ditt trust center. Eftersom dina kontroller och deras bevis redan är aktuella och kopplade är säkerhetsställningen du publicerar för köpare densamma som din revisor ser. Du underhåller ett program och det svarar två publiker samtidigt.
Kom igång
Du behöver inte ha alla ramverk kopplade dag ett. En realistisk första omgång:
- Lista dina kontroller först, inte dina ramverk. Skriv ner vad du faktiskt gör för att hålla dig säker. De flesta företag kör redan fler kontroller än de tror.
- Koppla varje kontroll till kraven den uppfyller i ramverken du bär. Låt överlappet göra jobbet åt dig.
- Fäst bevis vid varje kontroll och sätt takten den behöver. Det är steget som håller vid en revision.
- Lyft fram luckorna. Krav utan kontroll, och kontroller utan aktuellt bevis, är din egentliga backlog.
Ramverk talar om vad du ska bevisa. Kontroller är hur du gör arbetet. Bevis är det som gör arbetet till något både en revisor och en köpare accepterar. Koppla ihop de tre en gång, håll bevisen aktuella, så slutar programmet vara en brandövning.
Vill du se dina ramverk, kontroller och bevis i ett sammankopplat program? Boka en demo så visar vi hur OptiTech kopplar en kontroll till varje krav den uppfyller.
