Säkerhet
Var uppgifterna ligger och vem som kommer åt dem
Var uppgifterna ligger
Databas, autentisering och objektlagring ligger inom EU. Det gäller både ärendeuppgifterna och de filer som hör till dem: SBOM, teknisk dokumentation, försäkran och de PDF-kvitton som skapas vid varje inlämning. Filerna omfattas av samma åtkomstregler som databasraderna — de ligger inte i en öppen hink med svårgissade namn.
Sidorna under /app och /admin skickas med Cache-Control: private, no-store. Ett kvitto eller ett ärende ska inte kunna ligga kvar i ett mellanliggande cachelager.
Hur åtkomsten är avgränsad
Avgränsningen mellan bolag ligger i databasen, inte i gränssnittet. Det är en medveten skillnad: en regel i ett formulär skyddar mot felklick, en regel i databasen skyddar även när någon anropar API:et direkt.
Användare i ett bolag
- Kan
- Ser och skriver i sitt eget bolags ärenden, produkter och dokument.
- Kan inte
- Kan inte se något i ett annat bolag, inte ens med rätt identifierare.
Inbjuden byrå eller konsult
- Kan
- Ser klientbolagets ärenden genom ett medlemskap i det bolaget.
- Kan inte
- Har ingen egen åtkomstregel. Tas medlemskapet bort försvinner åtkomsten i samma stund — det finns ingen väg in vid sidan av.
Plattformsadministratör hos oss
- Kan
- Läser ärenden, inlämningar, produkter och dokument för att kunna ge support.
- Kan inte
- Kan inte ändra i ett bolags ärenden eller anmälningar. Att se att en kund fastnat är support; att skriva i deras anmälan till myndighet är något annat.
Fakturering och abonnemang
- Kan
- Uppdateras enbart av Stripes webhook.
- Kan inte
- Inget inloggat konto kan sätta sin egen abonnemangsstatus — tabellen saknar skrivregel för användare helt.
Reglerna testas, inte bara skrivs
Åtkomstavgränsningen täcks av automatiska kontroller som körs mot databasen. Skriver någon en genvägsregel som ger en byrå en egen väg in går kontrollen sönder innan ändringen kan släppas. Det är hela poängen med att ha dem.Underbiträden
Fyra leverantörer behandlar uppgifter för vår räkning. Listan uppdateras när den ändras, och ändringar aviseras till bolag med aktivt abonnemang innan de träder i kraft.
| Leverantör | Ändamål | Behandlingsort |
|---|---|---|
| Supabase ↗ | Databas, autentisering och objektlagring för ärenden, kvitton och dokument. | EU (Frankfurt, eu-central-1) |
| Stripe ↗ | Betalning och fakturering av abonnemanget. Ser aldrig ärende- eller rapportinnehåll. | EU och USA, under standardavtalsklausuler |
| Resend ↗ | Utgående e-post: påminnelser, eskaleringar och inlämning till mottagare. | EU och USA, under standardavtalsklausuler |
| Vercel ↗ | Drift av webbgränssnittet. Lagrar inget ärendeinnehåll. | EU (Stockholm, arn1) för serverrendering |
Utöver dessa används Google Analytics för anonymiserad besöksstatistik på de publika sidorna. Verktyget körs inte i den inloggade appen och får aldrig ärende- eller rapportinnehåll. Se integritetspolicyn.
Bevarande och radering
Dokument med bevarandeplikt enligt cyberresiliensakten får ett bevaras till-datum när de laddas upp: tio år från att produkten släpptes ut på marknaden för teknisk dokumentation och försäkran, hela supportperioden för SBOM. Före det datumet går dokumentet inte att radera — en databasregel avvisar försöket, oavsett vem som gör det.
Samma sak gäller ett helt bolag. Ett bolag med bevarandepliktiga dokument går inte att radera förrän tiderna löpt ut. Det är avsiktligt obekvämt: ett krav som går att kringgå med en uppsägning är inget krav.
Uppgifter utan bevarandeplikt raderas på begäran. En uppsägning stänger möjligheten att lämna in nya rapporter men rör inte underlaget.
Kvitton och spårbarhet
Varje inlämning får ett PDF-kvitto med en SHA-256-summa över exakt den datamängd som skickades. Ändras något i efterhand stämmer inte summan, och det går att visa. Kvittot anger också mottagare, tidpunkt och försök — inklusive misslyckade.
Statusen skickad och statusen kvitterad av myndighet är två olika tillstånd i gränssnittet och i kvittot, och blandas aldrig ihop. Ett ärende flyttas fram först när det nationella CSIRT:et tagit emot — en rad som ligger kvar i kö hos en annan mottagare får inte få klockan att se avklarad ut.
Rapportera en sårbarhet till oss
Hittar ni en sårbarhet i Frist72, hör av er till security@frist72.eu. Vi bekräftar mottagandet inom två arbetsdagar och återkommer med bedömning och plan. Vi vidtar inga rättsliga åtgärder mot den som rapporterar i god tro, håller sig till sina egna testdata och ger oss rimlig tid att åtgärda innan något publiceras.
Det vore olämpligt att sälja ett verktyg för sårbarhetsrapportering utan att själva ta emot sådana.