Back to home

Privacy Impact Assessments for UK Mortgage Brokers

By Casefile

Privacy Impact Assessments for UK Mortgage Brokers

A privacy impact assessment is a structured review of the data protection risks in a project before the project starts. Under UK law the formal version is the data protection impact assessment (DPIA), and it is mandatory where processing is likely to result in a high risk to individuals. For a mortgage brokerage, the question usually arises when the firm adopts a new system that collects, reads and stores client bank statements, payslips, tax forms and ID.

This guide explains what the assessment is, when a broker needs one, what it must contain, how it relates to contracts with software suppliers, and how to complete one in six steps without turning it into a consultancy project.

TL;DR

  • "Privacy impact assessment" (PIA) is the general term. Under the UK GDPR the legal requirement is a data protection impact assessment (DPIA), and the two are used interchangeably in most guidance.
  • A DPIA is required before processing starts where the processing is likely to result in a high risk to individuals' rights and freedoms. Brokers should screen every new document collection or verification tool against that test and record the result.
  • The assessment must describe the processing, test necessity and proportionality, assess risks and set out mitigations. There is no mandatory template, and small firms can scale the work to their size.
  • Using a cloud supplier does not move accountability. The broker remains responsible for the data and needs a written contract with the supplier.
  • A DPIA is a living document. Review it when the system, the data or the way clients upload documents changes.

Table of Contents

PIA or DPIA: what the terms mean

"Privacy impact assessment" was the term used before the GDPR took effect and it still appears in vendor material, security frameworks and search results. The UK GDPR uses a narrower, legally defined term: the data protection impact assessment. The ICO describes a DPIA as a process to help you systematically analyse, identify and minimise the data protection risks of a project or plan, and as a key part of your accountability obligations.

In practice, the difference matters in one place. A PIA can be any internal privacy review a firm chooses to run. A DPIA is the one the law requires in defined circumstances, and the one the ICO can ask to see. A broker that wants one document to serve both purposes should build it to the DPIA standard.

The legal basis sits in two places: Article 35 of the UK GDPR and section 64 of the Data Protection Act 2018, which applies the same duty to law enforcement processing. Brokers are concerned with Article 35.

PIA or DPIA: what the terms mean — overview diagram

When a mortgage broker needs a DPIA

The general rule in Article 35(1) is that a DPIA is required where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of individuals. The assessment must be carried out before the processing begins. The ICO's guidance on when a DPIA is needed treats this as a screening exercise: you look for red flags, then examine the likelihood and severity of potential harm in more detail.

Screening questions for a broker

A broker cannot assume a DPIA is always required, and cannot assume it never is. The sensible approach is a short, written screening record for each new tool or process change. Questions to answer:

  1. Does the processing use new technology, such as automated reading of documents, automated cross-checks or tamper detection?
  2. Does it involve evaluating or scoring individuals, or building a profile of their finances?
  3. Is the volume of clients, and the volume of documents per client, large for the firm?
  4. Does it involve data that could cause serious harm if lost or misused, such as full bank statements, tax records and identity documents together?
  5. Does it involve vulnerable individuals, or applicants who cannot realistically object to the processing?
  6. Does it combine data from several sources, or share it with lenders and other third parties?

The ICO's research notes for this topic point out that processing involving new technologies, AI or large-scale profiling raises the likelihood of high risk. Automated document verification sits close to that territory, which is why many brokers treat a DPIA as the safer default for this kind of tool. Where the screening answer is genuinely uncertain, completing the DPIA is cheaper than defending a decision not to.

Small firms are not exempt

The ICO's advice for small organisations addresses the question directly: a small organisation needs a DPIA if its plans meet the same high-risk threshold. Size changes how much work the assessment takes. It does not change whether the duty applies.

Other triggers during the life of a system

A DPIA is not a one-off exercise to be filed away. The ICO treats it as a document that needs regular review, particularly when system configurations change, new risks appear or the nature of data collection is altered. For a brokerage, review triggers include:

  • adding a new document type, such as self-employed tax returns or foreign income evidence
  • adding a new feature that analyses documents rather than just storing them
  • changing who in the firm can see client files
  • changing supplier, hosting location or sub-processors
  • a data incident or a near miss

What the assessment must contain

Article 35(7) sets out four minimum elements, and the ICO's how-to guidance follows the same structure.

Required elementWhat a broker records
Systematic description of the processingWhich documents are collected, from whom, through which channel, where they are stored, who sees them, how long they are kept, and where they are sent
Necessity and proportionalityWhy each document type is needed for the mortgage advice and application, and why a less intrusive route would not work
Risks to individualsWhat could go wrong for the client: exposure of financial details, wrong flags that delay an application, identity fraud after a breach
Measures to address the risksAccess controls, encryption, retention rules, UK hosting, audit trails, staff training, supplier contract terms

Two points are often missed. First, the risks assessed are risks to the individuals whose data is processed, not risks to the brokerage. Commercial or regulatory risk to the firm is a separate exercise. Second, the DPIA should record the decision, including who signed it off and when, and any advice taken from the firm's data protection lead.

There is no single template

The ICO states that DPIAs are flexible and scalable and that no one template is mandatory. It publishes sample templates that a small brokerage can adapt to its own document workflow. A three-page assessment that covers the four elements honestly is stronger than a forty-page generic form that never mentions bank statements.

Six steps to complete a DPIA for document verification

The ICO's process runs from identifying the need for a DPIA through to recording outcomes and keeping the assessment under review. The version below applies that sequence to a broker adopting or reviewing a document collection and verification platform.

Step 1: identify the need

Complete the screening record described above. Date it and name the person who made the decision. If the answer is "no DPIA required", write down why.

Step 2: describe the processing

Map the data flow from the client's first upload to the submission to the lender. Include each document type, whether the client uploads by phone or desktop, who reviews, which automated checks run, how long files stay on the system, and what happens at deletion. If the mortgage process includes joint applicants, note how each applicant's data is separated. Process maps from your existing document approval workflow are a good starting point. Our guide to document approval controls that auditors can trace lists the checkpoints worth mapping.

Step 2: describe the processing — overview diagram

Step 3: consider consultation

Speak to the people affected or those who understand their position: advisers, case administrators, compliance staff and, where practical, a sample of clients. Ask the supplier for its security documentation and data handling description. Note the responses and what changed as a result.

Step 4: assess necessity and proportionality

For each document type, record the lawful basis and the reason it is needed. Test data minimisation: does the platform ask for six months of statements when the lender requires three? Does the document list adjust to the client's income type, or does every client upload everything? A list that builds itself from the client's payment type reduces over-collection by design.

Step 5: identify and assess the risks

Score each risk by likelihood and severity of harm to the client. Typical entries for a broker:

  • unauthorised access by a staff member who has no case-related need
  • documents sent to the wrong applicant or the wrong lender
  • data transferred or handled outside the UK
  • retention beyond the period the firm can justify
  • false positives in automated checks that wrongly suggest dishonesty
  • compromise of the client's login or upload link

Step 6: identify measures, sign off and keep it under review

For each risk, record the control, who owns it, and the residual risk. Record sign-off. Then diarise a review date and name the events that bring it forward. On access, the principle of tasks over job titles is worth building in: our piece on role based access control for UK brokers explains how to give each person only the access their task requires.

When the risk cannot be reduced

If the DPIA concludes that a high risk remains and the firm cannot mitigate it, the processing must not begin until the Information Commissioner's Office has been consulted. The ICO's guide to DPIAs sets out this prior consultation duty. Plan for timing: the ICO's usual response window is eight weeks, with a possible extension of a further six weeks for complex cases. For a brokerage this is rare, but it is the reason the assessment belongs at the start of procurement and not after go-live.

Suppliers, contracts and accountability

The second query brokers raise is how a data processing agreement fits with all this. The two documents do different jobs.

  • The DPIA is the broker's own risk assessment of the processing.
  • The data processing agreement is the contract between the broker as controller and the platform provider as processor.

Under Article 28, the ICO's guidance on contract contents says the contract must set out the subject matter and duration of the processing, its nature and purpose, the type of personal data and categories of data subject, and the controller's obligations and rights. It must also cover processing only on documented instructions, a duty of confidence, security measures, sub-processor rules, support for data subject rights, end-of-contract provisions, and audits and inspections.

The contract terms feed the DPIA. If the processor agreement commits the supplier to UK data residency and to named sub-processors, the DPIA can cite those terms as mitigations. If the contract is silent on deletion at the end of the relationship, the DPIA should record it as a gap.

Cloud assessment does not replace a DPIA

The National Cyber Security Centre's cloud security principles help a buyer judge how well a service is designed, built and operated. They are a useful input to Step 5. They do not discharge the legal duty: brokers remain accountable for their data when it sits on third-party infrastructure. The NCSC's page on using SaaS securely starts from the same place: understand who will use the application, how sensitive its data is and which regulations apply.

DPIA and legitimate interests assessment

Brokers who rely on legitimate interests for some processing will also have a legitimate interests assessment. The ICO treats the two as separate. The LIA justifies a lawful basis, while the DPIA is a deeper systematic assessment of risk. If an LIA turns up potential high risks, that can be the trigger for a full DPIA, as the ICO's legitimate interests guidance explains.

Our view: build privacy into document handling

We build Casefile for UK mortgage brokers, and the same pattern appears in the firms we speak to. The DPIA is treated as a form to complete after the tool is chosen. By then the decisions that matter, such as where data is hosted, who can see it and how long it stays, have already been made.

Our position is that the assessment works best when it runs alongside the choice of system. That is what the ICO's guidance on starting early recommends, and it is also cheaper: reworking a process after launch costs more than choosing the right design at the start.

Three design choices make the assessment shorter and the answers stronger:

  1. UK-only data residency and no manual or offshore handling. The processing description is simpler when documents stay in one jurisdiction and are not read by people outside the firm's control.
  2. Document lists built from the client's payment type. An employed client and a self-employed client are asked for different evidence, which supports data minimisation.
  3. Clear audit trails. When the DPIA asks who accessed what and when, the answer is a record, not a recollection.

Automated cross-checks also reduce a specific risk to clients. When undeclared commitments or mismatched wage deposits are flagged inside the brokerage, the adviser can resolve them with the client before anything reaches a lender. That keeps unnecessary queries, and unnecessary re-sharing of documents, to a minimum. Our data security page describes how Casefile handles client documents, and brokers can use it as input to Step 2 and Step 6.

None of this replaces the broker's own assessment. The controller decides, signs and owns the DPIA. A good supplier makes that task easier by giving plain answers to specific questions.

— Darren

Questions to put to any document platform supplier

Use this list as the consultation input for Step 3. Record the answers in the DPIA.

  1. Where are client documents stored and processed, and is any handling done outside the UK?
  2. Does anyone at the supplier read client documents manually, and under what conditions?
  3. Which sub-processors are used, and how will you be told about changes?
  4. How are access rights set, and can they follow tasks rather than job titles?
  5. What audit trail exists for views, downloads, approvals and deletions?
  6. What are the retention and deletion terms during the contract and at its end?
  7. How are incidents notified to the broker, and within what time?
  8. How are automated flags explained to the adviser, so a person makes the final decision?
  9. Will the supplier support audits and inspections in line with Article 28?

Where Casefile fits

Casefile is a cloud platform for UK mortgage brokers that automates the collection of client documents, cross-checks bank statements, payslips, tax forms, ID and utility bills, flags discrepancies and undeclared commitments, and manages approval queues under the brokerage's own branding. Data is held in the UK, and applicant privacy is part of the design. Brokers preparing a DPIA can start with the Casefile data security overview or look at the platform on the Casefile website.

Common mistakes in broker DPIAs

  • Writing it after go-live. Article 35 requires the assessment before processing starts.
  • Copying a generic template unchanged. The description should name your document types and your workflow.
  • Assessing the supplier instead of the processing. A supplier's security certificate is evidence for a control. It is not an assessment of your use.
  • Ignoring false positives. Automated flags can be wrong. Record how an adviser reviews them before any decision about a client.
  • No review date. A DPIA with no owner and no next review is a record of a past intention.
  • Skipping the tax data. Tax returns carry a lot of detail about a person's finances. Our practical guide to tax return verification shows what is needed and what is not.

FAQ

What is the difference between a DPIA and a PIA?

"PIA" is the older and wider term for any privacy risk review. "DPIA" is the term defined in Article 35 of the UK GDPR, with minimum content and a legal trigger. In day-to-day use, UK guidance and most firms treat them as the same exercise.

Does a small mortgage brokerage need a DPIA?

The test is the same for every organisation: is the processing likely to result in a high risk to individuals? The ICO's advice for small organisations applies that test to firms of any size. A small firm adopting a new document verification tool should complete a written screening and, where risk is likely to be high or unclear, a DPIA.

How long does a DPIA take?

There is no fixed duration, because the work scales with the processing. A single tool with a clear data flow can be assessed in a few working sessions, and the ICO says the exercise is flexible and scalable. The ICO's prior consultation process, needed only where high risk remains, is a separate matter and usually takes eight weeks or more.

Is a data processing agreement the same as a DPIA?

No. The data processing agreement is the contract with the supplier required by Article 28. The DPIA is the broker's own assessment of risk to individuals. The contract terms can be cited as measures in the DPIA, but one does not replace the other.

How often should a DPIA be reviewed?

Review it whenever the system, the data collected, the users or the supplier arrangements change, and on a set date even if nothing has changed. The ICO describes the DPIA as an ongoing process, not a document to be filed away.

Sources

This article was generated with AI, and whilst it is our expectation that the article is accurate, it should not be taken as advice.