Läser in
Vid acceptans laddas Google Analytics 4. Inget körs om ni avböjer. Integritetspolicy ·
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.
Cybersäkerhetslagen (SFS 2025:1506) namnger ingen specifik säkerhetsansvarig-roll. Lagen kräver däremot i 2 kap. 3 § att verksamhetsutövaren vidtar de tio minimiåtgärderna och i 2 kap. 4 § att personer i ledningen genomgår utbildning om säkerhetsåtgärder. I praktiken utser de flesta organisationer en CISO eller IT-chef som operativ säkerhetsansvarig, det är personen som tillsynsmyndigheten ringer till och som styrelsen pekar ut i styrelseprotokollet med namn och rollbeskrivning, även om det är ett internt val snarare än ett uttryckligt lagkrav.
NIS2 Officer-funktionen kombinerar nattlig automation och mänsklig prövning. Plattformen kör fyra schemalagda jobb i Postgres-cron, alla mappade mot Cybersäkerhetslagen 2 kap. Officer-kärnan körs nattligt 02:00 UTC och granskar policy, riskregister, styrelseprotokoll och kontinuitetsplan i en samlad körning. En operativ NIS2-snapshot per område beräknas 02:17 UTC. Extern leverantörscheck körs 03:15 UTC. Incidentdeadlines bevakas var 30:e minut. Styrelsens kvartalsrapport är ett separat kvartalsvis jobb. Förslag presenteras i en åtgärdskö på /agent-forslag. Inga ändringar görs i ert riskregister, era policyer eller mot tillsynsmyndighet utan att en namngiven användare godkänner.
Den automatiserade delen ersätter inte den utsedda säkerhetsansvariga. Bedömning av vad som är en incident, vilken risk som är kritisk eller vilken leverantör som är väsentlig kräver omdöme och sektorkännedom, det arbetet ligger kvar hos människan. 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. Incidentdeadlines från CERT-SE räknas i timmar. Den digitala officeren tar vid där: kollar status, sammanställer underlag, skriver utkast, 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.
Fyra jobb i Postgres-cron mappade direkt mot Cybersäkerhetslagens artiklar. Tre kör nattligt mellan 02:00 och 03:15 UTC, ett tickar var 30:e minut. Styrelsens kvartalsrapport är ett separat kvartalsvis jobb. Inget av dem skickar mejl, ändrar status eller kommunicerar med tillsynsmyndighet utan att en människa godkänner först.
nis2-officer-nightly är jobbet som Anthropic-modellen driver. Kontrollerar att cybersäkerhetspolicyn är formellt antagen och inom 12-månadersfönstret, att kritiska risker (likelihood × impact ≥ 12) har mitigation med ansvarig och deadline, att styrelsens kvartalsrapport är digitalt signerad, och att kontinuitetsplanen har en testkörning inom 12 månader. Avvikelser skrivs som förslag till agent_proposals med koppling till källobjekt och utkast till åtgärd.
nis2-operational-snapshot-daily beräknar NIS2-poäng per område, incidenthantering, supply chain, kryptografi, tillgänglighet, basic cyber hygiene, åtkomstkontroll, sårbarhetshantering, som underlag till dashboard, styrelserapport och granskning. Helt deterministisk SQL i Postgres, ingen generativ modell. Sju av nio områden mäts kvantitativt; två (sårbarhetshantering, MFA-täckning) är fortsatt manuell bedömning.
vendor-external-check verifierar TLS-konfiguration på leverantörens publika ändpunkter, matchar leverantörens domän mot CERT-SE:s flöden, och kontrollerar att uppladdade bevis (ISO 27001-certifikat, SOC 2-rapport, DPA) inte gått ut. Utgångna eller nära förestående bevis genererar mejlutkast till leverantörens kontaktperson med begäran om uppdaterat underlag.
incident-followup-check bevakar tidslinjen för aktiva incidenter, tidig varning 24 h, incidentanmälan 72 h, slutrapport en månad, och tickar var 30:e minut för att fånga snabba eskaleringar. 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 plattformens inkorg.
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 namnger ingen specifik roll, men 2 kap. 3 till 4 §§ kräver att verksamhets- utövaren faktiskt vidtar säkerhetsåtgärderna och att ledningen utbildas. I praktiken behöver någon hos er äga arbetet operativt, 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. Demon är en 3-minuters gap-bedömning mot er sektorprofil, utan inloggning och utan möte. Pris och villkor finns på /priser. Anonym klassning av NIS2 och AI-förordningen på /diagnos (90 sek), eller mät mognad mot Art. 21(2) på /nis2-quiz.
Ja. Cybersäkerhetslagen (SFS 2025:1506) kräver inte uttryckligen en utsedd säkerhetsansvarig, den specifika rollen finns inte i lagtexten, men 2 kap. 3 § kräver att verksamhetsutövaren faktiskt vidtar de tio minimiåtgärderna och 2 kap. 4 § kräver att personer i ledningen genomgår utbildning om säkerhetsåtgärder. I praktiken behöver någon hos er äga arbetet operativt, oftast en CISO eller IT-chef, och styrelsen bär det yttersta ansvaret. 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 ansvariga personen 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 är vår defaultnivå för underlag inför tillsyn. Cybersäkerhetslagen specificerar inte ett exakt antal månader, men praxis kring tillsynsmyndighetens bevisbegäran gör 24 månader till en rimlig miniminivå. 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, sektorvis tillsynsmyndighet och CERT-SE vid MCF 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 (Myndigheten för civilt försvar, tidigare MSB, omdöpt 2026-01-01) är gemensam kontaktpunkt enligt Cybersäkerhetsförordningen och driver CSIRT-funktionen CERT-SE, att PTS är tillsynsmyndighet för digital infrastruktur och telekom, och att incidentrapporter enligt Cybersäkerhetslagen 2 kap. 5 till 8 §§ lämnas till CERT-SE. 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.