A contract with a marketing script vendor should require evidence of code security, notice before the script changes, limits on what data it may collect and where it goes, and your right to remove it. OWASP's guidance suggests including a requirement to show code security evidence, and penalties for serving malicious JavaScript.
This is a drafting aid for discussion with your counsel, not legal advice.
Why contracts matter for scripts
A vendor script is code you do not write, review or host. OWASP notes that vendor side changes are hard to see, since the code is usually obfuscated and can be altered without notice. Technical controls such as SRI and CSP help. A contract covers what technology cannot: who is responsible, what you are told, and what happens if something goes wrong.
Clause checklist
| Topic | What to ask for |
|---|---|
| Evidence of code security | A requirement to show it, in line with OWASP's MarTechSec guidance |
| Malicious code | Remedies or penalties if the vendor serves malicious JavaScript |
| Change notice | Advance notice of changes to the script, hosting domain or sub processors |
| Versioning | A pinned, versioned file where possible, so SRI can be used |
| Data collected | A list of fields, a purpose for each, and a ban on collecting more |
| Data destinations | Where data is sent and which sub processors receive it |
| Cookies and storage | What is set and for how long |
| Incident notice | How fast and how the vendor tells you of a compromise |
| Testing | Your right to test client side behaviour, which OWASP lists under MarTechSec |
| Exit | Removal on request, data deletion and return, and a plain end of service process |
Pair each clause with a control
A contract line is only as good as your ability to notice a breach of it. For each clause, name the check.
- Evidence of code security: ask for it at onboarding and at renewal, and file it.
- Change notice: also use technical detection. See how to detect when a third party script changes.
- Data fields: verify in the browser what is actually sent, with the network panel.
- Versioning: use SRI where the vendor allows pinned files.
- Exit: test that you can remove the tag and see requests stop.
Questions to ask before signing
Does the vendor load other scripts, and from whom? Will the vendor agree to a fixed version URL? What happens to collected data after termination? Who at the vendor answers a security question, and how fast? The questions before embedding a third party SDK post has a longer list that adapts well to scripts.
Keep marketing and security in the same room
OWASP's MarSecOps idea is that marketing, vendors and operations coordinate on SRI hash updates, tag manager configuration and data layer changes. A contract owner who talks to only one of those groups will miss something. Make one person responsible for the vendor file, with a review date.
Quick check
Can a contract replace technical controls?
No. It sets expectations and remedies. You still need inventory, review and monitoring to see a problem.
What if the vendor refuses to share evidence?
Treat that as risk information. Limit the pages the script runs on, or choose a different approach.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you keep vendor files and review dates in one place. Try the free scan for your code.
Sources
Last reviewed: 19 October 2026.
