Säkerhet & infrastruktur - Säkerhet & datahantering hos Siteflow

1. Översikt — så jobbar vi med säkerhet

Säkerhet är inte en kryssruta vi bockar av efter lansering — det är en kontinuerlig process som löper genom hela leveransen. Från det att en besökare når er hemsida via en krypterad HTTPS-förbindelse, till att ett formulär skickar leadet till vårt CRM, till att en backup skrivs till separat, krypterad lagring varje natt — varje länk i kedjan har granskats och härdats.

Vi följer principer som defence in depth (flera försvarslager i stället för ett enda perimeterskydd), least privilege (minsta möjliga åtkomst för varje system och anställd) och secure by default (säkra inställningar aktiverade direkt, utan att ni som kund behöver be om det). I praktiken innebär det att en sajt vi levererar har moderna säkerhetsheaders, kryptering, bot-skydd och övervakning aktiverat från första dagen — inte som ett tillval.

Den här sidan beskriver vår säkerhetsmodell i klartext så att ni som kund — eller revisor, säkerhetsansvarig eller upphandlare — kan göra en informerad bedömning. Behöver ni djupare dokumentation för en riskanalys eller upphandling skickar vi gärna vår tekniska säkerhetsbilaga på begäran.

2. Teknisk säkerhet på applikationsnivå

All trafik till och från hemsidor som drivs av Siteflow är krypterad med moderna standarder. Vi använder ingen egen certifikatutfärdare och låter aldrig en sajt gå live utan giltigt certifikat.

2.1 HTTPS överallt med TLS 1.3

Alla våra sajter levereras uteslutande över HTTPS. Vi använder TLS 1.3 som primärt protokoll med fallback till TLS 1.2 för äldre klienter. Äldre versioner (TLS 1.0, TLS 1.1, SSLv3) är helt avstängda. Certifikaten förnyas automatiskt via Let's Encrypt och övervakas så att vi får larm 30 dagar innan utgång — vi tillåter inte att ett certifikat hinner gå ut i produktion.

Alla HTTP-anrop på port 80 omdirigeras med 308 Permanent Redirect till HTTPS i edge-lagret — innan trafiken ens når applikationen. Det innebär att en besökare aldrig kan råka skicka data okrypterat, även om en länk skulle vara hårdkodad till http://.

2.2 HSTS med preload

För att eliminera risken för man-in-the-middle-attacker via okrypterad fallback skickar vi alltid en Strict-Transport-Security-header med max-age=63072000; includeSubDomains; preload. Det betyder att webbläsare i två år framåt vägrar prata HTTP med er domän överhuvudtaget — även om en länk pekar fel. När domänen är stabil ansöker vi om plats på Chromes HSTS preload-lista, vilket bygger in skyddet direkt i alla större webbläsare innan ens första besök sker.

2.3 Content Security Policy (CSP)

Cross-site scripting (XSS) är fortfarande en av de vanligaste attackvektorerna mot webbsidor. Vi skickar därför en strikt Content-Security-Policy som vitlistar exakt vilka domäner som får ladda script, bilder, typsnitt och stilar. Inline-script körs enbart med nonce, vilket betyder att ett injicerat <script>-element från en angripare aldrig kommer att exekvera ens om en sårbarhet skulle finnas i ett annat lager.

Policyn loggar även rapporter om eventuella brott via report-uri, så att vi får signal om någon försöker injicera kod eller om en tredjepartsleverantör börjat ladda nya resurser som inte är godkända. Vi granskar rapporterna veckovis.

2.4 Säkerhetsheaders och hardening

Utöver CSP skickar vi en komplett uppsättning säkerhetsheaders på varje response:

• X-Frame-Options: DENY — förhindrar att sajten bäddas in i en iframe på annan domän, vilket stoppar klassiska clickjacking-attacker.
• X-Content-Type-Options: nosniff — tvingar webbläsaren att respektera deklarerad Content-Type istället för att gissa, vilket eliminerar MIME-sniffing-attacker.
• Referrer-Policy: strict-origin-when-cross-origin — begränsar vilken referrer-information som läcker till externa domäner när besökaren klickar på en utgående länk.
• Permissions-Policy — stänger av webbläsar-API:er som sajten inte använder (kamera, mikrofon, geolocation, USB) så att en eventuell sårbarhet inte kan utnyttja dem för spårning eller åtkomst till enheten.
• Cross-Origin-Opener-Policy: same-origin och Cross-Origin-Resource-Policy: same-origin — isolerar dokumentet från andra browsing-contexts, vilket är ett modernt skydd mot Spectre-liknande sidokanalattacker.

Konfigurationen verifieras regelbundet via securityheaders.com och Mozilla Observatory där vi siktar på betyget A eller bättre på varje produktionssajt.

2.5 Skydd mot överbelastning och missbruk

Trafiken till siteflow.se och kundernas hemsidor når oss genom Vercels edge-nät, som absorberar volymbaserade angrepp (lager 3/4) innan de når applikationen. Kundportalen, CRM:et och webbmejlen ligger bakom en egen reverse proxy på våra AWS-maskiner i Stockholm, utan lastbalanserare framför. Fram till 1 oktober 2026 stod här att all trafik passerar genom Cloudflare och att en Web Application Firewall filtrerar lager 7. Inget av det stämde, och vi beskriver hellre ett tunnare skydd som finns än ett tjockare som inte gör det. Till 3 oktober 2026 stod Fly.io:s edge-noder här — det var sant då, och är det inte längre.

På applikationsnivå är skyddet vår egen kod och plattformens: all utdata escapas av ramverket, databasfrågor är parametriserade, och CSP-reglerna i avsnitt 2.3 stoppar injicerade skript i webbläsaren. Vi kör ingen WAF, och säger det hellre än att låta er tro att ett lager finns som inte gör det.

Formulären skyddas av vår egen kod i stället för av en extern bot-tjänst: ett dolt fält som bottar fyller i men människor aldrig ser, och en takt-gräns per IP-adress i två lager — en i webbskiktet och en i backenden. Ingenting om inskicket lämnar oss för den kontrollen, och besökaren får inget pussel att lösa.

3. Datalagring och GDPR

Var data fysiskt lagras spelar både roll juridiskt (GDPR och Schrems II) och tekniskt (latens och driftsäkerhet). Vår grundprincip är enkel: så mycket som möjligt ska ligga i EU, och allt som lagras utanför EU måste ha laglig grund och dokumenterade skyddsåtgärder.

3.1 EU-hosting — appar och databas i Stockholm, hemsidorna renderas i USA

Våra applikationer och vår databas ligger sedan 3 oktober 2026 hos Amazon Web Services i region eu-north-1 — fysiskt placerad i ett datacenter i Stockholm. Det gäller kundportalen, CRM:et, webbmejlen, e-signeringen, AI-receptionisten och den PostgreSQL-databas som bär leads, kundkonton, bokningar, besöksstatistik och personalmodulens scheman. (AI-receptionistens språkmodell anropas härifrån men körs på en EU-inferensprofil och kan betjänas i en annan EU-region — inom EU/EES, men inte nödvändigtvis i Sverige.) Säkerhetskopiorna ligger i samma region. Lagringslandet för er data i våra system är alltså Sverige — och det är det ordet som ska stå i en personuppgiftsförteckning. Fram till 3 oktober 2026 låg applikationerna hos Fly.io i Stockholm och databasen hos Neon i Frankfurt, alltså med Tyskland som lagringsland.

Ett led ligger däremot utanför EU, och vi skriver ut det: kundernas publika hemsidor körs hos Vercel, och deras serverfunktioner exekveras i regionen iad1 — Washington, D.C. Mätt 4 oktober 2026 svarade 17 av 18 kundadresser från just den regionen. Det som passerar där är besökarens förfrågan när en sida renderas, inte er databas. siteflow.se själv körs i arn1 — Stockholm. Överföringen bärs av standardavtalsklausuler och EU-US Data Privacy Framework, se DPA:t.

Behöver er organisation att varje led ligger i EU — det förekommer i offentlig upphandling — säg det innan vi börjar bygga. Databasen och kopiorna uppfyller det redan; renderingsregionen är en inställning per sajt som vi kan flytta, och då vill vi veta det i förväg i stället för att ni upptäcker svaret efteråt.

3.2 GDPR-compliance

Hela vår tjänst är designad med GDPR som utgångspunkt — inte som ett eftermonterat lager. Det innebär bland annat:

• Besöksmätning utan spårningskakor — vår egen, server-side, utan beständig identifierare. Det är varför siteflow.se sedan 1 oktober 2026 inte har någon cookie-ruta: det finns ingen lagring på besökarens enhet att inhämta samtycke för. Se Cookies.
• Cookie-ruta på en kundsajt där den behövs — alltså när något på sajten lagrar på besökarens enhet (en inbäddad karta, en video) — med knappar av samma visuella vikt, i linje med IMY:s tillsynspraxis från april 2025.
• Automatisk gallring av leadsdata och formulärinskick baserat på den retention som ni som kund anger.
• Stöd för registerutdrag, radering och rättelse via vårt kundgränssnitt eller på begäran från oss.
• Pseudonymisering av IP-adresser i analys- och felrapporteringsverktyg.

För detaljer om vilka personuppgifter vi behandlar, varför och hur länge — läs vår integritetspolicy.

3.3 Personuppgiftsbiträdesavtal (DPA)

Eftersom Siteflow behandlar personuppgifter för er räkning är vi personuppgiftsbiträde enligt artikel 28 GDPR och ni är personuppgiftsansvariga. Vi tecknar ett personuppgiftsbiträdesavtal (DPA) med samtliga kunder som ett standardled i avtalsskrivningen. DPA:n beskriver:

• Föremålet och varaktigheten för behandlingen.
• Behandlingens art och syfte samt kategorier av personuppgifter.
• Tekniska och organisatoriska säkerhetsåtgärder enligt artikel 32.
• Lista över underbiträden (Amazon Web Services, Vercel, Resend, Stripe, Sentry m.fl. — den fullständiga och aktuella listan står i DPA:t) och rutiner för att meddela byten.
• Bistånd vid begäranden från registrerade och vid eventuell incidenthantering.
• Återlämning eller radering av data när avtalet upphör.

Behöver ni en kopia av vår standard-DPA innan ni signerar huvudavtalet skickar vi den utan extra kostnad. Vi accepterar också i de flesta fall er egen DPA-mall om den följer GDPR:s minimikrav.

4. Backuper och redundans

Data som inte säkerhetskopieras tillhör inte er — den tillhör nästa hårddiskfel. Därför är backup-strategin en av de viktigaste komponenterna i vår säkerhetsmodell.

4.1 Daglig backup

Samtliga produktionsdatabaser backas upp automatiskt varje natt. Backuperna är fulla snapshots, inte inkrementella, vilket gör återställning snabbare och enklare att verifiera. Ett backupjobb misslyckas inte tyst: om en backup inte slutförts inom förväntat tidsfönster larmar vårt övervakningssystem så att vi kan agera samma morgon.

4.2 Retention i 30 dagar

Vi behåller dagliga backuper i 30 dagar rullande. Det ger marginal att återställa från en korruption eller en oavsiktlig radering som upptäcks först efter någon vecka. För kunder med högre krav (t.ex. revisorer eller verksamhet med lagstadgad arkiveringsplikt) erbjuder vi förlängd retention upp till 7 år som tillval.

4.3 Separat lagring — men samma region

Backupfilerna lagras i en annan tjänst än produktionsdatabasen — objektlagring med egen livscykel och egna behörigheter — så att ett misstag eller ett intrång i databasen inte kan ta med sig kopiorna. Filerna är krypterade i vila med AES-256. De ligger däremot i samma region som databasen (eu-north-1, Stockholm), spridda över flera separata anläggningar inom regionen. Till 3 oktober 2026 stod här att kopiorna låg i ett annat geografiskt område inom EU/EES. Efter flytten till AWS är det inte sant, och vi skriver om stycket i stället för att låta påståendet stå: en incident som slår ut hela Stockholmsregionen skulle nå både originalet och kopian. Behöver er verksamhet geografisk spridning över två regioner är det ett tillval vi kan sätta upp — säg till.

Återställningstest körs regelbundet — vi återställer en backup till en isolerad miljö och verifierar att data är intakt. En backup som aldrig har återställts är ingen backup, det är en förhoppning.

5. Incident response och felmonitoring

Även den bästa säkerhetsarkitektur garanterar inte att inget händer. Skillnaden mellan en bra och en dålig leverantör är hur snabbt incidenten upptäcks, hanteras och kommuniceras.

5.1 Övervakning och felrapportering

Vi använder Sentry för automatisk fel- och prestandaövervakning av samtliga produktionssajter och bakomliggande tjänster. Sentry fångar oväntade exceptions, JavaScript-fel hos slutanvändare, långsamma databasfrågor och avvikande HTTP-status. IP-adresser scrubbas innan de skickas till Sentry så att vi inte skickar mer personuppgifter än nödvändigt utanför EU/EES.

Utöver Sentry har vi externa uptime-prober som kontaktar varje sajt minst varje minut från flera geografiska punkter. Om en sajt inte svarar på två konsekutiva prober larmar systemet oss omedelbart, dygnet runt. Åtgärd påbörjas så snart vi kan — garanterad svarstid gäller helgfria vardagar 08–17.

5.2 72-timmars rapportering till IMY

Vid en personuppgiftsincident — exempelvis obehörig åtkomst, dataläckage eller förlust av uppgifter — agerar vi enligt en dokumenterad incident response-plan. För personuppgiftsansvariga (våra kunder) är det kritiskt att veta att vi som biträde uppfyller artikel 33 GDPR: vi meddelar er utan onödigt dröjsmål och senast inom 72 timmar efter att vi fått kännedom om incidenten — i enlighet med vårt DPA — så att ni i er tur kan rapportera till Integritetsskyddsmyndigheten (IMY) inom er egen frist.

Meddelandet innehåller minst: incidentens natur, kategorier och ungefärligt antal berörda registrerade, troliga konsekvenser, vidtagna eller föreslagna åtgärder och kontaktuppgifter för uppföljning. Vi bistår också med tekniskt underlag om ni behöver bilägga loggar eller tidslinjer till er IMY-anmälan.

5.3 Information till berörda kunder och besökare

Om incidenten medför hög risk för registrerades fri- och rättigheter (artikel 34 GDPR) bistår vi också med utkast till information till berörda slutanvändare. Detta kan omfatta e-postutskick, in-app-notiser eller offentlig kommunikation på sajten. Vi tar fram förslag på ordval som är tydligt, faktabaserat och utan onödig juridisk distans — men slutligt beslut om kommunikation fattas alltid av er som personuppgiftsansvariga.

6. Penetrationstest och sårbarhetsskanning

Egen kod blir blind för sina egna sårbarheter — därför kompletterar vi vår interna granskning med externa tester och automatiserade skanningar.

Penetrationstest beställs av en oberoende säkerhetspartner med erfarenhet av modern webbinfrastruktur. Testet täcker både applikationslagret (OWASP Top 10, authentication, autorisering, sessions) och infrastrukturlagret (DNS, TLS, header-konfiguration, exponerade endpoints). Rapportens fynd prioriteras enligt CVSS, och allt som klassas som High eller Critical åtgärdas med förtur.

Sårbarhetsskanning körs kontinuerligt. Beroenden i våra Node.js- och TypeScript-projekt kontrolleras mot CVE-databaser via automatiserade verktyg vid varje pull request, och nya kritiska sårbarheter (Log4Shell, npm-supply-chain-attacker etc.) flaggar omedelbart. Infrastrukturen beskrivs som kod i en CloudFormation-mall, så en felkonfiguration syns som en ändring i en fil i stället för som ett klick i en konsol. Till 3 oktober 2026 stod här att vi använder Fly.io:s egna infrastrukturskanningar; driften ligger inte där längre.

Resultat och remediation från senaste penetrationstest delas på begäran med kunder som har avtal med oss — typiskt under sekretess.

7. Säkerhetskultur hos anställda

Den mest sofistikerade tekniska säkerhetsarkitekturen kan brytas av ett enda phishing-mail som en oförsiktig medarbetare öppnar. Därför behandlar vi mänsklig säkerhet som en lika viktig komponent som teknisk.

Alla anställda och konsulter genomgår en obligatorisk säkerhetsintroduktion vid onboarding som täcker grundläggande hygien: starka unika lösenord, hantering av MFA-tokens, identifiering av phishing och social engineering, hantering av personuppgifter i vardagen och eskaleringsrutiner vid misstänkt incident. Utbildningen repeteras minst en gång per år och uppdateras när nya hotbilder framträder.

För tekniska medarbetare gäller dessutom:

• Hårdvarunycklar (YubiKey eller motsvarande) för åtkomst till produktionssystem och GitHub.
• Single sign-on med MFA för samtliga molntjänster — ingen lösenordsdelning, inga delade konton.
• Princip om minsta privilegium — utvecklare har inte produktionsåtkomst som standard, utan måste höja behörighet temporärt med audit-log.
• Krypterade hårddiskar (FileVault eller motsvarande) på samtliga arbetslaptops, med automatisk lockscreen efter 5 minuter inaktivitet.
• Säker hantering av API-nycklar och hemligheter via centraliserad secret manager — aldrig i klartext i Git eller chat.

När en medarbetare slutar revokeras samtliga accesser samma dag, hårdvarunycklar samlas in och konton inaktiveras enligt en checklista som signeras av två personer.

8. Rapportera en säkerhetsbrist

Om ni — eller en oberoende säkerhetsforskare — upptäcker en sårbarhet i en sajt eller tjänst som drivs av Siteflow vill vi gärna veta det innan den blir publik. Vi uppskattar ansvarsfull rapportering och svarar normalt inom ett arbetsdygn.

Rapportera en säkerhetsincident eller sårbarhet:
E-post: support@siteflow.se
Vid akut incident utanför kontorstid — ring vår jourtelefon: +46 10 189 84 80

Inkludera om möjligt: beskrivning av sårbarheten, steg för att återskapa, vilken sajt eller tjänst som påverkas och eventuella skärmdumpar eller proof-of-concept. Vi accepterar krypterad e-post via PGP — fingerprint skickas på begäran.

Vi har för närvarande inget formellt bug bounty-program, men vi erkänner publikt (med ert tillstånd) säkerhetsforskare som rapporterar giltiga sårbarheter på ett ansvarsfullt sätt, och vi vidtar inga rättsliga åtgärder mot forskare som följer god praxis för coordinated disclosure.

9. Frågor och ytterligare information

Behöver ni djupare dokumentation för en upphandling, en riskanalys eller en revision — kontakta oss så delar vi:

• Tekniska säkerhetsbilagan med detaljerad arkitekturöversikt.
• Lista över aktuella underbiträden och deras compliance-certifikat.
• Sammanfattning av senaste penetrationstest.
• Vår incident response-plan i fullständig version.
• DPA-mall (svenska eller engelska) inför avtalsskrivning.

Siteflow Stockholm AB
Varuvägen 9, 125 34 Älvsjö
Säkerhetsärenden: support@siteflow.se
Allmänna frågor: hello@siteflow.se
Telefon: +46 10 189 84 80

Senast uppdaterad: 26 maj 2026.