För informationssäkerhetsansvarig

Säkerhet och regelefterlevnad

Granska Hubs på djupet – allt underlag på ett ställe.

För er som utvärderar Hubs mot krav som Schrems II, NIS2 och sekretess: kryptering, identitet, drift och öppen källkod i verifierbar form. Varje påstående länkar till sitt underlag.

Utgångspunkt

Fyra dokumenterade säkerhetsegenskaper i Hubs.

Varje egenskap länkar till sin beskrivning i plattformsöversikten.

End-to-end-kryptering

Modulen Meddelanden har end-to-end-kryptering som standard. Filhantering har server-side-kryptering med end-to-end-kryptering som tillval. Se modulbeskrivningen.

Stark autentisering

BankID, SITHS, Freja eID och stöd för er befintliga identitetsleverantör (IdP) och identitetsfederation — för både intern och extern åtkomst. Se identitetsavsnittet.

Svensk drift och datakontroll

Tre driftmodeller — svensk molndrift, lokal installation och hybrid — gör att ni väljer var era data lagras utifrån informationsklass. Se driftmodellerna.

Öppen källkod

Plattformen bygger på öppen källkod med full insyn: koden går att granska, och säker digital kommunikation (SDK) levereras via DIGG:s ramverk. Se plattformsöversikten.

Drift och datakontroll

Ni bestämmer var era data lagras.

Hubs är uppbyggt i tre lager — säker kommunikation, säkert samarbete och verksamhetsverktyg — och kan driftas i tre modeller. Driftmodellen väljs per informationsklass, inte efter leverantörens affärsmodell. Se arkitekturöversikten.

Svensk molndrift

Drift med svensk förankring där era data stannar i Sverige.

Lokal installation

Komplett kontroll i er egen infrastruktur, för högsta krav på isolering.

Hybrid

Blanda driftmodeller utifrån informationsklasser och mognad — stegvis migrering utan tvärstopp.

Driftkedjan bakom svensk molndrift

Svensk molndrift levereras från två geografiskt skilda datahallar i Stockholmsregionen, med redundant kraftförsörjning, kylning och brandskydd samt fysiskt tillträdesskydd i flera lager där all inpassering loggas. Därutöver finns en geografiskt skild, fysiskt skyddad katastrofplats i Sverige med uppdaterade kopior av systemet. Miljön övervakas dygnet runt, och ytterligare detaljer om driftkedjan — anläggningar och partner — redovisas under sekretess i upphandlingar och kundprojekt.

Drift och kontinuitet

Byggt för att förlora så lite som möjligt — och komma tillbaka snabbt.

Tabellen beskriver hur plattformen är konstruerad för säkerhetskopiering och katastrofåterställning. Värdena är konstruktionsmål — det plattformen är byggd och testad för — inte avtalade servicenivåer; avtalade nivåer regleras i ert avtal.

Område Så är plattformen konstruerad
Säkerhetskopiering Täta ögonblickskopior kompletteras med dagliga inkrementella och veckovisa fullständiga kopior av databas, filytor och konfiguration — flera generationer bevaras, så att återställning kan ske till olika tidpunkter.
Återställningspunkt (RPO) Konstruktionsmålet är att högst omkring en timmes arbete ska kunna gå förlorat även vid en totalförlust — ofta mindre.
Återställningstid (RTO) Konstruktionsmålet vid en total katastrof är återställd drift inom minuter till timmar, beroende på händelsens art och omfattning.
Geografisk separation Säkerhetskopior skrivs krypterade till en backupmiljö som är fysiskt och logiskt åtskild från produktionen. En sekundär datahall och en geografiskt skild, fysiskt skyddad katastrofplats i Sverige ger ytterligare redundans.
Skydd mot utpressningsangrepp Produktionsmiljön kan bara lägga till nya säkerhetskopior — inte radera eller skriva över historiken. Åtkomsten till backupmiljön är strikt begränsad, och kopiorna är oläsliga utan rätt nyckelmaterial.
Återläsningstester Återläsning från backup testas regelbundet. Eftersom hela miljön är definierad som kod kan den dessutom återuppbyggas ur kod och återlästa data — oberoende av den ursprungliga servern.
Ändringshantering

Tre formella vägar för varje förändring.

Alla ändringar i er miljö följer en av tre fastställda rutiner enligt ITIL 4 (Change Enablement) — vid planerade ändringar vet ni i förväg vad som ändras, kan verifiera i er egen QA-miljö och kan invända; akutändringar följer i förväg etablerade kontakt- och eskaleringsvägar. Inga direktändringar görs i produktion utanför dessa rutiner.

Ändringstyp När den används Godkännande Så genomförs den
Standardändring Rutinmässiga version- och paketuppgraderingar med låg risk samt säkerhets- och felrättningar som verifierats i QA. Förhandsgodkänd rutin med tyst godkännande — ni får en changelog i förväg och kan alltid invända aktivt; då planeras driftsättningen om. Fast rytm: changelog, uppdatering av er QA-miljö, verifieringsfönster där ni testar själva, därefter produktionssättning utanför kontorstid med efterkontroll. Inkommande SDK-meddelanden köas under driftsättningen och behandlas när miljön åter är tillgänglig.
Normaländring Ny integration, ny ansluten organisation, arkitekturförändring eller annan ändring med väsentlig eller svårbedömd påverkan. Aktivt godkännande av er ändringsauktoritet — till exempel change manager eller ändringsråd — enligt er egen ändringsprocess. Formell ändringsbegäran med risk- och konsekvensbedömning, testplan och återgångsplan; efterutvärdering genomförs för väsentliga ändringar.
Akutändring Brådskande åtgärd för att åtgärda eller förebygga en incident, till exempel en säkerhetsrättning som inte kan invänta ordinarie cykel. Påskyndat godkännande via kontakt- och eskaleringsvägar som etablerats i förväg — även utanför kontorstid. Beslutet dokumenteras alltid i efterhand. Genomförs kontrollerat med verifiering och efterutvärdering. Rutinen får aldrig användas för att kringgå ordinarie planering.

Gemensamt för alla tre: korrigering sker framåt genom en ny version i stället för återställning bakåt, eftersom databasförändringar är framåtriktade, och varje ändring dokumenteras spårbart med ändrings-ID i ett versionshanterat system. Rutinerna är fastställda i ITSL:s verksamhetsledningssystem som ITSL-RUT-CHG-001, 002 och 003.

Kryptering

Kryptering i transit och i vila — per funktion.

Tabellen sammanfattar hur data skyddas under överföring och i lagring, med länk till var respektive funktion beskrivs.

Funktion I transit I vila Beskrivs här
Meddelanden TLS 1.2 eller högre; end-to-end-kryptering som standard. Autentisering via BankID, SITHS och Freja eID. Krypterade lagringsvolymer med kundunika nycklar per instans. Plattform → Meddelanden
Filhantering TLS 1.2 eller högre för all extern åtkomst; kontrollerad extern delning med lösenord och utgångsdatum. Server-side-kryptering; end-to-end-kryptering på mappnivå som tillval. Säkerhetskopior lagras krypterade. Plattform → Filhantering
Video och chatt Krypterad realtidstrafik (WebRTC med säkra protokoll); möten hanteras i er miljö utan externa tredjepartstjänster. Krypterade lagringsvolymer med kundunika nycklar per instans. Plattform → Video & chatt
SDK — säker digital kommunikation Ömsesidig TLS (mTLS) i meddelandekedjan; spårbar leverans med kvittens och ärendelogg via DIGG:s ramverk. Krypterade lagringsvolymer; policystyrd gallring per brevlåda. Plattform → SDK
Signering TLS 1.2 eller högre; undertecknaren skriver under med BankID. Signerade dokument förseglas kryptografiskt med tidsstämpel och lagras på krypterade volymer — ändringar i efterhand upptäcks. Plattform → Signering
Federation mellan organisationer TLS server-till-server via det öppna protokollet Open Cloud Mesh; delning och samtal sker endast på uttrycklig inbjudan. Data stannar i respektive organisations egen instans — även vid samarbete över organisationsgränser. Plattform → Arkitektur
Confidential Computing — tillval För särskilda säkerhetskrav kan data skyddas även under bearbetning, i betrodda exekveringsmiljöer (TEE) — ett tillval som aktiveras på beställning. Plattform → Arkitektur
AI-assistent All AI-bearbetning sker i ITSL:s egna svenska datacenter med lokala öppna språkmodeller — inga anrop till externa AI-tjänster; gäller även vid lokal installation Plattform → AI-assistent
Identitet och åtkomst

Stark autentisering med svenska eID-metoder.

Inloggning federeras mot er befintliga identitetsleverantör via SAML 2.0 eller OIDC — er egen MFA-policy gäller — och stark autentisering sker med svensk e-legitimation via förmedlingstjänst. Plattformen har därtill inbyggt stöd för WebAuthn.

Kontolivscykeln — att konton skapas, uppdateras och avslutas — automatiseras via standardprotokollet SCIM 2.0: er katalogtjänst — exempelvis Microsoft Entra ID — skapar, uppdaterar och inaktiverar konton, kompletterat med katalogsynkronisering via LDAPS och en återkommande avstämning som fångar ändringar som provisioneringsflödet inte förmedlat. Vid användning av administratörskonton krävs alltid multifaktorautentisering, och alla ändringar via sådana konton dokumenteras.

Nivå Vad som styrs
Systemnivå Globala inställningar och vilka funktioner som är aktiverade — förbehållet ett fåtal administratörer, alltid med multifaktorautentisering.
Gruppnivå Åtkomst till funktioner, filareor, grupprum och brevlådor. Grupper skapas och underhålls i er IdP och synkroniseras automatiskt — förändringar i organisationen får direkt genomslag i plattformen.
Resursnivå Rättigheter per resurs: läsa, skriva, dela, radera eller administrera.

Behörigheter tilldelas enligt principen om minsta privilegium, primärt på gruppnivå. Delegerad administration låter utsedda grupper hantera avgränsade delar — till exempel användare inom den egna enheten eller lagringskvoter — utan att vara fullständiga systemadministratörer.

Loggning och spårbarhet

Spårbarhet med skyddade, tidssynkroniserade loggar.

Säkerhetsrelevanta händelser loggas centralt och skyddas mot obemärkt manipulation.

Händelsetyp Vad som registreras
Inloggningar Lyckade och misslyckade inloggningsförsök, med användare, tidpunkt och IP-adress.
Filhändelser Skapande, åtkomst och radering av filer.
SDK-meddelanden Skickade SDK-meddelanden, med den sändningslogg och kvittens som DIGG:s regelverk kräver.
Konto- och konfigurationsändringar Ändringar i inställningar samt kontohändelser — skapande, attributändring, inaktivering och radering — i applikationens revisionslogg.
Administrativa åtgärder Åtgärder med förhöjd behörighet loggas separat för granskning.

Loggarna lagras centralt på en loggserver som är separerad från applikationsservrarna, så att de inte kan manipuleras obemärkt — åtkomst till råloggar kräver särskild behörighet och stark autentisering. Alla servrar tidssynkroniseras via NTP, vilket ger konsistenta tidsstämplar över alla loggkällor, och automatiska realtidslarm utlöses vid avvikande mönster.

AI-assistentens datahantering

AI på svenska GPU:er — utan externa AI-tjänster.

All AI-bearbetning sker i ITSL:s egna datacenter i Sverige, på ITSL:s GPU:er, med lokala språkmodeller med öppen källkod och öppna vikter — inga anrop går till externa AI-tjänster. Det gäller även vid lokal installation: väljer ni AI-stöd sker bearbetningen i ITSL:s driftmiljö. Se modulbeskrivningen.

Öppen källkod

Granskningsbar kod, ingen inlåsning.

Hubs paketerar etablerade komponenter med öppen källkod — bland andra Collabora, Moodle, OpenProject och Vaultwarden — kring en öppen samarbetskärna med realtidskommunikation, vilket ger full insyn och möjlighet att granska koden. För er som jämför med Microsoft 365 finns en saklig jämförelse av arkitektur och datakontroll.

Sårbarhetshantering

Sårbarhetshantering: bevaka, bedöma, åtgärda — hela tiden.

Sårbarhetsarbetet är en löpande kedja från omvärldsbevakning till applicerad rättelse. Den målsatta tiden om 24 timmar är ett arbetssätt, inte en avtalsnivå — avtalade åtgärdstider regleras i ert avtal.

Bevaka

Aktiv omvärldsbevakning via CERT-SE, MSB och CVE-databaser samt säkerhetsbulletiner för plattformens öppna komponenter. Automatiska skanningar av systemets nätverksytor, även i produktionsmiljön, kompletterar bilden.

Bedöma

När en ny sårbarhet upptäcks analyseras om Hubs är påverkad och vilka skyddsåtgärder som krävs. Med jämna mellanrum görs dessutom manuella genomgångar av säkerhetsarkitektur och hotbild för att fånga risker som verktygen missar.

Åtgärda

Uppdateringar testas i QA-miljö innan de når produktion. Kritiska säkerhetsrättelser prioriteras alltid, med 24 timmar som målsatt tid från tillgänglig rättelse till applicerad — vid behov via akutändringsrutinen. Övriga rättelser tas med i nästa ordinarie release.

Incidenthantering

En dokumenterad process — från upptäckt till lärdom.

Incidenter hanteras enligt en fast process där ni informeras tidigt och varje steg dokumenteras.

1. Upptäckt och klassificering

Incidenter fångas via larm eller felanmälan och klassificeras direkt utifrån allvarlighetsgrad och påverkan. Vid misstänkt säkerhets- eller personuppgiftsincident larmas den informationssäkerhetsansvariga funktionen omedelbart.

2. Begränsning

Första steget är att begränsa skadan: drabbade system eller konton isoleras för att stoppa pågående angrepp och säkra bevismaterial.

3. Utredning

Intrångsväg, omfattning och vilka data eller användare som påverkats kartläggs genom logganalys och forensiska verktyg.

4. Information till er

Er utsedda kontaktperson får tidigt besked om vad som hänt, vilka initiala fakta som finns och vilka åtgärder som vidtas — med löpande uppdateringar tills incidenten är löst.

5. Återställning och lärdom

När incidenten är åtgärdad görs en rotorsaksanalys, och en incidentrapport med tidslinje, påverkan och lärdomar upprättas och delas med er.

Vanliga frågor

Frågorna er säkerhetsfunktion ställer om incidenter.

Tre frågor som återkommer i säkerhetsgranskningar — besvarade utifrån den dokumenterade incidentprocessen.

Hur stödjer ITSL vår anmälan till IMY inom GDPR:s 72 timmar?

Vid en personuppgiftsincident får er utsedda kontaktperson tidigt besked, och ert dataskyddsombud kontaktas omedelbart. Vi tar skyndsamt fram underlag — vilka uppgifter och registrerade som kan vara berörda, hur incidenten skedde och vilka konsekvenser den kan få — så att ni kan fullgöra er anmälningsplikt till Integritetsskyddsmyndigheten inom 72 timmar och informera berörda.

Vilket stöd får vi för incidentrapportering enligt NIS2?

Incidentprocessen dokumenterar tidslinje, påverkan och åtgärder löpande, och vi förser er med de tekniska fakta er rapportering kräver. Vilka tidsfrister som gäller styrs av författning och av ert avtal.

Vad händer efter att en incident är åtgärdad?

Varje incident avslutas med en rotorsaksanalys där grundorsaken identifieras och permanenta åtgärder vidtas. En incidentrapport med tidslinje, påverkan och lärdomar upprättas och delas med er, och vid behov följs den av förbättringsåtgärder som förebygger upprepning.

Miljöseparation

Fyra miljötyper — och er data finns bara i en av dem.

Hubs är uteslutande en single-tenant-plattform: varje organisation har en dedikerad instans i både applikations- och databasskiktet, med kundunika krypteringsnycklar. Hur instansmodellen är uppbyggd beskrivs i arkitekturöversikten.

Miljö Syfte Separation och data
Produktion Er skarpa miljö med verkliga data och användare. Hårt säkrad med fullständig säkerhetskopiering. Endast behörig driftpersonal kan göra ändringar — utvecklare har ingen direktåtkomst.
QA Integrationstester och kvalitetssäkring tillsammans med er före driftsättning. Speglar produktionskonfigurationen och ger er möjlighet att verifiera ändringar i förväg. Säkerhetskopieras i mer begränsad omfattning.
Demo Visning och utvärdering under en avgränsad period. Innehåller aldrig skarp kunddata; miljöerna är temporära och avvecklas efter behov.
Utveckling ITSL:s interna miljöer för ny funktionalitet. Helt avskilda — ingen kundåtkomst och ingen koppling till produktionsdata eller externa tjänster.

Alla icke-produktionsmiljöer är strikt avskilda från produktionen och körs på separata instanser och nät — produktionsdata blandas aldrig in i test-, demo- eller QA-miljöer. Eftersom miljöerna byggs ur kod kan de återskapas från grunden i stället för att drivas som permanenta instanser, vilket håller dem identiska med aktuell produktionskonfiguration.

Styrning och ansvar

Säkerhetsarbetet har en ägare — och en fastställd policy.

Informationssäkerhetsarbetet styrs av en fastställd informationssäkerhetspolicy som omfattar all informationshantering och gäller alla medarbetare, konsulter och samarbetspartners med tillgång till företagets informationsresurser. VD har det yttersta ansvaret, och en utsedd informationssäkerhetsansvarig leder den dagliga styrningen och den kontinuerliga förbättringen.

Riskhanteringen bedrivs proaktivt och är integrerad i verksamhetens löpande processer, alla medarbetare genomgår obligatorisk säkerhetsutbildning, och policyn granskas årligen eller vid betydande förändringar i verksamheten eller hotbilden.

Gå igenom säkerheten mot era krav.

Vi går igenom kryptering, identitet och driftmodeller tillsammans med er säkerhetsfunktion — och svarar på era frågor.

Boka teknisk säkerhetsgenomgång Se driftmodellerna i plattformsöversikten