Supply Chain Security and Third-Party Risk Management (TPRM)

Instead of forcing your front door, the attacker cracks the weak password of the small accounting software vendor that serves you, and walks in from there. Your million-dollar firewall means nothing against a connection that an authorized supplier left open. Because that supplier is already labeled "trusted" and connects to your network from the inside. That is why the attack does not climb the wall, it opens the door from within.

At DSET, the pattern we see most often in the field is this: a company protects its own systems tightly, yet never questions the security of the dozens of suppliers with access to its network. Today, most breaches come not from you, but from the weakest link in your supply chain.

What is a supply chain attack and why is it so dangerous?

A supply chain attack targets an organization not directly, but through a third party that provides it with software, services or access. The logic is simple but devastating: compromising one supplier reaches hundreds of that supplier's customers in a single move.

This is not a theoretical concern; the most expensive breaches of recent years happened exactly this way:

  • SolarWinds (2020): Attackers planted malicious code in the update mechanism of SolarWinds' Orion network management software. Thousands of organizations installed the backdoor themselves, believing it to be a "trusted update." Nearly 18,000 customers, including US federal agencies, were affected.
  • MOVEit (2023): A SQL injection flaw in the MOVEit file transfer software was mass-exploited by the Cl0p group. Through banks, public agencies and large enterprises using it, data of more than 2,000 organizations and millions of people was exfiltrated.
  • Kaseya (2021): A flaw in the Kaseya VSA remote management tool let ransomware spread in one shot to hundreds of managed service providers and their customers.

All three share one thing: none of the victims were hacked directly. Every one was hit through a trusted supplier.

"We wrote security shall be provided into the contract" does not protect you

This is the most common misconception we encounter in audits. A company adds a line such as "the supplier shall provide the necessary security measures" to the contract and considers risk management done. This is inadequate both legally and technically.

A sentence does not tell you whether the supplier uses multi-factor authentication, whether it encrypts its backups, or within how many hours it will notify you of a breach. A commitment that is never audited is not a commitment. Real third-party risk management requires concrete evidence, measurable controls and continuous verification.

Under data protection law, you are liable for the processor's breach

This is the point most executives overlook but that produces the harshest consequence. Under data protection law (KVKK in Türkiye, GDPR in the EU), the party deciding why and how data is processed is the "data controller," which is usually you. The cloud provider, CRM software or call center processing data on your behalf is the "data processor."

The critical part: the legal and financial responsibility for a breach suffered by the processor largely rests with the controller, that is, with you. Even if your supplier leaks the data, the party liable to the affected individuals and facing administrative fines is you. The Personal Data Protection Authority expects the controller to audit the processor and to secure the necessary technical and organizational measures by contract. "The supplier did it" will not save you.

For the compliance side, see our KVKK compliance and data security solutions page and our KVKK compliance consulting, VERBIS and audit article.

Tier your suppliers by risk, do not treat everyone the same

Lumping hundreds of suppliers together and sending all of them a 200-question survey is both overwhelming and useless. The right approach is to tier suppliers by the data and systems they can reach.

Risk level Example supplier Access/impact Audit depth
Critical Cloud infrastructure, payment/bank integration, core ERP Personal data + network access + business continuity Full security questionnaire, evidence, annual audit, continuous monitoring
High CRM, email provider, software developer Access to personal data SIG-style questionnaire, contract clauses, periodic review
Medium HR/payroll, call center Limited data access Short questionnaire, basic controls
Low Stationery, physical maintenance, no network service No data/system access Record + minimal controls

This tiering lets you focus your limited audit budget on the small number of suppliers that truly matter.

Frameworks and standards that work in the field

You do not need to reinvent TPRM. Mature frameworks exist:

  • NIST SP 800-161 (C-SCRM): The reference guide for supply chain risk management, covering the full lifecycle from supplier selection to monitoring.
  • ISO/IEC 27036: The international standard for information security in supplier relationships, structuring the contractual and process side.
  • SIG (Standardized Information Gathering) questionnaire: A widely adopted questionnaire framework that measures a supplier's security posture with standardized questions.
  • SBOM (Software Bill of Materials): A list of all components and dependencies in a piece of software. Without an SBOM, you cannot know which open-source library in your software carries which vulnerability. In incidents like Log4Shell, this is the only thing that makes a difference.

With NIS2, supply chain security is now a legal obligation

The European Union's NIS2 directive moved supply chain security from "nice to have" to direct board-level responsibility. In-scope organizations are required to assess and manage the security of their suppliers, and failing this obligation can create personal liability for senior management. For exporters in Türkiye and companies working with EU firms, this is already on the table as a contractual pressure.

We covered NIS2's impact on organizations in Türkiye in our NIS2 directive compliance article. To measure your suppliers' technical flaws, our vulnerability management service process comes into play.

How does DSET build supply chain security?

Our approach is not a one-off audit but a continuously running program:

  1. Vendor inventory: First we answer "who reaches our network and data." Most companies are surprised to find this list far longer than they assumed.
  2. Risk tiering: We layer each supplier by the data and systems it can reach.
  3. Security questionnaires: We apply SIG/ISO 27036-based, evidence-requesting questionnaires to critical suppliers.
  4. Contract security clauses: We embed clauses such as breach notification timelines, encryption, MFA, subcontractor control and the right to audit.
  5. Continuous monitoring: We periodically track the supplier's externally visible security posture and leak intelligence.
  6. Forensics on breach: When a supplier-originated incident occurs, our digital forensics team steps in to scope it and preserve evidence.

Frequently Asked Questions (FAQ)

What is the difference between a supply chain attack and a normal cyberattack? In a normal attack the target is hit directly. In a supply chain attack the target is reached through a trusted intermediary, a software, service or access provider. Compromising a single supplier opens the door to hundreds of organizations connected to it.

Am I legally liable for a data breach suffered by my supplier? Under data protection law, your responsibility as the data controller largely continues. Auditing your supplier acting as a data processor, securing protection by contract and ensuring the necessary measures are taken is your obligation. The administrative fine is usually levied on the data controller.

Is adding a security clause to the contract enough? No. A commitment that is never audited or evidenced is unprotected. The contract clause is a starting point; without a security questionnaire, an evidence request and continuous monitoring alongside it, it remains inadequate legally and technically.

What is an SBOM and why does it matter? An SBOM is a list of all components and dependencies inside a piece of software. When a new critical vulnerability emerges, it is the only thing that lets you determine within hours whether you are affected. Organizations without an SBOM stay blind for days during Log4Shell-style events.

How many suppliers do I need to audit? You do not need to audit them all at the same depth. Classifying suppliers by the data and systems they can reach, then concentrating your audit effort on the small number of critical and high-risk suppliers, is both effective and sustainable.

Sources

Secure your supply chain with DSET

Your suppliers do not have to be your weakest link. At DSET we build and run the full TPRM program, from your vendor inventory to contract clauses, from continuous monitoring to breach-time forensics.

DSET, cybersecurity and digital forensics since 2003. Hacettepe Teknokent, Beytepe, Ankara. Phone: +90 536 662 38 09.