Security requirements in a software contract should describe responsibilities and evidence, not rely on a broad promise to follow industry standards. The commercial and legal wording needs qualified review, but buyers can prepare a clear engineering schedule covering access, secure delivery, incidents, maintenance and exit.
A practical decision guide
| Situation | Starting point | What to verify |
|---|---|---|
| Secure delivery | Defined checks and evidence | Agree what is reviewed, tested and handed over. |
| Incident handling | Contacts and notification process | Align wording with applicable law and your own response duties. |
| End of engagement | Export, handover and access removal | Test that another team can operate the system. |
This guide explains planning and engineering considerations. It is not legal advice; obtain jurisdiction-specific advice for contracts, privacy and permitted data use.
Ownership and access
Agree ownership and licensing of commissioned work, pre-existing components and third-party dependencies. Specify when rights transfer, what happens if the engagement ends early and whether subcontractor arrangements support the promised rights. These are legal terms to review, not assumptions to leave implicit.
For custom development, consider client-controlled repositories, hosting and domains, with individually attributable supplier access. Define who approves access and how it is removed. For a hosted product, focus instead on usable data exports and continuity.
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 depend on the applicable law, incident and role of each party.
Vague language here is 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. Agree a written authorisation process for your own security testing or a third party, including scope, timing and any cloud-provider requirements. 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 an agreed deletion and backup-expiry process that accounts for legal retention and technical constraints.
- 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 meet — which protects you no more than a smaller, real cap backed by insurance you have verified exists.
A short pre-signature checklist
- Are ownership, licences and subcontractor rights explicit?
- Do we own the repositories, cloud accounts and domains?
- Is there a breach notification window measured in hours?
- Will we receive a bill of materials and a patching commitment?
- Is there an agreed process for authorised security testing?
- Who pays to fix security defects found after delivery?
- 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 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 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 to change the contract. Sometimes it is simply to know precisely which risks you have accepted, so that they are decisions rather than surprises.
Worked example
“The supplier will keep dependencies secure” leaves timing and evidence unresolved. A more useful schedule identifies the component inventory, how vulnerabilities are triaged, the agreed remediation windows and who verifies urgent fixes. Counsel should incorporate the agreed responsibilities into terms appropriate to the engagement.
This is an illustrative planning scenario, not a client case study.
Turn the decision into a plan
Write down the outcome you need, the evidence that would show success, the unresolved risks and the person responsible for the next decision. Use a bounded first step to test the difficult assumptions before committing to a larger programme.
ANAWAZ can help you scope the engineering work through our related service. Tell us about your current systems and the result you want to achieve.