Mason is a legal consultant at Sprintlaw. Having founded his own media production company, Mason has experience in both film and music industries. He is also currently working towards his law degree at Macquarie University.
What Should A Research And Development Agreement Include?
- 1) Scope, Deliverables, And Milestones
- 2) Fees, Funding, And Project Costs
- 3) Background IP vs Project IP (And Who Owns The Results)
- 4) Confidentiality And Information Security
- 5) Data Protection And Data Sharing (If Personal Data Is Involved)
- 6) Publication Rights (Common In University And Research Partnerships)
- 7) Warranties, Liability, And Risk Allocation
- 8) Term, Termination, And "What Happens Next?"
- Key Takeaways
If you're building a new product, testing a prototype, or collaborating with a university or specialist supplier, the "exciting" part is the innovation.
The part that can quietly cause the biggest headaches later is who owns what, who can use what, and what happens if things go wrong.
That's exactly what a Research and Development (R&D) Agreement is for. It sets out the ground rules for an R&D project so you can move fast and stay protected from day one.
What Is A Research And Development Agreement?
A Research and Development Agreement (often called an "R&D Agreement") is a contract that sets out the terms on which two or more parties will collaborate on an R&D project.
In plain English: it's the document that answers the practical questions you'll wish you'd clarified once the project is underway, such as:
- What exactly are we developing (and what is "out of scope")?
- Who is paying for what, and when?
- Who owns the intellectual property (IP) created during the project?
- What happens to existing IP each party brings in?
- How will confidential information be shared and protected?
- What happens if the project is delayed, fails, or needs to end early?
- Can either party publish the results (and when)?
- Who is liable if something causes loss or a third-party claim?
R&D Agreements are common in the UK across:
- software and AI development
- life sciences and medical devices
- manufacturing and engineering
- food and cosmetics formulation
- clean tech and energy projects
- university spin-outs and grant-funded collaborations
Depending on your project, the agreement might be a standalone contract, or it may sit alongside other documents like a Heads of Agreement (if you're still aligning on the commercial deal) or a longer set of commercial terms.
Why Is An R&D Agreement Different From A Normal Services Contract?
An ordinary services agreement is usually about delivering a known output (for example, building a website to a clear specification).
R&D is different because the outcome can be uncertain. You might not know whether the research will work, whether the prototype will be viable, or what the final solution will look like.
That uncertainty creates legal risk - especially around IP ownership, scope drift, confidentiality, and "what happens next" if the collaboration produces something valuable.
If you want a tailored document for this kind of collaboration, a dedicated Research And Development Agreement is usually the cleanest and most protective approach.
When Do You Need An R&D Agreement (And When Is It Overkill)?
You don't need a heavy contract for every conversation about ideas. But you do want something in place once you move from "early discussion" to "let's actually build and test this".
You'll Usually Need An R&D Agreement If:
- You're co-developing something new (product, software, process, formulation, device) with another party.
- IP could be created during the project (patentable inventions, source code, designs, datasets, documentation, know-how).
- One party is contributing critical inputs (specialist know-how, lab access, proprietary tech, materials, data, algorithms).
- You're working with a university or research body (publication rights and background IP issues come up quickly).
- You'll share confidential information that could be commercially damaging if leaked.
- There's funding involved, including grants, investor money, or milestone-based payments.
- There's a regulatory angle (e.g. healthcare, biotech, consumer products), where documentation and responsibilities matter.
It Might Be Overkill If:
- you're just having a preliminary meeting and not sharing anything sensitive (or you can keep it high-level)
- you're buying a standard, off-the-shelf product with no customisation
- the other party is simply providing ordinary services with no expectation of creating new IP (and a standard service agreement covers it)
That said, many disputes start with "we thought it was just a quick pilot" - and then the pilot turns into the foundation of the commercial product.
As a rule of thumb, if you'd be upset to lose control of the output (or if you'd be worried the other party could reuse it for a competitor), it's time to formalise the arrangement.
What Should A Research And Development Agreement Include?
Every R&D project is different, but the same building blocks come up again and again. The key is getting them drafted in a way that fits how you'll actually work together - not in a generic, "template" way.
1) Scope, Deliverables, And Milestones
This is where you clearly describe:
- the project objectives (what success looks like)
- the activities included (research, experiments, prototyping, testing, iteration)
- deliverables (reports, prototypes, code commits, test results, technical documents)
- milestones, timelines, and dependencies
- change control (what happens if the scope needs to change)
Without a solid scope section, scope creep becomes a legal problem, not just a project management problem.
2) Fees, Funding, And Project Costs
R&D costs can move around - materials cost more than expected, testing expands, timelines extend. Your agreement should cover:
- fixed fees vs time-and-materials
- payment milestones
- reimbursable expenses (and what approvals are needed)
- what happens if the project needs extra work
- who owns equipment or materials bought for the project
If there's grant funding or third-party funding, you'll also want to ensure the contract aligns with the conditions of that funding (including reporting requirements and IP conditions).
3) Background IP vs Project IP (And Who Owns The Results)
This is often the most important part.
In an R&D collaboration, each party typically brings something to the table (existing code, designs, methods, know-how). That is usually called "Background IP". The new stuff created during the project is often called "Foreground IP" (or "Project IP").
Your agreement should be very clear about:
- what background IP each party retains (and what licences are granted to use it during the project)
- who will own the project IP created during the collaboration
- whether ownership depends on who created it (sole ownership) or whether it's jointly owned
- what "joint ownership" means in practice (including who can exploit it, who can license it, and whether consent is needed)
- whether there's an obligation to assign IP to one party, and what assistance is required to perfect that ownership (signing documents, patent filings, etc.)
If your commercial plan relies on owning the output (for example, to raise investment, license the tech, or sell the business), you'll usually want tight IP assignment language, potentially backed up by an IP Assignment approach where appropriate.
4) Confidentiality And Information Security
R&D requires sharing sensitive information: product roadmaps, formulas, prototypes, source code, datasets, customer insights, or experimental results.
Your agreement should cover:
- what counts as confidential information
- how it can be used (usually "only for the project")
- who can access it (including subcontractors)
- minimum security standards (especially where data is involved)
- how long confidentiality lasts (often several years, sometimes longer)
Sometimes, you'll use a separate Non-Disclosure Agreement early on, and then include confidentiality clauses within the R&D Agreement once the project is formalised.
5) Data Protection And Data Sharing (If Personal Data Is Involved)
If your project uses personal data (for example, user testing data, patient data, employee data, or any dataset that identifies individuals), you need to think about UK GDPR and the Data Protection Act 2018.
Depending on who is doing what, you may need to deal with:
- controller/processor roles (and who is responsible for compliance)
- data sharing rules (especially if both parties decide how data is used)
- security obligations and breach notification processes
- international transfers (if tools, cloud services, or team members are outside the UK)
Where one party is processing personal data for the other, it's common to include a Data Processing Agreement style schedule to ensure the required clauses are covered.
6) Publication Rights (Common In University And Research Partnerships)
If you're collaborating with academics or research institutions, publication is often part of their mission (and sometimes a condition of funding).
A good R&D Agreement will typically address:
- whether publication is allowed at all
- review/approval rights before publication
- timeframes to allow IP protection steps (like filing patents) before any public disclosure
- how confidential information is protected in published materials
This is a big one because public disclosure can seriously affect your ability to patent an invention later.
7) Warranties, Liability, And Risk Allocation
Because R&D is uncertain, you need to be careful with promises and responsibility.
Common legal points include:
- no guarantee of success (i.e. research may not produce a commercially viable result)
- quality standards (reasonable skill and care, industry standards, agreed protocols)
- liability caps and exclusions (especially for indirect or consequential loss)
- indemnities (for example, if one party's background IP infringes third-party rights)
- insurance requirements (where the risk profile is higher)
This is where getting the drafting right matters - small wording choices can shift risk in a big way.
8) Term, Termination, And "What Happens Next?"
Your agreement should clearly deal with the end of the relationship, including:
- how long the agreement runs (project term, renewal options)
- termination for breach, convenience, insolvency, or force majeure
- what happens to work-in-progress materials
- return/destruction of confidential information
- who owns the IP created up to termination
- transition support (if needed)
A practical (and often overlooked) question is: if the project ends early, can you still use the partial results? If yes, under what licence or ownership structure?
How Do You Set Up An R&D Agreement Without Slowing The Project Down?
It's completely normal to worry that "legal" will delay innovation. In reality, a well-structured R&D Agreement speeds things up because it reduces uncertainty and prevents rework later.
Here's a simple, business-friendly way to approach it.
Step 1: Get Clear On The Commercial Goal
Before you get into clause-by-clause negotiation, ask:
- Is this a one-off project, or the start of an ongoing partnership?
- Do you need to own the output, or is a licence enough?
- Will you commercialise alone, or together?
- Do you need exclusivity in a market, territory, or use case?
Your answers shape the IP and licensing sections (which are usually the "make or break" parts of the deal).
Step 2: Map The Inputs And Outputs
List what each party contributes, including:
- existing tech / background IP
- people and time commitments
- equipment, lab access, software tools
- data sources
- expected outputs (and what "good enough" looks like)
This makes it much easier to draft an accurate scope, deliverables, and IP ownership framework.
Step 3: Decide The IP Model Early (And Put It In Writing)
Most R&D agreements end up in one of these broad models:
- Customer-owned model: one party funds the project and owns the resulting IP (common where a business is commissioning development).
- Developer-owned model: the party doing the R&D owns the IP but grants the other party a licence (common where a specialist has reusable tech).
- Joint model: both parties own the output (common in genuine collaborations, but it needs careful drafting to avoid future gridlock).
There's no "one-size-fits-all" answer - but there is a right answer for your commercial plan.
Step 4: Keep The Contract Practical
R&D projects move quickly and change direction. Your agreement should reflect that with:
- clear change control processes
- simple acceptance/testing procedures
- a sensible governance structure (for example, regular steering meetings and decision-makers)
- clear escalation paths for disputes
This isn't about adding bureaucracy. It's about making sure the project doesn't stall because nobody knows who can approve a change or how to handle a disagreement.
Step 5: Don't DIY The Clauses That Carry The Most Risk
It's tempting to grab a template and fill in the blanks. The issue is that R&D agreements aren't really "fill in the blanks" documents - especially when the value is in IP, data, and confidentiality.
If the project matters to your business (and especially if investor money is involved), it's worth getting the agreement drafted or reviewed properly so it matches your real-world risks and goals.
Common Mistakes To Avoid In R&D Collaborations
Most R&D disputes aren't caused by bad intentions. They're caused by assumptions.
Here are a few common traps we see (and what to do instead).
Assuming You Own The Output Because You Paid For It
Payment alone doesn't automatically decide IP ownership. Unless the contract clearly assigns IP, the default position can be very different to what you expect.
Fix: Make IP ownership and assignment/licensing explicit (and match it to your commercial plan).
Not Defining "Background IP" Properly
If "background IP" isn't clear, you can end up accidentally licensing your pre-existing core tech more widely than intended - or, on the flip side, you might not get the rights you need to use the other party's tools after the project.
Fix: Describe background IP carefully, and set strict licence terms for how it can be used.
Letting Confidentiality Be Vague
In R&D, confidentiality isn't just "don't share secrets". It's also about controlling how information flows internally and externally, and making sure subcontractors are bound too.
Fix: Use clear confidentiality definitions, permitted purpose clauses, and subcontractor obligations.
Ignoring Data Protection Until Late In The Project
If personal data becomes part of testing, training, or evaluation, you can't fix compliance with a quick clause at the end. UK GDPR compliance often requires planning and documentation.
Fix: Decide roles and responsibilities early, and bake the required clauses into the agreement from the start.
Forgetting About The "After" (Commercialisation And Next Steps)
Even if the R&D phase is short, the value is often in what happens next: manufacturing, licensing, distribution, investment, or further development.
Fix: Ensure the contract supports your next step - including rights to use the results, exclusivity (if needed), and clear exit/transition terms.
Key Takeaways
- A Research and Development Agreement is the contract that sets out how an R&D collaboration will run, including scope, payments, confidentiality, and risk allocation.
- IP is usually the core issue: you'll want clear rules around background IP, project IP (foreground IP), and whether anything must be assigned or licensed.
- If personal data is involved, the agreement should reflect UK GDPR and Data Protection Act 2018 responsibilities, and may need a data processing schedule.
- University and research collaborations often require extra care around publication rights and protecting patent opportunities before disclosure.
- Trying to "move fast" without clear written terms can backfire - a good R&D Agreement usually makes the project smoother and helps prevent disputes later.
- Because R&D arrangements are highly specific, it's worth getting the agreement drafted or reviewed so it matches your real commercial goals and risk profile.
If you'd like help putting an R&D Agreement in place (or reviewing one you've been sent), you can reach us at 08081347754 or team@sprintlaw.co.uk for a free, no-obligations chat.


