Most software contracts handle scope, price and timeline carefully, then cover security with a single sentence promising industry-standard practices. That sentence commits the supplier to nothing measurable and gives you nothing to enforce.

The clauses below are the ones that matter in practice. They are cheap to agree before signature and expensive to negotiate afterwards, when you have already handed over your data and the leverage has moved.

Ownership and access

Code ownership on creation. All work product assigned to you as it is written, not on final payment or project completion. If the relationship ends early, you must own what you have already paid for. Confirm the supplier’s own employees and any subcontractors have assigned their rights upward — a company cannot transfer what it does not hold.

Your accounts, your infrastructure. Repositories, cloud accounts, domains, certificates and third-party services in your organisation’s name. The supplier receives access; you hold the account. This single arrangement prevents the most damaging failure mode in outsourced development, where the only copy of a working system lives somewhere you cannot reach.

Named access, revocable individually. No shared accounts. Every person who can reach your systems has their own credentials, and you can see the list. Ask for it quarterly.

Disclosure and incident handling

A disclosure window in hours, not “promptly”. If the supplier suffers a breach affecting your data or systems, you need to know within a defined period — and it should be short enough to let you meet your own regulatory obligations, which in many jurisdictions run to 72 hours from your awareness.

Vague language here is genuinely dangerous. “Without undue delay” has been interpreted very differently by parties whose interests diverge at exactly the moment it matters.

Cooperation during investigation. Access to logs, personnel and systems needed to understand what happened. Suppliers sometimes go quiet during incidents on legal advice; agree in advance that they will not.

Who notifies whom. Establish that you, not the supplier, communicate with your customers and regulators. You own that relationship.

The dependency clauses

These are the least common and among the most useful, because the majority of a modern application is code somebody else wrote.

A software bill of materials. A list of third-party components and their versions, delivered and kept current. When the next widely-exploited library vulnerability is announced, the question “are we affected?” should take minutes, not days of archaeology.

A patching commitment. Defined timeframes for applying security updates to dependencies, tiered by severity. Without this, dependency updates are nobody’s job and quietly become a large, unfunded liability.

Licence compliance. Confirmation that no component carries a licence incompatible with how you intend to use the software. This is discovered painfully late otherwise, usually during due diligence for an acquisition.

Testing rights

The right to test. Explicit permission to perform your own security testing, or commission a third party, without needing case-by-case approval. Suppliers occasionally refuse this. That refusal is itself informative.

Evidence of their testing. If the supplier claims to test, ask what kind, how often, and to see a summary. A supplier who tests will answer specifically. Note the distinction between a scan and a genuine penetration test — those are different products and are frequently conflated in sales conversations.

Remediation obligations. Agree who pays to fix security defects found after delivery, and within what timeframe, tiered by severity. Absent this clause, every finding becomes a commercial negotiation at the worst possible moment.

Offboarding

The most commonly omitted section, and the one you will most regret omitting.

• Access revocation within a defined period of an individual leaving the supplier’s team, and of contract termination. Ask how you will verify it happened.
• Data return and deletion — what is returned, in what format, over what period, followed by confirmed deletion of their copies including backups. “Including backups” is the clause people forget.
• Handover contents defined now: source, documentation, credentials, deployment procedures, architecture notes. Negotiating this during a breakdown in the relationship goes badly, and that is exactly when it is needed.
• Transition assistance at agreed rates for an agreed period, so you are not choosing between paying whatever is asked and losing institutional knowledge.

What to leave out

Two things buyers commonly insert that add cost without adding security.

Certification demands disproportionate to the work. Requiring ISO 27001 from a three-person supplier building a small internal tool will either exclude capable suppliers or add cost you ultimately pay. Match the requirement to the sensitivity of what they will access.

Unbounded liability. It reads as strong protection and mostly is not. Suppliers either refuse, price the risk in heavily, or accept a liability they could never actually meet — which protects you no more than a smaller, real cap backed by insurance you have verified exists.

A short pre-signature checklist

1. Is IP assigned on creation, including from subcontractors?
2. Do we own the repositories, cloud accounts and domains?
3. Is there a breach notification window measured in hours?
4. Will we receive a bill of materials and a patching commitment?
5. May we test the system ourselves without prior approval?
6. Who pays to fix security defects found after delivery?
7. What exactly happens at termination, including backup deletion?

If most answers are “it does not say”, the contract protects the supplier rather than you — and that is a conversation to have before signature, not during an incident.

SaaS vendor or development supplier? The clauses differ

The list above assumes someone is building software for you. If you are instead buying a hosted product, the emphasis shifts, and reusing the wrong template leaves real gaps.

With a SaaS vendor, you will not own the code and should not ask to. What matters instead is where your data lives and what happens to it:

• Data location and sub-processors. Which countries, which third parties, and notification before that list changes. A vendor quietly moving processing to a new jurisdiction can breach your own obligations without you knowing.
• Export in a usable format. Not a PDF, not a proprietary blob — structured data you could actually load elsewhere. Test this during the trial, not at termination.
• Tenant isolation. Ask how your data is separated from other customers’. The answer should be specific.
• Their security evidence. Certification, most recent test summary, and status page history. You cannot test their infrastructure yourself, so you are relying on their assurance — verify it exists.
• Business continuity. What happens if the vendor fails or is acquired? For anything business-critical, an escrow or documented exit plan is proportionate.

With a development supplier, the code and account clauses above carry most of the weight, because you retain the asset and the risk sits in whether you can actually take it back.

A useful framing: with SaaS you are buying an ongoing relationship, so contract for exit. With custom development you are buying an asset, so contract for ownership and handover.

When there is no room to negotiate

Smaller buyers frequently cannot amend a large vendor’s standard terms. That does not make the exercise pointless — it changes what you do with the answers.

Read the terms anyway and write down what is missing. Where a clause you wanted is absent, decide deliberately how to compensate: keep your own independent backups if deletion and return terms are weak; avoid putting your most sensitive categories of data into a product whose breach-notification language is vague; keep a documented migration path if there is no continuity commitment.

The goal is not always to change the contract. Sometimes it is simply to know precisely which risks you have accepted, so that they are decisions rather than surprises.

How we contract

We assign IP on creation, work in client-owned repositories and cloud accounts, and agree handover terms at the start of every engagement rather than the end. Our cyber security team can review a prospective supplier’s security posture before you sign, and our information security practice helps build the supplier due-diligence process that makes these questions routine.

Get in touch — and bring the contract you are about to sign.