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, how the form was used (clicks, time on each step, which fields were filled in, never what was typed), 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] |
See also: Data Processing Agreement · Sub-processor list · Privacy notice.