Åttiosju minuter, spårade en vecka för sent

Själva intrånget varade omkring 87 minuter under de tidiga morgontimmarna den 27-28 juli 2026. Enligt Beacons tekniska redogörelse, given av teknikchef David Simpson, hade en AWS-åtkomstnyckel legat exponerad i JavaScript-byggartefakter som levererades direkt från företagets egen publika webbplats, precis den typ av klientpaket som alla besökares webbläsare laddar ner utan att någonsin utlösa något larm.

Beacon upptäckte inte intrånget i realtid. Enligt Simpson rekonstruerade företaget vad som hänt först i efterhand, genom att analysera AWS kostnads- och användningsrapporter för maj till juli 2026, och hittade en topp i datatransportkostnaderna just de två aktuella dagarna, ett bevis som stämde överens med nedladdningsaktiviteten snarare än att härröra från något system som upptäckte det i realtid.

Den retrospektiva metoden förklarar glappet i offentliggörandet: intrånget skedde den 27-28 juli, Beacon informerade kunderna den 4 augusti och gav ut en uppdaterad redogörelse den 13 augusti som fortfarande inte kunde besvara alla frågor. Simpson sa direkt till kunderna att det finns saker man kanske aldrig kommer att kunna klargöra kring incidenten, och lovade en fylligare redogörelse under de kommande veckorna.

Vilka som faktiskt är exponerade

Beacons kundbas uppgår till mer än 1 500 välgörenhetsorganisationer, och företaget har varit tydligt med att man inte har fastställt hur många av dem som faktiskt fått data stulen, bara att en fullständig kopia av databasen, inklusive bilagor, gjordes och nästan säkert laddades ner i läsbar form.

The Registers rapportering namnger specifika drabbade organisationer, däribland Molly Rose Foundation, Macmillan Cancer Support Jersey, English National Ballet, Sheffield Hospitals Charity, Shrewsbury and Telford Hospital Charity, British Deaf Association och Lincoln Cathedral, ett spann som sträcker sig från stöd vid sorg och psykisk hälsa till sjukhusinsamlingar, funktionshinderrättigheter och kulturarv.

Inget av detta är medicinska eller kliniska uppgifter på samma sätt som ett sjukhus egen patientjournal, men givar- och supporterregister hos organisationer som dessa omfattar rutinmässigt personer i sorg, sjukdom eller kris, precis den population en personuppgiftsansvarig förväntas skydda med proportionerligt mer omsorg, inte mindre, än en vanlig adresslista.

Glappet som DORA och NIS2 skulle täppa till, men inte når

EU:s förordning om digital operativ motståndskraft (DORA) kräver att finansiella enheter för ett register över varje IKT-tredjepartsleverantör och bedömer risken var och en utgör, enligt artiklarna 28 till 30, just för att en leverantörs säkerhetsläge ska granskas före, inte efter, en incident. NIS2 ålägger jämförbara säkerhets- och rapporteringsskyldigheter för väsentliga och viktiga enheter inom energi, hälsa, digital infrastruktur och offentlig förvaltning.

Välgörenhetsorganisationer och de SaaS-leverantörer som betjänar dem faller helt utanför båda regelverken. Deras enda skyddsnät är den allmänna ansvarsprincipen i den brittiska dataskyddslagen, som fortfarande gör en välgörenhetsorganisation ansvarig som personuppgiftsansvarig även när ett personuppgiftsbiträdes egen produkt sviktar, samt Charity Commissions frivilliga process för rapportering av allvarliga incidenter, som tillsynsmyndigheten själv beskriver som en prioritering av rapporter efter risk snarare än att hantera alla samtidigt.

Det är Servolas egen slutsats som inte förekommer i någon enskild källrapport: en AWS-nyckel som lämnats kvar i publikt JavaScript är precis den typ av grundläggande brist i hantering av hemligheter som ett DORA-reglerat leverantörs obligatoriska penetrationstest och granskningsspår finns till för att fånga upp innan ett avtal skrivs under. Ta bort det regelverket, som är fallet för välgörenhetssektorn, och den granskning som borde ha skett vid upphandlingen sker nu i efterhand, en incidentrapport i taget hos Charity Commission.

Vad en välgörenhetsorganisation, eller vilken liten ideell köpare som helst, bör fråga innan man förnyar

Det praktiska svaret kräver ingen ny lag. Varje välgörenhetsorganisation eller ideell förening som skriver under eller förnyar ett SaaS-avtal kan direkt be en leverantör om belägg för automatiserad hemlighetsskanning i sin byggpipeline, ett skriftligt åtagande om incidenthantering med en angiven tidsram, och en bekräftelse på exakt vilka givar- eller mottagarfält som verkligen behöver lagras snarare än att bara vara bekväma.

Mönstret är inte unikt för Beacon. Leverantörsintrång som drivs av grundläggande brister i hantering av inloggningsuppgifter, från RingCentrals fortfarande oförklarade social ingenjörskonst-incident till komprometteringen av fraktleverantören hos Trezor och ShipMonk, fortsätter att återkomma eftersom säkerhetsgarantier för leveranskedjan som byggts för reglerade sektorer inte automatiskt sträcker sig till angränsande sektorer som köper samma kategori av verktyg med en bråkdel av säkerhetsbudgeten och utan kontraktuell hävstång.

Tills den hävstången finns för välgörenhetsorganisationer på samma sätt som den finns för banker under DORA, utför självrapportering via Charity Commission det kontrollarbete som ingen extern tillsynsmyndighet i dag är i stånd att göra, en underbemannad organisation och en allvarlig incidentrapport i taget.

Läs vidare: När e-postsäkerhet blir en jurisdiktionsfråga  |  Ett dataintrång ert DORA-register inte kan förklara