DATA PROTECTION IMPACT ASSESSMENT

How to read this document

This document follows the seven steps of the ICO sample template. Each grey box repeats the template prompt; the text beneath it is Handyhand's answer. Facts were taken from the production codebase (what the system does), the production database (how much data and how many people), the live websites and Tag Manager container (what actually runs in users' browsers), and the published privacy notice (what users are told). Where these sources disagree, the disagreement is recorded as a risk and addressed in Step 6.

Handyhand is established in Denmark and operates in Denmark and the Netherlands, so the EU GDPR applies rather than the UK GDPR. The ICO method is used because it is clear and widely accepted; the substantive requirements (Articles 35 and 36) are the same, and the Danish Datatilsynet endorses the same WP248 criteria. Datatilsynet's own DPIA template and list of processing that always requires a DPIA were also checked (datatilsynet.dk/regler-og-vejledning/behandlingssikkerhed/konsekvensanalyse).

Explain broadly what project aims to achieve and what type of processing it involves. You may find it helpful to refer or link to other documents, such as a project proposal. Summarise why you identified the need for a DPIA.

What Handyhand does

Handyhand is a two-sided online marketplace. Private customers and small businesses post tasks (moving, cleaning, gardening, assembly, repairs and similar) with a description, photos, location and budget. Independent service providers ('Handyhanders') browse tasks, make offers, chat with the customer, carry out the work and are paid through the platform. Pinploy ApS operates the platform, takes a service fee, handles payments and payouts, verifies identities, moderates disputes and cancellations, and reports Handyhander income to the tax authorities where the law requires it.

Type of processing

The service cannot work without processing personal data about both sides: identity and contact details, home addresses and precise locations, photos of people's homes, free-text descriptions and private chat, payment and payout details, national identity numbers used for verification and tax reporting, ratings and reviews, device and behavioural data, and derived data such as tier levels, AI price suggestions and fraud or quality signals.

Why a DPIA is required

Screening against the ICO and WP248 criteria shows the processing meets several 'likely high risk' indicators at once. Two or more indicators normally means a DPIA is mandatory; Handyhand meets at least eight:

The processing is also on Datatilsynet's national list in at least one respect (systematic monitoring and profiling of a large number of people, and processing of national identity numbers at scale), which makes a DPIA compulsory under Article 35(4).

Trigger for doing it now

No DPIA has previously been recorded. The privacy notice was last updated 26 February 2024 and pre-dates the Netherlands launch, the AI features, server-side advertising conversions, message screening and the current cancellation and tier systems. This assessment therefore serves both as the retrospective DPIA for the live platform and as the baseline for updating the privacy notice.

Describe the nature of the processing: how will you collect, use, store and delete data? What is the source of the data? Will you be sharing data with anyone? You might find it useful to refer to a flow diagram or other way of describing data flows. What types of processing identified as likely high risk are involved?

Sources and collection

• Directly from users: sign-up form (name, email, phone, password or social login, promotional-consent checkbox), profile (photo, description, education, address, working hours), task creation (title, description, photos/videos, address, date, budget, insurance consent), offers and chat, reviews, support tickets, cancellation and decline reasons, appeal texts, bank account or Stripe Connect onboarding, optional date of birth.
• From identity providers: MitID through the broker Criipto (Denmark; verified name, date of birth and CPR number), Google, Apple and Facebook single sign-on (subject id, name, email, access token), Stripe (identity and bank verification results, bank fingerprints).
• From public registries: Danish CVR and Dutch KVK/VIES for business customers; Danish BBR building register, looked up from the user's address, to build a property report (building year, area, heating, rooms).
• Generated automatically: IP address and request headers at sign-up (stored in the user record as 'flagged data' with an ipdata.co geolocation lookup), per-session and per-activity IP logs, device and push tokens, page and task views, 'last online', ratings, completion and cancellation rates, strength score, tier, AI price suggestions, AI offer recommendations, moderation verdicts, email/SMS/push delivery logs, Vapi voice-call transcripts and chatbot conversations.
• Historic: tasks and users were synchronised with the Shouter marketplace, a partner platform that has since closed (confirmed 10 Sept 2026). The integration code, API token, database connection and shouterUserId fields still exist and should be removed.

Use

Data is used to run the marketplace end to end (matching, chat, payment escrow, payouts, invoices, disputes, cancellation rules), to verify identity and prevent fraud, to compute trust signals (ratings, tiers, completion rates), to notify users, to support them (human support, chatbot, voice agent), to improve the product (analytics, AI models), to market (reactivation emails, ad conversion measurement) and to meet legal duties (bookkeeping, tax reporting).

Storage and access

• Core data: PostgreSQL (write and read replicas) and Redis, operated on AWS. Files (photos, documents, invoices) in Amazon S3, region eu-central-1 (Frankfurt), served through CloudFront. Invoice PDFs are written with server-side encryption; encryption for other objects is governed by the bucket default setting (confirmation scheduled, action B-2). The database is also hosted in Frankfurt; encryption-at-rest and backup retention settings are infrastructure settings that are to be documented from the AWS console (action B-2).
• Passwords are stored as salted one-way hashes. National identity numbers and bank details are held in access-restricted tables; strengthening their protection with field-level encryption is scheduled in the action plan. A separate table holds one-way hashes of email, phone, bank account and national ID used only to detect duplicate or banned accounts.
• Access: role-based (user, admin, superadmin, content-writer, influencer, insurance). Admins use an admin dashboard (with a generic CSV export of any table view), an admin chatbot with MitID and payment tools, and a one-time-code impersonation feature. Staff and AI-assisted analysis also read production data through an internal analytics tool. Admin write actions are audit-logged; admin read access is not.
• Task location: the API strips the street address for anyone who is not the task owner and returns only city and postcode (verified in the task controller); the exact address is shared with the accepted Handyhander. Remote tasks carry no address.

Sharing and processors

Personal data leaves Handyhand's systems to the following recipients (evidence in code; the published privacy notice currently names only Stripe and Google):

Tracking: live-site check (9 September) and Tag Manager container audit (10 September 2026)

A fresh browser visit to handyhand.dk from Denmark showed a Cookiebot banner, injected by the Tag Manager container (it is not in the code). Before any choice was made, with Cookiebot reporting statistics and marketing consent as false, the page had already loaded Microsoft Clarity session recording, Bing UET, the Reddit pixel, the bestofluck.io tracker, the Trustpilot widget and the full PostHog bundle including the session recorder, and had set the _fbp (Meta), _rdt_uuid (Reddit), PostHog and hh_uid cookies. No Google Consent Mode entries were present in the data layer. In other words the banner is displayed but does not gate the trackers. The public web app shares the same container. The exported container (GTM-5T5GZ93, workspace 206) was then audited tag by tag; the full table is in the appendix. Summary: 51 tags, 55 triggers. Cookiebot is correctly installed as the consent-mode source (defaults: statistics and marketing denied), and Google tags (GA4, Google Ads) honour it natively. Only 3 of the 51 tags (Meta, TikTok) use Tag Manager's built-in consent checks. The Reddit pixel, the bestofluck.io ('Glückauf') tag, the Tune/Trackwise affiliate tag and Microsoft Clarity (loaded by the Bing UET tag) fire on every page without any consent condition. The web app pushes raw, unhashed email and phone number into the data layer for every signed-in user, and the GA4 configuration tag forwards them to Google Analytics as user properties and event parameters, which breaches Google's own no-PII terms and the minimisation principle. The Bing enhanced-conversion tag forwards the same email and phone to Microsoft. An OpenAI Ads pixel is also installed (consent-mode gated). PostHog, Trustpilot and AdTraction are loaded from the application code, not from Tag Manager, so Cookiebot cannot gate them at all today.

Deletion

Users can delete their account in settings when they have no active tasks, offers or paid stored credit. Deletion anonymises the user row (name to 'Deleted', email to a placeholder, password reset, personal fields nulled, soft-deleted), removes the profile image and portfolio from S3 (unless the user is under investigation, in which case the profile image is preserved as evidence), erases pending tasks and offers, deletes notifications, social logins, Dinero records and property reports, closes support tickets and deletes the Mautic contact. It does not delete: national ID records, bank account details, identifier hashes, push tokens, session and activity IP logs, phone-verification and SMS logs, chat messages and their edit history, reviews, admin notes, voice-call transcripts, chatbot conversations, moderation records, sign-up 'flagged data', invoices, payouts or ad-tracking events, and it sends no deletion request to any external recipient other than Mautic. Scheduled jobs delete only the generic log table (7 days) and old notifications. Chat, photos, IP logs and transcripts are therefore kept indefinitely today.

New technologies and novel processing

• Contact-detail leak screening: every message, offer and attached image can be scanned by regex, then by Google Vision OCR, then by an OpenAI model that receives the author's recent message history and prior violations, producing a culpability grade (none, accidental, negligent, deliberate, engineered). Grades are stored per user with a 90-day look-back and a third violation is automatically floored to 'negligent'. The leaked values themselves are deliberately not stored.
• Legacy censoring: message, offer, comment, review and profile text posted to in-house ML endpoints; offending text stored verbatim in a censorship table; users with 20+ completed offers are exempt.
• LLM features: price suggestion from similar tasks (embeddings), AI offer recommendation explaining to the customer which Handyhander to pick, AI cleaning of decline reasons before they are shown to the other party, AI-written reactivation emails from the user's past task, chatbot for users and admins, voice agent on the support line, LLM screening of ban appeals, AI profile-tag suggestions.
• Automated decisions: long automatic ban when a new account matches the email, phone or payment identifiers of a banned or high-cancellation account (no human step); automatic ban until age 18 when an under-18 birthdate is entered; sign-up blocked when the IP country does not match the chosen market (feature-flagged); tier and fee levels; cancellation penalties.

Screening criteria flagged as likely high risk

Large scale; evaluation/scoring; automated decision-making with significant effect; systematic monitoring of private communications; national identity numbers and financial data; matching with third-party datasets; vulnerable individuals; innovative technology; risk of physical harm from location data. See Step 1.

Describe the scope of the processing: what is the nature of the data, and does it include special category or criminal offence data? How much data will you be collecting and using? How often? How long will you keep it? How many individuals are affected? What geographical area does it cover?

Categories of personal data

Special category and criminal offence data

Handyhand does not intentionally collect special category data (Article 9) or criminal offence data (Article 10). Three points need care: (1) task descriptions and chat are free text and customers sometimes disclose health or family circumstances ('I am recovering from surgery and cannot lift'); this is incidental and must be treated as potentially sensitive in storage, AI processing and access control. (2) National identity numbers (CPR, BSN) are not Article 9 data but are subject to specific national rules (Danish Data Protection Act §11, Dutch UAVG Article 46) that restrict use to purposes required by law and demand strong security. (3) Criminal record certificates (straffeattest / børneattest, VOG) are not collected by the platform, and support staff are instructed not to request or accept them; this instruction is formalised in the action plan (B-9).

Volume and frequency (production database, 9 September 2026)

Processing is continuous (24/7), real-time for chat and notifications, and batch for scheduled jobs (reminders, payouts, tier recalculation, tax reporting, analytics).

Retention

There is currently no written retention schedule. Practice observed in the system: accounts are kept until the user deletes them or is erased; erased users are anonymised in place (name, email and identifiers overwritten) rather than deleted, so that tasks, offers, payments and reviews remain for accounting and dispute purposes; bookkeeping records must be kept 5 years under the Danish Bookkeeping Act (7 years in the Netherlands). Chat messages, photos, logs and analytics events have no defined deletion point. Defining and enforcing a retention schedule is a Step 6 measure.

Geography

Data subjects are in Denmark and the Netherlands. All hosting, including the database, is in AWS eu-central-1 (Frankfurt), confirmed by management on 10 September 2026. Many processors are US-headquartered (Amazon, Cloudflare, Google, Stripe, OpenAI, Anthropic, Perplexity, Vapi, Meta, Twilio, Expo, ipdata.co); see Step 2 nature and Step 4 for transfer safeguards.

Describe the context of the processing: what is the nature of your relationship with the individuals? How much control will they have? Would they expect you to use their data in this way? Do they include children or other vulnerable groups? Are there prior concerns over this type of processing or security flaws? Is it novel in any way? What is the current state of technology in this area? Are there any current issues of public concern that you should factor in? Are you signed up to any approved code of conduct or certification scheme (once any have been approved)?

Relationship and control

Users enter a contract with Pinploy ApS (the terms of use) and, for each task, a separate contract with each other. Handyhand is the controller for platform data. Users create their own accounts, choose what to write and upload, decide whom to chat with and can edit or delete their profile and account in settings. They have less control over derived data (ratings, tiers, fraud flags) and over what the other party does with information exchanged for a task.

Reasonable expectations

Users expect their contact details, address and task details to be used to get the job done and to be shared with the person they hire. They are less likely to expect: AI systems reading their task text and chat; server-side sharing of hashed emails with Google for advertising measurement; automatic monitoring of messages for off-platform contact; national ID numbers being stored beyond the verification moment; or that erasing an account leaves an anonymised record. Each of these needs to be clearly explained in the privacy notice.

Children and vulnerable groups

The service is for adults (18+ per the terms and privacy notice). Handyhanders in Denmark can verify through MitID, which confirms age, but verification is optional and date of birth is not collected at sign-up, so under-18s could hold accounts in either role until a birthdate is entered. Customers often include elderly people, people with disabilities or illness, and people in stressful life events (moving, bereavement). Handyhanders are frequently students, migrants or people on low or irregular incomes for whom suspension or payout delays have real consequences. Both groups count as potentially vulnerable for DPIA purposes.

Prior concerns, security history and public concern

No personal-data breach has been notified to Datatilsynet to date. Known gaps this assessment surfaced: an out-of-date privacy notice, a consent banner that does not gate several trackers, raw contact data forwarded to analytics vendors, no written retention schedule, an incomplete erasure routine, and broad internal access to production data through analytics tools. Gig-economy platforms are under active regulatory attention in the EU (Platform Work Directive 2024/2831, which restricts automated decision-making and monitoring of platform workers and must be transposed by December 2026; DAC7 tax reporting; the AI Act's transparency duties for AI systems interacting with people). Public concern about AI reading private messages and about ad tracking without consent is high; the Danish and Dutch authorities have both fined companies for consent failures.

Novelty and state of the art

Marketplace processing itself is well understood. The novel elements are the LLM features (price suggestion from similar tasks, cleaning of free-text decline reasons before showing them to the other party, chat and voice support assistants), embedding-based similarity search over task text, and automated screening of messages. Industry practice for these is to use EU-hosted or EU-region model endpoints with no-training/zero-retention terms, to minimise the text sent, and to keep a human in the loop for decisions with significant effect.

Codes of conduct and certification

Handyhand is not signed up to an approved GDPR code of conduct or certification scheme. Processors used hold ISO 27001 / SOC 2 (AWS, Stripe, Google, Microsoft/OpenAI) and Stripe is PCI DSS Level 1, which is why card data never touches Handyhand systems.

Describe the purposes of the processing: what do you want to achieve? What is the intended effect on individuals? What are the benefits of the processing – for you, and more broadly?

Where Handyhand relies on legitimate interests (fraud prevention, analytics, message screening, first-party marketing to existing users, 'last online' indicators), the interest, its necessity and the balance against users' rights are set out in Step 4.

Consider how to consult with relevant stakeholders: describe when and how you will seek individuals' views – or justify why it's not appropriate to do so. Who else do you need to involve within your organisation? Do you need to ask your processors to assist? Do you plan to consult information security experts, or any other experts?

Individuals (users)

Consultation is appropriate and practical because the data subjects are existing users. Plan (October and November 2026): (1) a short in-product survey to a sample of customers and Handyhanders on the points where processing may exceed expectations (AI reading task text and chat, message screening, ad measurement, retention after account deletion, 'last online' indicator); (2) review of existing support tickets and Trustpilot reviews mentioning privacy, deletion or verification; (3) a feedback channel on the updated privacy notice. Views must be recorded and, where the final decision departs from them, the reasons documented in Step 7.

Internal stakeholders

• Management (Saxo Merrild) – owner of this DPIA, approves measures and residual risk.
• Engineering lead – confirms the technical facts in Step 2, owns security and retention measures.
• Support / operations – confirms manual data handling (ID documents received by email, dispute evidence, account deletion requests).
• Marketing – confirms tracking, ad platforms, CRM (Mautic) and consent practice.
• Finance / accounting – confirms bookkeeping retention and DAC7 reporting scope.

Processors

Processors are contractually obliged to assist with DPIAs (Article 28(3)(f)). Ask each main processor for: their DPA, sub-processor list, transfer mechanism and security documentation. Main processors (full list in Step 2): Amazon Web Services, Cloudflare, Stripe, Criipto (MitID), Dinero, OpenAI, Anthropic, Perplexity, Google (Vision, Maps, Ads, Firebase, Tag Manager via Stape), Vapi, Twilio/JT, Expo, PostHog, Trustpilot, AdTraction, ipdata.co, n8n, plus the dormant integration with the closed Shouter marketplace.

External experts

Recommended: (a) a Danish data-protection lawyer to review lawful bases for CPR/BSN, message screening and ad measurement, and to assess whether a DPO must be designated (Article 37: 'core activities consist of regular and systematic monitoring of data subjects on a large scale' is arguably met); (b) an independent penetration test of the API, web and app; (c) advice on the Platform Work Directive as transposed in Denmark and the Netherlands.

DPO

No DPO is designated. Handyhand's core activity involves regular and systematic monitoring of a large number of users (ratings, tiers, message screening, fraud detection), so Article 37(1)(b) is likely to apply. Management will obtain a written Article 37 assessment and, unless it concludes otherwise, appoint an external DPO (action B-1). Until then the external legal adviser gives the advice recorded in Step 7.

Describe compliance and proportionality measures, in particular: what is your lawful basis for processing? Does the processing actually achieve your purpose? Is there another way to achieve the same outcome? How will you prevent function creep? How will you ensure data quality and data minimisation? What information will you give individuals? How will you help to support their rights? What measures do you take to ensure processors comply? How do you safeguard any international transfers?

Legal framework applied

• Regulation (EU) 2016/679 (GDPR), in particular Articles 5, 6, 9, 12-22, 25, 28, 30, 32-36 and 37, and Recitals 75-76 and 84-94 on impact assessments.
• Danish Data Protection Act (databeskyttelsesloven), notably §11 on national identification numbers (CPR).
• Dutch GDPR Implementation Act (Uitvoeringswet AVG), notably Article 46 on the citizen service number (BSN).
• Danish Executive Order on cookies (cookiebekendtgørelsen) and Dutch Telecommunications Act Article 11.7a on storing and reading information on users' devices.
• Danish Marketing Practices Act (markedsføringsloven) §10 and Dutch Telecommunications Act Article 11.7 on electronic direct marketing.
• Council Directive (EU) 2021/514 (DAC7) as implemented in the Danish Tax Reporting Act and the Dutch implementation act, on reporting of platform sellers' income.
• Danish Bookkeeping Act (bogføringsloven) and Dutch General Tax Act (Algemene wet inzake rijksbelastingen) on retention of accounting records (5 and 7 years).
• Directive (EU) 2024/2831 on improving working conditions in platform work (transposition by 2 December 2026), on algorithmic management, monitoring and human review.
• Regulation (EU) 2024/1689 (AI Act), Article 50 transparency obligations for AI systems that interact with people, applicable from 2 August 2026.
• Guidance: Article 29 Working Party WP248 rev.01 on DPIAs; EDPB Guidelines 05/2020 on consent and 8/2020 on targeting of social media users; Datatilsynet guidance on consequence analyses, cookies and CPR numbers.

Lawful basis per purpose

Necessity and alternatives

Running the marketplace, paying out and reporting tax cannot be done with less data. For the optional layers the assessment is: (a) Fraud detection could use keyed hashes with the same effect; (b) message screening could run the deterministic scan first and only send the minimum text to an LLM when a hit is found, and could skip OCR unless regex flags an image; (c) ad measurement can work with consented, hashed data only, and postcode/country need not be sent in clear; (d) sign-up geolocation could use Cloudflare's country header alone rather than sending the raw IP to ipdata.co; (e) IP logging per session can be truncated or dropped after 30 days; (f) session replay can be turned off or masked and made consent-based; (g) CPR/BSN can be replaced by a verification flag plus a hash once DAC7 reporting no longer needs the number.

Preventing function creep

Every new feature that touches personal data goes through the existing spec-review gate before code is written; add a one-page privacy checklist to that gate (new data field? new recipient? new automated decision? new AI use?). Any 'yes' triggers an update of the Record of Processing Activities and this DPIA. Analytics and AI use of production data is limited to defined purposes; ad-hoc analysis should use anonymised extracts.

Data quality

Users edit their own profile data; MitID and Stripe supply verified identity; addresses are validated with DAWA (DK) and Google Places (NL); email typo detection at sign-up. Derived scores (tiers, ratings) recalculate from source events. Risk area: AI-generated text (cleaned decline comments, offer recommendations, summaries) is stored as fact about a person; label it as AI-generated and keep the original.

Data minimisation

Current practice is not minimal: raw sign-up headers and IP geolocation are stored on the user record indefinitely; social-login access tokens are persisted; phone-verification rows keep the phone, IP, code and raw provider response; SMS bodies are logged; MitID raw token content is stored in a legacy table; CPR/BSN appears in three tables plus invoices. Step 6 sets out the reductions.

Information to individuals

The privacy notice (last updated 26 February 2024) must be rewritten to describe: all categories of data including national ID numbers and location; all recipients listed in Step 2 with their role; the AI and monitoring features and what they decide; automated bans and how to obtain human review; retention periods per category; international transfers and safeguards; the NL market and Dutch-language version; the anonymisation approach on deletion; the cookie and tracking practice with a working cookie notice link (the current /cookiepolitik link returns 404); and a privacy contact. It should also correct the statements 'we do not process sensitive information' and 'we do not receive any information from third parties'. Layered just-in-time notices are needed at: MitID/ID-number entry, chat (screening notice), task creation (address sharing), sign-up (tracking consent).

Supporting individuals' rights

• Access and portability: build a self-service export (JSON/CSV of profile, tasks, offers, messages, reviews, payments) and a documented DSAR procedure with a 30-day clock. No export endpoint exists today.
• Erasure: extend the deletion routine to the tables listed in Step 2 and to external recipients (PostHog, Google, Meta, Trustpilot, Vapi, OpenAI/Anthropic logs), keeping only what bookkeeping and tax law require, and document those exceptions.
• Rectification: already available in settings for profile data; add a route for contesting ratings, moderation verdicts and AI-generated texts.
• Objection and restriction: provide opt-outs for Trustpilot invitations, 'last online' indicator, AI-written marketing and analytics.
• Automated decisions (Art. 22): human review, explanation and appeal for autobans, geo-blocks and tier downgrades. The appeal flow exists for bans but is LLM-screened first; a human must be reachable.
• Consent management: keep a versioned, timestamped consent history (current implementation overwrites the previous record).

Processor compliance

Handyhand will maintain a processor register (Article 28 and Article 30) with, for each processor: a signed data processing agreement, sub-processor list, transfer mechanism, security attestation (ISO 27001 / SOC 2), 'no training on customer data' and retention terms for AI vendors, and deletion-on-request support. Confirm DPAs exist for Criipto, Dinero, OpenAI, Anthropic, Perplexity, Vapi, Twilio/JT, Expo, PostHog, Stape, Trustpilot, ipdata.co, n8n and the Shouter data-sharing arrangement (which is controller-to-controller and needs a data-sharing agreement). Credentials for all processors are held in secrets management.

International transfers

Primary storage stays in the EU. Transfers to US providers must rely on the EU-US Data Privacy Framework (where the provider is certified: Amazon, Google, Meta, Microsoft, Stripe, OpenAI, Anthropic and others should be checked on the DPF list) or on Standard Contractual Clauses with a transfer impact assessment. Prefer EU endpoints where offered (OpenAI EU data residency, Google Vision EU region, Twilio EU region). Record each transfer in the processor register (action B-9).

Describe source of risk and nature of potential impact on individuals. Include associated compliance and corporate risks as necessary. Likelihood: remote, possible or probable. Severity: minimal, significant or severe. Overall risk: low, medium or high.

Identify additional measures you could take to reduce or eliminate risks identified as medium or high risk in step 5.

Method: every tag in the export was listed with its firing triggers, blocking triggers and Tag Manager consent settings, and cross-checked against what actually loaded on a fresh visit to handyhand.dk with consent declined. 'Built-in consent check' means the tag has an ad_storage or analytics_storage condition in Tag Manager. 'Consent mode' means the vendor's script reads the Google consent signals that Cookiebot sets. Paused tags are omitted (Facebook init/pageview and three blueMediaService tags are paused).

Not in the container but loaded by the application code and therefore not controlled by Cookiebot: PostHog (identify with email and name, session replay), Trustpilot widget, AdTraction tag (hashed email on task creation). These need code-level gating on Cookiebot's consent state.

Every measure in Step 6 and every fact still to be confirmed has an owner and a target date. Status is reviewed monthly until all items are closed.

Sources: production codebase (api, api-v2, web, app, SEO, admin) as of 9 September 2026; production database counts as of 9 September 2026; live-site check of handyhand.dk on 9 September 2026; Tag Manager container GTM-5T5GZ93 workspace 206 exported 10 September 2026; handyhand.dk/privatlivspolitik (version dated 26 February 2024); ICO 'How do we do a DPIA?'; Article 29 Working Party Guidelines WP248 rev.01; Datatilsynet guidance on consequence analyses and its list of processing operations always requiring one.