Tekniska och organisatoriska åtgärder

Det här dokumentet publiceras på flera språk. Vid avvikelser mellan språkversionerna är den polska versionen bindande.

Version 1.1 · Senast uppdaterad: 22 oktober 2026

Åtgärder enligt Art. 32 GDPR med vilka LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, skyddar tjänsten formexposed. Denna sida utgör en del av personuppgiftsbiträdesavtalet som bilaga 2.

1. Tillämpningsområde och princip

Åtgärderna gäller för alla uppgifter som tjänsten behandlar: för de uppgifter vi behandlar för våra Kunders räkning (beskrivna i personuppgiftsbiträdesavtalet) och för de uppgifter för vilka vi själva är personuppgiftsansvariga, till exempel kundkonton och loggar. Det finns inga separata skyddsnivåer för de två; det som skyddar kontot skyddar också biträdesuppgifterna.

Struktur enligt Art. 32(1) GDPR. Pseudonymisering och kryptering (led a) behandlas i avsnitt 4; systemens fortlöpande konfidentialitet, integritet, tillgänglighet och motståndskraft (led b) i avsnitten 3, 5, 6 och 7; förmågan att i rätt tid återställa tillgängligheten efter en incident (led c) i avsnitt 7.1; förfarandet för att regelbundet testa, undersöka och utvärdera effektiviteten (led d) i avsnitt 9. Vi har valt åtgärderna utifrån de risker som beskrivs i vår konsekvensbedömning avseende dataskydd, med beaktande av den senaste utvecklingen och genomförandekostnaderna.

Princip: uppmätt snarare än avsett. Här anges endast det som faktiskt har genomförts i koden eller i driften. Det som är planerat men ännu inte genomfört listas uttryckligen som ”planerat” i avsnitt 10. En åtgärd som saknas här finns inte underförstått på plats.

Namn på maskiner, interna adresser, portar, användarnamn och programvaruversioner anges medvetet inte. De hjälper ingen att bedöma åtgärderna, men de hjälper den som vill kringgå dem. Den som behöver dem för en granskning enligt personuppgiftsbiträdesavtalet får dem inom ramen för den granskningen under sekretess, i den mån de är nödvändiga för granskningen.

2. Tjänstens uppbyggnad

Tjänsten körs på två av leverantörens egna servrar i Polen, som finns i samma interna nätverk:

Webbserver med databas. Den levererar applikationen, rymmer databasen, skickar aviseringar och säkerhetskopierar uppgifterna. Den är den enda som är konfigurerad för att ta emot förfrågningar från internet.
Skanningsserver. Den utför kontrollerna av tredje parters och egna webbplatser i en webbläsare och kör språkmodellen som klassificerar enskilda formulär och lägger till kod i ”Fix it for me”. Den är inte konfigurerad för att ta emot förfrågningar från internet, utan hämtar själv sina jobb från webbservern och lämnar tillbaka resultaten dit.

Ingen leverantör av webbhotell, datacenter eller molntjänster är inblandad i driften, och ingenting går till en extern AI-tjänst. Vilka tredje parter som tar emot uppgifter anges på sidan Underbiträden.

3. Konfidentialitet

3.1 Fysisk tillträdeskontroll

Servrarna finns i lokaler hos leverantören i Polen som inte är öppna för allmänheten. Endast ägaren har tillträde (enligt operatörens uppgift). Platsens exakta adress anges medvetet inte här.

3.2 Åtkomstkontroll: inloggning i tjänsten

Lösenord sparas endast som hash med PHP:s standardmetod (bcrypt). Om standardmetoden ändras förnyas hashen vid nästa inloggning. Vid ett inloggningsförsök med en okänd adress beräknar servern ändå en hash, så att svarstiden inte avslöjar om ett konto finns. På samma sätt avslöjar svaret på en begäran om lösenordsåterställning varken genom sin formulering eller sin varaktighet om kontot finns; återställningsmejl skickas till samma adress högst tre gånger per timme. Nya lösenord måste vara minst tio tecken långa och får inte överstiga 72 byte (UTF-8), eftersom bcrypt inte tar hänsyn till fler byte. Byte av lösenord loggar ut alla andra enheter; återställning via länken loggar ut alla enheter, och länken gäller endast en gång.
Spärr efter misslyckade försök. Misslyckade inloggningar räknas per IP-adress; efter för många inom kort tid (för närvarande åtta på 15 minuter) spärras inloggning från den adressen tillfälligt. En lyckad inloggning nollställer räknaren. Försöken raderas efter sju dagar. Dessutom räknas före varje lösenordskontroll ett försök per konto (för en okänd adress per angiven adress) och per IP-adress, inklusive lyckade försök: för närvarande högst åtta per konto från samma IP-adress och 80 per IP-adress på 15 minuter; en betydligt högre gräns gäller per konto för alla adresser sammantaget, mot distribuerad gissning. Misslyckade försök från en annan adress låser därför inte längre ute ägaren från ett konto. Dessa räknare innehåller endast en HMAC-nyckel, ingen e-post- eller IP-adress i klartext, och löper ut med sitt tidsfönster. Om räknarlagringen inte är tillgänglig nekas inloggningen i stället för att släppas igenom. Samma typ av gräns gäller för bekräftelse av lösenordet före byte av lösenord eller adress, aktivering eller avaktivering av andra faktorn, överföring av en arbetsyta, dataexporten och radering av kontot (fem försök per konto på 15 minuter), för registreringar (tio per IP-adress och timme) och för lösenord till klientportaler (tio försök per portal och IP-adress, 50 per portal på 15 minuter).
Andra faktor. Varje konto kan aktivera inloggning med en engångskod enligt RFC 6238 (TOTP). Hemligheten för detta sparas krypterad i databasen; nyckeln sparas inte i databasen, så ett utdrag ur databasen räcker inte ensamt. En godkänd kod gäller inte en andra gång. Tio återställningskoder sparas endast som hash. Engångs- och återställningskoder är begränsade till tio försök per konto på 15 minuter, även under konfigurationen.
Administrationsområdet endast med andra faktor. Operatörens administrationsområde öppnas endast för konton med andra faktorn aktiverad. Konfigurationschecklistan rapporterar varje administratörskonto utan andra faktor.
Sessioner. Sessionscookien kan inte läsas av skript (HttpOnly), skickas endast via HTTPS (Secure) och skickas inte med förfrågningar från tredje parters webbplatser som skulle kunna ändra något (SameSite=Lax). Vid inloggning skapas ett nytt sessions-ID, så att ett ID som planterats i förväg inte längre gäller; servern godtar inget sessions-ID som den inte själv har utfärdat. Varje konto ser sina inloggade enheter och kan logga ut dem var för sig.
”Håll mig inloggad” är frivilligt och gäller i 30 dagar, men inte för konton med administratörsrättigheter; de loggar alltid in med lösenord och andra faktor. Token består av två delar; den verifierande delen sparas i databasen endast som hash. Varje användning ersätter den med en ny, och även vid samtidiga förfrågningar gäller varje token endast en gång, så att en stulen token upptäcks senast vid nästa äkta besök.
Länkar i mejl. Länkar för att bekräfta adressen och återställa lösenordet sparas i databasen endast som hash. Återställningslänken gäller i en timme, länken för att bekräfta en registrering i 72 timmar, länken för att bekräfta en ändrad adress i 24 timmar. Om e-postadressen ändras blir en öppen återställningslänk ogiltig.
Gränssnitt. API-nycklar, anslutningskoder för tilläggen och utrullningskoder sparas endast som hash. API-nycklar kan endast användas ett begränsat antal gånger per minut; anslutningskoder för tilläggen gäller i 15 minuter och endast en gång.
Botskydd på de offentliga formulären (registrering, inloggning, lösenord, kontroll, headerverktyg, opt-out, support och kontakt): Google reCAPTCHA, som laddas först vid inlämning. Endast ett giltigt svar från Google med tillräckligt högt värde för exakt formulärets åtgärd godtas; om Google inte svarar inom tre sekunder nekas inlämningen. Detaljer finns i integritetspolicyn.

3.3 Åtkomstkontroll: serveradministration

Servern som kan nås från internet använder ett paketfilter för att endast tillåta de tjänster den erbjuder, och spärrar automatiskt adresser efter upprepade misslyckade inloggningar i serveradministrationen.
Automatiserade processer mellan servrarna använder egna nycklar med snävt begränsade rättigheter. Den nyckel med vilken webbservern levererar nya versioner av skannern får endast köra en fast lista med kommandon på skanningsservern och får endast kopiera, enbart skrivande, till skannerns katalog; en interaktiv inloggning är inte möjlig med den, och varje avvisat kommando loggas. På samma sätt får skanningsservern endast skriva skärmbilder till en viss katalog på webbservern.
Processen som betjänar webbplatsen har varken skrivåtkomst till produktionsinstallationen eller en nyckel till skanningsservern. En driftsättning som utlöses i administrationsområdet registrerar endast ett jobb, som en separat körning utför.
Hemligheter som databasinloggningar och nycklar förvaras i konfigurationsfiler utanför den katalog som serveras och kopieras inte med vid driftsättning. Webbserverns konfiguration distribueras inte via webbgränssnittet.

3.4 Behörighetskontroll: rättigheter inom tjänsten

Roller. Varje arbetsyta har rollerna ägare, administratör och läsare. Att ändra, radera, bjuda in och spara inloggningsuppgifter är förbehållet ägare och administratörer; endast ägaren får ändra roller och ta bort medlemmar. En inbjudan gäller endast så länge den person som skickade den fortfarande är ägare eller administratör. Läsare ser adresserna till webhooks och chattkanaler endast förkortade till värden, eftersom adressen ensam gör det möjligt att posta i kanalen. Kontrollen sker på servern, inte bara i gränssnittet.
Bindning till arbetsytan. Domäner och inställningar är endast tillgängliga för arbetsytans medlemmar. För varje kontroll skapar tjänsten en rapport under en slumpmässig länk som inte kan gissas; resultaten och skärmbilderna från en kontroll kan nås via denna länk utan inloggning, skärmbilder endast tillsammans med länken till deras rapport. Länken visas i kontot och i larm; den som vidarebefordrar den vidarebefordrar rapporten.
Förfrågningar som ändrar tillstånd kräver en säkerhetstoken per session (CSRF-skydd), som jämförs i konstant tid.
”Visa som kund”. För support kan operatören se applikationen så som en kund ser den. Vyn upphör efter en timme, blockerar ändringar av lösenord, adress, andra faktor, enheter, abonnemang, export och radering, stänger administrationsområdet under tiden och loggas. När den avslutas loggas operatören ut helt; operatören kan återvända till administrationsområdet endast genom att logga in igen med lösenord och andra faktor. Kunden kan se den i sin dataexport.
Administration. Endast ett fåtal uttryckligen behöriga konton har administratörsrättigheter; varje återställning av en andra faktor av administrationen loggas.

3.5 Separationskontroll

Kundernas uppgifter är logiskt separerade per arbetsyta. Varje läs- och skrivväg i det inloggade området bär med sig denna bindning; rapporter är dessutom tillgängliga via sin länk (avsnitt 3.4).
Utveckling och drift körs i separata installationer med separata databaser och separata databasanvändare. Utvecklingsanvändaren har ingen åtkomst till produktionsdatabasen. Verkliga kunduppgifter kopieras inte till utvecklingsmiljön; där arbetar vi med genererade exempeldata.
För varje miljö har skannern egna inloggningsuppgifter med rättigheter endast till de uppgifter den behöver för sina jobb. Den kan inte läsa konton, fakturering eller loggar.
På webbservern körs även andra tjänster från samma leverantör. De har egna databaser och egna databasanvändare utan åtkomst till denna tjänsts uppgifter.

4. Kryptering, pseudonymisering och uppgiftsminimering

4.1 Inloggningsuppgifter för skanningen bakom inloggningen

För denna funktion sparar Kunden användarnamn och lösenord för ett testkonto. De är de mest känsliga uppgifterna i tjänsten och skyddas därför annorlunda än allt annat:

När de sparas krypterar webbservern dem med skanningsserverns offentliga nyckel (ECIES: X25519 med en engångsnyckel per post, HKDF-SHA256, AES-256-GCM). Den privata nyckeln finns endast på skanningsservern. Webbserver, databas och säkerhetskopior innehåller endast chiffertext; inte heller vi kan läsa den där.
Varje post är kryptografiskt bunden till sin domän. Om den flyttas till en annan domän misslyckas dekrypteringen.
För en skanning bifogas chiffertexten till jobbet. Skanningsservern dekrypterar den och lämnar inloggningsuppgifterna till kontrollcontainern endast via standardinmatning, aldrig som kommandoradsargument som skulle synas i processlistor. Så snart skanningsservern har läst den raderas chiffertexten från jobbet; en körning rensar eventuella rester senast efter en timme.
Inloggningsuppgifterna visas aldrig, loggas aldrig, lämnas aldrig ut via API:t och exporteras inte. Gränssnittet visar endast det första tecknet och längden på användarnamnet. Borttagning skriver över chiffertexten.
Bakom inloggningen läser skannern endast: ingen inlämning, inget aktivt test, inga skärmbilder, inga sidor för utloggning, radering eller uppsägning.

4.2 Ytterligare kryptering och hashar

Lösenord, återställningskoder, lösenord till klientportaler, API-nycklar, anslutnings- och utrullningskoder, tokens för ”Håll mig inloggad”, sessions-ID:n i enhetslistan och länkar för bekräftelse och återställning sparas endast som hash.
Hemligheter för andra faktorn sparas krypterade (avsnitt 3.2).
Vi påstår inte att hela databasen är krypterad i vila. De känsliga värdena skyddas var för sig, som beskrivs ovan.

4.3 Uppgiftsminimering genom design

Leveranskontroll: Endast rubrikerna och högst de första 8 KB av texten läses. Endast tidpunkten, kopplingen, i förekommande fall testinlämningens ID och resultatet av äkthetskontrollen (SPF, DKIM, DMARC) hamnar i databasen, aldrig innehållet eller en fullständig avsändaradress. Äkthetsresultatet för det senaste mejlet sparas med domänen och skrivs över av nästa; det innehåller IP-adressen till den levererande e-postservern och avsändarens e-postdomän. Mejlet raderas från brevlådan efter lyckad behandling; om hämtning eller radering misslyckas sker detta vid nästa lyckade körning.
Kontroller: Formulärens struktur sparas med fältnamn, typer och etiketter, attribut för obligatoriska fält och synlighet, inga värden; skannern läser början av förifyllda dolda fält (upp till 24 tecken) och av dataattribut (upp till 60 tecken) endast under kontrollen och sparar dem inte. Skärmbilderna från den fullständiga kontrollen maskeras inte; endast webbläsarkontrollerna täcker över inmatningsfält. Mottagaradresser i formulär sparas endast som domän. Aktiva testinlämningar innehåller endast märkta testtexter utan personuppgifter.
Tilläggen för WordPress och TYPO3 överför endast dagliga siffror och egenskaper som plugininventeringen, och för ett anslutet WordPress-plugin även domänerna för länkar från blockerade meddelanden för svärmskyddet (aktiverat som standard); inget annat innehåll, inga namn, adresser eller IP-adresser för besökare. Frivilliga formulär- och fältfelsräkningar är avstängda som standard.
”Fix it for me”: Den inklistrade koden behandlas endast under förfrågans varaktighet och sparas inte.
Märke: Märkesbilden på kunders webbplatser sätter ingen cookie och startar ingen session.
Driftaviseringar till operatörens telefon är fasta texter utan variabler, det vill säga utan namn, adresser eller innehåll. Felaviseringar via e-post till operatören innehåller felmeddelandets råtext, inte rensad och avkortad till 400 tecken; i enskilda fall kan den innehålla adresser eller länkar.
Svärmskydd: Mellan kundernas tillägg delas endast domäner från länkar i blockerad spam; utbytet av IP-nätverk är avstängt.
Plats: Landet för en IP-adress bestäms utifrån en lokal databasfil; ingen adress går till en geolokaliseringstjänst.

5. Skydd mot missbruk av skannern

Skannern laddar tredje parters sidor med en riktig webbläsare. Utan skydd vore den ett verktyg med vilket någon utifrån skulle kunna nå vårt interna nätverk eller andra icke-offentliga mål (server-side request forgery). Därför finns två oberoende skikt och isolering av varje enskild körning.

5.1 Isolerad körning

Varje kontroll körs i en egen container som tas bort efteråt. Den körs utan administratörsrättigheter, utan ytterligare operativsystemsbehörigheter och utan möjlighet att utöka sina privilegier. Dess filsystem är skrivskyddat förutom små flyktiga områden.
Minne, antal processer och körtid är begränsade; en körning som överskrider tiden avbryts.

5.2 Nätverk: två skikt

Första skiktet, i skannern: Före skanningen och sedan för varje enskild förfrågan från webbläsaren, inklusive omdirigeringar och inbäddat innehåll, kontrolleras vart adressen pekar. Privata, lokala, reserverade och dokumentationsnätverk (IPv4 och IPv6) avvisas, liksom andra portar än de som är brukliga för webben. Webbläsaren tillåter inga service workers, och WebSocket-anslutningar stängs, eftersom båda skulle kunna kringgå denna kontroll.
Andra skiktet, i nätverket: Containrarna körs i ett eget nätverk. Brandväggsregler tillåter anslutningar därifrån till internet endast på webbportar; anslutningar till privata nätverk, inklusive vårt interna nätverk med webbserver och databas, blockeras. Undantag som själva kontrollkörningen kräver är begränsade till det nödvändiga och beskrivs i vår interna dokumentation. Detta skikt verkar även om ett namn pekar någon annanstans först efter den första kontrollen.

5.3 Förfrågningar från webbservern

Där webbservern själv gör förfrågningar till tredje parters adresser – för bevis på kontroll över domänen, för headerverktyget, för sökningen efter exponerade filer, för pulsförfrågningar, för RDAP-förfrågningar och för kontroll av certifikat, för webhooks och chattlarm och för den valfria andra kontrollpunkten – gäller samma regler: endast webbprotokoll, på de brukliga webbportarna (webhooks och chattlarm endast via HTTPS på standardporten), endast offentliga adresser, anslutning endast till exakt den adress som kontrollerats i förväg, så att ett namn inte i efterhand kan omdirigeras till ett internt mål, omdirigeringar antingen inte följda alls eller endast följda manuellt och kontrollerade på nytt varje gång, korta tidsgränser; för bevis på kontroll över domänen, för pulsförfrågningar och för den andra kontrollpunkten i webbläsarkontroller även en begränsad svarsstorlek.

5.4 Vad skannern inte gör på tredje parters webbplatser

Aktiva testinlämningar (högst fem per kontroll) finns för kunder endast för domäner för vilka bevis på kontroll har lämnats (DNS, metatagg, fil eller tillägg); det enda undantaget är interna kontroller av våra egna test- och demodomäner. Värdnamnet för en domän med bevis på kontroll kan inte ändras, så att beviset inte går över till en annan värd. Allt annat är passivt: läsning av sidor som en besökare.
Webbläsarkontroller går fram till steget före inlämning och utlöser ingen beställning, betalning eller inlämning.
Domäner på opt-out-listan kontrolleras inte; pågående övervakning upphör vid nästa schemalagda kontroll.

6. Integritet: överföring och inmatning

6.1 Transport

Applikationen kan nås från internet endast via HTTPS; webbläsaren instrueras att endast använda HTTPS i ett år (HSTS). Certifikat förnyas automatiskt.
Ytterligare headers begränsar inbäddning av applikationen på tredje parters sidor, gissning av filtyper och inlämning av formulär till tredje parters mål. En innehållssäkerhetspolicy (content security policy) låter endast de skript köras i applikationen som servern släpper med respektive svar; aktuella webbläsare kör inte injicerade skript eller händelsehanterare i HTML-koden.
Leveranskontrollens brevlåda hämtas via en krypterad anslutning med certifikatverifiering.
Webhooks kan signeras med en hemlighet från Kunden (HMAC-SHA256 med tidsstämpel), så att mottagaren kan verifiera ursprung och integritet. Förfrågningar till den valfria andra kontrollpunkten signeras, och för webbläsarkontroller även deras svar.
Öppet redovisat: Anslutningar inom vårt interna nätverk är inte krypterade genomgående. Inloggningsuppgifterna för skanningen bakom inloggningen förblir krypterade hela vägen (avsnitt 4.1).

6.2 Inmatningskontroll och loggar

Viktiga åtgärder i konton och arbetsytor (till exempel inloggning, ändringar av domäner, larmmottagare och rättigheter, raderingar, supportåtkomst) registreras i aktivitetsloggen med konto, tidpunkt, IP-adress och land, och raderas efter 365 dagar.
Uppgifter om sidåtkomst som sparas för säkerhet och förebyggande av missbruk raderas efter 60 dagar, felloggar efter 90 dagar, innehållet i skickade mejl efter 30 dagar. Åtkomsttokens i begärda adresser och hänvisningsadresser, till exempel de i rapport- eller portallänkar, förekommer i uppgifterna om sidåtkomst endast i maskerad form.
Godkännandet av avtalsdokumenten sparas med den visade versionen, dess kontrollsumma, tidpunkt, IP-adress och webbläsaridentifierare.
Bevisloggar kan förses med en tidsstämpel från en extern tidsstämplingsmyndighet; endast en kontrollsumma av innehållet går dit, inte själva innehållet.

7. Tillgänglighet och motståndskraft

7.1 Säkerhetskopiering

Databasen säkerhetskopieras varje natt. En säkerhetskopia får sitt slutliga namn först efter att dess innehåll har kontrollerats: lyckat avslut av säkerhetskopieringsprogrammet, minst en post, lika många tabeller som databasen har och slutraden från en fullständig körning. Äldre säkerhetskopior tas bort först efter en lyckad ny.
Varje säkerhetskopia raderas efter 14 dagar. Lagringsplatsen ligger utanför varje katalog som serveras; en plats inom projektet avvisas.
Återställningstest: En gång i veckan laddas den senaste säkerhetskopian in i en tillfällig databas, jämförs tabell för tabell med produktionen och raderas igen. Resultatet sparas.
Om en säkerhetskopiering eller ett test misslyckas skickas en avisering via e-post och till operatörens telefon.
Återställning efter en incident: Om databasen fallerar eller uppgifter blir korrupta återställer vi den senaste testade säkerhetskopian. Ändringar som gjorts sedan den säkerhetskopian, som regel högst en dags ändringar, kan då gå förlorade; om en säkerhetskopiering har misslyckats, motsvarande fler. Vi verkställer sedan kända senare raderingsbegäranden på nytt (avsnitt 8). Vi förbinder oss inte till någon viss återställningstid.
Begränsning, öppet redovisad: Säkerhetskopiorna lagras för närvarande på samma plats som databasen och är inte separat krypterade. De skyddar mot driftfel, felaktiga ändringar och korrupta uppgifter, inte mot förlust av själva servern. En krypterad kopia på en andra plats är planerad (avsnitt 10).
Inloggningsuppgifterna för skanningen bakom inloggningen finns i säkerhetskopiorna endast som chiffertext; hemligheten för andra faktorn endast i krypterad form, med en nyckel utanför databasen.

7.2 Övervakning

En statuskörning kontrollerar tjänstens komponenter var femte minut, inklusive databasen, kön och skannerns hjärtslag, som skannern skriver regelbundet även när den är inaktiv. Om en komponent fallerar skickas en avisering; när den återhämtar sig, en friklarering.
Korsövervakning: En statuskörning kan inte rapportera att den maskin den körs på har fallerat. Skanningsservern kontrollerar därför varje minut om applikationen svarar och rapporterar, efter flera misslyckanden i följd, med en fast text till operatörens telefon. Omvänt övervakar webbservern skannerns hjärtslag; konfigurationschecklistan visar om korsövervakningen körs.
Fellarm: En typ av fel som aldrig har inträffat tidigare rapporteras en gång omedelbart; en anhopning av fel utlöser endast en enda signal till operatörens telefon; en gång om dagen skickas en översikt. Det innebär att vi inte först får veta om ett fel från en kund.
Begränsning, öppet redovisad: Båda servrarna finns på samma plats. Ett avbrott på hela platsen, till exempel av ström eller internetanslutning, rapporteras inte av någon larmmekanism utan upptäcks av en människa.

7.3 Ändringar och driftsättning

Nya versioner byggs och testas först i den separata utvecklingsmiljön. Driftsättningen kontrollerar alla förutsättningar innan den första filen skrivs, genomför ändringarna i databasschemat och låter pågående kontroller avslutas ordnat innan skannern startas om.
För en ny kunds väg finns ett röktest via verklig HTTP, som körs efter omställningar. Vi påstår inte att en automatiserad testsvit körs före varje enskild driftsättning.

8. Radering och lagringstider

En raderingskörning varje natt verkställer de frister som anges i integritetspolicyn och personuppgiftsbiträdesavtalet. Den läser samma inställningar som siffrorna i texterna hämtas från; för dessa frister skiljer sig därför text och beteende inte åt.
Kontrollresultat inklusive skärmbilder raderas efter 13 månader (det senaste per domän finns kvar), tilläggens siffror efter 13 månader, leveransloggar för larm efter 90 dagar, supportärenden efter 24 månader.
Att ta bort en domän raderar domänens uppgifter, inklusive kontroller, formulär, resultat, skärmbilder, rapporter, jobb, larmmottagare och loggar, incidenter, leveransuppgifter, inloggningsuppgifter för skanningen bakom inloggningen och bevis.
Radering av ett konto sker omedelbart; arbetsytor utan ytterligare medlemmar raderas med sina uppgifter, arbetsytor med ytterligare medlemmar övergår till en annan medlem, i första hand till administratörer och bland dem till den som varit med längst. Tills deras egna frister löper ut finns följande kvar: loggarna vars poster behåller det gamla kontonumret, som inte längre hänvisar till något befintligt konto, inklusive raderingsposten, samt skickade mejl, beviset på avtalsslutet, supportärenden, rapporter från kontroller av potentiella kunder (upp till 90 dagar) och faktureringsuppgifter hos Stripe; detaljer finns i integritetspolicyn.
Raderade uppgifter finns kvar i säkerhetskopior tills de löper ut efter 14 dagar. Riktad radering inom en säkerhetskopia sker inte; om en säkerhetskopia återställs verkställs kända senare raderingsbegäranden på nytt manuellt.

9. Organisation och översyn

Personer: Tjänsten drivs för närvarande av ägaren själv. Ytterligare personer får åtkomst först efter ett åtagande om konfidentialitet och endast i nödvändig omfattning, och de behandlar uppgifter endast på våra instruktioner (Art. 29 och Art. 32(4) GDPR).
Underbiträden: Vi anlitar dem endast efter att ha granskat deras garantier och enligt ett avtal i enlighet med Art. 28(4) GDPR, och listar dem på sidan Underbiträden; detaljer regleras av personuppgiftsbiträdesavtalet.
Personuppgiftsincidenter: Om en personuppgiftsincident berör biträdesuppgifter underrättar vi Kunden utan onödigt dröjsmål, om möjligt inom 48 timmar; detaljer regleras av personuppgiftsbiträdesavtalet.
Rapportering av sårbarheter: Vi tar emot rapporter på Säkerhet och via filen /.well-known/security.txt.
Checklista för konfiguration och lansering: I administrationsområdet mäter en checklista tillståndet för säkerhetsrelevanta inställningar, till exempel säkerhetskopiering, administratörer utan andra faktor, e-postkonfiguration och hjärtslag, och visar avvikelser.
Översyn av dessa åtgärder (Art. 32(1)(d) GDPR): vid varje betydande ändring av tjänsten, efter varje säkerhetsincident och i övrigt minst en gång per år. Vi bedömer då om åtgärderna är effektiva och fortfarande motsvarar riskerna, och dokumenterar resultatet i en ny version av denna sida eller, om inget ändras, med datum för översynen i avsnitt 11. Löpande mäter checklistan för konfiguration och lansering tillståndet för de inställningar den omfattar.
Externa granskningar: Inga externa penetrationstester är för närvarande beställda, och det finns inga säkerhetscertifieringar. Detta anges här för att ingen ska anta att de finns.

10. Planerat, ännu inte genomfört

Dessa punkter är inte åtaganden förrän de anges här som genomförda i en ny version:

Säkerhetskopia på en andra plats: en krypterad kopia av den nattliga säkerhetskopian utanför servern, så att inte ens en total förlust av servern leder till dataförlust.
Andra kontrollpunkt: Oberoende bekräftelse av webbläsarkontroller från en andra plats är förberedd i tjänsten men inte konfigurerad. Utan den finns ingen bekräftelse från en andra plats.
Härdning av serveradministrationen: Detta pågår. Av de skäl som anges i avsnitt 1 publicerar vi inga detaljer.

11. Status och version

Version 1.1 · Senast uppdaterad: 22 oktober 2026 · vid avvikelser mellan språkversionerna har den polska versionen företräde i stället för den tyska; ingen annan ändring.
Version 1.0 · Senast uppdaterad: 11 oktober 2026 · första versionen som separat sida; tidigare bilaga 2 till personuppgiftsbiträdesavtalet. Rättat jämfört med den tidigare bilagan: återställningstestet körs varje vecka, säkerhetskopiorna finns på samma server, ingen automatiserad testsvit körs före varje driftsättning, anslutningar i det interna nätverket är inte krypterade genomgående. Nytt beskrivet: krypteringen av inloggningsuppgifterna för skanningen bakom inloggningen, isoleringen av skannern, korsövervakning och fellarm.
Ändringar publiceras med nytt versionsnummer här och i översikten Ändringar i avtalsdokumenten; för varje försvagning av åtgärder gäller personuppgiftsbiträdesavtalets varseltid.
Vid avvikelser mellan språkversionerna har den polska versionen företräde.

Hur kan vi hjälpa till?