A SaaS contract is not just a pricing or legal document.
It also decides how much visibility, control, and protection you will really have once the vendor starts handling your data or supporting a critical business process.
That is why security review matters before signature, not after.
NIST describes due diligence as the process of researching and verifying available information about a supplier or product before entering into an agreement so informed decisions can be made. CISA also says software customers should ask product security questions before procurement and integrate security requirements into the procurement lifecycle.
Start with one simple question
What is this vendor actually doing for us?
Are they storing your data?
Processing personal data on your behalf?
Supporting a critical workflow?
Connecting into your systems?
Using sub-processors you do not know about?
That first level of clarity matters because it tells you how deep the review needs to go. If the vendor will process personal data for you, the contract should not stop at commercial terms. It should also cover the data processing relationship clearly. The ICO explains that an Article 28 processor contract must include the subject matter and duration of processing, the nature and purpose, the type of personal data and categories of data subjects, and the controller’s obligations and rights.
Check whether there is a proper DPA
If the vendor is acting as a processor, a proper DPA is one of the first things to review.
This is not just paperwork. It defines the rules around how your data can be processed and what the vendor is required to do.
According to the ICO, the contract should cover processing only on documented instructions, confidentiality, appropriate security measures, use of sub-processors, support for data subject rights, assistance with breach handling and DPIAs, end-of-contract data return or deletion, and audits or inspections.
If those basics are unclear, the contract leaves too much open to interpretation later.
Read the security measures carefully
Many contracts say something like “we use appropriate security measures.”
That sounds reassuring, but on its own it is too vague.
The ICO points to Article 32 expectations such as encryption or pseudonymisation where appropriate, preserving confidentiality, integrity, availability and resilience, restoring access after an incident, and regularly testing the effectiveness of measures. Those are much more useful anchors than vague promises.
So when you review a SaaS contract, look for practical detail.
Can you see how security is described?
Does the wording say enough to understand the vendor’s responsibility?
Does it leave everything to a hidden security page that can be changed later?
The goal is not to force every technical detail into the main agreement. The goal is to avoid signing something that sounds secure but gives you very little to rely on.
Do not ignore breach notification language
This is one of the most important parts of the review.
If something goes wrong, you do not want to discover that the contract gives the vendor too much room to delay, limit, or soften the notification.
The ICO says the processor must assist the controller with obligations relating to breach notifications and security. That is the legal baseline. In practice, the contract should also make the operational side clearer, such as how quickly the vendor notifies you, what kind of information they provide, and how updates will be handled.
The shorter and clearer this clause is, the better it usually works when pressure is high.
Review the sub-processor clause properly
A surprising amount of risk sits here.
Your direct vendor may not be the only party touching your data. They may rely on cloud providers, support providers, analytics tools, or other third parties.
The ICO explains that the contract should say the vendor cannot appoint a sub-processor without prior specific or general written authorization, must notify you of intended changes if general authorization is used, and must impose equivalent Article 28 obligations on the sub-processor. It also says the original processor remains liable to the controller for the sub-processor’s compliance.
This is why you should check:
-
whether sub-processors are listed
-
how changes are communicated
-
whether you have a right to object
-
whether equivalent obligations flow down the chain
If this section is weak, your visibility over the real processing chain becomes weak too.
Look at data return and deletion before you sign
Most teams think about deletion at the end of the relationship.
That is too late.
The ICO (Information Commissioner’s Office) says the contract must explain that, at the controller’s choice, the processor returns or deletes the personal data at the end of the contract and deletes existing copies unless law requires retention. It also notes that backups may not always be deleted immediately, but safeguards and a defined deletion cycle matter.
That means a good contract should make it clear:
-
what happens to your data on exit
-
how long copies may remain in backups
-
whether data export is available
-
whether the format is usable
-
whether deletion is secure and verifiable
If exit terms are vague, the real cost of leaving the vendor may be much higher than it looks.
Check audit and evidence rights
A contract can promise strong security and still make it hard for you to verify anything.
The ICO says the contract must require the processor to provide the information needed to show Article 28 obligations are met and to allow for audits and inspections by the controller or its auditor.
In practice, this does not always mean you need unrestricted onsite access. Sometimes independent audit reports, certifications, or structured evidence packs are enough. But the contract should not leave you with no practical way to verify compliance.
This is one of those areas where balance matters. You want enough assurance to manage risk without making the relationship unworkable.
Review data residency and transfer wording
If the vendor handles personal data across borders, this needs proper attention.
The European Commission publishes standard contractual clauses for controllers and processors in the EU/EEA, and its guidance notes that these clauses support Article 28 requirements in the right circumstances. The Commission also separately explains that the SCC framework is part of how organizations address international data transfers under GDPR.
So before you sign, check:
-
where data is hosted
-
whether transfers outside the EU or UK happen
-
what transfer mechanism is being used
-
whether the vendor’s DPA and transfer terms line up with reality
This matters even more if your customers care about residency, locality, or sector-specific obligations.
Do not stop at privacy clauses
A lot of contract reviews focus only on the DPA.
That is important, but it is not the whole picture.
On our Clause-Review page, the focused clause pack includes not only data processing and security measures, but also breach notice time, audit and pen-test rights, sub-processors, data residency and transfers, DPIA cooperation, liability cap carve-outs, SLA and incident communications, support and patching, and termination and data deletion. That is a useful reminder that security risk in SaaS contracts is spread across multiple sections, not just one privacy appendix.
A vendor can have a decent DPA and still leave you exposed through weak SLA wording, narrow liability language, poor support commitments, or unclear incident communications.
A simple review checklist
If you want a practical first pass, look for these areas:
-
DPA or processor terms
-
security measures
-
breach notification
-
sub-processors
-
audit rights
-
data residency and transfers
-
deletion and return of data
-
support and patching commitments
-
incident communication obligations
-
liability language for security and privacy failures
You do not need to turn every contract into a major legal project.
But you do need to spot the clauses that can create real operational pain later.
What good looks like
A good SaaS contract does not remove all risk.
What it does is make responsibilities clearer.
You should be able to understand:
-
what the vendor is responsible for
-
what evidence or assurance you can request
-
how incidents will be handled
-
how subprocessors are controlled
-
what happens to your data at the end
-
where you still carry the risk yourself
That level of clarity is far more useful than a document full of vague comfort language.
Where Clause-Review fits
This is exactly the problem Clause-Review is built for.
On our aneo platform, Clause-Review is positioned for SaaS contracts, DPAs, and vendor terms. It highlights what is not in your favor, explains the impact in plain English, and suggests wording you can use in email or redlines. It also focuses on clause areas like security measures, breach notice time, audit and pen-test rights, sub-processors, data residency and transfers, liability carve-outs, support and patching, and data deletion. Aneo is also clear that it is not a CLM system and does not replace your lawyer.
That is the right way to think about it.
Faster security review.
Clearer negotiation points.
Better questions before signature.
Final thought
A SaaS contract is one of those documents that can look harmless until something goes wrong.
That is why security review matters before the relationship starts.
Not because every vendor is risky.
But because unclear clauses create unclear expectations, and unclear expectations usually become your problem at the worst possible time.
