October 20, 2026

Beyond the Small Print: Putting Vendor Contracts on the Cybersecurity Front Line

Beyond the Small Print: Putting Vendor Contracts on the Cybersecurity Front Line

In brief: Vendor contract security clauses only help if you can act on them when something goes wrong. Set out the controls a supplier must maintain, your right to evidence after signing, deadlines for fixing vulnerabilities, how quickly incidents must be reported, what happens if a deadline is missed and who owns the contract day to day.

By Alice Stephenson

Nobody opens a shopping app hoping for a message from hackers. On 6 October 2026, that’s what ASOS customers got.

An unauthorised notification announced “ASOS HACKED” and claimed the retailer’s Snowflake environment had been compromised. ASOS confirmed unauthorised activity involving third-party customer communication platforms. It said names and contact details may have been accessed, although it didn’t believe payment-card information or passwords were affected. Snowflake said it had found no compromise of its platform. The attackers’ specific claim had not been verified at the time of writing.

AI-generated illustrative reconstruction of the notification reported on 6 October 2026.

We can’t tell from those announcements what ASOS’s supplier contracts said, or whether different terms would’ve changed the outcome. But imagine being the person who has to find out what happened. You need answers from a supplier, quickly. Somewhere in a signed PDF are the promises that should help you get them.

That’s when a vendor contract earns its keep. It should tell you what information you can demand, what the supplier must do next and how quickly it must act. Connect those promises with up-to-date information about supplier risk, and the contract can help you act long before anyone starts talking about damages.

Make the security promises mean something

“We take security seriously” sounds reassuring. So does “I’ll be there in five minutes”. You’ll probably want a bit more detail before relying on either.

A contract can do better. Agree which controls the supplier must maintain, how it’ll demonstrate they’re working and what happens when a weakness appears. Broad wording such as “commercially reasonable security practices” may still carry legal weight; its effect depends on the wording, context and governing law. The clearer you are now, the less you’ll have to argue about when time’s short.

Think beyond patching. In the August 2025 Salesloft Drift compromise, attackers used stolen access tokens to reach customer Salesforce environments. Supplier access and integrations deserve attention too. Start with what the supplier can reach and the damage a failure could cause, then agree the controls that matter for that service.

Keep asking once you’ve signed

A supplier can pass your checks in January and look quite different by June. New software, new connections and newly discovered vulnerabilities can change the picture. Signing the contract doesn’t mean you should stop asking questions.

Some of that’s already a legal requirement. Where a supplier acts as your processor under the UK or EU GDPR, Article 28 requires contractual provisions on information, audits and inspections. Then work out how that’ll happen in practice: what evidence you’ll get, who’ll review it and who’ll chase up concerns.

External monitoring adds another source of evidence between assessments. It can flag exposed services, certificate problems and signs of vulnerable software. Black Kite’s continuous cyber risk monitoring helps teams spot supplier findings worth following up, giving you something concrete to discuss.

Each source has limits. External monitoring can’t see every internal control. A SOC 2 Type II report assesses controls over a period; it isn’t a certification or a promise about tomorrow. ISO 27001 certification also has a defined scope. Use these sources together, and check what each actually covers.

Agree the scope and any permissions needed for assessments, plus a way to check findings and resolve disputes. A falling security rating is a reason to investigate. Whether the supplier has breached the contract depends on what it agreed to do and the facts behind the score.

Put a date against the fix

“We’re looking into it” is a reasonable first update. Three weeks later, you’ll probably want a better one.

A remediation service level agreement gives you something firmer to work with. Define when the clock starts, what counts as a fix and who can approve an exception. Cover weaknesses the supplier discovers as well as those you report. If there isn’t a patch yet, require interim protection and a plan for a lasting fix.

You could use the following timetable to start the negotiation. These are examples, not universal standards. Agree the clock and whether days mean calendar days.

SeverityIllustrative deadlineResponse if overdue
Critical
CVSS 9.0–10.0
15 daysEscalate immediately to security and legal; review mitigation and recovery plan.
High
CVSS 7.0–8.9
30 daysEscalate to security and the contract owner; agree corrective action.
Medium
CVSS 4.0–6.9
60 daysReview the missed deadline; assign an owner and escalate or approve an exception.

The Common Vulnerability Scoring System (CVSS) describes technical severity; its base score isn’t the whole risk assessment. Exposure, active exploitation and the importance of the service can make a problem more urgent. An attacker already exploiting a weakness is a reason for immediate assessment, escalation and appropriate containment, with a shorter fix deadline where needed. The table doesn’t give anyone permission to wait.

Ask for evidence that the fix worked. If risk remains, record who’s agreed to accept it and why.

Get the first call before the full report

At the start of an incident, the supplier may have more questions than answers. Your reporting clause needs to work in that situation. Set an early reporting trigger, agree who to call out of hours and require updates as the picture develops.

The legal clocks matter. Under Article 33 of the UK GDPR and the EU GDPR, a controller must notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it’s unlikely to risk individuals’ rights and freedoms. A supplier acting as processor must tell the controller without undue delay after becoming aware of a personal data breach. The contract can’t give either party more breathing room than the law allows.

The ICO’s guidance allows information to follow in phases. A notification that’s already due can’t wait for a finished investigation; reporting after 72 hours requires reasons for the delay.

You could, for example, require the processor to notify you without undue delay and in any event within 24 hours of becoming aware of a personal data breach affecting data it processes for you. That’s an illustrative contractual maximum, not a statutory safe harbour. Require the facts available at the time, followed by prompt updates.

Also consider an early warning for reasonably suspected incidents that could materially affect your data or services. That contractual warning can help you respond while facts are still emerging. It’s separate from the legal trigger for notifying a regulator.

Decide what happens if the supplier misses a deadline

The deadline passes. The vulnerability is still there. What now? It’s a much easier conversation to have before signing.

Agree a response that fits the risk: a corrective-action plan, closer reporting and escalation to someone with authority to act. Serious or repeated failures may justify rights to suspend affected access or terminate. Spell out the triggers, notice requirements and any opportunity to put things right. Think through how you’d keep the business running and move to another supplier, too. A termination right isn’t much comfort if you can’t realistically use it.

Liability clauses, indemnities and insurance still matter when allocating and recovering losses. You also need a way to get the problem fixed while there’s still time to limit the damage.

Give the contract an owner

Imagine a monitoring alert flags a potentially vulnerable service at a critical supplier. Who checks whether it’s relevant? Who contacts the supplier? Who follows up on Friday when the promised fix hasn’t arrived?

Agree those responsibilities before you sign. Security identifies the controls and evidence that matter. Legal turns them into clear obligations and remedies. Procurement and the business owner

help establish what the supplier can deliver and what the business can tolerate. Give someone responsibility for chasing overdue actions and handling exceptions. “Everyone” is a surprisingly unreliable contract manager.

The Bridge™, Black Kite’s vendor engagement platform, supports that work by sharing findings with suppliers and recording communications and remediation progress. It gives teams a place to keep the finding, the supplier’s response and the follow-up together.

Elasticito combines cyber risk assessment and monitoring technology with specialist services and managed support. As a Black Kite partner, it can help organisations build that intelligence into everyday supplier oversight. That helps you work out which suppliers need your attention, what to ask them and how to keep things moving.

At your next critical supplier renewal, put the contract beside the latest security assessment. Pick one finding and work through what would happen next. If nobody can explain who calls the supplier, what they can require or when they expect an answer, you’ve found a useful place to start.

Join Elasticito’s webinar “Are Your Vendor Contracts Secretly Sabotaging Your Cybersecurity?” to explore how contracts and ongoing monitoring can work together. To discuss using Black Kite in your supplier oversight, speak to Elasticito.

Share this article:
LinkedIn
Facebook
WhatsApp

More posts

Elasticito article header – The Identity Backdoor: Why a Vendor's Identity Is the Most Common Path Into Your Data – identity security and vendor access risk
July 1, 2026
Third-party identities are a leading cyber-breach vector because they bypass internal zero-trust architectures. Since static security questionnaires cannot detect compromised vendor credentials or tokens, continuous external monitoring is essential.
Elasticito article header – What 4th-Party Risk Does Your 3rd Party Bring to Your Supply Chain? Fourth-Party and Sub-Processor Risk Explained – supply chain cybersecurity
June 24, 2026
This article explains fourth-party risk – the hidden vulnerability from your vendors’ sub-processors. While organisations lack direct audit rights over these hidden relationships, regulations like GDPR and DORA hold them legally liable for any breaches.