Är din kakbanner laglig? Blockerar den verkligen icke-nödvändiga skript? 7 vanliga fel

Knappen ”Neka” bevisar inte att spårningen stannar. En praktisk guide till kakbannerns Network-anrop, lagring, samtyckesläge och återtester.

Du öppnar webbplatsen i en ny webbläsarprofil, klickar på ”Neka” och ser att kakmeddelandet försvinner. Utifrån verkar allt vara i ordning, men frågan är din kakbanner laglig börjar besvaras först nu: gick ett anrop redan till en annonsplattform före klicket, försökte svaret sätta en identifierare som blev kvar i webbläsarens lagring och fick taggarna rätt samtyckesstatus efter nekandet? Knappen är bara kontrollpanelen, och kontrollen måste visa att ledningarna under den faktiskt är inkopplade, eftersom CMP:n kanske ännu inte har angett standardläget när tagghanteraren redan kör sin första regel.

En visuell kontroll av bannern eller en grön bock från en automatisk skanner berättar inte vad som hände under inläsningens första sekunder. Den visar inte heller vilket skript som utlöste åtgärden, vilken samtyckesstatus skriptet kunde läsa just då eller om det synliga slutläget motsvarar hela den föregående händelsekedjan. Därför jämför vi på en och samma tidslinje webbplatsens beteende före valet, efter att alla icke-nödvändiga kategorier har nekats, efter samtycke och efter ett senare återkallande. I varje läge granskar vi nätverksanrop, svarshuvuden, kakor, localStorage och annan lagring, samtyckessignalernas ordning och vilken konkret åtgärd som initierade anropet. Först den jämförelsen skiljer en korrekt konfiguration från en banner som bara stängs.

Det här är en teknisk artikel, inte ett individuellt juridiskt utlåtande. Den visar hur du samlar verifierbara fakta utan att dra slutsatser som bevisningen inte bär. Om webbplatsen använder Google Tag Manager, Google Analytics 4, Google Ads, Meta Pixel, inbäddad video, chatt eller andra tredjepartsverktyg är listan över kakor i en enda vy bara en del av helheten. Den avgörande frågan är därför inte ”är bannern installerad?”, utan ”vad gör webbplatsen i vart och ett av användarens valda lägen?”.

Vad kontrollen av kakbannern visar — och inte kan intyga

Kontrollen följer den tekniska samtyckeskedjan från sidans första anrop till statusändringen efter användarens val. Det räcker inte att studera slutläget, eftersom den första inläsningsordningen redan kan ha utlöst en åtgärd som en senare stängd banner inte gör ogjord. Omfattningen innefattar skriptens inläsningsordning, nätverksanslutningar, kakor och annan lagring, signaler från CMP:n eller plattformen för samtyckeshantering, Google Consent Mode, kategoriernas faktiska beteende och möjligheten att ändra valet senare. Resultatet är ett tekniskt bevisunderlag för hur webbplatsen använder kakor och spårning, inte ett certifikat på att hela organisationens personuppgiftsbehandling är juridiskt felfri.

Juridiskt behöver två närliggande nivåer hållas isär. Artikel 5.3 i ePrivacy-direktivet gäller lagring av information i användarens terminalutrustning och åtkomst till information som redan finns där; i Sverige har bestämmelsen genomförts genom 9 kap. 28 § lagen (2022:482) om elektronisk kommunikation (LEK), och det tekniska tillämpningsområdet är inte begränsat till filer som råkar heta ”cookie”. GDPR blir relevant när personuppgifter behandlas och reglerar dessutom kraven på ett giltigt samtycke och principerna för återkallande. En teknisk kontroll enligt den ena ordningen ersätter därför inte en juridisk bedömning enligt den andra. I rapporten namnger vi nivåerna var för sig, så att ett observerat tekniskt faktum inte framställs som en bredare juridisk slutsats.

Post- och telestyrelsen (PTS) förklarar att samtycke ska inhämtas innan icke-nödvändiga kakor används och att användaren ska kunna ta tillbaka sitt samtycke. Men kategorinamnet ”nödvändig” bevisar ingenting i sig. Undantaget för det som är absolut nödvändigt ska bedömas snävt: åtgärden måste behövas för att överföra ett elektroniskt meddelande via ett elektroniskt kommunikationsnät eller vara nödvändig för att tillhandahålla en tjänst som användaren uttryckligen har begärt, inte bara vara praktisk för analys, marknadsföring eller webbplatsägarens interna behov. Den som granskar behöver koppla åtgärden till funktionen som gör den nödvändig och samtidigt kontrollera att kategorin inte döljer ett annat ändamål som den begärda funktionen inte motiverar.

Sökfrasen ”GDPR-granskning av webbplats” avser i den här tjänsten endast kakor, spårning och samtyckeshantering. Utanför omfattningen ligger bland annat rättsliga grunder för andra processer, de registrerades begäranden, avtal och intern styrning. Vår granskning av kakor och spårning ger de tekniska fakta som en jurist eller ett dataskyddsombud behöver för att bedöma just den delen av webbplatsen, men GDPR-efterlevnad är inte en enda brytare som en teknisk skanner kan slå på för hela organisationen. Den avgränsningen är ingen friskrivning; den anger tydligt vad rapporten styrker och vilka frågor som fortfarande måste avgöras utanför den tekniska granskningen.

Är din kakbanner laglig? Så samlar du bevis i stället för ett skannerresultat

Ett bra test börjar i en ren webbläsarprofil utan tidigare sparat samtycke, kakor från webbplatsen eller anrop från tillägg. Innan du klickar på något startar du Network-loggen, kontrollerar panelen Application och dokumenterar utgångsläget. Därefter upprepas samma följd av åtgärder efter nekande, efter samtycke och efter återkallande. Varje scenario ska börja från ett dokumenterat läge och hela loggen ska sparas, eftersom gårdagens val annars kan se ut som dagens bannerfel eller, omvänt, dölja det verkliga felet.

En rad i Network visar att webbläsaren försökte kontakta en viss adress och låter dig granska initiator, status, begärande- och svarshuvuden samt den information som skickades. Den bevisar däremot inte att en kaka sparades. Svarshuvudet Set-Cookie visar serverns försök att sätta en kaka, men webbläsaren kan blockera försöket. JavaScript kan samtidigt skriva till document.cookie eller localStorage utan ett sådant huvud. Därför måste det faktiska resultatet kontrolleras i Application, och ingen enskild indikator får ersätta de andra. Ett synligt anrop till en analysdomän visar ett försök till dataflöde, inte automatiskt att en analyskaka sattes eller att servern tog emot en bestämd uppsättning personuppgifter.

För varje fynd antecknar vi testad webbadress och användarväg, tidpunkt, enhet och webbläsarkontext, vald samtyckesstatus, anropets initiator och destination, överföringens resultat samt förändringar i lagringen. Då går exakt samma test att upprepa efter rättningen. Automatisk genomsökning ger en bred första inventering, men den går inte igenom alla menyer, köpsteg, inloggade områden, språkversioner och dynamiskt öppnade integrationer, och den kan inte säkert avgöra ändamålet enbart från ett filnamn eller en domän. Därför följer manuella scenarier och ett samtal med verktygens ansvariga: vem införde verktyget, för vilket ändamål, i vilken taggbehållare ligger det och vilken samtyckessignal ska det följa? Bevis utan sammanhang är bara en skärmbild; sammanhang utan bevis är bara ett löfte.

1. Icke-nödvändiga skript körs före användarens val

Ett kritiskt ordningsfel uppstår när CMP-bannern visas snabbt, men en analys- eller annonstagg redan har körts. Användaren läser fortfarande knapparna medan webbläsaren har kontaktat en tredje part eller skrivit en identifierare. PTS utgångspunkt är tydlig: samtycke ska finnas innan icke-nödvändiga kakor används. Den tekniska kontrollen börjar därför vid dokumentets första inläsning, inte när granskaren har hunnit hitta och klicka på ”Neka”.

I Google Tag Manager är en felaktig händelseordning en vanlig orsak. Standardläget för samtycke måste anges innan taggarna körs, med utlösaren Initiering av samtycke eller en annan lösning som garanterar samma ordning, och först efter användarens åtgärd skickas en uppdatering. Om standardläget kommer för sent kan taggen under ett kort ögonblick läsa en odefinierad eller tidigare sparad status och aktiveras. En banner som stängs snabbt löser inte den kapplöpningen, eftersom felet ligger i exekveringsordningen och inte i animationen.

Påståendet ”kakorna laddas före samtycke” måste delas upp mer exakt i rapporten. Själva skriptet kan ha lästs in, ett nätverksanrop kan ha gjorts, en signal utan kakor kan ha skickats, ett Set-Cookie-försök kan ha skett eller en identifierare kan faktiskt ha sparats. Varje åtgärd har olika bevisvärde. I avancerat samtyckesläge kan vissa Google-taggar läsas in med nekad lagring och skicka signaler utan kakor. Skriptets närvaro räcker därför varken som bevis på en överträdelse eller som bevis på efterlevnad.

Rättningen börjar med en karta över verktygen och en gemensam, tydlig statusmodell: vilka taggar får fungera utan ett val, vilka kräver en viss kategori och vilken händelse ändrar standardläget? Efter konfigurationsändringen upprepas testet i en ren profil med sparad Network-logg, med särskild uppmärksamhet på de första anropen och deras initiatorer. Om felet bara uppträder ibland tyder det ofta på en tidskonflikt mellan CMP:n, taggbehållaren och webbplatsens kod. Den behöver lösas i själva inläsningsordningen, inte döljas bakom en banner som visas snabbare.

2. ”Neka” ändrar gränssnittet men inte dataflödet

Knappen kan stänga bannern, gråmarkera valet och till och med spara värdet ”denied”, medan tredjepartstaggarna fortsätter precis som förut. Testet av ett nekande handlar därför inte om att texten har försvunnit, utan om att jämföra två lägen. Före och efter att alla icke-nödvändiga kategorier har nekats dokumenterar vi anrop och lagring. Sedan granskar vi om de berörda taggarna ändå får en aktiverande händelse, om nya identifierare dyker upp och om nekandet består vid följande sidvisningar. En tidigare session kan lätt förstöra testet: gav du samtycke i går kan dagens sida först läsas in med gårdagens status och ändra den först när du klickar på ”Neka”, efter att det första anropet redan har skickats. Manuell radering av kakor mellan stegen skapar på samma sätt en konstgjord renhet och testar inte det verkliga återkallandet. Ett första nekande och ett senare återkallande är därför skilda scenarier: det första börjar utan beslut, det andra med ett medvetet lämnat samtycke, och resultaten får inte blandas ihop i samma skärmbild.

Webbplatsen får även efter ett nekande utföra åtgärder som verkligen behövs för en säkerhetsfunktion, varukorg eller annan funktion som användaren uttryckligen har begärt. Påståendet ”varje anrop efter ett nekande är fel” vore därför lika oprecist som skannerns gröna bock. För varje kvarvarande anslutning måste du fastställa ändamål, initiator och lagringsåtgärd. Därefter konfigureras CMP:n så att nekandet först uppdaterar samtyckesstatusen och taggarna använder inbyggda eller uttryckligen angivna samtyckeskontroller. En fungerande knapp är en knapp som förutsägbart ändrar det anslutna dataflödet på flera sidor. Om nekandet stoppar annonstaggen men lämnar en sessionskaka från första part kan det vara rätt resultat; om en kategori i tysthet aktiverar en annan är konfigurationen inte tillförlitlig. Efter rättningen ska nekandet kunna upprepas på flera sidor utan manuell tömning av lagringen och varje gång ge samma reproducerbara, verifierbara status.

3. Kategorierna och informationen om kakor motsvarar inte den verkliga inventeringen

En banner kan vara tekniskt disciplinerad och ändå vilseleda om kategorierna eller informationen om kakor beskriver en annan webbplats. Det händer när en mall kopieras, en taggbehållare tas över eller ett nytt verktyg läggs till utan att dokumentationen uppdateras. Då står en sedan länge oanvänd kaka kvar, medan videospelaren, chatten eller taggen för annonskonvertering saknas. Användaren gör sitt val utifrån ofullständig information, och företaget kan inte förklara vilken mottagare som får data, i vilket syfte eller hur länge identifieraren finns kvar.

PTS knyter informationen om kakor till den faktiska användningen: ändamålet, vem som sätter eller tar emot kakan och lagringstiden måste anges, inte bara det som CMP:ns katalog råkade känna igen automatiskt. En kaka med samma namn kan användas olika i olika konfigurationer, medan en egen förstapartsidentifierare kan sakna beskrivning helt i en offentlig databas. Därför kopplar granskningen det tekniska objektet till webbplatsägarens verkliga ändamål och den som ansvarar för verktyget. Uppgiften är inte att skriva av katalogens gissning, utan att kontrollera att konfiguration, mottagare och lagringstid motsvarar det företaget faktiskt använder och kan förklara.

Inventeringen slutar inte på fliken Cookies. Den behöver omfatta localStorage, sessionStorage, IndexedDB, pixel- och serveranrop samt identifierare i webbadresser eller formulärflöden när de används för spårning. Europeiska dataskyddsstyrelsens tekniska riktlinjer klargör att ePrivacy-reglernas tillämpningsområde inte är knutet till en enda lagringsteknik. En text som lovar ”vi använder inga kakor” svarar alltså inte på om webbplatsen använder en annan metod för åtkomst till terminalutrustning eller skickar mätsignaler. Listan över kaknamn är början på inventeringen, inte en fullständig beskrivning av teknikerna som kan lagra, läsa eller överföra identifierare.

En praktisk rättning är ett gemensamt huvudregister som används för CMP-klassificeringen, den tekniska tabellen i informationen om kakor och testscenarierna. För varje post anges verktygets interna ägare, leverantör, ändamål, utlösande samtyckesstatus, använd lagring, mottagare och lagringstid. Att lägga till en ny tagg blir då inte bara en ändring i en Google Tag Manager-behållare, utan en kontrollerad förändring där informationen till användaren och testfallen uppdateras före publicering. Samma register ger återtestet en startpunkt efter ändringen och visar vem i företaget som ansvarar för att rätta avvikelsen.

4. Ett Network-anrop förväxlas med bevis på att en kaka har sparats

En analysdomän i Network-panelen är ett viktigt fynd, men den räcker inte för slutsatsen ”en kaka sattes”. Raden bevisar ett anslutningsförsök och visar vad webbläsaren lade till i webbadressen, huvudena eller anropets innehåll, men ett misslyckat, blockerat eller avbrutet anrop är inte samma sak som data som servern tog emot. För kakan måste du kontrollera om begärandehuvudet innehöll Cookie, om svaret innehöll Set-Cookie, om webbläsaren blockerade det och om posten faktiskt hamnade i lagringen. Anropet kan ha blockerats eller avbrutits innan servern fick uppgifterna. Den gränsen för bevisningen ska synas också i hur fyndet formuleras: anslutningsförsök, överföringsresultat och lagring får inte slås ihop till ett påstående.

Inte heller den motsatta slutsatsen är säker. Ett anrop utan kaka kan innehålla samtyckesstatus och andra parametrar, och webbplatsen kan använda en identifierare i localStorage, en URL-parameter eller någon annan teknisk metod. Att en kaka saknas gör inte anslutningen automatiskt anonym eller tom. Set-Cookie är samtidigt en instruktion från servern till webbläsaren, inte en garanti för att posten sparades. Webbläsaren kan neka den på grund av domänen, säkerhetsattribut, tredjepartsbegränsningar eller en annan regel, medan en förstapartskaka som sätts med JavaScript kan dyka upp utan detta svarshuvud. DevTools visar också blockeringsorsakerna, så förekomsten av Set-Cookie måste läsas tillsammans med webbläsarens beslut och det faktiska läget i Application. Om ingen ny rad visas i tabellen Cookies kallar vi inte signalen ”utan data”, utan kontrollerar webbadress, huvuden, parametrar och övrig lagring.

Den säkraste metoden för samman tre vyer på samma tidslinje: vad som utlöste anropet, vad servern bad webbläsaren göra och vad som sedan verkligen blev kvar i just den webbläsarprofilen. Rapporten namnger medvetet bara det som är styrkt. Vi skriver exempelvis ”ett anrop skickades till domän X före valet”, ”svaret innehöll ett försök att sätta en kaka” eller ”identifierare Y låg kvar i Application efter nekandet”. Ett sådant steg kan utvecklaren upprepa, juristen ser gränsen för det tekniska faktumet och resultatet kan jämföras objektivt efter rättningen. Från en enda skärmbild drar vi inte slutsatser om hela personuppgiftsbehandlingen, eftersom bilden bara kan styrka en viss åtgärd, status och tidpunkt.

5. Återkallandet är dolt eller tekniskt ofullständigt

Samtycke är inte ett engångsklick som webbplatsen får glömma. Artikel 7.3 i GDPR ger rätt att återkalla samtycket när som helst och kräver att det ska vara lika lätt att återkalla som att lämna det, en princip som Integritetsskyddsmyndigheten (IMY) också har tillämpat i sin tillsyn av svenska kakbanners. Om samtycke kan lämnas direkt på startsidan men återkallandet kräver att användaren letar i en undersektion av integritetspolicyn, skickar e-post eller tömmer webbläsarens inställningar är mekanismen inte lika tillgänglig. En vanlig lösning är en permanent länk för att hantera valen i sidfoten. Vi kontrollerar att den går att hitta från varje sida även när bannern inte längre syns, eftersom det är just då användaren försöker ändra ett tidigare beslut.

Det tekniska testet börjar med ett medvetet lämnat samtycke och taggar som verkligen har aktiverats. Därefter öppnar granskaren inställningarna, återkallar samtycket för de icke-nödvändiga kategorierna och fortsätter genom webbplatsen utan att skapa ett konstgjort utgångsläge genom att radera lagringen manuellt. Det måste kontrolleras om CMP:n skickar den uppdaterade statusen och taggarna tar emot den, om nya samtyckesbaserade dataflöden slutar starta och vad som händer med lokalt sparade identifierare. Så upptäcks en knapp som sparar det nya valet men inte meddelar redan inlästa taggar. Samtidigt dokumenterar vi ordningen på ändringshändelserna för att skilja ett korrekt sparat val från ett läge där den beroende taggen får uppdateringen för sent eller inte alls.

Ett återkallande verkar framåt och skriver inte i sig om historien eller raderar alla uppgifter som tidigare behandlades lagligt. Efter återkallandet ska fortsatt behandling som bygger på samtycket upphöra, men lagring eller radering av uppgifter som redan har nått servern kan kräva en separat bedömning. Därför skiljer rapporten mellan att stoppa framtida dataflöden och att hantera tidigare uppgifter, utan att lova att en teknisk ändring av valet löser båda. Rättningen måste binda ihop gränssnittet med integrationen: länken ska gå att hitta från varje sida, CMP:n ska visa aktuell status, ändringen ska nå varje beroende tagg och testet ska upprepas med flera kategorikombinationer. ”Neka alla” kan fungera samtidigt som det inte händer något när bara reglaget för marknadsföring stängs av. Även radering av identifierare i webbläsaren ska bedömas utifrån deras funktion, utan löftet att ett klick i CMP:n automatiskt rensar alla tredjepartssystem.

6. Grundläggande och avancerat samtyckesläge blandas ihop — eller så utlovas modellerade data

Grundläggande (Basic) och avancerat (Advanced) Google Consent Mode är inte två utseenden på samma brytare. I det grundläggande samtyckesläget läses Google-taggarna inte in före samtycke, och Google får ingen mätdata från dessa taggar dessförinnan; efter samtycket kan taggarna börja mäta på vanligt sätt. I det avancerade läget läses de in med lagring som inledningsvis nekad och kan skicka signaler utan kakor innan samtycke ges. Det läget får därför inte beskrivas som att ”ingenting skickas”, och det grundläggande läget är inte automatiskt en sämre analyskonfiguration. Skillnaden ligger i taggarnas verkliga beteende före valet, inte i bannerns utseende eller namnet på en inställning.

Valet ska bygga på företagets juridiska bedömning och analysbehov, inte på antagandet att Googles produktnamn i sig löser kraven enligt ePrivacy eller GDPR. Googles dokumentation om samtyckesläget skiljer blockeringen av taggar i det grundläggande läget från signalerna utan kakor i det avancerade. I granskningen undersöker vi ändå den verkliga konfigurationen: börjar standardstatusarna gälla före taggarna, vilken uppdatering skickas efter klicket och vilka anrop visas faktiskt i varje läge? Produktlägets namn är ingen juridisk slutsats. Rapporten beskriver därför det verifierade dataflödet och företagets valda konfiguration i stället för att ge den en automatisk märkning om efterlevnad.

”Utan kakor” betyder inte ”utan information”, så signalens namn får inte ersätta en bedömning av innehåll och ändamål i rapporten. I Network-panelen ska destination, parametrar, samtyckesstatus och initiator granskas. Google Tag Assistant eller felsökningsverktygen för samtyckesläget hjälper samtidigt till att kontrollera standardstatusen och den uppdaterade statusen. Vyerna kompletterar varandra: den första visar dataflödet i det konkreta testet, den andra konfigurationslogiken. Om vyerna inte stämmer överens ska den snyggare skärmen inte få företräde. Du behöver hitta var en standard- eller uppdateringshändelse inte nådde taggen i avsedd ordning.

Modellerade data är inte heller garanterade bara för att det avancerade läget aktiveras. Tillgången till beteendemodellering i Google Analytics 4 beror på Googles villkor för egendomen, datavolymen och kvaliteten, och funktionen kan saknas eller försvinna om villkoren inte längre uppfylls. Modelleringen återskapar inte sessionerna för enskilda användare som har nekat samtycke. I erbjudandet lovar vi därför en korrekt konfiguration och en verifierbar signalordning, inte en bestämd mängd modellerade data; tillgången avgörs av Googles system och av om den aktuella egendomen uppfyller kraven. Resultatet av granskningen är med andra ord en reproducerbar konfiguration och verifierade signaler, inte ett löfte om en datamängd som leverantören inte styr över.

7. Testet slutar på den första sidan och den första dagen

Startsidan omfattar sällan hela inventeringen av spårning. En videotagg kanske läses in först när uppspelningen startar, en kartintegration på kontaktsidan, en annonskonvertering efter att formuläret skickas, betalverktyget i kundvagnens sista steg och ett chatt- eller personaliseringsskript efter en viss tid. Den som öppnar en webbadress, väntar några sekunder och stänger skannern kan skriva en tekniskt korrekt rapport om just den vyn och samtidigt en farligt ofullständig rapport om webbplatsen som helhet. Varje sådant läge måste öppnas med åtgärden som faktiskt aktiverar det; startsidans inventering får inte antas representera alla mallar och användarvägar.

Vi bygger scenarierna efter verkliga användarvägar och webbplatsmallar. De omfattar en publik sida, en artikel, kontaktformuläret, kontoområdet, köpflödet, inbäddat innehåll och varje relevant språk- eller regionversion. Mobilvyn behöver också kontrolleras, eftersom CMP-knappar kan överlappa eller länken till valen bli oåtkomlig där trots att allt fungerar på datorn. En automatiserad genomsökning ger bredd, medan ett manuellt scenario öppnar lägen som en robot utan konto, klick eller inmatning aldrig får se. Språk- och regionversioner är, precis som mobilvyn, inte dekorativa kopior om integrationerna läses in annorlunda eller användarens val inte är lika tillgängliga där.

En engångskontroll täcker inte förändringar över tid. En ny marknadsföringstagg, en utbytt CMP-mall eller en importerad Google Tag Manager-behållare kan förstöra en tidigare korrekt ordning utan att bannern ser annorlunda ut. Därför ska varje nytt verktyg testas före publicering och jämförelsen upprepas senare. Den disciplinen bör finnas redan i avtalet om webbutveckling, vilket vi förklarade i artikeln om 10 misstag när du beställer en webbplats. I vår granskningsprocess genomsöks webbplatsen igen 30 och 180 dagar efter införandet med samma scenarier och bevisfält. Då ser vi om rättningen håller i den vanliga publiceringstakten och om nya verktyg eller konfigurationsavvikelser har tillkommit. Den första tidpunkten visar om införandet har klarat den dagliga publiceringen, den andra fångar senare ändringar. I återtestet jämför vi ett bestämt anrop, lagringsläge och samtyckesstatus med ursprungsfyndet i stället för att nöja oss med intrycket att ”det ser bättre ut nu”.

Vad du får i en teknisk granskning av kakor och spårning

Det första resultatet är en verifierad inventering av kakor, lagring, taggar och tredjepartsanrop. Varje fynd kopplas till sida, användaråtgärd och samtyckesstatus, och bredvid anges både beviset och dess gräns: en Network-rad, ett Set-Cookie-försök, en kaka som faktiskt sparades i Application, en localStorage-post eller en CMP-händelse. Utvecklaren får därmed ett reproducerbart fel i stället för den oklara anmärkningen ”fixa GDPR”, medan den dataskyddsansvariga ser vilka fakta som fortfarande kräver ett juridiskt beslut. Varje fynd får också en reproduktionsväg, så att exakt samma sida, val, anrop och lagringsresultat kan kontrolleras efter införandet.

Den andra delen är införandet. Vi ordnar CMP-kategorierna och följden av standard- och uppdateringshändelser i Google Tag Manager, konfigurerar samtyckeskontrollerna för Google Analytics 4, Google Ads, Meta Pixel och andra verktyg samt tar fram texten till kakdeklarationen och integritetspolicyn. Det grundläggande eller avancerade samtyckesläget väljs efter din juridiska bedömning och dina analysbehov. Vi framställer inte det avancerade läget som den universellt rätta lösningen och lovar inte modellerade data om den aktuella Google-egendomen inte uppfyller Googles villkor. Införandet verifieras i samma samtyckeslägen som ursprungsfyndet dokumenterades i, så att konfigurationsändringen kan styrkas med jämförbar bevisning.

Priset för tjänsten är från 800 € och leveranstiden 1–4 veckor, beroende på webbplatsens omfattning, antalet språk och mallar, hur komplexa CMP:n och taggbehållarna är samt hur många integrationer som behövs. Innan arbetet börjar skiljer vi tydligt i pris och tidsplan mellan granskningens bevisning, de tekniska rättningarna och de frågor som företagets jurist eller dataskyddsspecialist måste avgöra. Efter 30 och 180 dagar gör vi en ny genomsökning mot de dokumenterade scenarierna. Pris och tidsram gäller därmed en klart angiven teknisk omfattning, inte ett obestämt löfte om att ordna hela företagets dataskydd.

Om du behöver en ”GDPR-granskning av webbplatsen” klargör vi först att den här tjänsten omfattar kakor, spårning, CMP och samtyckesläge, inte en fullständig kontroll av hela organisationens GDPR-efterlevnad. Vi lovar därför bara det vi kan styrka tekniskt: webbplatsens beteende före valet, efter nekande, efter samtycke och efter återkallande, signalerna som skickas till verktygen samt de punkter där bevisningen ännu inte räcker för en juridisk slutsats. Avgränsningen gör det möjligt att avsluta det tekniska arbetet med ett verifierbart resultat och lämna de juridiska frågorna till den som ansvarar för den bredare personuppgiftsbehandlingen. Boka en granskning av kakor och spårning genom att skicka webbplatsens adress och namnet på den CMP eller tagghanterare som används.