Atlas Paragon Digital living magazine
Money & Growth

When to stop adding tools: the legal cost of one more integration

September 10, 2026 ·
A tall precarious tower built from many small blank paper slips on a desk, each approval minor, the accumulated stack of tools unmistakably large.

Marketing and operations stacks grow because every individual decision is defensible. Forty pounds a month for a scheduling tool, twenty for a form builder, a free tier for heatmaps. Nobody approves a bloated stack. They approve eleven small things over two years. The reason to stop earlier than feels necessary is that the invoice is the smallest part of what each tool costs you, and the rest of the bill is legal rather than financial.

Every tool that touches customer data is a processor

If a supplier processes personal data on your instructions, they are a processor and you are the controller. The ICO is blunt about the consequence: whenever a controller uses a processor, there must be a written contract or other legally binding act in place. Not a preference. A condition of using the tool lawfully.

That contract has required contents. It must set out the subject matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subject, and your own obligations and rights. On top of those details, Article 28(3) requires specific clauses covering eight things: processing only on your documented instructions, a duty of confidence, security measures meeting Article 32, rules on sub-processors, assistance with data subject rights, assistance with breach notification and impact assessments, what happens to the data at the end of the contract, and submission to audits and inspections.

The work also starts before you sign. Article 28(1) says you may only use a processor that provides sufficient guarantees, and the ICO puts the assessment on you, in particular their expert knowledge, resources and reliability. It then keeps going after you sign, because the accountability principle expects you to monitor the processor’s compliance on an ongoing basis rather than filing the contract and forgetting it.

Read that as a unit cost. Per tool, you owe a due diligence assessment, a compliant contract, an entry in your processing records, and a monitoring habit. Eleven tools is eleven of those, and the tool costing four pounds a month carries the same obligations as the one costing four hundred.

The four standing legal obligations each tool carries under UK GDPR Article 28, and why eleven tools means forty-four of them rather than eleven.
Four standing obligations, incurred once per tool.

The part that scales badly: sub-processors

Your processor almost certainly uses its own processors, for hosting, email delivery, error tracking, support ticketing. A processor cannot engage a sub-processor without your prior specific or general written authorisation, and when it does, it must impose terms offering an equivalent level of protection to those in your contract. The processor stays liable to you for its sub-processors, which is some comfort, but it does not remove your position as controller.

This is the mechanism that turns a modest stack into something nobody in the company can describe. Each new tool adds not one supplier but a subtree, and the practical test of whether your stack is too large is simple: can you produce a current list of every organisation that holds your customers’ personal data, including the ones your suppliers chose? If not, the stack is already past the point where you can meet the accountability obligations you have, regardless of how reasonable each addition looked.

The tracking layer changed in February 2026

This is the part most stack advice has not caught up with. The Data (Use and Access) Act 2025 rewrote the consent rules in regulation 6 of PECR, and the changes took effect on 5 February 2026. There is now a statistical purposes exception, and the ICO’s guidance sets out how narrow it is.

You do not need consent to store or access information on a device where the sole purpose is collecting statistical information about how your service is used with a view to improving it. That covers how many people access the service, what they access and how long for. The ICO’s framing is the useful one to remember: the exception is about how your service is used, not about who uses it. It is not available for identifying, tracking or monitoring people, and it does not extend to online advertising.

Three conditions come attached. You must give clear information and a simple, free way to object. Your analytics provider must be a processor rather than a joint controller. And the provider may only use the information to deliver your purpose, without linking it to information from other services. A tool that quietly enriches your visitor data against its own graph is outside the exception no matter what its marketing page says about privacy.

Advertising did not change. The ICO’s May 2026 advice to government proposes permitting some lower-risk advertising purposes without consent under a first-party framework, while keeping consent for intrusive tracking and profiling across services. The ICO is explicit that nothing has changed at this stage and the existing rules still apply. Planning a stack around a relaxation that is currently a policy proposal would be a mistake.

Worth knowing alongside it: the separate strictly necessary exemption covers a short, practical list. Securing terminal equipment, preventing or detecting fraud, preventing or detecting technical faults, authenticating the user, and recording information or selections the user makes. Convenience for you is not on that list.

Enforcement also got heavier rather than lighter. The DUAA brought PECR enforcement under the Data Protection Act 2018 toolkit, with information notices, assessment notices, enforcement notices and penalty notices, and placed regulation 6 breaches in the higher penalty band, which is the one with a ceiling of £17.5 million or 4% of worldwide turnover. For a small company the realistic exposure is an enforcement notice and the cost of rebuilding your consent layer under a deadline, not a headline fine, but the direction is unambiguous.

A stop rule you can actually apply

The question is not whether a tool is useful. Almost all of them are somewhat useful. The question is whether it clears the overhead it creates.

  1. Name the decision it changes. If you cannot say what you will do differently depending on what the tool shows you, it is reporting, not instrumentation, and you are paying compliance overhead for reassurance.
  2. Check whether something you already pay for does it. Overlapping tools are the most common finding in any stack audit, and the second tool carries a full set of obligations to deliver a feature you already own.
  3. Ask whether it touches personal data. If yes, price in the contract, the records entry and the monitoring, then decide.
  4. Ask whether it writes to the visitor’s device. If yes, work out which exception applies before installing the tag, because retrofitting consent is far more expensive than not needing it.
  5. Read the sub-processor list. If the supplier will not publish one, that is information about your ability to answer a subject access request later.
  6. Set a removal date at the point of adoption. Tools are almost never removed because nobody is responsible for removing them.

What a five-person team actually needs

Starting from nothing, the defensible minimum is small: somewhere to keep customer records, email, a way to take payments, a password manager, and first-party analytics configured to stay inside the statistical purposes exception. That is a stack you can document completely, contract for properly, and describe to a regulator in one sitting.

Everything after that should be added against a named problem and removed when the problem goes. The failure pattern is not choosing bad tools. It is adding good tools faster than you can maintain the paperwork that makes them lawful, and then discovering the gap at the worst possible moment, which is when somebody asks for their data or a supplier has a breach.

Two limits worth stating. All of the above is the UK position under UK GDPR and PECR as amended by the DUAA; if you have an EU establishment or offer services to people in the EU, the EU rules apply to that processing separately and the February 2026 analytics exception is a UK change that does not transfer. And this is a description of published regulatory guidance rather than legal advice, so for anything consequential, particularly international transfers or a breach in progress, get a view from someone who will put their name to it.