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.

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 og én gang om måneden gendanne den nyeste backup i en tom database for at kontrollere, at den kan bruges
• 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 (art. 28, stk. 3, litra a). 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.

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 ikke den samme for alle felterne. For kontooplysningerne, for kontakt og drift og for de tekniske felter, der bærer kundeforholdet, er grunden, 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.

For nogle af felterne under "Kontoens tekniske felter" holder den grund ikke, og det skal stå her: andel husholdningsemballage, andel til udlandet, mikrostatus, sporet over, hvornår markeringerne af emballagens oprindelse er anvendt på ordrer, og de leverancer af emballage, butikken selv har importeret. Dem opretter kunden selv i dashboardet, og tjenesten regner dem med i emballageregnskabet. De er altså en del af den ydelse, kunden betaler for, jf. handelsbetingelsernes punkt 2, og kunden instruerer PackReport i dem. At de alligevel står uden for denne aftale, skyldes noget andet: felterne er mængder, andele, datoer og en kort tekst om emballage, og de er ikke oplysninger om en person. Denne aftale regulerer behandling af personoplysninger, og den gælder derfor ikke for dem. Afsnit 5 om sikkerhed, afsnit 6 om fortrolighed og kundens rettigheder og afsnit 8 om sletning gælder for dem alligevel, og afsnit 8 nævner dem udtrykkeligt i sletteløftet. Skriver kunden en oplysning om en person i en begrundelse eller i en beskrivelse af en leverance, behandler PackReport den efter denne aftale.

Den behandling, PackReport selv er dataansvarlig for, 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å at modtage og at gemme er væsentlig, og 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: rækkens eget løbenummer, butiks-id, ordre-id, tidsstempel, vægte, materialefordeling, status, profilnavn, testmarkering, markering af manuel rettelse og emballagens oprindelse pr. materiale. 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: stakspor ved en ufanget fejl. Payloaden gemmes ikke og skrives ikke til driftsloggen under normal drift. 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. Postkassen ligger hos DanDomain (afsnit 4). 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).

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. Kundens medarbejdere med en konto er også 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 (art. 28, stk. 2, og stk. 3, litra d). Tabellen er udtømmende for de oplysninger, aftalen gælder for: PackReport sender dem ikke 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. Varslet og indsigelsen nedenfor gælder ikke Renders egne underdatabehandlere, heller ikke rækken "Cloudflare, som Renders underdatabehandler". For dem gælder afsnittet "Renders egne underdatabehandlere" under tabellen.

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.

Turnstile er ikke underdatabehandler efter denne aftale. PackReport bruger Cloudflare Turnstile (afsnit 5) på en konto, PackReport selv har hos Cloudflare. Turnstile ser kun oplysninger om den, der opretter en konto, logger ind eller udfylder en formular på sitet, og for de oplysninger er PackReport selv dataansvarlig (afsnit 3). Den behandling står i privatlivspolitikken.

Renders egne underdatabehandlere. Render har selv underdatabehandlere, og Cloudflare er en af dem. De står på Renders liste (render.com/trust). Render varsler en ny underdatabehandler på listen mindst 10 dage i forvejen (Renders tillæg pkt. 4.2). For dem kan PackReport derfor ikke give de 30 dages varsel, der gælder for tabellen ovenfor. I stedet gælder Renders egen ordning: en ny underdatabehandler står på Renders liste mindst 10 dage, før Render tager den i brug, og listen er offentlig. Gør kunden skriftlig indsigelse mod en ny underdatabehandler på Renders liste, giver PackReport indsigelsen videre til Render. Tager Render den alligevel i brug for kundens data, kan kunden opsige abonnementet uden varsel.

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, så "pålægger" betyder leverandørernes egne aftaler og ikke et særskilt dokument. For Render er grundlaget beskrevet i afsnit 7. Cloudflare er Renders underdatabehandler, og Render har i sit tillæg forpligtet sig til at pålægge sine underdatabehandlere tilsvarende forpligtelser og til at hæfte for dem (afsnit 7). For GitHub gælder GitHubs databehandleraftale ikke for den konto, backuppen ligger på, og der er derfor ikke en kontrakt efter art. 28, stk. 4 med GitHub. Hvorfor, og hvad det betyder, står i afsnit 7. For DanDomain er det ikke dokumenteret, at DanDomains databehandleraftale er accepteret for PackReports konto; det er et åbent punkt.

Sikkerhed

PackReport har truffet følgende tekniske og organisatoriske foranstaltninger (art. 28, stk. 3, litra c, og art. 32). Listen beskriver, hvad koden og driften gør, ikke hensigter. Den er gennemgået mod koden den 14. september 2026, og punkterne om transport, backup og overvågning igen den 21. 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 som en del af Renders drift; 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. Konti fra før overgangen kan stadig have en hash i det tidligere, usaltede SHA-256-format. Den flyttes til det saltede format, næste gang brugeren logger ind, og antallet af konti med det gamle format tælles ved hver opstart og skrives i driftsloggen.
• Adgang pr. butik: hver butik har to adskilte hemmeligheder. Webhook-nøglen ligger i kundens fragt- eller shopsystem og giver kun ret til at indberette en forsendelse. Dashboard-nøglen bruges af kundens egen browser og giver adgang til regnskabet. En lækket webhook-nøgle giver altså ikke læseadgang til data. Begge sammenlignes i konstant tid, og hvert opslag er bundet til butikkens shop_id i selve SQL-forespørgslen, så ét svar kun kan indeholde én butiks rækker. Tokentjekket sker før noget som helst læses.
• Ordrer på tværs af butikker: der er et unikt indeks på (shop_id, order_id) og ikke på order_id alene, så to webshops kan begge have en ordre "1001" uden at overskrive hinanden. Det er tokentjekket ovenfor, der forhindrer, at en butik tilgår en andens data, ikke indekset.
• Rate limiting: alle API'ets endpoints har et loft over antal kald pr. minut, og oprettelsen af en konto har desuden et timeloft. Undtaget er kun /health, /robots.txt og administrationens endpoints, som kræver adminadgang og tæller forkerte forsøg. Webhooken, der modtager forsendelser (/api/v1/report-shipment), og opslaget af betalingslinket (/api/shops/checkout-link) har loft pr. butik og afsender-IP. De øvrige har loft pr. afsender-IP, læst fra Cloudflares CF-Connecting-IP, som klienten ikke kan forfalske. Forkerte adgangskoder tælles desuden: ved kundelogin pr. e-mailadresse (loft 10 inden for 5 minutter) og ved adminadgang pr. afsender-IP (loft 8 inden for 5 minutter) og samlet (loft 50 inden for 5 minutter, uanset afsender). Når loftet for kundelogin er nået, behandles et loginforsøg først, når et Cloudflare Turnstile-robottjek er bestået, også med rigtig adgangskode. Forkerte adminforsøg over et af lofterne afvises med 429.
• Botbeskyttelse: Cloudflare Turnstile på de tre offentlige formularer, der kan lægge en række i databasen eller sende en e-mail til en adresse, afsenderen selv skriver: oprettelse af konto, leadformularen og partneransøgningen. Verifikationen er fail-closed: mangler eller fejler nøglen til Cloudflare, afvises indsendelsen i stedet for at slippe igennem. Login kræver Turnstile, når kontoens loft for forkerte forsøg er nået (se Rate limiting). Nulstilling af adgangskode har ikke Turnstile: mailen går kun til en adresse, der har en konto, og højst 3 gange i timen pr. adresse.
• Indholdssikkerhedspolitik (CSP): der er to, fordi frontend og API er to forskellige tjenester med hver sin politik.
  • Frontenden (Vercel): default-src 'self', object-src 'none', frame-ancestors 'none', base-uri 'self', form-action 'self' mailto:, og script kun fra eget domæne, Cloudflare Turnstile og Vercels statistik. script-src indeholder desuden 'unsafe-inline', fordi temaet sættes af inline-scripts, før siden tegnes.
  • API'et (Render): default-src 'none'; style-src 'unsafe-inline'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'. API'et svarer med JSON på nær én side, afmeldingssiden fra tjeklistemailen, og politikken er skåret efter den: ingen scripts, ingen billeder, ingen formularer.
• Backup: en fuld dump af databasen én gang i døgnet (planlagt kl. 03:00 UTC; GitHubs planlægning kan forskyde kørslen), krypteret med AES256 og gemt som CI-artefakt hos GitHub i 7 dage. Adgangskoden ligger hos PackReport, med en kopi i API'ets driftsmiljø hos Render, og som hemmelighed hos GitHub, der bruger den i kørslen. Krypteringen beskytter altså backuppen mod andre, men ikke mod GitHub selv. Hver kørsel kontrollerer, at dumpens indholdsfortegnelse kan læses, før den krypteres. Én gang om måneden gendannes den nyeste backup desuden i en tom database på en engangsmaskine hos GitHub for at vise, at den kan bruges. Øvelsens log får kun tabelnavne og antal rækker, ikke indholdet. Lagerstedet ligger uden for EU/EØS; se afsnit 4 og 7.
• Adgang for personale: PackReport har ingen ansatte ud over stifteren, og der er én administrativ adgang: en admin-nøgle, der sættes i driftsmiljøet. Der er ingen nødadgang i koden: er nøglen ikke sat, er adminadgang slået fra. Forkerte forsøg tælles, jf. lofterne ovenfor. Adminadgangen kan hente sessionsnøglen til én kundes dashboard og dermed se kundens emballageregnskab. Det bruges til support.
• Overvågning: oppetidstjek af API'et, planlagt hver time, og en fuld systemtest mod produktion, planlagt én gang i døgnet og desuden kørt, når API'ets kode ændres. Begge kører hos GitHub, hvis planlægning ikke er garanteret og kan forsinke eller springe planlagte kørsler over; en fejlende kørsel sender mail. I perioden fra den 12. til den 20. september 2026 kom oppetidstjekket 5 til 8 gange i døgnet. Der er ingen ekstern oppetidsmonitor. Ufangede fejl i API'et udløser desuden alarmmail med det samme. Gentagelser af samme fejl samles til én mail i timen, så en fejlstorm ikke drukner alarmen. Det betyder også, at en mail kan dække flere hændelser.

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, bortset fra GitHub og DanDomain. For GitHub gælder databehandleraftalen ikke for kontoen (afsnit 7), og for DanDomain er det ikke dokumenteret, at databehandleraftalen er accepteret for PackReports konto (afsnit 4).

• Indsigt, berigtigelse, sletning, portabilitet: kunden kan til enhver tid hente sit emballageregnskab som CSV. 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, alle emballageprofiler, de angivne andele husholdningsemballage og til udlandet, mikrostatus, sporet over markeringerne og de leverancer af emballage, kunden selv har importeret, i samme handling; kunden har ikke selv en sletteknap.
• Bistand ved anmodninger fra registrerede (art. 28, stk. 3, litra e): henvender en registreret sig direkte til PackReport om oplysninger, vi behandler for kunden, svarer vi ikke selv. Vi henviser til kunden og giver kunden besked uden unødigt ophold. Skal kunden bruge hjælp til at besvare en anmodning om indsigt, berigtigelse, sletning, begrænsning, indsigelse eller dataportabilitet, bistår PackReport uden særskilt betaling, i det omfang det er nødvendigt, og med de oplysninger systemet faktisk har. I praksis er den bistand sjældent nødvendig: kunden kan selv se og hente alt, der ligger om kontoen og ordrerne.
• Bistand med art. 32-36 (art. 28, stk. 3, litra f): PackReport bistår kunden, under hensyn til behandlingens karakter og til de oplysninger, vi har adgang til, med sikkerheden om behandlingen (art. 32), med underretning om brud til Datatilsynet og til de registrerede (art. 33 og 34) og med en konsekvensanalyse og en forudgående høring (art. 35 og 36). Bistanden består i faktiske oplysninger om systemet: hvad der behandles og gemmes (afsnit 3), hvor det ligger (afsnit 4 og 7), og hvilke foranstaltninger der er truffet (afsnit 5). PackReport er én person og yder ikke juridisk rådgivning og udfylder ikke kundens konsekvensanalyse på kundens vegne.
• Brud på persondatasikkerheden (art. 33, stk. 2): PackReport underretter kunden uden unødig forsinkelse, efter at vi er blevet opmærksomme på et brud. Underretningen går til kontoens e-mailadresse og indeholder de oplysninger i art. 33, stk. 3, vi har på det tidspunkt; resten eftersendes, efterhånden som de foreligger, i stedet for at vente på et fuldstændigt billede. PackReport tilstræber at underrette samme dag og altid så tidligt, at kunden kan nå sin egen frist over for Datatilsynet efter art. 33, stk. 1.
• Dokumentation, revision og inspektion (art. 28, stk. 3, litra h): PackReport stiller alle oplysninger til rådighed, der er nødvendige for at påvise, at forpligtelserne i denne aftale overholdes, og giver mulighed for og bidrager til revisioner, herunder inspektioner, der foretages af kunden eller af en revisor, kunden har bemyndiget. Rammerne står lige nedenfor.

Revisionens rammer. 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:

• Den daglige backup. En fuld kopi af databasen lægges én gang i døgnet som CI-artefakt hos GitHub (USA). Den er AES256-krypteret, men adgangskoden ligger også hos GitHub (afsnit 5), og kryptering flytter ikke lagerstedet. Den slettes efter 7 dage. Én gang om måneden gendannes den nyeste kopi på en engangsmaskine hos GitHub (afsnit 5).
• Driftslogs. Hos Render i Oregon. Modtagerens navn og adresse fra webhook-payloaden skrives ikke i dem under normal drift; undtagelsen ved en ufanget fejl står i afsnit 3.

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ørslerne sker på det grundlag, den enkelte leverandørs databehandlertillæg fastsætter. Det står nedenfor for Render, for Cloudflare som Renders underdatabehandler og for GitHub.

De supplerende foranstaltninger, PackReport står inde for, er vores egne:

• 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. Adgangskoden ligger også hos GitHub, så krypteringen beskytter mod andre, der får fat i filen, men ikke mod GitHub selv.
• Modtagerens navn og adresse fra webhook-payloaden skrives ikke i driftsloggen i Oregon under normal drift.

Render: grundlaget er på plads, og der er intet at underskrive.

• 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 i pkt. 6.2, at overførsler fra EØS sker under EU-US Data Privacy Framework, eller, hvis det ikke gælder eller ophører, under EU's standardkontraktbestemmelser, der "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 PackReports situation: vi er databehandler for webshoppen, og Render er underdatabehandler for os.

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

Cloudflare foran API'et er en del af Renders drift.

• Hvem der driver det: api.packreport.dk peger på Renders tjeneste, og Render sender al trafik til sine webtjenester gennem Cloudflares netværk (Renders egne sider, render.com/docs/ddos-protection og render.com/articles/how-render-handles-ddos-attacks). PackReport har ingen konto hos Cloudflare til den trafik.
• Grundlaget: Cloudflare står på Renders liste over underdatabehandlere (render.com/trust, som i dag viderestiller til render.com/security). I Renders tillæg pkt. 4.5 forpligter Render sig til at pålægge sine underdatabehandlere databeskyttelsesforpligtelser svarende til Renders egne og til at hæfte for dem over for PackReport. Grundlaget for Cloudflare er altså Renders tillæg ovenfor, og det er det, en DPO skal henvises til. Cloudflare oplyser selv, at selskabets overførsler fra EØS til USA sker under EU-US Data Privacy Framework og ellers under standardkontraktbestemmelserne (cloudflare.com/privacypolicy).
• Hvad Cloudflare ser: Cloudflare terminerer TLS foran hele API'et. Hver anmodning, også fragtplatformens webhook med sin fulde payload, læses derfor i klartekst hos Cloudflare, før den når Render. 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.

GitHub: der er ingen databehandleraftale for denne konto.

GitHub opbevarer den daglige backup i USA. GitHubs databehandleraftale 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). Den aftale dækker bare ikke den konto, backuppen ligger på. GitHub oplyser selv på github.com/customer-terms (læst 12. oktober 2026), at databehandleraftalen gælder behandlingen af data for GitHub Enterprise Cloud, GitHub Enterprise (Unified), GitHub Teams og GitHub Copilot, og at GitHub Customer Agreement gælder for kunder, der køber direkte hos GitHub. Repositoryet med backuppen ligger på en personlig konto uden nogen af de fire produkter, og kontoen kører derfor på GitHubs almindelige brugervilkår, som ikke har databehandlervilkår.

Det har to følger. Selve overførslen til USA er dækket, fordi GitHub er selvcertificeret under EU-US Data Privacy Framework. Men art. 28, stk. 4 kræver en kontrakt med underdatabehandleren, og den findes ikke for GitHub. Krypteringen lukker ikke det hul, fordi adgangskoden også ligger hos GitHub (afsnit 5). Det, der begrænser omfanget, er kopien selv: én kopi i døgnet, AES256-krypteret, slettet efter 7 dage.

Hullet lukkes på én af to måder: backup-kørslen flyttes til en GitHub-organisation på en plan, databehandleraftalen dækker, eller backuppen lægges hos en leverandør i EU, der har en databehandleraftale. Indtil det er sket, står forbeholdet her, så kunden kan tage stilling til det, før aftalen indgås.

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. Én ting slettes automatisk efter en frist, og den står nedenfor.

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, emballageprofiler, andele husholdningsemballage og til udlandet, mikrostatus, sporet over markeringerne og de leverancer af emballage, kunden selv har importeret. Backupperne indhenter sletningen af sig selv: hver daglig kopi ligger syv dage hos GitHub og slettes derefter, så senest en uge efter sletningen findes rækkerne heller ikke i en backup.

Den ene automatiske frist: sporet over markeringerne. Sporet over, hvornår markeringerne af emballagens oprindelse er anvendt på ordrer, ryddes ved første opstart af API’et. En linje i sporet slettes, når den er mere end fem år gammel, og det sker, uden at kunden beder om det, og ved en opstart frem for på selve dagen. Fristen er en oprydning i en tabel, der ellers aldrig blev mindre, og fem år er valgt, så sporet rækker længere tilbage end den indberetning, linjen hører til. Resten af emballageregnskabet er ikke berørt: ordrer, emballageprofiler, andele, mikrostatus og de leverancer af emballage, butikken selv har importeret, bliver liggende efter reglerne ovenfor. Har kunden brug for at kunne fremvise sporet længere tilbage end fem år, skal hun selv gemme sin dokumentation, mens linjerne er der.

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. Ud over den ene frist ovenfor og de frister for betalingsloggen, der står i afsnit 4, sletter PackReport ikke af sig selv, 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.

Lovvalg og værneting. Aftalen er underlagt dansk ret. Tvister mellem parterne afgøres ved Københavns Byret. 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.