Jump to the English version

6 MSEK i vinst. 6 MSEK i böter. En sårbarhet som låg oupptäckt i 2,5 år.

I januari 2025 läckte 2,1 miljoner personuppgifter om svenskar, framförallt barn, till darknet. Namn, personnummer, relationer, och ibland hälsodata som allergier och funktionsnedsättningar. Även personer med skyddad identitet fanns bland de drabbade.

Integritetsskyddsmyndigheten (IMY) svarade med en sanktionsavgift på 6 miljoner kronor.

Det här var ingen sofistikerad attack från en statlig aktör. Det var en SQL-injektion via en enda oskyddad variabel.

För att sätta boten i perspektiv: Sportadmin, som visserligen ingår i en större koncern, omsatte cirka 54 MSEK 2024. Deras vinst samma år? 6 MSEK. Boten motsvarar alltså 100% av deras årsvinst — eller 11% av omsättningen. Det här är inte en administrativ smäll. Det är ett existentiellt hot.

Om ditt bolag hanterar personuppgifter är IMY:s beslut obligatorisk läsning.

Vad hände?

Juni 2022: En kodändring införs i inloggningsflödet. En ny variabel läggs till, men utan det SQL-injektionsskydd som redan fanns på plats för andra variabler. Ändringen klassas som högrisk och granskas av flera personer. Ingen upptäcker sårbarheten.

Januari 2025: Angripare börjar utnyttja sårbarheten den 14 januari. Intrånget upptäcks först den 16 januari — två dagar senare — när servrarna slutar svara.

Mars 2025: Den stulna datan publiceras på darknet.

Sårbarheten låg alltså öppen i 2,5 år.

De fem bristerna IMY pekade på

IMY:s beslut är detaljerat och lärorikt. De identifierade fem kritiska brister som ledde till den höga sanktionsavgiften. Varje punkt är en lärdom för oss andra.

1. De kände till risken — men agerade inte

Sedan 2021 hade Sportadmin i sin årliga riskbedömning identifierat en förhöjd risk för SQL-injektioner. Löpande åtgärder hade genomförts, men inte tillräckliga.

IMY var tydliga: att känna till en risk utan att agera är värre än att inte veta. Dokumenterade risker som ignoreras blir bevis mot dig, inte skydd.

2. De testade skydd — men pausade implementeringen

I maj-juni 2024 testade Sportadmin en Web Application Firewall (WAF). Implementeringen pausades på grund av “höga genomförandekostnader.”

Efter intrånget? WAF var på plats inom dagar.

IMY konstaterade att man kunde implementera WAF snabbt, då borde man ha gjort det innan. Och vad än WAF kostade var det inte 6 miljoner kronor.

3. De upptäckte intrånget två dagar för sent

Attackförsöken började den 14 januari. Intrånget upptäcktes först den 16 januari när systemen kraschade.

Övervakningen var byggt för att mäta prestanda och drifttid, inte för att upptäcka säkerhetsincidenter. Två dagar av angriparaktivitet kunde passera obemärkt.

4. Systemen hade för höga behörigheter

SQL-användarkontot hade högre rättigheter än nödvändigt. Windows-tjänstekontot som körde databasen hade också förhöjda behörigheter. Dessutom tillät databasservern körning av externa program som PowerShell.

Resultatet? Angriparen kunde röra sig till andra system och då komma åt betydligt mer data. Principen om lägsta behörighet (least privilege) är inte en rekommendation — det är en nödvändighet.

5. Kodgranskningen missade sårbarheten

Kodändringen från 2022 klassades som högrisk. Den granskades av flera personer. Ändå upptäcktes inte den saknade inputvalideringen.

Varför? Granskningen fokuserade på funktionalitet (inloggningsflödet), inte på attackvektorer (SQL-injektion). Dessutom saknades automatiserad säkerhetsskanning — ingen SAST, ingen DAST.

Mänsklig granskning är nödvändig men inte tillräcklig.

Frågor du behöver ställa ditt team

Efter att ha läst IMY:s beslut borde alla tech organisationer ställa sig följande frågor.

Riskhantering:

  • Har vi kända säkerhetsrisker som inte har åtgärdats? Finns det en dokumenterad anledning till varför — och en tidplan för åtgärd?
  • Om vi testat ett säkerhetsskydd och pausat implementeringen — varför, och när återupptar vi arbetet?

Detektering:

  • Hur snabbt skulle vi upptäcka onormala databasfrågor eller intrångsförsök?
  • Är vår övervakning byggd för säkerhet, eller bara för drifttid?
  • Granskas säkerhetsloggar i realtid, eller bara vid månatliga genomgångar?

Kodgranskning:

  • Ingår säkerhetsgranskning i våra kodgranskningsrutiner — inte bara funktionalitet?
  • Är kodgranskning obligatoriskt för alla ändringar, utan undantag?
  • Har vi automatiserad säkerhetsskanning (OWASP/SAST/DAST) i våra CI/CD-pipelines?

Behörigheter:

  • Följer våra databas- och tjänstekonton principen om lägsta behörighet?
  • När granskade vi senast behörighetsnivåerna?
  • Kan en komprometterad tjänst öppna för lateral förflyttning — eller är tjänsterna isolerade?
  • Tillåter våra databasservrar körning av externa kommandon?

En startpunkt: Åtgärder att överväga

Det här är ingen uttömmande säkerhetslista, men det är en startpunkt baserad på vad som gick fel i Sportadmin-fallet.

Detektering och övervakning

  • Implementera realtidsövervakning på WAF- och IDS-loggar. Månatlig genomgång räcker inte.
  • Övervaka för SQL-injektionsförsök specifikt, inte bara generell trafik.
  • Behåll loggar längre än 30 dagar för att upptäcka avancerade hot (APT).

Kodgranskning och pipelines

  • Lägg till OWASP/SAST/DAST/SCA-skanning i er CI/CD-pipeline.
  • Kräv obligatorisk kodgranskning — med extra fokus på säkerhetsprinciper.
  • Glöm inte scanna er kod som hanterar infrastruktur.
  • Använd AI-assisterad kodgranskning som komplement.

Isolation och arkitektur

  • Kör tjänster i isolerade containers för att begränsa lateral förflyttning.
  • Implementera zero trust mellan tjänster. Interna system ska inte lita på varandra per automatik.

Teknisk skuld och attackyta

  • Inventera och arkivera eller uppdatera gamla repos. Varje oanvänt repo är en potentiell attackvektor.

Behörigheter och åtkomst

  • Granska kontobehörigheter regelbundet.
  • Begränsa behörigheter till bara det absolut nödvändiga — inklusive för tjänstekonton.
  • Begränsa möjligheten att köra externa program från databasservrar.
  • Kryptera all lagrad data, speciellt databaser och under transport.
  • Implementera MFA för alla kritiska system och adminåtkomst.

Hemlighetshantering

  • Lagra aldrig API-nycklar, lösenord, certifikat m.m. i kod — använd en hemlighetshanterare
  • Skanna repos efter oavsiktligt inkluderade hemligheter

Riskhantering

  • Skanna alla repos automatiskt för nya CVE:er.
  • Dokumentera kända risker och er åtgärdsplan med tidslinje.
  • Om en risk dokumenteras men inte åtgärdas måste det finnas ett medvetet beslut och en plan, inte bara tystnad.

Testning och beredskap

  • Genomför penetrationstestning årligen — eller vid större systemförändringar.
  • Ha en dokumenterad och testad incidenthanteringsplan.

Slutsats

De här misstagen är lätta att göra. IMY:s beslut kan tyckas hårt, men om du bygger mjukvara som hanterar personuppgifter har ribban för säkerhetsåtgärder precis höjts.

Sportadmins agerande efter intrånget var föredömligt. De stängde ned systemen inom en timme, samordnade incidentanmälningar, och genomförde över 2 000 uppsökande samtal. IMY lyfte detta som en förmildrande omständighet.

Men de fick ändå betala 6 miljoner kronor. Hela sin årsvinst.

Varför? För att det som hände gick att förutse och förhindra. De kände till riskerna. De hade testat lösningar. De valde att vänta.

Den dyraste meningen i GDPR-sammanhang är: “Vi visste, men vi agerade inte.”

Om du hanterar svenska personnummer eller hälsodata är IMY:s beslut din nya botten-nivå. Läs, fråga, och agera innan du blir tvingad.

IMY:s fullständiga beslut finns tillgängligt på imy.se (diarienummer IMY-2025-7801).


Analysis: 6 MSEK in Fines — What Can We Learn from the Sportadmin Leak?

6 MSEK in profit. 6 MSEK in fines. A vulnerability that went undetected for 2.5 years.

In January 2025, personal data for 2.1 million Swedes, the majority children, leaked to the darknet. Names, ID numbers, relationships, and sometimes health data like allergies and disabilities. Even individuals with protected identities were among those affected.

The Swedish Authority for Privacy Protection (IMY) responded with a fine of 6 million SEK. That’s about €570,000 or $670 000.

This wasn’t a sophisticated nation-state attack. It was a SQL injection via a single unprotected variable.

Put it in perspective: Sportadmin, part of a larger group, had a turnover of about 54 MSEK in 2024. Their profit that year? 6 MSEK. The fine equals 100% of their annual profit — or 11% of revenue. This isn’t an administrative slap on the wrist. It’s an existential threat.

If you’re a technology leader in Sweden handling personal data, IMY’s decision is a must read.

What Happened?

June 2022: A code change in the login flow introduced a new variable. It lacked the SQL-injection protection already in place for other variables. The change got flagged as high-risk and reviewed by several people. No one caught the vulnerability.

January 2025: Attackers begin exploiting the vulnerability on January 14. The breach was discovered on January 16 — two days later — when servers stop responding.

March 2025: The stolen data released on the darknet.

The vulnerability remained open for 2.5 years.

The Five Failures IMY Identified

IMY’s decision is detailed and instructive. They identified five critical failures that led to the big fine. Each point is a lesson for the rest of us.

1. They Knew About the Risk — But Didn’t Act

Sportadmin’s annual risk assessments had flagged SQL injection as elevated since 2021. They had ongoing remediation work, but it wasn’t fast enough.

IMY was clear: knowing about a risk without acting is worse than not knowing. Documented risks that are not corrected become evidence against you, not protection.

2. They Tested Protection — But Paused Implementation

In May-June 2024, Sportadmin tested a Web Application Firewall (WAF). Implementation was paused due to “high implementation costs.”

After the breach? WAF was in place within days.

IMY stated the obvious: if it was easy to install after the incident, you could have done it before. And whatever the firewall cost was, it wasn’t 6 million kronor.

3. They Detected the Breach Two Days Too Late

Attack attempts began on January 14. On January 16 they discovered the breach. When systems crashed.

The monitoring system measured performance and uptime, not security incidents. Two days of attacker activity went unnoticed.

4. Systems Had Excessive Privileges

The SQL user account had higher privileges than necessary. The Windows service account running the database also had elevated privileges. Additionally, the database server allowed execution of external programs like PowerShell.

The result? The attacker could move between systems and access even more data. The principle of least privilege isn’t a recommendation — it’s mandatory.

5. Code Review Missed the Vulnerability

The 2022 code change was classified as high-risk, and reviewed by several people. Yet the missing input validation wasn’t detected.

Why? The review focused on functionality (the login flow), not attack vectors (SQL injection). Also, automated security scanning was absent — no OWASP, SAST or DAST scans.

Human review is necessary but not enough.

Questions You Need to Ask Your Team

After reading IMY’s decision, here are some questions every tech team should be asking.

Risk Management:

  • Do we have known security risks not addressed yet? Is there a documented reason why — and a timeline for remediation?
  • If we’ve tested a security control and paused implementation — why, and when will we resume?

Detection:

  • How fast would we detect anomalous database queries or intrusion attempts?
  • Is our monitoring built for security, performance, and/or uptime?
  • Are security logs reviewed in real-time, or only during monthly audits?

Code Review:

  • Is security review part of our code review routines?
  • Is code review mandatory for all changes, without exception?
  • Do we have automated security scanning (OWASP/SAST/DAST) in our CI/CD pipelines?

Privileges:

  • Do our database and service accounts follow the principle of least privilege?
  • When did we last review privilege levels?
  • Could a compromised service enable lateral movement — or are services isolated?
  • Do our database servers allow execution of external commands?

A Starting Point: Actions to Consider

This is not an exhaustive security checklist — but a starting point based on what went wrong here.

Detection and Monitoring

  • Setup real-time monitoring of WAF and IDS logs. Monthly review isn’t enough.
  • Watch for SQL injection attempts, not only general traffic.
  • Keep logs for longer than 30 days to detect advanced persistent threats (APT).

Code Review and Pipeline

  • Add OWASP/SAST/DAST/SCA scanning to your CI/CD pipeline.
  • Have mandatory code review — with extra focus on security principles.
  • Don’t forget to scan your infrastructure-as-code.
  • Use AI-assisted code review as a complement.

Isolation and Architecture

  • Run services in isolated containers to limit lateral movement.
  • Setup zero trust between services — internal systems shouldn’t trust each other by default.

Technical Debt and Attack Surface

  • Inventory and archive or update old repos — every unused repo is a potential attack vector.

Privileges and Access

  • Review account privileges.
  • Limit privileges to what is only necessary — including service accounts.
  • Restrict the ability to run external programs from database servers.
  • Encrypt all stored data, especially databases, and data in transit.
  • Enforce MFA for all critical systems and admin access.

Secrets Management

  • Never store API keys, passwords, certificates, etc. in code — use a secrets manager.
  • Scan repos for committed secrets.

Risk Management

  • Scan all repos for new CVEs.
  • Document known risks and your remediation plan with timeline.
  • If a risk found but not addressed — make sure there’s a decision and a plan, not ignorance.

Testing and Preparedness

  • Conduct annual penetration tests — or when making major system changes.
  • Have a documented and tested incident response plan.

Conclusion

These mistakes are easy to make. IMY’s decision may be harsh, but if you’re building software that handles personal data, the bar for security measures just got raised.

Sportadmin’s response after the breach was exemplary. Shutting down systems within an hour, coordinating incident reports, and making outreach calls. IMY noted this as a mitigating factor.

But they still paid 6 million kronor. Their entire annual profit.

Why? Because what happened was foreseeable and preventable. They knew about the risks. They had tested solutions. They chose to wait.

The most expensive sentence in GDPR enforcement is: “We knew, but we didn’t act.”

If you handle Swedish national ID numbers or health data, IMY’s decision is your new baseline. Read it. Ask the questions. Act before you are forced to.

IMY’s full decision is available at imy.se (case number IMY-2025-7801).

</div>