Who should approve an LIA: business owner accountability, privacy challenge, escalation for higher-risk processing and a documented authority matrix.
Topics: LIA, Legitimate Interests, Governance, Accountability
A Legitimate Interests Assessment can look straightforward until the approval field is left blank. The question of who should approve an LIA is not a matter of choosing the most senior person available. It is about assigning accountable decision-making to the people who understand the processing purpose, can assess operational need, and have access to appropriate privacy and legal challenge.
Under the UK GDPR and GDPR, there is no prescribed job title that must sign off an LIA. The controller remains accountable for demonstrating that its reliance on legitimate interests is justified. That means organisations need a documented approval model that reflects the nature, scale and risk of the processing, rather than an informal process where assessments are completed and filed without meaningful review.
Who should approve an LIA?
In most organisations, the appropriate approver is a designated business owner with accountability for the processing activity, following review by the privacy function. The business owner is best placed to confirm that the proposed purpose is real, specific and necessary. Privacy, legal, security and risk stakeholders then provide the independent challenge needed to test whether legitimate interests is an appropriate lawful basis.
This distinction matters. The person asking to use data should not be the only person deciding whether the processing is necessary and proportionate. Equally, a privacy team should not become the default owner of every operational decision. Its role is to set the assessment standard, test the reasoning, identify risk, and ensure the record can withstand scrutiny.
For lower-risk, well-established processing, a privacy lead or delegated privacy reviewer may approve the LIA under a documented authority matrix. For higher-risk or novel processing, approval should be escalated to a senior accountable owner, such as the relevant business executive, General Counsel, Chief Privacy Officer, or a governance committee.
The controller owns the decision
An LIA is a controller accountability record. It documents why the organisation considers its interests legitimate, why the processing is necessary, and why those interests are not overridden by the rights and freedoms of affected individuals.
The accountable business owner should therefore confirm three practical points. First, that the stated purpose is accurate and cannot reasonably be achieved by a less intrusive method. Second, that the proposed data use matches the operational design, including data sources, recipients, retention and any profiling. Third, that the team will implement the safeguards and mitigations recorded in the assessment.
This is particularly relevant when a programme operates across several jurisdictions. A central privacy team may define the LIA methodology, but local business owners may need to verify customer expectations, employment context, market practices, and the operational reality of a specific processing activity. A single global approval can be efficient, but only where it genuinely reflects local conditions.
The DPO should advise, not automatically approve
A Data Protection Officer has an essential role in an LIA process, but should not automatically be positioned as the final decision-maker. The DPO advises on data protection obligations, monitors compliance and provides independent guidance. Making the DPO the business approver for every LIA can blur that independent oversight role.
The DPO or privacy office should normally review whether the assessment properly addresses the three-part legitimate interests test. They should challenge vague purposes, unsupported necessity claims and balancing tests that rely on assumptions about reasonable expectations. They should also identify where an LIA is insufficient and a Data Protection Impact Assessment may be required.
There are exceptions. In lean organisations, the DPO may hold delegated approval authority for routine, low-risk processing where governance policies clearly define that delegation. Even then, the business owner should remain accountable for factual accuracy and implementation. The approval record should show both roles rather than treating privacy sign-off as a substitute for operational ownership.
Use risk to determine the approval route
Not every LIA needs executive committee review. Applying the same escalation path to a limited operational contact list and a large-scale behavioural analytics programme creates delays without improving control. The better approach is a risk-based approval matrix.
Routine processing may be approved by the business owner and privacy reviewer where the data is not sensitive, the purpose is expected, safeguards are established, and the assessment follows a previously approved pattern. Examples may include proportionate business-to-business contact management or security monitoring with defined access controls.
Enhanced review is appropriate where processing involves employees, children, location data, extensive profiling, large volumes of customer data, new technology, data matching, or sharing with multiple third parties. These factors do not automatically prevent reliance on legitimate interests, but they increase the likelihood that individuals' interests or expectations could outweigh the controller's purpose.
Senior or committee approval should be considered where the processing is high impact, strategically significant, novel, likely to attract stakeholder concern, or connected to a wider transformation programme. Where an LIA identifies high residual risk that cannot be reduced, the organisation should reassess the lawful basis and determine whether a DPIA, further safeguards, or a different processing design is necessary.
Separate review from approval
A defensible LIA workflow distinguishes contributors, reviewers and approvers. Without this separation, organisations often have records showing several names but no evidence that anyone accepted responsibility for the decision.
The business team should complete the factual input: purpose, data categories, affected individuals, system use, recipients, retention and expected benefit. Privacy or legal should review the legal reasoning and challenge the balancing test. Security may verify technical safeguards, while procurement or vendor risk teams may confirm the position of service providers and data-sharing arrangements.
The approver should then accept the final assessment, including any conditions. For example, approval may be conditional on reducing retention, providing clearer privacy information, excluding particular data categories, conducting a DPIA, or introducing a human review step before automated action. Conditions should become tracked actions, not narrative notes that disappear after sign-off.
Define when an approved LIA must be revisited
Approval is not permanent. An LIA reflects a specific processing design at a point in time. If that design changes, the organisation must be able to identify whether the original balancing test still holds.
A review should be triggered when the purpose expands, a new data source is introduced, profiling becomes more granular, data is shared with new recipients, retention changes, or a supplier begins using data in a different way. Complaints, objections, incidents and changes in regulatory guidance may also reveal that the assumptions in the original assessment need re-examination.
This is where a central operating system is more reliable than folders and spreadsheets. A structured LIA workflow can assign owners, preserve approval history, connect safeguards to actions, and trigger reassessment when related processing records, vendor reviews, incidents or DPIAs change. Privacy360 supports this model by placing Legitimate Interests Assessments alongside ROPA, DPIAs, third-party risk and evidence collection in one governed environment.
Make the approval evidence useful
A signed LIA is not defensible merely because it has a date and a name. The record should make the decision intelligible to someone who was not involved in the original discussion. That requires a clear purpose statement, an explanation of necessity, a realistic account of possible impact on individuals, and evidence of safeguards.
The approval entry should identify the approver's role, decision date, scope, conditions and next review date. If privacy or legal advice was not followed, record the rationale and the senior authority that accepted the residual risk. That is not about creating unnecessary paperwork. It is how an organisation shows that disagreement was recognised, assessed and resolved through an accountable route.
Build approval into operational governance
The strongest answer to who should approve an LIA is not a single title. It is a controlled decision model: a business owner accountable for the processing, privacy oversight that remains sufficiently independent, and escalation that increases with risk and impact.
Set that model before the next urgent project arrives. When the approval route, evidence standard and review triggers are already embedded in the workflow, teams can move quickly without turning legitimate interests into an unsupported assumption.