Commercial and data protection questions, answered

A data processing agreement (DPA) is the written contract required whenever a controller lets a processor handle personal data for them. Under Article 28 of the UK GDPR and the EU GDPR it is a legal requirement, not best practice. If you are a SaaS business, your customers are usually the controller and you are the processor, so the DPA sits underneath your main agreement and describes what you are allowed to do with their data.

A compliant DPA has to cover a fixed list: subject matter and duration, nature and purpose of processing, types of personal data and categories of data subject, and then the eight processor obligations in Article 28(3). Those are documented instructions only, confidentiality of staff, Article 32 security measures, rules on sub-processors, assistance with data subject rights, assistance with breach notification and DPIAs, deletion or return at the end, and audit and information rights.

A data sharing agreement is a different animal. That is controller to controller, where each side decides its own purposes. It is not mandated by statute, but the ICO’s data sharing code of practice expects one, and it is the document that saves you when a regulator or a customer asks who was responsible for what. Getting the two confused is the single most common mistake we see in signed paperwork.

GDPR compliance for a growing business comes down to a handful of things you can evidence: a lawful basis for each processing activity, a record of processing under Article 30, transparency through your privacy notice, security appropriate to the risk under Article 32, a route for data subject rights, a breach process that can hit 72 hours, and contracts with everyone who touches the data for you.

Data protection and data privacy are used interchangeably in conversation, but they are not quite the same. Privacy is the underlying right, the expectation that information about a person is not used in ways they would not expect. Data protection is the legal machinery that implements it: lawful bases, rights, duties, and the accountability principle that says you must be able to show your working.

Cross-border transfers are where UK and EU businesses most often get caught. Sending personal data outside the UK or EEA needs an adequacy decision, or a transfer mechanism plus a transfer risk assessment. In the UK that is the IDTA or the UK Addendum to the EU SCCs. In the EU it is the 2021 SCCs. Other regimes have their own rules: China’s PIPL requires a security assessment, standard contract filing or certification depending on volume and sensitivity, and Singapore’s PDPA requires comparable protection by contract or other means.

A privacy notice and a set of terms of service do different jobs. The privacy notice is a transparency obligation under Articles 13 and 14: what you collect, why, on what basis, who you share it with, how long you keep it, and what rights people have. The terms of service are the commercial contract: licence scope, payment, uptime, support, liability, termination and what happens to data at the end.

Generators and AI-written terms are attractive because they are instant. The problem is that they describe a generic product. They will not know that you have a free tier with different data handling, that you train models on aggregated usage, that your enterprise tier includes a private instance, or that you resell a third party component whose licence flows down to your customer. Terms that do not describe your actual product are worse than no terms, because they define your obligations in ways you cannot meet.

For SaaS specifically, the set is usually four documents: the terms of service or subscription agreement, the acceptable use policy, the DPA, and the service level commitment. Splitting them out matters, because it lets you change the ones that move often without reopening the commercial deal.

A SaaS agreement is not a software licence. A licence grants rights to a copy of software; a SaaS agreement grants access to a service you continue to run. That difference drives everything downstream: uptime rather than delivery, subscription rather than perpetual fee, your infrastructure rather than the customer’s, and data that lives with you rather than with them.

The common structure is a master agreement plus order forms. The master carries the legal terms that rarely change, and each order form carries the commercial specifics: users, tier, term, price, start date. That structure is worth building early, because it is what lets you close the second and third deal with a customer without a fresh negotiation each time.

Service levels deserve more care than they usually get. An SLA with a 99.9 percent target, service credits as the sole remedy, and no exclusion for scheduled maintenance is a very different commitment from one with maintenance windows, a measurement method, and a chronic failure termination right. Both look similar on a page. Only one of them is survivable at scale.

Pricing is a commercial decision, but it lands in the contract. Per-seat pricing needs a definition of user and a rule for what happens when the count changes mid-term. Usage-based pricing needs a metering definition, a source of truth for the count, and a dispute process for when the customer’s number differs from yours. Tiered pricing needs to say what happens when a customer exceeds a tier: automatic upgrade, overage rate, or throttle.

Renewals are the other half. If you want to raise prices, the contract has to give you the mechanism: a defined uplift, a notice period, and a renewal that does not silently lock last year’s rate in perpetuity. Auto-renewal clauses are useful but need to be clearly presented, especially in any consumer or small business context where fairness rules bite.

None of this requires a lawyer to design your pricing. It requires someone to read the pricing page and the contract in the same sitting, and to notice where the page promises something the contract does not deliver, or the contract charges for something the page said was included.

Templates are genuinely useful. They stop you forgetting a clause, they give you standard language for the parts nobody negotiates, and they make small deals fast. If you are choosing between an unsigned handshake and a decent template, use the template.

What a template cannot do is make the decisions. Every contract has a small number of clauses where value actually moves: liability cap and carve-outs, IP ownership, indemnities, termination rights, payment and renewal. A template fills those with a neutral default that suits neither side particularly. Whether that default is acceptable depends on your deal size, your insurance, and what you can afford to lose.

The practical middle ground is a template set that has been adjusted once, properly, for your business, plus a short playbook saying which clauses your team can change without asking and which always come to legal. That is usually a few days of work and it removes most of the ongoing legal spend that small businesses resent.

Contract drafting is the process of turning a commercial arrangement into terms that will still make sense to a stranger in three years. The writing is the last part. Most of the work is finding out what actually happens: who does what, when money moves, what the client thinks they are buying, what happens when the relationship ends, and which failures would genuinely hurt.

A drafting engagement usually runs: a short call to map the deal, a first draft with the assumptions flagged, one round of comments, and a final version plus a plain English note on the clauses that matter. For a standard services or SaaS agreement, that is days rather than weeks.

Cost varies by scope and by whether you are buying a bespoke document or a reusable one. A one-off bespoke agreement for a single deal is the expensive way to buy contracts. A reusable set with a playbook costs more up front and less every month afterwards.

A contract review should produce three things: a list of what is unacceptable, a list of what is negotiable, and a plain statement of the risk if you sign as-is. A review that returns forty tracked changes and no view is not much use to a business trying to close a deal this quarter.

Before signing anything, the fastest useful check is the exit and the money: how does this end, what happens to data and work in progress, what does it cost to leave, and what is the maximum I can be liable for. Those four answers catch most of the real damage. After that, look at IP, indemnities and anything that lets the other side change the deal unilaterally.

Yes, you can change a contract before signing. Nothing is binding until both sides agree, and a proposed contract is a proposal. Once signed, changes need a variation, usually in writing and signed, because most commercial contracts contain a clause requiring exactly that. Negotiation after signature is possible but you have lost your leverage.

A fractional general counsel is an experienced commercial lawyer who works with you on an ongoing, part-time basis, inside the business rather than at arm’s length. The difference from a law firm is not price, it is position. A firm answers the question you send. Embedded counsel sees the deal forming, the pricing changing, the customer pushing back, and gets to the risk before it is baked in.

That model suits companies at a specific stage: enough deal flow that ad hoc legal spend is unpredictable, not enough to justify a full-time hire. Typically that is a scaling technology or SaaS business signing enterprise customers, answering security reviews, and finding that contracts have become a bottleneck in the sales cycle.

Eliga works this way with technology and SaaS businesses: fractional legal and contract support, on an ongoing arrangement, sitting alongside the commercial team. The practical output is usually a contract set, a negotiation playbook, and someone who answers in hours rather than days.

There is no general rule making an AI system responsible for anything, because a system is not a legal person. Liability lands on the humans and companies in the chain: the developer, the deployer, the supplier who put it in a product, and the customer who used it. Which of those pays is decided by contract first, then by ordinary negligence and product liability rules, then by regulation.

In the EU, the AI Act takes a risk-based approach with prohibitions on certain practices, transparency duties for general purpose models, and a heavier set of obligations for high risk uses, phased in over several years from its 2024 entry into force. Timing has been the subject of live debate and proposed amendment, so the safest position is to check the current phasing rather than rely on a date quoted in an article. The proposed AI Liability Directive was later dropped from the Commission’s work programme, which leaves the revised Product Liability Directive, which does extend to software, plus national tort and contract law. The UK has taken a principles-based route through existing regulators rather than a single AI statute.

For most businesses the practical work is not regulatory. It is: an AI use policy staff actually follow, a record of which AI tools touch which data, vendor due diligence for AI suppliers, contract clauses on training data and output ownership, and a DPIA where the processing is high risk. Those five things answer almost every question a customer or regulator asks.

Once you start selling to larger organisations, you enter their vendor risk process. That means a security questionnaire, evidence of your controls, your DPA, your sub-processor list, your incident process, and often proof of certification. Failing that process is a common and avoidable reason deals stall late.

The frameworks people reference do different things. ISO 27001 certifies an information security management system. SOC 2 is a US attestation report on controls against trust services criteria. HIPAA is a US healthcare regime that reaches you through business associate agreements if you touch protected health information. SOX is financial reporting control, relevant to you mainly as a supplier to listed companies. NIST publishes frameworks rather than certifications. None of them are GDPR, and having one does not give you another.

Running due diligence in the other direction matters just as much. Before you take on a supplier who touches customer data, you want to know their security posture, their sub-processors, their location, their incident notification commitment, and what happens to your data when the relationship ends. That is your Article 28 obligation as well as good practice.

Early stage companies need less legal work than they fear and different work than they expect. The set that actually matters: the right corporate structure, a founders agreement with vesting, IP assigned into the company from every founder and contractor, a workable NDA, standard customer terms, and a privacy notice if you handle personal data.

The founders agreement is the one people regret skipping. Equity split, vesting and cliff, roles and decision rights, what happens if someone leaves early, and IP assignment. Agreeing it while everyone is friendly costs a conversation. Agreeing it after a founder leaves costs the company.

IP assignment is the other quiet killer. Work created by a contractor belongs to the contractor unless the contract assigns it. Investors and acquirers check this, and it is expensive to fix retrospectively because you have to find people who may no longer be reachable or friendly.

Contract lifecycle management covers request, drafting, approval, signature, storage, obligation tracking and renewal. Businesses usually feel the pain at two points: nobody can find the signed version, and a renewal or notice deadline passes unnoticed.

You do not need a platform to fix that. A single repository, a naming convention, a spreadsheet of key dates and obligations, and a rule that nothing is signed without going through one route will solve it for most companies under a hundred contracts. Buy software when the manual process is genuinely straining, not before.

Approval workflow is the other half. A simple matrix of who can approve what, by value and by clause, removes most of the delay in a sales cycle. It also stops the situation where a salesperson agrees to unlimited liability by email because nobody told them they could not.

Liability is limited by a cap, usually expressed as a multiple of fees paid in a period, plus a set of exclusions for indirect and consequential loss. Around that sit carve-outs where liability is unlimited or separately capped: typically confidentiality, data protection, IP infringement and, unavoidably, death or personal injury caused by negligence and fraud, which cannot be excluded under English law.

Under UCTA 1977, exclusions in standard terms and in consumer contracts are subject to a reasonableness test, so an aggressive cap in your own boilerplate is not automatically enforceable. A cap that bears a sensible relationship to contract value and to your insurance is far more likely to hold up than one that leaves the other side with no meaningful remedy.

Software suppliers should hold professional indemnity cover, and buyers increasingly ask for cyber cover too. Two practical points: check that your cap is not lower than the loss types your insurer expects you to accept, and check that your contract does not commit you to something your policy excludes. An indemnity given without checking your cover is an uninsured promise.

A software licence agreement grants permission to use software on stated terms. The core is the grant: what may be used, by whom, how many, where, for how long, and for what purpose. Then the restrictions, then the ownership statement making clear that a licence is not a transfer, then support and maintenance if any, then warranties and liability.

Perpetual, subscription and open source licences behave differently. Perpetual grants ongoing use rights for a one-off fee, usually with paid maintenance separate. Subscription rights end when payment ends. Open source licences carry obligations, and permissive licences such as MIT and Apache 2.0 behave very differently from copyleft licences such as the GPL, which can force disclosure of your own source in some distribution scenarios.

For a services or development business, the IP question is simpler and more urgent: who owns what you built. In the UK, work created by an employee in the course of employment generally belongs to the employer, but work created by a contractor belongs to the contractor unless assigned in writing. If you have never checked your contractor agreements for an assignment clause, check them this week.

Employment contracts, consultancy agreements and contractor terms cover overlapping ground with very different consequences. The label on the document does not decide status. Courts and HMRC look at the reality: control over how work is done, personal service versus a right of substitution, and mutuality of obligation.

For businesses engaging contractors in the UK, the off-payroll working rules matter. Where the client is a medium or large private sector organisation, responsibility for determining status sits with the client, and getting it wrong carries tax exposure. Small companies fall outside that, but status still matters for employment rights claims.

For contract review on the individual side, the clauses that carry the most value are notice, restrictive covenants, bonus and commission terms, IP, and post-termination restrictions. Restrictive covenants are enforceable only so far as they are reasonable to protect a legitimate business interest, which means the drafting has to be proportionate to be worth anything.

An ongoing service contract covers work that continues rather than a one-off delivery: maintenance, support, managed services, retained work. The clauses that matter most are the ones people leave out: the notice period to end it, how the price changes over time, what happens to work in progress on termination, and what the service actually includes versus what is chargeable extra.

For B2B contracts generally, the useful discipline is to write down what happens when things go normally and what happens when they do not. Most contracts are good at the first and vague about the second, which is why disputes hinge on termination, payment and scope rather than on the substance of the work.

Small businesses often operate on a purchase order or an email chain. That is a contract, legally, but it is one where the terms are whatever can be pieced together afterwards. A one page standard terms document attached to every quote fixes this cheaply.