EDUCATION, SUPPLY CHAIN, TPRM

🔗 Management of third parties and supply chains

How to manage the risks posed by suppliers, service providers and software dependence by international practice (ISO 27036, NIST SP 800-161, NIS2, DORA, CRA, SLSA). Examples are fictional, designed for training.

Why It Is Important

Extended attack surface - each third introduces risk

Third party attack surface Organisation in the centre, around six types of third parties whose access and data flow extend the perimeter of risk. Extended attack surface Each party with access or traffic is part of your risk perimeter TAVA ORGANISATION assets, data, customers SaaS / Clouds M365, CRM, data storage Open source code npm, PyPI, dependencies MSP / IT support remote privileged access Apparatus / firmware manufacturers, equipment Payments / API integration of partners Subcontracting 4th-party (n-th side) access, data, trust Third party risk is managed as SAU: Article 21 (2) (d) of the NIS2 requires supply chain security. Significant incidents: SolarWinds 2020, Log4Shell (2021), MOVEit (2023), XZ Utils backdoor (2024)

Risks to third parties

Risk to the organisation from external suppliers, service providers and software components with access to your data, systems or processes. You remain responsible for the consequences, even if the third party is guilty.

Related standards

ISO/IEC 27036 (security of supplier relations), NIST SP 800-161 Rev.1 (C-SCRM), NIST CSF 2.0 function GOVERN (GV.SC), NIS2 21(2) (d), DORA (financial ICT third party), CRA (product safety).

Fourth party risk

Your suppliers (fourth and furthest sides) and the risk of concentration (too much dependence on one cloud or service) often remain invisible, but can stop operation just like a direct incident.

Third Party Life Cycle

TPRM life cycle with continuous revaluation

TPRM Life Cycle Six stages from planning to ending with continuous re-evaluation loop. Third party risk management life cycle Shared Assessments / ISO 27036 - risk management from procurement to termination 1. Planning need decrease thinning what data, what access 2 before signing SIG, SOC 2, ISO sert. safety condition 3. Contract DPA (GDPR p. 28) SLA, right-to-audit notification of incidents 4 least privatege forecasting access integration, MFA Monitoring continuous security rating periodic reasses 6. Termination revocation of access return/deletion of data offboarding risk-based periodic reassessment The most critical suppliers are revalued more frequently. The end of cooperation is as important as the beginning. Reference: Shared Assessments TPRM Framework, ISO/IEC 27036, NIST SP 800-161

Pre-contractual due diligence

Prior to cooperation, the security status of the supplier shall be assessed: Shared Assessments SIG, independent opinions (SOC 2 Type II, ISO 27001 certificate), intrusion test summaries and financial stability.

Contract safeguard clauses

Data processing contract (DPA, Article 28 GDPR), SLA with security objectives, right to audit, deadlines for notification of incidents, approval of sub-processors and data return/removal shall be terminated.

Continuous monitoring

One questionnaire is not enough: the security situation is changing. Follow safety ratings, vulnerability to warnings and certificate validity, and re-evaluate the supplier on a regular basis - the more critical, the more frequent.

Tiering and due diligence depth

Criticality classification determines test depth

Risk classification Three levels of fall (Tier 1-3) with corresponding due diligence depth. Classification of suppliers' criticality (tiering) Data sensitivity × level of access × business impact → thin → depth of testing LEVEL 3 CRITERIA DUE DILIGENCE Tier 1, Critical high dependence difficult to replace - access to sensitive/personal data - critical systems or privileged access - idleness endangers the main activity SOC 2 Type II + on-site audit pen-test summary, BCP/DR revaluation ≥ yearly Tier 2, Important restricted access interchangeable with effort - limited or indirect access to data - an important but not critical service - moderate business influence SIG Core + ISO 27001 certificate monitoring security ratings revaluation every 1-2 years Tier 3, Low no data access easy to replace - no access to data/systems - standard, widely available product - minimal business impact SIG Lite/self-assessment framework contract clauses revaluation as appropriate

Why Tiering

All suppliers are not equally risky. Classification allows to devote limited resources to the most critical - deep examination where the consequences are greatest, easy where the risk is minimal.

Standardised questionnaires

Shared Assessments SIG (Standardized Information Gathering) - industry standard questionnaire for assessment of safety status. SIG Lite for lower risk, SIG Core for deeper testing. CAIQ (Cloud) for cloud services.

Independent opinions

SOC 2 Type II (AICPA) - effectiveness of control over the time period. ISO/IEC 27001 certificate - ISMS compliance. ISAE 3402 for international services. They reduce the need for own audit.

Software supply chain

Software supply chain - attacks and defences

Software supply chain Development line with attack points (bottom) and protection controls (top). Software supply chain Above - Protection (SLSA, SBOM). Bottom - attack points PROTECTION SBOM (SPDX/CycloneDX), SLSA provision, signing (Sigstore/cosign), SCA scan, lockfiles, OpenSSF Scorecard Source code git, developers Dependence npm, PyPI, Maven Build CI/CD conveyor Artefact figure 1, package Exploit register, prod Compromised maintainer / committee (XZ Utils 2024) Typosquating / reserve confusion abusive package Build systems compromising (SolarWinds 2020) Unsigned or counterfeit artifact lack of integrity Compromised register / update (3CX 2023) SLSA (Supply-chain Levels for Software Arts) defines building integrity levels. SBOM gives the transparency of components (USA EO 14028).

SBOM - List of constituents

Software Bill of Materials - machine-readable list of all software components and dependencies (formats SPDX, CycloneDX). Lets quickly determine whether you are affected by a new vulnerability (e.g. Log4Shell).

SLSA and signing

SLSA (OpenSSF) - building integrity levels with provenance (evidence of origin). Signing artifacts with Sigstore/cosign makes it possible to verify that the package comes from a reliable construction and is not counterfeit.

Dependent hygiene

Fixed versions and lockfile (repeated structures), SCA scanning (OWASP Dependency-Check, pip-audit, Trivy), monitoring of transitive addiction and OpenSSF Scorecard project for health evaluation before implementation.

Standards and regulation

Landscape of supply chain security standards

Standard landscape Five standard and regulatory blocks for supply chain security. Standards and regulation Choose by purpose - they often overlap and complement each other ISO/IEC 27036 ratio of suppliers safety (4 parts) 28000 supply chains safety management 27001 A.5.19-23 ratio of suppliers control NIST SP 800-161 C-SCRM practices organisations CSF 2.0 LUSC supply chain risk (GOVERN function) SP 800-218 SSF safe development (software) EU framework NIS2 21(2)(d) supply chains safety (mandatory) DORA ICT Third Parties (financial sector) CRA a product with digital element security SW integrity SLSA build levels + provenance (OpenSSF) SBOM SPDX, CycloneDX (NTIA min elements) Scorecard OpenSSF project health assessment Evaluation SOC 2 / ISAE 3402 independent opinion Shared Assessment. SIG standard questionnaire CIS Control 15 service provider management NIS2 requires security of the supply chain as a mandatory measure - other standards provide technical and methodological implementation.

NIS2 - Legal requirement

Article 21 (2) (d) of the NIS2 Directive (EU 2022/2555) provides for supply chain security as a mandatory risk management measure, including security aspects in relation to direct suppliers and service providers.

ISO 27036 and NIST 800-161

ISO/IEC 27036 provides a governance framework for the security of supplier relationships. NIST SP 800-161 Rev.1 (C-SCRM) - detailed practices for managing cybersecurity supply chain risks at system and organisation level.

DORA and CRA

DORA (Regulation (EU) 2022/2554, applicable from 17 January 2025) regulates the supervision of financial sector ICT third party risk and critical service providers. Cyber Resilience Act (Regulation (EU) 2024/2847) imposes safety requirements on manufacturers of products with digital features across the EU market: reporting on actively used vulnerabilities from 11 September 2026, full requirements from 11 December 2027.

Practical controls

Three-layer controls + invisible risks

Control layers Contractual, technical and organisational controls and concentration and fourth party risk. Controls and protection Defense-in-expth: controls in three complementary layers Contractual before and during DPA (GDPR p. 28) SLA + safety objectives right-to-audit notification of incidents (time limits) approval of sub-processors Technical daily least privatege segmentation MFA + Access Logs monitoring SBOM + SCA Zero Trust access Organisational governance tiering / register periodic reasses offboarding process incident response plan 4th-party mapping and monitoring Invisible risks Concentration risk too much dependence on one cloud/service Fourth party risk supplier's suppliers Preparing for an incident - supplier's incident = your incident (NIS2 p. 23) - include suppliers of IR plan and training - exit / replacement plan Reference: CIS Control 15, ISO 27036, NIST SP 800-161, NIS2 Articles 21 and 23

The Treaty is the first line of protection

The security requirements must be incorporated into the contract before signing - it is difficult to add them later. Data processing contract, SLA with measurable security objectives, audit authority and clear incident notification deadlines.

Technical insulation

Give the supplier only the necessary (lat privilege), isolate his access (segmentation, Zero Trust), request MFA and log operations. It limits injury when the supplier is compromised.

Planned exit from the beginning

The concentration and fourth party risk require a plan to replace the supplier and a continuity check. The supplier's incident is your incident - including suppliers in the incident response plan and training.

Abbreviations

Abbreviations used in the Roadmap: the original name and what it means.

TPRM
Third-Party Risk Management - third party risk management.
C-SCRM
Cyber Supply Chain Risk Management - cybersecurity supply chain risk management (NIST SP 800-161).
SBOM
Software Bill of Materials - list of software components and addictions.
SPDX / CycloneDX
Two SBOM formats.
SLSA
Supply-chain Levels for Software Artifacts - building integrity levels.
SCA
Software Composition Analysis - verification of dependence against known injuries.
SSDF
Secure Software Development Framework - NIST Safe Development Practices (SP 800-218).
SIG
Standardized Information Gathering - Shared Assessments supplier safety questionnaire.
CAIQ
Consensus Assessments Initiative Questionnaire - Cloud Service Security Questionnaire (CSA).
SOC 2
System and Organization Controls 2 - an independent auditor's opinion on the controls of the service provider.
ISAE 3402
International standard for the opinion of controls of service organisations.
AICPA
American Institute of Certified Public Accountants - the US Institute of Auditors, which issues SOC standards.
DPA
Data Processing Agreement - data processing contract (Article 28 GDPR).
SLA
Service Level Agreement - service level agreement - availability, response time.
MSP
Managed Service Provider - the company that manages the client's IT.
DORA
Digital Operational Resilience Act - the EU Financial Sector Digital Sustainability Regulation.
CRA
Cyber Resilience Act - EU regulation on the safety of digital products.
IKT / ICT
Information and communication technologies
BCP / DR
Business Continuity Plan / Disaster Recovery - business continuity plan / recovery from an accident.
EO 14028
Executive Order 14028 - U.S. Presidential Order on Cyber Security (2021), requires SBOM.
OpenSSF
Open Source Security Foundation - the organisation maintaining SLSA and Scorecard.
CI/CD
Continuous Integration / Continuous Delivery - the construction, testing and delivery of an automatic code.