Läser in
Läser in
En digital NIS2-officer som körs varje natt. Bevakar policy, risk, leverantörer, incidenter och styrelsens kvartalsprotokoll mot Cybersäkerhetslagen (SFS 2025:1506). När något avviker skickar agenten ett konkret förslag till ansvarig användare. Föreslår, inte beslutar. Godkänner gör ni.
I Cybersäkerhetslagen 3 kap finns en utsedd säkerhetsansvarig som bär det operativa ansvaret för att de tio minimiåtgärderna enligt Art. 21(2) faktiskt finns på plats. Det är personen som tillsynsmyndigheten ringer till. Oftast är det en CISO eller en IT-chef som fungerar som de facto-säkerhetsansvarig. I styrelseprotokollet är det den person som styrelsen pekat ut med namn och rollbeskrivning.
Officer-rollen är inte en automatiserad funktion. Den kräver omdöme, sektorkännedom och förmåga att tolka vad som faktiskt utgör en incident, en kritisk risk eller en leverantör med betydelse för verksamheten. NIS2 Officer Always-On är en digital assistent som arbetar bredvid den utsedda säkerhetsansvariga, inte istället för den.
Det praktiska problemet är att den utsedda personen sällan hinner med det löpande nattarbetet. Riskregistret står stilla i sex månader. Leverantörscertifikat går ut utan att någon märker det. Incidentdeadliner från CERT-SE räknas i timmar. Styrelseprotokoll signeras inte i tid. Det är där den digitala officeren tar vid: den kollar varje natt, sammanställer underlag, skriver utkast och flaggar avvikelser. Beslutet ligger kvar hos människan.
Resultatet är att en organisation med en CISO på halvtid ändå kan upprätthålla en löpande operativ process som tillsynsmyndigheten kan granska, utan att anställa fler människor. Mer om hur det knyts till de tio mätbara kriterierna i audit-ready-garantin.
Sex schemalagda uppgifter mappade direkt mot Cybersäkerhetslagens artiklar. Ingen av dem skickar mejl, ändrar status eller kommunicerar med tillsynsmyndighet utan att en människa godkänner först.
Kontrollerar att den dokumenterade cybersäkerhetspolicyn är formellt antagen av styrelsen, har en aktuell version, och att den hänvisas till från riskbedömningen, leverantörsregistret och incidentprocessen. Om versionen är äldre än tolv månader skapas ett förslag om årlig översyn med utkast till styrelseprotokoll.
Söker efter risker med likelihood × impact ≥ 12 som saknar en mitigation eller har en mitigation utan ansvarig och deadline. Skapar ett förslag per kritisk risk: kort sammanfattning, hänvisning till råddata och ett föreslaget åtgärdsspår mappat mot rätt minimiåtgärd.
Kör externa TLS-checkar på leverantörens publika ändpunkter, matchar leverantörens domän mot CERT-SE:s RSS-flöden och kontrollerar att uppladdade bevis (ISO 27001-certifikat, SOC 2-rapporter, DPA) inte gått ut. Vid utgången skapas ett mejlutkast till leverantörens kontaktperson med begäran om uppdaterat dokument.
Kollar att alla aktiva incidenter respekterar tidslinjen. 24 timmars förvarning till CERT-SE, 72 timmars formell anmälan, en månad slutrapport. Om en deadline är inom 6 timmar och underlaget inte är klart, eskaleras förslaget till säkerhetsansvarig och dennes ställföreträdare via mejl och i plattformens inkorg.
Letar efter kvartalsrapporten till styrelsen. Saknas signering med digital ID, eller är protokollet inte uppladdat före utgången av månaden efter kvartalsslutet, skapar agenten ett utkast baserat på senaste data och föreslår en kallelse. Säkerställer att styrelsens personliga ansvar är dokumenterat.
Bevakar BCP-mallen: kritiska processer, krisroller, RTO och RPO. Plattformen kräver minst en testkörning per år och agenten påminner när nästa övning närmar sig 60-dagarsfönstret. Saknas dokumentation av senaste testet skapas ett förslag om planering med ansvarig övningsledare.
Allt som agenten producerar landar i tabellen agent_proposals, som är en kö för manuellt godkännande på ytan /granskningslogg och den interna sidan /agent-forslag. Ingen åtgärd lämnar plattformen utan att en användare med rollen säkerhetsansvarig eller administratör tryckt godkänn.
Varje körning loggas separat i tabellen agent_runs: starttid, sluttid, modell och version, antal förslag, status och hashvärde över input. Tillsammans bildar de två tabellerna en oavbruten kedja från lagrum via agentlogik till mänskligt beslut. Båda tabellerna är append-only via databastriggers.
Säkerhetsmodellen är read-only på operativ data. Officer-agenten kan läsa policyer, risker, leverantörer, incidenter och styrelseprotokoll. Den kan inte ändra dem. Den kan inte skicka mejl. Den kan inte ringa CERT-SE. Den skriver utkast och hänvisar till källa, sedan väntar den.
Cybersäkerhetslagen pekar ut sektorvisa tillsynsmyndigheter utöver MCF. Officer-agenten anpassar bevakning, formulär och rapportmottagare per sektorprofil. En bank får utkast riktade till Finansinspektionen, ett vårdbolag till IVO, en telekomoperatör till PTS. Det är inte en estetisk skillnad, det avgör vilket diary-id som loggas och vilken rapportmall som används.
Plattformen täcker 18 sektorer per den svenska implementationen. Hela listan finns på /ai-act/sektor.
Lika viktigt att säga rakt ut. Officer-agenten är ett hjälpmedel, inte en ersättare. Tre tydliga gränser.
Se hela audit-ready-garantinAgenten kan inte ändra leverantörens status, kan inte publicera ny policy, kan inte skicka in incidentanmälan till CERT-SE. Det skiljer den från RPA-verktyg som driver andra system. Här är gränsen avsiktlig: läsbehörighet, inget mer.
Cybersäkerhetslagen 3 kap kräver en utsedd, namngiven person hos er. Den rollen kvarstår oavsett vilken plattform ni använder. Agenten avlastar nattarbete och underlag, men personen står kvar i styrelseprotokollet.
Audit-ready uppstår när tio mätbara kriterier är uppfyllda under 60-dagars-fönstret. Agenten kollar status varje natt och flaggar luckor, men kriterierna fylls i av människor. Hela mekaniken finns i /audit-ready-garanti.
Sprint kostar 79 000 kr exklusive moms och tar er till audit-ready på 60 dagar (eller pengarna tillbaka). Always-On ligger sedan på 36 000 kr per år och driver officer-agenten löpande. Demo är 30 minuter mot er sektorprofil. Pris och villkor finns på /priser. Snabb omfattningsbedömning på /nis2-quiz.
Ja. Cybersäkerhetslagen 3 kap kräver en utsedd ansvarig hos den verksamhetsutövande organisationen, och styrelsen bär det yttersta ansvaret enligt 2 kap. NIS2 Officer Always-On ersätter inte den rollen. Agenten avlastar det löpande nattarbetet (kollar status, sammanställer underlag, skriver utkast) så att den utsedda säkerhetsansvariga kan ägna tiden åt beslut, prioritering och dialog med tillsynsmyndigheter. Allt som agenten producerar är förslag som passerar manuell granskning.
Agentens körningar lagras i tabellen agent_runs i 24 månader, vilket matchar bevarandekravet i Cybersäkerhetslagen för underlag inför tillsyn. Förslag i tabellen agent_proposals sparas tills de är godkända, avvisade eller arkiverade, och behåller sedan en signerad logg i ytterligare 24 månader. Vid uppsägning kan all agentdata exporteras som strukturerad JSON plus PDF-protokoll inom 30 dagar.
Officer-agenten använder Anthropic Claude Sonnet 4.5 som primär modell för textgenerering och Claude Haiku 4.5 för enklare statuskontroller där hastighet och kostnad väger tyngre. Modellanrop går via en EU-region, ingen kunddata används för träning, och varje anrop loggas med modell, version och promptlängd så att modellbyten kan revideras i efterhand. Vid större modelluppgraderingar testar vi mot en regressionssvit innan default-modellen byts.
Risken finns i alla generativa modeller och hanteras med tre lager. Först: agenten har bara läsbehörighet till plattformens egna data, så ett förslag måste alltid hänvisa till ett konkret objekt (en policy-rad, ett risk-id, en leverantör, en incident). Andra: alla förslag passerar en mänsklig godkännare via /agent-forslag innan något skickas vidare eller ändrar status. Tredje: vi lagrar full prompt och full svarstext i agent_runs så att en granskare kan följa hela kedjan vid efterhandsbedömning.
Ja. Varje körning skriver en rad till agent_runs med starttid, sluttid, modell, antal förslag, status och ett hashvärde över input. Förslag skrivs till agent_proposals med koppling till källobjektet. Båda tabellerna är append-only på databasnivå genom en trigger som blockerar UPDATE och DELETE från applikationskontot. PTS, MCF och sektorvis tillsynsmyndighet kan begära ut hela loggen som signerad CSV via /granskningslogg.
Officer-agenten är schemalagd nattligt klockan 02:00 till 04:00 svensk tid med ett fönster på sex timmar för retry. Om Anthropic är otillgängligt försöker agenten åter två gånger med exponentiell backoff. Om det fortfarande misslyckas registreras körningen som status failed i agent_runs, ansvarig användare får ett mejl, och nästa nattliga schema fortsätter normalt. Det är ett känt fall i kontinuitetsplanen: en utebliven körning är inte en compliance-incident, eftersom regelverket kräver löpande process, inte att den sker varje 24 timmar.
Agenten är medveten om att MCF (tidigare MSB, omdöpt 2026-01-01) är tillsynsmyndighet för delar av Cybersäkerhetslagen, att PTS är tillsynsmyndighet för digital infrastruktur och telekom, och att CERT-SE är CSIRT-funktionen där incidentrapporter enligt 4 kap registreras. När agenten genererar utkast till incidentanmälan adresseras CERT-SE. När den genererar tillsynsunderlag adresseras rätt sektorvis myndighet enligt organisationens registrerade sektorprofil.
Nej. Förslag på utgående mejl (till leverantör, styrelse, tillsynsmyndighet eller CERT-SE) genereras som förhandsgranskad PDF eller HTML. Innan något lämnar plattformen krävs en manuell godkännandehandling från en användare med rollen säkerhetsansvarig eller administratör. Det är samma princip som för alla andra förslag: agenten skriver utkast, människor klickar.