Trust Center

Svenskägt. Data lagras i Sverige. Certifierad säkerhet. Öppna standarder. Här hittar ni information om hur vi skyddar data, uppfyller regulatoriska krav och bygger en plattform som organisationer med höga krav kan lita på.

• Hur styr ni systemändringar under utvecklingen?Säker utveckling#

  Ändringar i system under utvecklingslivscykeln styrs med formella rutiner för ändringskontroll. Det innebär till exempel att ändringar dokumenteras och godkänns, att kod granskas av kollega (peer review) före sammanslagning, att automatiserade tester körs och att det finns dokumenterade rutiner för att återställa (rollback) om något går fel.

• Hur konstruerar ni säkra system?Säker utveckling#

  Vår interna utveckling utgår från principen om djupförsvar (Defense in Depth) i alla tekniska lager och från etablerade säkerhetsriktlinjer, bland annat OWASP Top 10. Vi tillämpar säkra kodningsprinciper, till exempel parametriserade databasfrågor mot SQL-injektion och kontextbaserad escaping mot skriptattacker (XSS), och källkoden skannas automatiskt i våra byggflöden. Konfiguration hanteras som kod från granskade, oföränderliga baslinjer, och sessioner skyddas med säkra cookie-inställningar.

• Säker utvecklingsmiljöSäker utveckling#

  Säkra utvecklingsmiljöer för systemutveckling och integration är etablerade och skyddade genom hela utvecklingslivscykeln. Affärskritiska applikationer granskas och testas noggrant efter plattformsändringar, så att ändringar i driftplattformar inte påverkar verksamheten eller säkerheten negativt.

• Utlagd utvecklingSäker utveckling#

  Vi lägger i allmänhet inte ut systemutveckling och undviker det i största möjliga mån. I de fall det förekommer övervakas arbetet och följer organisationens standarder och regulatoriska krav.

• Avidentifierad testdataSäker utveckling#

  Inga riktiga kund- eller personuppgifter används vid test. Testdata är avidentifierad eller syntetisk och hanteras därför inte med samma skyddskrav som produktionsdata.

• Stödjer ni Single Sign-On (SSO)?Åtkomst & behörighet#

  Ja. Vår plattform stöder SSO-inloggning via branschstandarderna OpenID Connect (OIDC) och SAML2, vilket gör att ni kan integrera med er egen identitetsleverantör (IdP) och styra åtkomsten centralt enligt era egna policyer. Användare identifieras med unika användar-ID:n som är frikopplade från e-postadressen. Flerfaktorsautentisering stöds och sessioner avslutas automatiskt efter en tids inaktivitet.

• Hur hanterar ni förändringar i miljön?Förändringshantering#

  Varje förändring följer våra policyer, instruktioner och SLA:er. Ju större risk en förändring kan innebära, desto högre krav ställer vi på riskbedömning, planering och godkännande. Förändringar testas före och efter införande och har dokumenterade återställningsrutiner (rollback). Vi informerar kunder via vår statussida och aviserar förändringar enligt våra SLA:er.

• Hur varslar ni om planerat underhåll?Förändringshantering#

  Vi aviserar planerade servicefönster minst tio dagar i förväg på vår statussida, och akut underhåll så snart det är möjligt, ibland med kortare framförhållning. Ändringar som rör en specifik tjänst publiceras även på tjänstens announcement-sida i vår dokumentation (docs.elastx.cloud), och vid väsentliga förändringar som berör en tjänst ni använder kan vi dessutom informera era behöriga beställare via e-post. Vi notifierar er också vid förhöjd risk. Planerade servicefönster omfattas inte av tillgänglighets-SLA:n.

• Hur hanterar ni incidenter?IncidenthanteringNIS2#

  Vi levererar tjänster dygnet runt och har därmed felsökning och incidenthantering dygnet runt, året runt, med kontinuerlig övervakning av plattformen och larmmottagning. När en händelse identifieras klassificeras och prioriteras den utifrån allvarlighetsgrad och påverkan på tjänsterna, och den eskaleras enligt fastställda rutiner till rätt teknisk kompetens. Ett allvarligt problem kan eskaleras till en kritisk incident, vilket aktiverar en särskild krisledning med mandat att fatta snabba beslut. Efter en åtgärdad incident genomförs en grundorsaksanalys för att fånga permanenta förbättringar i plattformen och våra arbetssätt. Vår dokumenterade incidenthanteringsrutin kan delas med kunder på begäran.

• Hur informeras vi vid en pågående incident?Incidenthantering#

  Vi håller kunder informerade via vår statussida under ett pågående problem. När ett problem är löst skickar vi på begäran en incidentrapport till berörda kunder. Våra rutiner inkluderar kraven på incidentrapportering i Cybersäkerhetslagen (NIS2).

• Hur snabbt informerar ni vid en incident eller personuppgiftsincident?IncidenthanteringNIS2GDPRDORA#

  Vid en incident som berör er informerar vi utan onödigt dröjsmål, och senast inom 24 timmar efter att vi fått kännedom, så att ni hinner uppfylla era egna skyldigheter. Vid en betydande incident följer vi Cybersäkerhetslagen (NIS2) i rapporteringen till behörig myndighet (Myndigheten för Civilt Försvar): tidig förvarning inom 24 timmar, incidentrapport inom 72 timmar och slutrapport senast en månad efter incidentrapporten.

• Ansvar och rutiner vid incidenterIncidenthantering#

  Ledningsansvar och rutiner är etablerade för en snabb, effektiv och ordnad respons på integritets- och informationssäkerhetsincidenter. Incidentteamet arbetar utifrån fördefinierade spelböcker för bland annat ransomware, DDoS och dataläckor, och oföränderlig loggning säkrar underlag för forensik.

• Hur rapporteras säkerhetshändelser och hot internt?Incidenthantering#

  Säkerhetshändelser och misstänkta hot rapporteras genom etablerade interna kanaler så snabbt som möjligt, så att de kan bedömas och vid behov eskaleras utan dröjsmål. Alla medarbetare och konsulter har ansvar för att rapportera, och rutinen ingår i vår säkerhetsutbildning.

• Hur rapporterar ni väsentliga händelser till myndigheter?IncidenthanteringNIS2GDPRDORA#

  Väsentliga händelser rapporteras enligt gällande regler. Allvarliga incidenter som omfattas av Cybersäkerhetslagen (NIS2) rapporteras till Myndigheten för Civilt Försvar (MCF), och för incidenter som rör finansiella entiteter vi levererar till följer vi DORA. Vid en personuppgiftsincident informerar vi som personuppgiftsbiträde berörd personuppgiftsansvarig utan onödigt dröjsmål enligt GDPR, så att de kan fullgöra sin egen anmälningsskyldighet.

• Rapportering av svagheterIncidenthantering#

  Medarbetare och konsulter ska notera och rapportera observerade eller misstänkta svagheter i system eller tjänster, och det finns etablerade eskaleringsvägar för hur rapporterna tas om hand.

• Hur bedömer ni om en händelse är en incident?Incidenthantering#

  Inrapporterade säkerhets- och integritetshändelser bedöms strukturerat och klassas utifrån fastställda kriterier, bland annat påverkan på konfidentialitet, riktighet och tillgänglighet (CIA-triaden), hur många system eller kunder som berörs, om personuppgifter är inblandade och om händelsen kan utlösa rapporteringsskyldighet. Utifrån bedömningen beslutas om händelsen ska hanteras som en incident och vilken allvarlighetsgrad den får.

• Lärande från incidenterIncidenthantering#

  Efter en incident gör vi en grundlig genomgång (retro) och fångar lärdomar som vi delar internt och omsätter i förbättrade rutiner och kontroller. Hur grundlig genomgången är beror på incidentens omfattning, och incidentrapporter delas med kunder som efterfrågar dem.

• Testar ni er kontinuitetsförmåga?Kontinuitet & återställningNIS2DORA#

  Ja. Vi övar vår kontinuitetsplan (Business Continuity Plan, BCP) genom återkommande, fullskaliga kontinuitetsövningar som en del av vårt ISO/IEC 27001-arbete. Övningarna är typiskt oannonserade för merparten av organisationen för att ge ett realistiskt resultat och prövar krisledningens beslutsförmåga, de tekniska inneslutningsrutinerna och våra kommunikationsvägar under hög press.

• Vad visade årets kontinuitetsövning?Kontinuitet & återställning#

  Övningar bekräftar vår krisberedskap och tekniska motståndskraft. Krisledningen etablerar struktur snabbt, och vi kan vid behov isolera en hel tillgänglighetszon för att skydda kundmiljöer i övriga zoner. Identifierade förbättringsområden följs upp strukturerat och förvaltas över tid, bland annat tydligare krismandat, dedikerad kommunikationsansvarig, mer formaliserade rutiner för uthållighet vid långvariga incidenter samt förbättrad spårbarhet och rapportering i linje med Cybersäkerhetslagen (NIS2) och DORA.

• Hur är plattformen byggd för redundans och återställning?Kontinuitet & återställningNIS2DORA#

  Plattformen är fördelad över tre aktiva tillgänglighetszoner i Stockholmsområdet (STO1, STO2 och STO3), geografiskt åtskilda så att en fysisk eller miljörelaterad störning i en zon inte slår ut tjänsten. Tjänster replikeras mellan zonerna för automatisk redundans. För kritiska säkerhetskopior och loggar erbjuder vi The Vault - en oföränderlig (immutable), ransomware-motståndskraftig lagring som dessutom ligger i en separat region cirka 350 km från Stockholmsområdet, i en skyddad underjordisk anläggning. Den bygger på Object Lock (WORM - Write Once, Read Many), vilket gör att data inte kan ändras eller raderas under den konfigurerade låsperioden, även om behörigheter komprometteras.