Written by Jaiz Anuar

Your Vendor Passed the Security Assessment. The Breach Still Came Through Them.

A supplier can answer every questionnaire, provide valid certifications and still become the path into an organisation. Vendor approval must begin ongoing assurance, not end it.

The vendor completed the security questionnaire.

Its policies were reviewed. Certifications were provided. Penetration-test summaries were submitted. Contractual security clauses were accepted.

The risk was assessed and the vendor was approved.

Months later, the organisation suffered a breach through the same vendor.

This does not necessarily mean the assessment was performed incorrectly. It may mean we expected the assessment to prove something it could never prove.

A vendor security assessment shows what the vendor was able to demonstrate at a particular moment. It does not guarantee that every control continues operating, every employee behaves securely or every subcontractor is equally protected.

Approval is not permanent assurance.

The Assessment Captured a Moment

Most third-party assessments happen before onboarding or during an annual review.

The vendor answers questions about access control, encryption, vulnerability management, incident response and business continuity. Evidence may be requested for higher-risk services.

The resulting assessment can be useful. It identifies obvious weaknesses and establishes a minimum level of assurance.

But it remains a snapshot.

A vendor may change its infrastructure after the assessment. New administrators may be appointed. Permissions may accumulate. A cloud service may be reconfigured. An unreviewed subcontractor may begin processing information. A previously secure system may become vulnerable.

The assessment can remain valid on paper while the actual environment has already changed.

This is the first limitation organisations must recognise: compliance evidence has a date, but cyber risk continues moving.

The Vendor May Not Be the Only Vendor

An organisation may contract with one provider, but that provider often depends on many others.

Its application may run on a cloud platform. Customer support may be outsourced. Software development may involve external contractors. Email, analytics, identity verification and payment processing may each be delivered by another company.

The organisation assesses the primary vendor.

The primary vendor depends on a supply chain the organisation may never see.

This creates inherited trust. When the organisation trusts its vendor, it may also be trusting the vendor’s cloud provider, software dependencies, administrators and subcontractors.

The contract may be with one company.

The real attack surface may include dozens.

A mature assessment must therefore ask not only how the vendor protects the service, but also which other parties can influence its confidentiality, integrity and availability.

Certification Is Evidence, Not Immunity

Security certifications are valuable. They indicate that defined controls and management processes have been independently assessed.

But certification should not be interpreted as proof that a breach cannot happen.

An audit reviews controls against a defined scope. A critical system may sit outside that scope. A recently introduced service may not yet have been assessed. A control may be well designed but inconsistently operated.

Attackers are not required to attack the controls covered by the certificate.

They search for whatever remains exposed.

The organisation should therefore understand what the certification covers, when the assessment was performed and which systems or locations were excluded.

The question is not simply, “Is the vendor certified?”

The better question is, “What does this certification actually give us confidence about?”

Attackers Look for Connected Trust

Third parties are attractive because one compromised provider may create access to several customers.

The attacker may target remote support tools, service accounts, API tokens, software updates or trusted integrations. These connections often receive broad access because the vendor needs to operate efficiently.

Over time, temporary access becomes permanent. An integration gains additional permissions. A service account remains active after a project ends.

The vendor may be secure within its own environment while the connection into the customer remains excessive.

This is why supply-chain risk is fundamentally an architecture problem.

Every connection must have a clear purpose, defined identity, limited privilege and accountable owner. Trust should be restricted to the actions genuinely required.

A vendor should not receive access to an entire environment merely because supporting one application is easier that way.

Security Questionnaires Cannot See Everything

Questionnaires typically ask whether controls exist.

Does the vendor use Multi-Factor Authentication? Are vulnerabilities patched? Is sensitive data encrypted? Is privileged access reviewed?

These are reasonable questions, but a “yes” answer may hide important differences.

MFA may protect employees but not service accounts. Vulnerabilities may be patched according to policy while unsupported systems remain exposed. Data may be encrypted in storage but widely accessible to applications. Privileged access may be reviewed annually even though permissions change every week.

The control exists.

Its effectiveness remains uncertain.

A stronger assessment asks how the control works, where it applies, how failure is detected and what happens when it does not operate as intended.

As recommended in NIST’s Cybersecurity Supply Chain Risk Management guidance, supply-chain risk must be managed throughout the lifecycle rather than treated as a single procurement exercise.

Monitoring Must Continue After Approval

Third-party risk management often becomes less active once a contract is signed.

The vendor moves from assessment into an approved list. Attention returns during renewal, after a major change or when an incident is reported.

But the period between assessments may be when risk changes most.

Continuous assurance does not require constant surveillance of every supplier. It requires monitoring proportionate to the vendor’s importance and access.

For critical vendors, organisations should understand:

• What systems and data the vendor can access
• Which human and machine identities are used
• Whether access patterns have changed
• When privileged accounts were last reviewed
• Which subcontractors support the service
• Whether new vulnerabilities affect the platform
• How quickly the vendor must disclose an incident
• Whether access can be revoked without stopping the business

This turns third-party security from a questionnaire process into an ongoing control.

Contracts Do Not Contain the Attack

Contracts remain important. They establish responsibilities, notification periods, audit rights, security requirements and consequences for non-compliance.

But contractual language does not stop lateral movement.

When a vendor account is compromised, the firewall does not read the contract before allowing traffic. An API does not know that the supplier agreed to maintain least privilege. A stolen token continues functioning until a technical control rejects or revokes it.

Legal controls define expectations and accountability.

Technical controls limit what can happen.

Both are necessary, but they perform different functions.

Organisations must assume that a vendor may eventually be compromised and design the connection so that the incident does not automatically become their own enterprise-wide breach.

Critical Vendors Need Different Treatment

Not every supplier requires the same level of scrutiny.

A vendor providing office furniture should not receive the same assessment as a provider processing customer information, managing security infrastructure or connecting directly to production systems.

Criticality should reflect more than annual spending.

A low-cost vendor with privileged access may create far greater cyber risk than an expensive supplier with no system connectivity.

The organisation should consider:

• Sensitivity and volume of accessible data
• Level of system privilege
• Connectivity to critical environments
• Ability to disrupt essential services
• Difficulty of replacing the provider
• Dependence on subcontractors
• Concentration risk across the organisation
• Recovery options if the vendor becomes unavailable

Higher trust requires stronger verification, tighter architecture and more frequent review.

Prepare for the Vendor to Fail

The most useful third-party risk question is not whether the vendor can prove it is secure.

It is whether the organisation can survive if the vendor is compromised.

Can vendor access be disabled quickly? Can tokens and credentials be revoked? Can suspicious activity be distinguished from legitimate support? Can the business operate temporarily without the service? Is there an alternative provider or manual process?

These questions move the discussion from assurance to resilience.

The same principle applies to trusted security products. As discussed in The Tools We Trust To Secure The Supply Chain Can Become The Supply Chain Risk, highly trusted tools may create highly privileged paths across the organisation.

The objective is not to eliminate trust completely.

It is to ensure that one failed trust relationship does not become unrestricted access to everything.

Final Thought

A vendor assessment is necessary, but it is not a guarantee.

It gives the organisation evidence to make a decision. It does not transfer the risk or remove the need for monitoring, containment and recovery.

The vendor may have answered every question honestly. Its certification may have been valid. Its controls may have worked when they were assessed.

The breach can still come through them.

Third-party security therefore cannot end when the vendor is approved. It must continue through access design, monitoring, reassessment, incident response and eventual termination.

The most mature organisations do not merely ask whether their vendors are secure.

They ask what happens to the business when one of them is not.

Question assumptions. Share knowledge. Build trust.