Databehandleraftale

Parterne

Databehandler: PackReport, CVR 40362134, Willemoesgade 42, 1. th., 2100 København Ø. Kontakt: info@packreport.dk

Dataansvarlig: den webshop (kunden), der opretter et abonnement på PackReport.

Sådan indgås aftalen. Den gælder mellem PackReport og kunden fra det tidspunkt, kunden opretter et abonnement, og så længe kontoen består. Den er offentliggjort på packreport.dk/databehandleraftale og indgår i handelsbetingelserne, punkt 11. Kunden behøver ikke underskrive noget; ønsker kunden i stedet at bruge sin egen databehandleraftale, tager PackReport imod den på info@packreport.dk.

Vejen hertil, for den der vil vide hvorfor teksten ser ud som den gør: udfyld de to regionsfelter (målt 9. september), accepter Renders SCC (der var intet at acceptere — Renders databehandlertillæg indgås ved brug af tjenesten og har SCC modul 3 indbygget, se afsnit 7), læg den som /databehandleraftale (gjort 9. september; siden genereres af denne fil, så de to ikke kan sige hver sit), henvis fra handelsbetingelsernes punkt 11 og fra oprettelsen (gjort). Tilbage står en juridisk gennemlæsning.

Handelsbetingelserne dækker den ikke. Efterprøvet 9. september: ordet "databehandler" står der nul gange, og persondata-afsnittet er to sætninger, der peger videre til privatlivspolitikken. Ved oprettelsen accepterer kunden handelsbetingelserne og bekræfter at have læst privatlivspolitikken — ingen af delene er en aftale efter art. 28, stk. 3.

Hvad aftalen dækker

Genstand. PackReport behandler personoplysninger på vegne af kunden i forbindelse med driften af PackReport-tjenesten: modtagelse af kundens forsendelsesdata, beregning af emballagemængder og udstilling af det færdige emballageregnskab for kunden.

Formål. Det ene formål er at opgøre og dokumentere kundens forsendelsesemballage til brug for EU's emballageforordning (PPWR) og det udvidede producentansvar. PackReport bruger ikke kundens forsendelsesdata til egne formål og videregiver dem ikke til andre end de underdatabehandlere, der står i afsnit 4.

Karakter. Behandlingen består af disse handlinger:

- modtage og opbevare kontooplysninger, når kunden opretter sig, logger ind eller nulstiller sin adgangskode - modtage forsendelseskald fra kundens webshop eller fragtplatform, beregne emballagevægten og gemme resultatet (felterne står i afsnit 3) - modtage og behandle en CSV-import af kundens historiske ordrer på samme måde - vise kundens data i dashboardet og udlevere dem som CSV - sende rapport- og systemmails til den e-mailadresse, kontoen er oprettet med - administrere kontoen, herunder emballageprofiler og webhook-nøgle, når kunden selv udløser det fra dashboardet - tage en daglig krypteret backup af databasen - yde support, hvilket kan kræve, at PackReports administrator ser kundens egne data (adgangen er beskrevet i afsnit 5) - slette kundens data efter afsnit 8

Varighed. Behandlingen løber, så længe kunden har en konto hos PackReport, og derefter indtil data slettes efter afsnit 8. Aftalen gælder i samme periode.

Typer af personoplysninger og kategorier af registrerede står i afsnit 3.

Instruksen. Behandlingen sker udelukkende efter kundens dokumenterede instruks. Instruksen er denne aftale: listen over handlinger ovenfor, afsnit 3 om hvilke oplysninger der behandles, afsnit 4 om underdatabehandlere og afsnit 7 om overførsel til tredjelande. Kundens brug af tjenesten — at sende ordrer ind, at importere en CSV, at bede om en rapport — er selve instruksen om at udføre den pågældende handling. Andre behandlinger kræver en skriftlig instruks fra kunden.

Overførsel til tredjelande er en del af instruksen. API'et kører i USA (se afsnit 4 og 7). Ved at indgå denne aftale instruerer kunden PackReport i at lade behandlingen ske dér på det grundlag, afsnit 7 beskriver. PackReport overfører ikke personoplysninger til andre tredjelande eller til andre underdatabehandlere end dem i afsnit 4 uden kundens instruks, medmindre EU-retten eller dansk ret kræver det. Sker det sidste, underretter PackReport kunden om kravet, før behandlingen finder sted, medmindre underretning er forbudt.

Hvis en instruks er ulovlig. Mener PackReport, at en instruks fra kunden strider mod databeskyttelsesforordningen eller anden EU- eller dansk databeskyttelsesret, underretter PackReport straks kunden og kan udsætte udførelsen, indtil forholdet er afklaret.

Hvilke oplysninger behandles

PackReport har to roller, og afsnittet skelner mellem dem. Her stod før alle tre kategorier i én tabel, som om aftalen dækkede dem alle. Det gjorde den ikke: kontooplysningerne er PackReports egne, og privatlivspolitikken har hele tiden sagt netop det.

Det, PackReport behandler på vegne af kunden. Denne aftale gælder for det:

Det, PackReport selv er dataansvarlig for. Denne aftale gælder ikke for det:

Grunden er, at kunden ikke instruerer PackReport i den behandling. Oplysningerne findes, fordi der er et kundeforhold mellem PackReport og webshoppen: login, fakturering, support. PackReport fastlægger selv formålet med dem, og så er PackReport dataansvarlig og ikke databehandler. Den behandling er beskrevet i privatlivspolitikkens afsnit "Vores rolle", ikke her.

Det flytter ikke sikkerheden: foranstaltningerne i afsnit 5 gælder hele systemet, uanset hvilken rolle oplysningerne hører under.

PackReport gemmer ingen oplysninger om kundens slutkunder. Forskellen på "modtager" og "gemmer" er væsentlig, og den skal stå tydeligt, fordi afsnit 7 hviler på den:

- Modtager: fragtplatformens webhook sender hele sin payload, og den kan indeholde modtagerens navn og adresse. Det kan PackReport ikke styre. - Gemmer: modtagerfelterne bliver hverken hentet frem eller skrevet. ppwr_logs har præcis disse kolonner: butiks-id, ordre-id, tidsstempel, vægte, materialefordeling, status, profilnavn, testmarkering og markering af manuel rettelse. Der er hverken kolonne eller kode til navn, adresse, telefonnummer eller e-mail på modtageren. Udtrækket slår kun op på vægt-, ordre-id- og datofelter, uanset hvor dybt i payloaden de ligger. Ingen anden del af den bliver hentet ud.

Én undtagelse, og den skal stå her: stakspor ved en ufanget fejl. Her stod tidligere "og payloaden logges ingen steder". Det holdt ikke. Payloaden gemmes ikke og skrives ikke til driftsloggen under normal drift, men går et kald i stykker, dannes et stakspor, og et stakspor citerer den værdi, der gik galt. Den værdi kan være et felt fra payloaden. Sporet ender to steder:

- i en alarmmail til info@packreport.dk, sendt via Resend/Amazon SES i Irland. Lange spor forkortes, og samme fejl mailes højst én gang i timen. - i Renders driftslog i Oregon, fordi serveren selv skriver sporet ud, efter at alarmen er sendt.

Det er ét felt ved en fejl og ikke hele payloaden, og det sker kun ved fejl, der ikke er fanget i koden. Men det er en behandling, og det ene af de to steder ligger uden for EU/EØS (se afsnit 7). Derfor står det her i stedet for en pænere sætning, der ikke kan belægges.

Registrerede under denne aftale: kundens slutkunder. Dels indirekte gennem ordre-ID'et, som kunden selv kan slå op på en person, dels direkte i det øjeblik, webhook-payloaden modtages og behandles. Her stod før "kundens medarbejdere med en konto". De er registrerede, men i PackReports egen rolle som dataansvarlig og ikke under denne aftale; se de to tabeller ovenfor.

Underdatabehandlere

Kunden giver ved aftalens indgåelse generel godkendelse til de underdatabehandlere, der står i tabellen nedenfor. Tabellen er udtømmende: PackReport sender ikke data til andre tjenester end disse.

Varsel om planlagte ændringer (art. 28, stk. 2). PackReport underretter kunden skriftligt pr. e-mail til kontoens adresse mindst 30 dage før en underdatabehandler tilføjes eller udskiftes. Varslet er en underretning om en planlagt ændring, ikke en meddelelse om en ændring, der allerede er gennemført. Her stod før blot, at der varsles "før en ny tilføjes": udskiftning var ikke nævnt, og uden ordet "planlagt" var indsigelsesretten tom.

Indsigelse. Kunden kan gøre skriftlig indsigelse inden for de 30 dage. Ændringen sættes ikke i værk for kundens data, før fristen er udløbet. Gør kunden indsigelse, gennemfører PackReport ikke ændringen for kundens data, hvis ydelsen kan leveres uden den. Kan den ikke det, siger PackReport det og oplyser hvorfor, og kunden kan da opsige abonnementet uden varsel med virkning senest fra den dag, ændringen træder i kraft. Data behandles derefter efter afsnit 8.

Samme forpligtelser og PackReports ansvar (art. 28, stk. 4). PackReport pålægger hver underdatabehandler de samme databeskyttelsesforpligtelser, som følger af denne aftale, i det omfang de er relevante for den behandling, underdatabehandleren udfører, herunder tilstrækkelige garantier for passende tekniske og organisatoriske foranstaltninger. Opfylder en underdatabehandler ikke sine databeskyttelsesforpligtelser, er PackReport fuldt ansvarlig over for kunden for underdatabehandlerens opfyldelse.

Det sker ved, at PackReport som kunde er bundet af leverandørernes egne databehandleraftaler. Der er ikke forhandlet særskilte vilkår med nogen af dem, og det skal stå her, så ingen læser "pålægger" som et selvstændigt dokument, der ikke findes. For Render er grundlaget dokumenteret i afsnit 7 (render.com/dpa, punkt 6.2.3).

Sikkerhed

PackReport har truffet følgende tekniske og organisatoriske foranstaltninger (art. 32). Listen beskriver hvad koden gør i dag, ikke hensigter. Hvert punkt er efterprøvet mod kildekoden 9. september 2026:

- Transport: al kommunikation over HTTPS. HSTS med max-age=63072000; includeSubDomains; preload på både frontenden og API'et. Cloudflare terminerer TLS foran API'et; se afsnit 4. - Adgangskoder: gemmes aldrig i klartekst, hverken i databasen eller i logfiler. Nye og ændrede adgangskoder gemmes som saltet PBKDF2-SHA256 med 200.000 iterationer.

Fortrolighed, kundens rettigheder og PackReports bistand

Fortrolighed (art. 28, stk. 3, litra b). De personer, der kan tilgå personoplysninger behandlet for kunden, er pålagt fortrolighed om dem. Fortroligheden gælder også, efter at aftalen er ophørt, og efter at den pågældende er holdt op med at arbejde for PackReport.

I dag er den kreds én person. PackReport har ingen ansatte, og kun stifteren har administrativ adgang til produktionsdata, beskyttet af en separat admin-nøgle med tælling af fejlforsøg (afsnit 5). Får PackReport medarbejdere, eller får en ekstern adgang til produktionsdata, sker det kun mod en skriftlig fortrolighedsforpligtelse, og kun for den, der har brug for adgangen til at udføre et bestemt stykke arbejde. Underdatabehandlerne i afsnit 4 er bundet af fortrolighed i deres egne aftaler.

Her stod ingenting før. Art. 28, stk. 3, litra b kræver, at forpligtelsen står i aftalen — det er ikke nok, at kredsen er lille.

- Indsigt, berigtigelse, sletning, portabilitet: kunden kan til enhver tid hente sit emballageregnskab som CSV. Efterprøvet i koden 9. september 2026: læseadgangen (GET /api/reports) er bevidst ikke betinget af et aktivt abonnement, og den skærm, en konto uden aktivt abonnement møder i stedet for dashboardet, har sin egen knap "Hent mine rapporter (CSV)". Filen dækker hele perioden uden loft på antal ordrer. Testordrer er holdt ude, fordi de ikke hører med i regnskabet. Rettelser og nye ordrer kræver derimod en aktiv konto: skrivevejene — og kun de — afvises på en inaktiv konto. Sletning foretages af PackReport efter anmodning (afsnit 8) og fjerner kontoen, alle ordrelinjer og alle emballageprofiler i samme handling; kunden har ikke selv en sletteknap.

Første trin er dokumentationen i afsnit 3-5 og 7 plus svar på kundens konkrete spørgsmål. Det koster ikke noget og vil normalt være nok. Er det ikke nok, kan kunden kræve en egentlig revision. Den kan gennemføres én gang om året med 30 dages skriftligt varsel — og derudover, hvis en tilsynsmyndighed kræver det, eller hvis der har været et brud, der berører kundens data. Revisionen sker i normal arbejdstid, må ikke give adgang til andre kunders oplysninger eller til oplysninger, der ville svække sikkerheden, og kunden bærer sine egne omkostninger samt PackReports rimelige, dokumenterede tidsforbrug.

PackReport driver ingen serverrum. En inspektion af underdatabehandlerne i afsnit 4 sker derfor gennem deres egne aftaler og erklæringer, ikke ved et fysisk besøg, vi kan skaffe adgang til.

Overførsel til tredjelande

Der sker en overførsel til USA, og den er ikke tilfældig — den er en følge af, hvor API'et kører.

Databasen ligger i EU. Kontooplysninger, emballagemængder og ordrenumre ligger i Frankfurt.

To ting ligger alligevel uden for EU, og de skal nævnes. Her stod tidligere "data i hvile bliver i EU". Det var forkert, og det blev fundet ved en gennemgang 9. september 2026:

- Den daglige backup. En fuld kopi af databasen lægges hver nat som CI-artefakt hos GitHub (USA). Den er AES256-krypteret, og kun PackReport har adgangskoden, men kryptering flytter ikke lagerstedet. Levetiden er skåret ned fra 90 til 7 dage. - Driftslogs. Hos Render i Oregon. De indeholdt e-mailadresser, indtil de blev fjernet 9. september: loggen skriver nu kun modtagerens domæne plus et saltet fingeraftryk, der ikke kan regnes tilbage til en adresse.

Data under behandling passerer USA. API'et modtager og behandler forespørgslerne i Oregon: kontooplysninger ved login og oprettelse, og fragtplatformens webhook-payload, som kan indeholde modtagerens navn og adresse. PackReport gemmer ikke de felter (se afsnit 3), men at modtage og behandle er i sig selv en behandling, og den finder sted i et tredjeland.

Overførslen sker på grundlag af EU-Kommissionens standardkontraktbestemmelser (SCC, modul 3: databehandler til underdatabehandler).

- Al trafik til API'et går over HTTPS, med HSTS og preload (afsnit 5). - Databasen — det eneste sted, oplysningerne ligger permanent — ligger i Frankfurt, ikke i Oregon. - Backuppen krypteres med AES256, før den forlader kørslen, og adgangskoden ligger ikke hos den, der opbevarer filen. - Driftslogs i Oregon indeholder ikke længere e-mailadresser.

Beskriver Render selv sine foranstaltninger i tillæggets bilag, kan de vedlægges som leverandørens egen erklæring. Så skal det til gengæld stå, at det er Renders ord og ikke vores.

Grundlaget er på plads, og der er intet at underskrive. Efterprøvet 9. september 2026 på Renders egne sider:

- Renders vilkår (render.com/terms) siger, at man ved at bruge tjenesten er bundet af deres Data Processing Addendum — den indgås altså ved brug, ikke ved en underskrift. - Tillægget (render.com/dpa, senest ændret 19. december 2024) siger ordret, at EU's standardkontraktbestemmelser "are deemed entered into (and incorporated into this DPA by this reference)", med henvisning til Kommissionens afgørelse 2021/914 af 4. juni 2021. - Punkt 6.2.3: "Module Three (Processor to Subprocessor) of the EU SCCs apply when Customer is a processor and Company is processing Personal Data on behalf of Customer as a subprocessor." Det er præcis PackReports situation — vi er databehandler for webshoppen, Render er underdatabehandler for os.

Beder en kundes DPO om dokumentation, er svaret altså henvisningen til render.com/dpa punkt 6.2.3 — ikke et underskrevet dokument.

Render er ikke den eneste. To leverandører mere skal nævnes her.

- Cloudflare sidder foran hele API'et som reverse proxy og terminerer TLS. Hver eneste anmodning — også fragtplatformens webhook med sin fulde payload — læses derfor i klartekst hos Cloudflare, før den når frem til os. Netværket er anycast: anmodningen håndteres af den af Cloudflares lokaliteter, der svarer hurtigst. Hvilken det er, vælger PackReport ikke og kan ikke garantere, og den kan ligge uden for EU/EØS. Cloudflares eget databehandlertillæg (version 6.4, efterprøvet 9. september 2026) lader modul 3 af SCC'erne gælde "where Customer ... is a Processor" (pkt. 6.2(a)(i)) — netop vores situation. Modsat Renders indgås Cloudflares tillæg ikke ved brug: det virker efter sin ordlyd "from the date on which Customer signed or the parties otherwise agreed to this DPA". Det skal derfor accepteres i Cloudflare-kontoen, og indtil det er gjort, er det et åbent punkt — ikke et grundlag, man kan henvise en DPO til. - GitHub opbevarer den daglige backup i USA. GitHubs databehandleraftale (efterprøvet 9. september 2026) lader overførsler ske under GitHubs selvcertificering til EU-US Data Privacy Framework og/eller standardkontraktbestemmelserne (pkt. 7.B), og modul 3 gælder, når kunden selv er databehandler (pkt. 3.B og 7.C.ii).

Cloudflare stod kun i tabellen i afsnit 4, selv om det er det første sted uden for PackReport, hvor en webhook-payload bliver læst i klartekst. Backuppen kom med i dette afsnit 9. september, men uden sit overførselsgrundlag.

Opbevaring og sletning

Data opbevares, så længe kunden har en aktiv konto, og derudover så længe det er nødvendigt for, at kunden kan dokumentere sine indberetninger.

Ved ophør bliver data liggende, indtil kunden beder om sletning. Det er med vilje: kunden skal fortsat kunne dokumentere sine historiske indberetninger over for tilsynet, også efter at abonnementet er stoppet. Opsigelse gør kontoen inaktiv; den sletter ingenting.

PackReport sletter data inden for 30 dage efter en skriftlig anmodning fra kunden til info@packreport.dk. Sletning af en konto fjerner samtidig alle tilhørende ordrer og emballageprofiler. Backupperne indhenter sletningen af sig selv: hver natlig kopi ligger syv dage hos GitHub og slettes derefter, så senest en uge efter sletningen findes rækkerne heller ikke i en backup.

Valget mellem sletning og udlevering er kundens (art. 28, stk. 3, litra g). Udlevering kræver ikke, at kunden beder om noget: hele emballageregnskabet kan hentes som CSV, også med et inaktivt abonnement (afsnit 6). Træffer kunden ikke et valg, bliver data liggende som beskrevet ovenfor — det er den mulighed, en kunde med en dokumentationspligt normalt vil have — og de slettes, når kunden beder om det. PackReport sletter ikke af sig selv efter en frist, og teksten her lover det ikke.

Ansvar, løbetid og lovvalg

Løbetid. Aftalen gælder, så længe PackReport behandler personoplysninger for kunden. Den slutter altså ikke ved opsigelsen af abonnementet: opsigelse gør kontoen inaktiv, men dataene bliver liggende (afsnit 8), og så længe de gør det, er det denne aftale, der regulerer dem. Afsnit 5, 6, 7 og 8 gælder, indtil de sidste data er slettet. Fortrolighedsforpligtelsen i afsnit 6 gælder uden tidsbegrænsning.

Ansvar. Hver part er ansvarlig efter dansk rets almindelige regler og efter databeskyttelsesforordningens art. 82. Ansvarsbegrænsningen i handelsbetingelsernes punkt 9 — ingen dækning af indirekte tab og et loft svarende til de seneste 12 måneders abonnementsbetaling — gælder også for krav mellem parterne efter denne aftale. To forbehold, der ikke kan aftales væk: begrænsningen gælder ikke ved forsæt eller grov uagtsomhed, og den kan ikke gøres gældende over for en registreret, som efter art. 82 kan rette sit krav direkte mod databehandleren. En bøde, en tilsynsmyndighed pålægger kunden, er kundens egen.

Modstrid. Aftalen supplerer PackReports handelsbetingelser. Ved modstrid går denne aftale forud, for så vidt angår behandling af personoplysninger — dog ikke for ansvarsbegrænsningen, som er den samme i begge dokumenter, jf. ovenfor. Uden det forbehold ville forrangsbestemmelsen kunne læses, som om ansvarsbegrænsningen slet ikke gjaldt for netop de krav, der er de dyreste.

Lovvalg og værneting. Aftalen er underlagt dansk ret. Tvister mellem parterne afgøres ved Københavns Byret. Handelsbetingelsernes punkt 13 siger blot "de danske domstole"; denne aftale er den mere præcise af de to for tvister om behandling af personoplysninger. Værnetinget gælder mellem parterne. En registreret kan altid klage til Datatilsynet eller gå til domstolene efter art. 77-79, uanset hvad der står her.

---