DPIA template

For Operators using the Innkept widget · aligned to ICO guidance under Article 35 UK GDPR

This template covers the Processing carried out via the Innkept widget. If your use of personal data goes beyond what's described here (separate marketing platforms, CRM enrichment, profiling for pricing), extend it accordingly — the ICO's DPIA guidance is the authoritative reference.

When you need to do a DPIA

Article 35 UK GDPR requires a DPIA where Processing is “likely to result in a high risk to the rights and freedoms of natural persons.” The ICO's published list of operations that require a DPIA includes:

Innovative use of new technology;
Tracking individuals' location or behaviour;
Profiling on a large scale;
Targeting children or other vulnerable groups for marketing;
Combining datasets from different sources.

Use of the Innkept widget on its own does not normally trigger a mandatory DPIA. It probably does if you also: enable Meta CAPI / GA4 server-side conversions, run audience-based remarketing using the lead data, or combine widget data with other datasets (e.g. CRM enrichment from a third party). When in doubt, do one — they're cheap insurance.

1. Identify the need for a DPIA

Briefly describe the project or processing operation. Why are you doing it? What outcomes are you trying to achieve?

Sample: We have embedded the Innkept quote widget on our website to allow prospective customers to self-configure event enquiries (event type, date, guest count, menu, add-ons) and submit them as leads. Submitted leads flow into our internal lead-management workflow and are pushed to [our CRM] via a webhook integration.

We have additionally enabled the Meta Conversions API integration to attribute conversions to our paid social campaigns. We have not enabled additional behavioural profiling, audience inference, or remarketing.

2. Describe the processing

2.1 Nature of the processing

Collection of enquiry data via an embedded JavaScript widget on our public website.
Storage of enquiry data on Innkept's hosted platform (processor) for the duration of our subscription.
Transmission of enquiry data to: [our CRM via webhook], [Meta Conversions API for ad attribution].
Aggregation of enquiry data into operator-facing analytics (funnel, lead time, demand heatmap).

2.2 Scope of the processing

Data subjects: members of the public visiting our website. Approximately [number] per month engage with the widget; approximately [number] submit a lead.
Personal data: name, email, phone (optional), event date, guest count, event type, selected menu/add-on items, GDPR consent flag, pseudonymous session identifier, truncated IP, user-agent.
If marketing consent is granted: GA client/session ids, Meta browser id, Google Ads click id, Meta click id, referrer URL, landing page URL.
Retention: leads are retained for the duration of the subscription and pruned on request; raw widget event records are retained for [365 days / our configured value].
Geographic scope: visitors are predominantly UK-based.

2.3 Context of the processing

Source of data: directly from the data subject when they engage with the widget.
Relationship: prospective customer relationship; processing is necessary to take pre-contractual steps at the request of the data subject (Article 6(1)(b) UK GDPR) for the lead itself, and based on consent (Article 6(1)(a)) for the marketing-class processing layer.
Children: the widget is intended for adults entering into venue/catering contracts. We have not taken specific child-safeguarding measures because we do not market to children.
Public concern: enquiry-form processing is a routine, expected operation; no novel public concern is anticipated.

2.4 Purposes of the processing

To respond to enquiries and provide quotes.
To analyse the performance of our enquiry form and improve conversion (operator analytics).
(If applicable) To attribute conversions to paid advertising campaigns via Meta CAPI / GA4.

3. Consultation

Have you consulted with data subjects, your DPO, or other stakeholders?

Sample: Internal stakeholders consulted: [marketing manager, IT lead, finance director]. We have not consulted with prospective data subjects directly; this is a standard enquiry-form processing operation similar to a contact form, and the privacy notice on our website describes the processing.

4. Assess necessity and proportionality

What is your lawful basis? Does the processing actually achieve the purpose? Is there a less intrusive way?

Lawful basis — lead enquiry: Article 6(1)(b) UK GDPR — necessary to take steps at the request of the data subject prior to entering into a contract.
Lawful basis — marketing email follow-up: Article 6(1)(a) UK GDPR (consent), captured by an explicit opt-in box on the widget.
Lawful basis — marketing-class analytics (GA4 cookies, Meta CAPI): Article 6(1)(a) UK GDPR (consent), captured via Google Consent Mode / IAB TCF / our own consent banner. PECR Regulation 6 also applies to setting non-essential cookies.
Data minimisation: we collect only what's needed to respond to an enquiry. The widget does not request a postal address, date of birth, or special-category information. IP addresses are truncated at the point of capture.
Less-intrusive alternatives considered: a free-text contact form would collect less structured data but result in significantly worse follow-up because we wouldn't know what they're enquiring about; we believe the structured form is proportionate.

5. Identify and assess risks

What could go wrong, how likely is it, and how serious would the impact be?

Risk	Likelihood	Severity	Overall
Confidentiality breach (lead database leak)	Low	Medium	Low
Marketing communications sent to subjects who didn't consent	Low	Low	Low
Visitor-level tracking without consent (PECR breach)	Medium	Medium	Medium
Excessive retention of pseudonymous event data	Low	Low	Low
Onward transfer to US ad platforms without lawful mechanism	Low	Medium	Low
Failure to fulfil right-to-erasure request	Low	Medium	Low

6. Identify measures to reduce risk

Risk	Mitigating measure	Residual risk
Confidentiality breach	Encryption in transit and at rest, access controls, MFA on operator dashboard, IP truncation, breach notification SLA from Innkept (72h).	Low — accepted
Marketing without consent	Marketing-email opt-in is a separate explicit checkbox in the widget, default off; only the consenting subject receives marketing.	Low — accepted
PECR cookie / tracking breach	Marketing-class tracking is gated behind the host page's Consent Mode v2 / TCF v2.2 signal. Innkept's `requires_marketing_consent` setting defaults to on. CMP banner deployed on the website.	Low — accepted
Excessive retention	Data retention configured to [365] days in Innkept settings. Anonymisation available on request via the lead detail page.	Low — accepted
US transfers	UK Data Bridge applies to Google LLC and Meta Platforms (self-certified). UK Addendum applies elsewhere as needed. Listed in Innkept's sub-processor list.	Low — accepted
Right to erasure	Documented internal procedure; the Innkept dashboard exposes an “Anonymize” action that nulls PII while preserving analytics totals.	Low — accepted

7. Sign off and outcomes

Measures approved by	[Name, role, date]
Residual risks approved by	[Name, role, date]
DPO advice provided / consulted	[Yes/No, summary, date]
Consultation responses reviewed	[Where applicable]
This DPIA will be kept under review by	[Name, frequency — we recommend annually or at any material change]