Data protection and privacy engineering

Our approach

Yeti Engines is designed for a category in which customers may provide detailed identity, contact, address, pet and underwriting information to obtain insurance quotes.

That means privacy cannot be treated as a final legal review after the customer journey has already been built. It must influence:

• which questions are asked;
• when information is collected;
• which organisations receive it;
• how quotes are generated and presented;
• what evidence is retained;
• who can access the information;
• how long it remains identifiable;
• how a customer exercises their rights; and
• how changes are reviewed before release.

Our design is informed by the UK General Data Protection Regulation, the Data Protection Act 2018 and, where a deployment falls within its scope, the EU GDPR.

1. Clear roles and responsibilities

The data-protection role of Yeti Engines depends on the activity being performed.

Yeti as controller

Yeti acts as a controller where it determines why and how personal information is processed. This includes its own:

• business and partner enquiries;
• regulatory and commercial administration;
• security and fraud prevention;
• supplier and professional relationships;
• complaints and rights requests; and
• parts of a consumer comparison journey for which Yeti determines the purpose and essential means of processing.

Yeti as processor

Yeti may act as a processor where it handles personal information solely on the documented instructions of a client or partner.

Where Yeti acts as a processor, an Article 28-compliant written agreement is put in place before that processing begins. The agreement addresses matters including:

• documented processing instructions;
• confidentiality;
• security measures;
• subprocessors;
• assistance with individual rights;
• breach notification and cooperation;
• audits and compliance information;
• international transfers; and
• return or deletion of personal information.

Separate controllers

In an insurance journey, Yeti, a publisher, an insurer, a broker, an authorised Principal and another intermediary may each act as separate controllers for their own purposes.

We do not assume that every party has the same role. The position is mapped and agreed for each deployment before live customer information is processed.

Where required, the customer-facing privacy information identifies:

• the organisations involved;
• their respective roles;
• why each organisation uses the information;
• which information is shared;
• the relevant legal basis;
• how long the information is retained; and
• where the customer can exercise their rights.

2. Privacy by design and default

Our platform is designed to apply data-protection principles at architecture, product and operational level.

For each live journey, we document:

1. the purpose of the processing;
2. the information required for that purpose;
3. the organisations that collect or receive it;
4. the controller and processor roles;
5. the lawful basis relied on by each relevant controller;
6. any special risks or additional safeguards;
7. the retention and deletion position;
8. the customer-facing notice and consent requirements;
9. the evidence that must be retained; and
10. the technical and organisational controls required before launch.

Higher-risk or novel processing is assessed through a Data Protection Impact Assessment where required or otherwise appropriate.

A partner's logo, colours and content can change without changing the underlying need for clear data ownership and accountability. White-label does not mean invisible data processing.

3. Security architecture

Security controls are selected according to the nature, scope, context and risk of the processing.

The production design includes the following control areas.

Encryption

• HTTPS is required for public and service endpoints.
• TLS 1.2 or later is the minimum target for data in transit.
• Managed databases, storage and backups use platform encryption at rest.
• Higher-risk direct identifiers may receive additional application-level protection where justified.
• Information is decrypted only where necessary for authorised application processing.

Identity and access

• role-based access control;
• least-privilege permissions;
• multi-factor authentication for privileged and internal access;
• separation of partner and organisation access;
• controlled administrative access;
• periodic access review; and
• prompt removal or restriction of access when no longer required.

Network and data-store controls

• databases are designed not to be publicly accessible;
• application components reach data through controlled interfaces;
• secrets and credentials are stored in managed secret storage rather than source code;
• production and non-production environments are separated;
• rate limiting, request validation and abuse controls are applied where appropriate; and
• access and security events are logged for investigation and accountability.

Development and release controls

• source code is held in version control;
• automated type, test, dependency and security checks form part of the release process;
• material changes are reviewed before production;
• changes affecting ranking, disclosures, consent or customer-facing regulated output require specific human review;
• production releases pass through a controlled deployment process; and
• generated or AI-assisted code is treated as draft work until reviewed, tested and approved.

Specific security commitments for a partner deployment are documented in the applicable contract and security schedule.

4. Non-production data and artificial intelligence

Production customer information, insurer credentials, access keys and live policyholder records must not be used casually in development, demonstration or general-purpose AI tools.

Our standard is to use:

• synthetic data;
• controlled test records;
• anonymised or appropriately pseudonymised information; or
• the minimum approved information needed for a defined support activity.

Yeti uses AI-assisted tools within a controlled development and business process. Those tools do not directly edit the regulated production runtime.

Before an AI, transcription or other supplier is approved to process personal information, the review considers:

• controller and processor status;
• contractual data-protection terms;
• retention;
• model-training settings;
• subprocessors;
• security controls;
• access;
• confidentiality; and
• international transfers.

Yeti does not intentionally use live consumer quote information submitted through a customer journey to train general-purpose AI models.

5. Auditability and evidence

A comparison platform must be able to evidence more than the final price displayed on a screen.

The platform is designed to retain structured evidence of relevant events, which may include:

• the quote session and source;
• the information submitted;
• the provider request;
• disclosure and privacy versions shown;
• consent or acknowledgement records;
• quote results returned;
• the ordering and presentation of results;
• policy-detail views;
• provider click-throughs;
• errors and integration outcomes; and
• later sale or revenue events where supported by the provider relationship.

Audit records are designed to support:

• customer support;
• complaints;
• Principal and provider oversight;
• reconciliation;
• security investigation;
• data-protection accountability; and
• the establishment, exercise or defence of legal rights.

“Auditability” does not mean retaining every payload indefinitely. The information retained and its duration must remain proportionate to the documented purpose.

6. Personal data breaches and incident response

Yeti maintains a documented incident-response runbook and breach log proportionate to its current processing activities.

The runbook covers:

• reporting and escalation;
• initial containment;
• preservation of relevant evidence;
• investigation and classification;
• assessment of risks to individuals;
• controller, partner and regulatory communication;
• recovery and remediation;
• decision recording; and
• post-incident review.

Where Yeti acts as controller:

• a personal data breach is assessed against the legal reporting threshold;
• the Information Commissioner's Office is notified without undue delay and, where feasible, within 72 hours after awareness where notification is required;
• affected individuals are informed without undue delay where the breach is likely to result in a high risk to their rights and freedoms; and
• the decision, evidence and remedial action are recorded.

Where Yeti acts as processor, the relevant controller is notified without undue delay in accordance with the applicable data-processing agreement.

The runbook is expanded before live consumer processing begins to reflect the approved infrastructure, providers, Principal, customer-support route and regulatory operating model.

Following a material incident, findings are fed into technical, procedural, supplier or training improvements.

7. Suppliers and subprocessors

Yeti maintains a controlled supplier and subprocessor register covering services approved to process personal information.

The register records, where relevant:

• the supplier and service;
• the Yeti contracting entity;
• the processing purpose;
• controller and processor status;
• categories of information involved;
• hosting and processing locations;
• subprocessors and onward transfers;
• the applicable contract and data-processing terms;
• the international-transfer mechanism;
• security and due-diligence status;
• retention and deletion arrangements;
• approval date and review date; and
• the service owner and exit position.

A supplier that may process personal information is reviewed proportionately before approval. The review may cover:

• the service and processing purpose;
• location and international transfers;
• security posture;
• data-protection terms;
• subprocessors;
• incident commitments;
• deletion and return;
• audit information;
• business continuity; and
• exit arrangements.

The register is expanded and the required review completed before a new supplier is permitted to process materially different personal information.

Where Yeti acts as processor, subprocessor approval and notification arrangements are governed by the applicable data-processing agreement.

The current deployment-specific supplier or subprocessor information is made available to relevant partners through the contract, due-diligence process or approved subprocessor list.

An insurer, broker or other recipient acting for its own insurance purposes will not normally be described as Yeti's subprocessor merely because Yeti sends it quote information.

8. Accountability and governance

Yeti maintains accountability documentation proportionate to its current processing activities and expands that documentation before materially different or higher-risk processing begins.

Depending on the activity, this includes:

• records of processing activities;
• data-flow maps;
• lawful-basis records;
• legitimate-interest assessments;
• Data Protection Impact Assessments;
• data-processing and data-sharing agreements;
• a supplier and subprocessor register;
• international-transfer records;
• retention schedules;
• security and access records;
• rights-request and complaint procedures and records;
• an incident-response runbook and breach records;
• change-control evidence; and
• training and policy documentation.

The documentation is reviewed when processing, technology, suppliers, regulation or the operating model changes materially.

Before a live consumer journey launches, the relevant records must reflect the final parties, data flows, infrastructure, integrations, retention periods, customer notices, regulatory approvals and contractual responsibilities for that deployment.

9. White-label and co-branded journeys

A white-label journey must still tell the customer who is involved.

Before launch, the approved privacy layer identifies, as applicable:

• the publisher or brand presented to the customer;
• Yeti Engines;
• the authorised Principal;
• insurers, brokers or intermediaries receiving quote information;
• any material processor;
• the purposes and lawful bases;
• marketing choices;
• the customer support and complaints route; and
• the organisations responsible for data-protection rights.

Partner branding and wording can be configured, but the underlying data-protection information cannot be removed, obscured or altered without the required review.

The role of a publisher is assessed individually. A publisher may be a marketing source, a separate controller, a joint controller in a defined activity, a client receiving a processor service, or another form of commercial participant depending on the actual design.

10. Partner due diligence

Prospective insurers, brokers and publishers can request appropriate information to support their due diligence.

Depending on the stage and proposed relationship, this may include:

• a data-protection and security overview;
• our standard data-processing terms;
• a deployment-specific data-flow summary;
• a current supplier or subprocessor list;
• retention and deletion information;
• international-transfer information;
• a technical architecture summary;
• incident and business-continuity information;
• answers to a proportionate security questionnaire; and
• relevant evidence for implemented controls.

Detailed or security-sensitive material may be supplied only under confidentiality or evaluation terms.

11. Relationship with our legal notices

This page explains Yeti's business-facing approach to data protection and privacy engineering.

It does not replace:

• the Yeti Engines Website Privacy Notice;
• the Cookies & website technologies notice;
• the privacy information provided within Yeti Compare;
• the privacy information for a white-label journey;
• a Partner Agreement;
• a Data Processing Agreement;
• controller or data-sharing terms;
• a security schedule; or
• the privacy notice of an insurer, broker, publisher or other independent controller.

Specific deployment documents take priority where they set out a more precise or binding arrangement.

Contact

For data-protection enquiries, partner due diligence or a copy of the relevant data-protection materials:

privacy@yetiengines.com

For security concerns:

security@yetiengines.com

See also:

• Privacy Notice
• Cookies & website technologies notice
• Website Terms of Use
• Complaints

Yeti Engines Ltd is registered in England and Wales under company number 17266550. Registered office: 5 Ribblesdale Place, Preston, England, PR1 8BZ.

This page is a high-level description of Yeti Engines' approach. It is not a certification or a contractual warranty that every control described applies identically to every environment. Deployment-specific commitments are set out in the relevant signed agreement and security documentation.