TPRM (Third-Party Risk Management, the management of risk coming from third parties) is no longer reserved for procurement or GRC (governance, risk and compliance): every SaaS, API, library or service provider your team integrates introduces a third-party risk into your information system. This lesson is for a technical team that has to answer the question of the CISO (chief information security officer) "have you assessed the supplier risk?" with a method: inventory the third parties, score them by impact and maturity, demand suitable evidence, then decide and monitor.
The case that makes you think: a team adopts an open source library and answers "it's open source, there is no supplier". Yet the sole maintainer has just handed the project over to a stranger, and the package gets millions of downloads a month.
This lesson covers the technical assessment of one supplier at a time. It does not re-explain why trust propagates along a chain: that is the subject of transitive trust, which this method puts into practice.
What you will learn
- Define TPRM and explain why technical teams are concerned.
- Inventory your third parties (SaaS, APIs, packages, service providers, infrastructure).
- Score a third party by impact and maturity, then choose to accept, mitigate or refuse.
- Demand the right evidence: a questionnaire for a SaaS, public signals for open source.
- Qualify a new third party quickly, and automate what can be automated.
- Produce the evidence for SOCLE-FRN-GEN-1 (in French), the tiering of suppliers by criticality, and for SOCLE-FRN-GEN-2 (in French), the proportionate security assessment of critical suppliers.
What are the prerequisites?
You need to know what is at stake in supply chain security and what an SBOM is (a machine-readable list of a piece of software's components). The lesson on the artifact firewall covers the technical filtering of incoming packages: here we cover the decision to accept a third party or not, upstream of that filtering.
What is TPRM (Third-Party Risk Management)?
A simple definition
TPRM (Third-Party Risk Management) is the set of practices for identifying, assessing and managing the risks linked to the third parties you work with:
- SaaS (software as a service) providers: the cloud services you integrate (Auth0, Stripe, Datadog, etc.)
- Libraries and packages: open source or proprietary dependencies
- Service providers: managed service providers, external developers, IT services firms
- Third-party APIs: data enrichment, payment and notification services
Why are technical teams concerned?
TPRM used to be handled by procurement or GRC teams. Reality has changed:
| Before | Now |
|---|---|
| Buying software goes through procurement | A single npm install adds a dependency |
| The contract frames the risk | Open source code has no contract |
| You assess before buying | You discover the transitive dependencies afterwards |
| A few strategic suppliers | Hundreds of dependencies per project |
The problem: technical teams make integration decisions (SaaS, packages, APIs) without always assessing the associated supplier risk.
What are the concrete risks of poor third-party management?
The table below pairs each risk family with a public incident that made it real. Read it looking for your own equivalent: the "Real example" column is there to measure whether the scenario is plausible at your organisation, not to retell the history of the sector. Note that several rows are not attacks: withdrawal by the maintainer, the inherited flaw, non-compliance and service outage have no attacker behind them, and yet these are risks that get forgotten, for lack of a spectacular incident to tell.
| Risk | Real example | Impact |
|---|---|---|
| Supplier compromise | SolarWinds (2020) | Supply chain attack via an update |
| Withdrawal or abandonment by the maintainer | left-pad (2016) | Package removed by its author after a naming dispute, breaking thousands of builds |
| Ownership transfer | Polyfill.io (2024) | Malicious code injection |
| Unpatched flaw | Log4Shell in a transitive dependency | Critical inherited vulnerability |
| Non-compliance | SaaS not compliant with the GDPR (the EU data protection regulation) | Regulatory penalties |
| Service outage | Outage of a critical SaaS | Your application is unavailable |
A practical approach inspired by NIST 800-161
NIST SP 800-161 Rev. 1 offers a framework of Cyber Supply Chain Risk Management (C-SCRM) practices, aimed mainly at US federal agencies. It is not a "turnkey framework" you can transpose directly, but its principles remain relevant to structure your approach.
For technical teams, these principles translate into 4 operational actions: identify, assess, respond, monitor.
What are the 4 operational actions of C-SCRM?
These four actions form a loop, not a checklist you tick once. The diagram shows them in execution order, and the Frequency column of the table gives the most important piece of information: only Identify runs continuously, the other three are triggered by an event or a calendar. An approach that stops after the initial assessment leaves a frozen inventory that goes stale within a few months, at the pace of maintainer changes and supplier acquisitions.
| Pillar | What you do | Frequency |
|---|---|---|
| Identify | List all your third parties (SaaS, packages, service providers) | Continuous |
| Assess | Score each third party against risk criteria | At onboarding + periodic |
| Respond | Decide: accept, mitigate, or refuse the risk | According to the assessment |
| Monitor | Review periodically, react to incidents | Quarterly/Annual |
The rest of the lesson walks through these actions in five steps: inventory the third parties (identify), score them (assess), question them with a questionnaire, judge the evidence received, then decide (respond) and monitor.
Step 1: Inventory your third parties
Which 5 categories of third parties should you track?
This split exists because each category is counted with a different tool: an SBOM for packages, billing or single sign-on (SSO) for SaaS, access accounts for service providers. Start with the categories nobody tracks in your organisation, generally third-party APIs and external infrastructure: these are the two where forgotten dependencies are often discovered, introduced during a prototype that stayed in production.
-
SaaS and cloud services
The services you use directly or integrate into your applications:
- Authentication (Auth0, Okta, Keycloak SaaS)
- Payment (Stripe, PayPal, Adyen)
- Monitoring (Datadog, New Relic, Sentry)
- Communication (Twilio, SendGrid)
- Storage (AWS S3, GCS, Azure Blob)
-
Third-party APIs
The services you call through an API:
- Data enrichment (Clearbit, FullContact)
- Geolocation (Google Maps, HERE)
- Verification (email, phone, identity)
-
Libraries and packages
Your direct and transitive dependencies:
- npm, PyPI, Maven, Go module packages
- Supplier SDKs
- Frameworks (React, Django, Spring)
-
Technical service providers
The people and organisations that access your systems:
- IT services firms and external developers
- Managed service providers (who operate part of your infrastructure)
- Security consultants
- Level 3 support of your suppliers
-
External infrastructure
The infrastructure components you do not manage:
- CDN (Cloudflare, Fastly)
- DNS (Route53, Cloudflare DNS)
- Package registries (npm, Docker Hub)
- CA (certificate authorities: Let's Encrypt, DigiCert)
What does a third-party inventory template look like?
An effective inventory must capture not only the basic data but also the type of access granted and the ability to exit the third party if needed. The sample rows below show the level of detail to aim for.
| Name | Category | Data exposed | Criticality | Access type | Replaceable? | Exit plan? | Owner | Last review |
|---|---|---|---|---|---|---|---|---|
| Auth0 | Auth SaaS | User credentials | Critical | API + Admin | No | Yes | Identity team | 2026-01-15 |
| Stripe | Payment SaaS | Banking data | Critical | API | No | No | Billing team | 2026-02-01 |
| lodash | npm package | None | Low | Code | Yes | N/A | Frontend team | - |
| axios | npm package | Data in transit | Medium | Code | Yes | N/A | Frontend team | - |
| Acme Consulting | Service provider | Prod access | High | Prod admin | Yes | No | CTO | 2025-12-01 |
Step 2: Assess the risk of each third party
How does the simplified scoring matrix work?
The scoring combines two dimensions, each rated from 1 to 4:
- Impact: what happens if this third party is compromised or unavailable?
- Security maturity: what guarantees does the third party provide, and can we verify them?
Maturity plays the role of probability in a classic risk matrix: the lower it is, the more likely an incident. These two ratings are then combined into a single score that serves only to prioritise, not to decide on its own.
Impact scoring (1-4)
Impact is judged on what the third party can reach, never on its size or price. A free utility that runs in your build pipeline with a write token is a 4, while a SaaS billed several thousand euros that only sees public data stays at 2. When hesitating between two levels, pick the higher one: an impact rating that is too low takes the third party off the radar for months.
| Score | Impact | Criteria |
|---|---|---|
| 4 - Critical | Loss of sensitive data, major outage | Access to customer data, credentials, prod |
| 3 - High | Significant degradation | Access to internal data, staging |
| 2 - Medium | Limited impact | Non-sensitive data, dev/test |
| 1 - Low | Negligible | No data, no system access |
Security maturity scoring (1-4)
Maturity is rated on the evidence obtained, not on stated intentions. The difference between a 3 and a 2 comes down to one criterion: do you hold a dated, enforceable document, or only a marketing page? Level 1 is reserved for third parties that do not answer or refuse to communicate: the absence of an answer is information in itself, and it weighs as much as an unresolved incident.
| Score | Maturity | Indicators |
|---|---|---|
| 4 - Mature | Excellent | SOC 2 Type II (an independent audit report on the supplier's controls), ISO 27001 (the international information security management standard), recent pentest (penetration test), SBOM provided |
| 3 - Good | Satisfactory | Certifications in progress, documented practices |
| 2 - Basic | Insufficient | No certification, opaque practices |
| 1 - Weak | Worrying | No answer, unresolved past incidents |
Level 4 reads as a complete set: you need all the indicators of the row, one is not enough. A third party that presents several of them, but not all, and whose practices are documented and backed by dated documents, ranks 3. A SOC 2 already obtained does not fall under the "in progress" of level 3: it counts as an indicator of level 4.
Mind the direction of the scales: here 4 is the best maturity score, whereas in the evidence hierarchy of step 4, level 1 is the best. The two numberings are not comparable: a third party with maturity 4 is one for which you hold level 1 or 2 evidence.
How is the risk score calculated?
The formula deliberately inverts maturity (5 - Maturity) so that an exemplary third party never brings the score down to zero: a fully mature third party keeps a score equal to its impact, and so stays visible in the inventory. The result ranges from 1 to 16 and has no absolute value: it serves to order your list of third parties, not to produce an indicator to present to the executive committee.
Risk score = Impact × (5 - Maturity)| Score | Level | Action |
|---|---|---|
| 12-16 | Critical | Block or mitigate immediately |
| 8-11 | High | Action plan within 30 days |
| 4-7 | Medium | Enhanced monitoring |
| 1-3 | Low | Standard follow-up |
What does a scoring example look like?
These four rows show the most counter-intuitive result of the method: the small service provider ranks ahead of Auth0 and of the analytics SaaS, even though it costs the least and appears in no architecture diagram. It combines production access with weak maturity, the exact combination the score is meant to bring to the surface. This is why an inventory limited to contracted suppliers often misses the highest risk.
| Third party | Impact | Maturity | Score | Level |
|---|---|---|---|---|
| Auth0 | 4 | 4 | 4 | Medium |
| New analytics SaaS | 3 | 2 | 9 | High |
| Popular npm package | 2 | 3 | 4 | Medium |
| Small service provider | 4 | 2 | 12 | Critical |
What about business criticality and substitutability?
The impact × maturity scoring does not capture everything. Two third parties with the same score can have very different risk profiles depending on their business criticality and substitutability. A SaaS with low maturity but easy to replace does not have the same profile as a mature SaaS that cannot be replaced quickly.
| Criterion | Question to ask | Effect on the decision |
|---|---|---|
| Substitutability | Can you change supplier in under 30 days? | If not, higher risk even if maturity is fine |
| Concentration | Is this third party a single point of failure (SPOF)? | If so, plan business continuity |
| Reversibility | Can the data and configurations be exported? | If not, lock-in is a strategic risk |
| Technical coupling | Is the integration deep or peripheral? | Deep means a high migration cost |
Step 3: A questionnaire to assess critical third parties
This questionnaire has 20 questions across 5 domains. Each row pairs a question with the expected evidence: it is this second column that does the work. A question asked without evidence demanded produces a reassuring, unverifiable answer. Send the questionnaire in writing, keep the answers dated, and treat a dodged question as a negative answer.
Authentication and access
This domain determines who can get into the supplier and how fast you can cut off access. Question 4, on revocation, is easy to forget although it governs your reaction when an administrator leaves or a token leaks. A supplier that cannot revoke an API key within an hour imposes its own reaction time on you.
| # | Question | Expected evidence |
|---|---|---|
| 1 | Do you support SSO (SAML/OIDC)? | Technical documentation |
| 2 | Is MFA (multi-factor authentication) available/mandatory? | Admin console screenshot |
| 3 | How do you manage API access (OAuth, rotated API keys)? | API documentation |
| 4 | What is the access revocation process? | Documented procedure |
Data security
Questions 5 to 8 follow the data lifecycle: where it lands, how it is protected, who reads it, and what becomes of it at the end of the contract. Question 7 is the most revealing, because encryption at rest does not protect against legitimate access by the supplier's technical support. Question 8 serves your reversibility: without a written purge procedure, your data outlives the contract.
| # | Question | Expected evidence |
|---|---|---|
| 5 | Where is the data physically stored? | Location documentation |
| 6 | Is data encrypted at rest and in transit? | Technical attestation |
| 7 | Who has access to customer data (support, dev, ops)? | Access policy |
| 8 | How is data deleted at the end of the contract? | Purge procedure |
Secure development
This block measures whether the supplier applies at home what you are trying to set up at yours. The acronyms: SDLC (software development lifecycle), SAST and DAST (static and dynamic code analysis) and SCA (dependency analysis). Question 11 is decisive: your supplier also inherits transitive dependencies, and its risk becomes yours. Question 12 on the SBOM may get no positive answer, but a reasoned refusal beats silence, and a supplier that agrees to provide one lets you cross-check its components against your own vulnerability alerts.
| # | Question | Expected evidence |
|---|---|---|
| 9 | Do you have a documented secure SDLC? | Process documentation |
| 10 | Do you run security tests (SAST, DAST, pentest)? | Anonymised report |
| 11 | How do you handle vulnerabilities in your dependencies? | SCA policy |
| 12 | Do you provide an SBOM for your products? | SBOM file |
Incident management
These four questions prepare for the day the supplier is compromised. Look for a numbered, contractual deadline in answer to question 13: "quickly" does not let you meet your own notification obligations, notably the 72 hours of the GDPR (the EU General Data Protection Regulation, Article 33), a deadline that weighs on the data controller (you) from the moment it becomes aware of the breach. The supplier, as processor, only has to inform you "without undue delay": it is up to you to obtain a numbered deadline. Question 15 deserves asking even if you know the answer: the way a supplier talks about its past incidents says more than the content of the plan it sends you.
| # | Question | Expected evidence |
|---|---|---|
| 13 | What is your incident notification deadline? | Documented SLA (service level agreement) |
| 14 | Do you have an incident response plan? | Plan excerpt |
| 15 | Have you suffered security incidents in the last 24 months? | Disclosure if applicable |
| 16 | How do you communicate vulnerabilities in your products? | Security advisories page |
Compliance and certifications
A certification is not a guarantee of security: it is proof that an external auditor checked a declared scope on a given date. So always ask for the scope and the validity date, not only the logo. An ISO 27001 certificate whose scope covers the head office but not the platform you consume brings you nothing, and this is a case met with vendors that grew through acquisitions.
| # | Question | Expected evidence |
|---|---|---|
| 17 | Do you hold an ISO 27001, SOC 2, or equivalent certification? | Valid certificate |
| 18 | Do you run regular external security audits? | Audit attestation |
| 19 | How do you ensure GDPR compliance? | Signed DPA (data processing agreement) |
| 20 | Do you have a liability policy in case of breach? | Contractual clause |
Which questions apply to open source packages?
For open source dependencies, the classic questionnaire does not apply: there is nobody to send it to, and no obligation to answer. The assessment becomes an observation of public signals, which you collect yourself from the repository and the registry. The thresholds in the third column are orders of magnitude to adjust to the ecosystem: a stable Go project can go six months without a commit with no problem, whereas an npm package exposed to the browser becomes suspect much faster.
| Criterion | How to check | Recommended threshold |
|---|---|---|
| Active maintainers | Number of contributors with recent commits | > 2 active maintainers |
| Update frequency | Date of the last commit/release | < 6 months |
| Vulnerability coverage | Open CVEs (publicly catalogued vulnerabilities) without a fix | 0 open critical CVEs |
| OpenSSF score | OpenSSF Scorecard | > 7/10 |
| Transitive dependencies | Number and quality of sub-dependencies | Recursive audit |
| Licence | Compatibility with your project | Approved licence |
| Adoption | Stars, downloads, major users | Active community |
Which questions apply to SaaS?
For SaaS services, these five questions complete the general questionnaire. They are not about security in the strict sense but about the operational dependency you create: availability, API stability, isolation between customers. The question on API deprecation is expensive when left unasked, because a supplier that breaks its interfaces every six months imposes a permanent maintenance burden nobody budgeted for.
| Question | Why it matters |
|---|---|
| What is your availability SLA? | Impact on your own SLA |
| What is your API deprecation policy? | Maintenance of your integration |
| Do you offer isolated test environments? | Security of your tests |
| How do you handle multi-tenancy? | Isolation between customers |
| What is your regional coverage (GDPR, location)? | Compliance |
Step 4: Acceptable vs insufficient evidence
The quality of evidence varies with the type of third party. A SOC 2 Type II is relevant for a SaaS, but makes no sense for an open source project maintained by volunteers.
What evidence for contractual suppliers (SaaS, service providers)?
Evidence is ranked by who produced it. Verifiable evidence comes from an independent third party, declarative evidence comes from the supplier itself. The first table gives this hierarchy, the second turns it into concrete cases. Be strictest at the border between levels 2 and 3: that is where the temptation to settle for a completed questionnaire, hence a mere declaration, is strongest. This scale runs in the opposite direction to the maturity seen above: here, level 1 is the most reliable.
| Level | Type of evidence | Confidence |
|---|---|---|
| 1 - Verifiable | External audit report (SOC 2 Type II, ISO 27001) | 5/5 |
| 2 - Documented | Pentest reports, signed policies, DPA | 4/5 |
| 3 - Declarative | Completed questionnaire, supplier attestation (a signed statement) | 3/5 |
| 4 - Indirect | Public ratings (SecurityScorecard, BitSight) | 2/5 |
| 5 - None | "Trust us" | 1/5 |
| Domain | Acceptable evidence | Insufficient evidence |
|---|---|---|
| Encryption | TLS configured + documented cipher suites | "Yes, we encrypt" |
| Access control | Audit logs + RBAC (role-based access control) policy | "Only admins have access" |
| Pentest | Anonymised report with date and scope | "We run tests" |
| Incidents | Public security advisories page | "We never had a problem" |
| MFA | Screenshot of the mandatory configuration | "It's available" |
What evidence for open source components?
For open source, traditional evidence does not apply. Focus on the project's maturity signals:
| Signal | Source | Confidence |
|---|---|---|
| SBOM + signed provenance | Artifact with signed provenance | 5/5 |
| Public security policy | SECURITY.md, disclosure process | 4/5 |
| OpenSSF Scorecard > 7 | scorecard.dev, deps.dev | 3/5 |
| Release history | Regularity, changelogs, CVEs fixed quickly | 3/5 |
| Identifiable maintainers | Public profiles, known affiliation | 2/5 |
| Popularity alone | GitHub stars, npm downloads | 1/5 |
Step 5: Decide and act
What does the decision tree say?
Once the score is calculated, the tree below guides the decision. For high risks (≥8), three options are open to you: mitigate the risk with compensating controls, transfer it (insurance, contractual clause), or refuse the third party if no mitigation is acceptable.
What are the typical mitigation actions?
These eight actions are compensating controls: they do not fix the third party's weaknesses, they limit your exposure. On a critical third party, you combine several. The first six are technical and depend on you alone, so they can be applied immediately. The last two go through a contract or documentation work, with delays counted in weeks: start with the technical ones, then open the negotiations without blocking the integration on them.
| Action | When to apply it | Example |
|---|---|---|
| Privilege reduction | Any third party that receives access | Minimal OAuth scopes, dedicated account without admin rights |
| Network isolation | Low-trust third party | Dedicated VPN, separate VPC, egress filtering, outbound proxy |
| Data limitation | Sensitive data exposed | Pseudonymisation, minimisation, tokenisation |
| Integrity verification | Third party feeding your build | Lockfiles, signatures, SLSA attestations |
| Enhanced monitoring | Any critical third party | Alerts on abnormal behaviour, on advisories, on maintainer changes |
| External backup | Dependence on a single supplier | Mirroring, local cache, fallback provider |
| Contractual clause | Financial risk | SLA, penalties, insurance |
| Exit plan | Strong dependence | Migration documentation |
Example: reducing the risk of an analytics SaaS
Take the New analytics SaaS from the scoring table (score 9, High level). Three actions from the previous table bring its exposure down to an acceptable level without waiting for the supplier:
- Isolation: route calls through your backend, with no third-party script in the customer's browser.
- Data limitation: never send user identifiers, only internal identifiers.
- Integrity verification: watch for changes to the script or SDK with integrity checks.
Which weak signals should you watch on open source?
Beyond the Scorecard score, some signals must trigger an in-depth review. The Polyfill.io affair (2024), already cited above, illustrates the first signal in the table: after an ownership change, the code was modified to inject malicious content into more than 100,000 sites according to Sansec.
| Warning signal | How to detect it | Recommended action |
|---|---|---|
| Main maintainer changed | Git history, announcements | Review the new maintainer |
| Namespace/repo transfer | npm unpublish + republish, GitHub transfer | In-depth analysis |
| Drop in activity then sudden release | Commit history | Inspect the release diff |
| Popular package, few maintainers | Contributors on GitHub | Plan an alternative or a fork |
| Suspicious postinstall scripts | package.json, npm audit | Block or audit |
| Obfuscation, surprising dependencies | Code inspection | Refuse or isolate |
| No SECURITY.md | Repo root | Prefer better-documented alternatives |
When is the technical assessment not enough?
The technical assessment is necessary but not sufficient for critical third parties. Some aspects belong to the contract and must be negotiated with procurement, legal or the CISO.
| Need | Why it matters | Who negotiates |
|---|---|---|
| Incident notification clause | Be informed quickly in case of a breach | Legal / CISO |
| DPA (Data Processing Agreement) | GDPR compliance for personal data | DPO (data protection officer) / Legal |
| Availability SLA | Impact on your own customer commitment | Procurement / Product |
| Right to audit | Being able to verify the supplier's practices | CISO / Compliance |
| Reversibility clause | Being able to recover your data and migrate | Procurement / Tech |
| Location commitment | Knowing where data is processed | DPO / CISO |
How do you qualify a third party in 10 minutes?
Need to validate a SaaS or a library quickly? Here is the express procedure for a first qualification.
-
Identify the type of third party
SaaS, package, API, service provider? This determines the evidence to ask for.
-
Assess the exposure
What data or access are you entrusting to it? Personal, financial, credentials, admin?
-
Determine the criticality
Is it critical for production or the business? Does an outage block users?
-
Look for the minimum evidence
- SaaS: SOC 2, ISO 27001, a public security page?
- OSS: Scorecard > 7, identifiable maintainers, regular releases?
-
Assess the possible isolation
Can you limit access, filter the data, plan a fallback?
What does the quick qualification produce?
The quick qualification produces a routing decision, not a final verdict. Two outcomes out of four allow the integration, the third suspends it for the time of a review, only the last refuses it. The most useful result is "In-depth review": it lets you say no to the immediate request without saying no to the project, and send people to the full questionnaire rather than to an emotional arbitration. Record the decision and its date in the inventory, which will save you from having the same debate again six months later.
| Result | Criteria | Action |
|---|---|---|
| Go | Low impact, evidence OK, replaceable | Integrate without delay |
| Go with mitigations | Medium impact, partial evidence | Integrate with compensating controls |
| In-depth review | High impact, insufficient evidence | Full questionnaire, CISO validation |
| No go | Critical impact, no evidence, no isolation possible | Refuse or look for an alternative |
How do you build TPRM into your processes?
In the development cycle
An isolated TPRM fades away fast. The three moments below are those where the approach anchors itself in gestures the team already makes: adding a dependency, running the CI/CD pipeline, the periodic review. The most profitable point is the second, because it is automatic and does not depend on the team's discipline. The other two require a human decision and degrade as soon as the workload rises.
-
Before adding a dependency
- Check the OpenSSF Scorecard score
- Consult the list of approved/banned packages
- For a new SaaS: trigger the assessment process
-
In CI/CD
- Block packages with critical CVEs
- Alert if a dependency changes maintainer
- Generate the SBOM at every release
-
Periodically
- Review critical third parties (quarterly)
- Update the inventory
- Check for new certifications/incidents
Which tools can automate the work?
No tool does TPRM for you: they feed the inventory and trigger alerts, the decision stays human. The row that changes a team's life the most is the first: without an SBOM generated at every build, the package inventory is rebuilt by hand and is therefore permanently wrong. The commercial solutions in the last two rows only pay off from a few dozen contracted suppliers; below that, a spreadsheet versioned in a Git repository does the job.
| Need | Tools |
|---|---|
| Package inventory | SBOM (Syft, in French), Dependency-Track |
| Open source score | OpenSSF Scorecard, deps.dev |
| Vulnerabilities | Grype, Trivy, Snyk |
| SaaS inventory | CASB (cloud access security broker), TPRM solution (OneTrust, SecurityScorecard), SaaSBOM |
| Questionnaires | Google Forms, Typeform, TPRM solutions |
Worked example: assessing a new SaaS
Imagine your team wants to integrate a new transactional email service: EmailService.
Quick qualification (10 minutes)
Three questions, asked in under ten minutes, are enough to decide between "we integrate" and "we assess seriously". The second row is the one that tips the file: a transactional email service carries password reset links, so access to its console lets someone take over user accounts without ever touching your application. The mention "SOC 2 on their website" remains at this stage a marketing claim, not evidence.
| Quick question | Answer | Note |
|---|---|---|
| Data exposed? | Emails, user names | Personal data |
| Criticality? | Sending password resets | Critical |
| Visible certifications? | SOC 2 on their website | To be verified |
Result: critical third party, so a full assessment is needed.
Sending the questionnaire and receiving the answers
The 20-question questionnaire goes to the sales contact, who relays it to their security team. Send it in writing, with an expected reply date, and ask for the attachments along with the answers: a supplier that promises the pentest report "on request" and never sends it costs you three weeks. Allow several working days for a complete reply.
Analysing the answers
The analysis does not consist of counting positive answers but of isolating the gaps. The two points of attention below, optional MFA and the missing SBOM, are not of the same nature: the first is an actionable weakness the supplier can fix on your tenant, the second is a structural limit you compensate for with your own monitoring. This distinction determines what goes to negotiation and what goes to the follow-up plan.
| Criterion | Answer | Assessment |
|---|---|---|
| SSO/OIDC | Yes with SAML2 | OK |
| Mandatory MFA | Available but not mandatory | To negotiate |
| SOC 2 Type II | Certified, report available | OK |
| GDPR/DPA | Standard DPA provided | OK |
| SBOM | Not provided | To follow |
| Breach notification | 72h contractual | OK, to tighten (mitigation 2) |
| Recent pentest | Yes, anonymised report provided | OK |
Scoring and decision
The supplier is serious, and the score is still high: this is the expected behaviour of the formula, since impact caps at 4 as soon as a third party touches authentication mechanisms. A high score therefore does not mean "bad supplier", it means "monitoring and counterparts". The three mitigations chosen are deliberately modest and negotiable: they must fit within the purchasing cycle, not block it.
- Impact: 4 (sensitive data, credentials)
- Maturity: 3 (SOC 2 Type II and recent pentest, but level 4 is not reached)
- Score: 4 × (5-3) = 8 → High
To justify maturity 3, go back to the indicators table. The third party presents two level 4 indicators: an available SOC 2 Type II and a recent pentest whose anonymised report was provided. At least two are missing: the SBOM is not provided, and the questionnaire mentions no ISO 27001.
Since level 4 requires all the indicators, it is refused, and level 3 is kept: the practices are documented and backed by dated documents. The optional MFA is not among the maturity indicators, it weighs on the risk assessment and on the negotiation. A looser reading, where a single indicator would suffice, would lead to a maturity of 4 and a score of 4.
Decision: accept with mitigations:
- Negotiate mandatory MFA for admins
- Ask for a breach notification clause < 48h
- Schedule a first review in 3 months, the cadence for critical third parties
When to say no: an example of refusal
A TPRM approach that has never produced a refusal is not an approach, it is a formality. The case below brings together the reason that justifies a no go: not an identified weakness, but the impossibility of verifying anything. Faced with a third party that refuses to provide evidence, no compensating control applies, since you do not know what you are protecting yourself against.
Key points
Six ideas to keep:
- TPRM concerns technical teams: as soon as you run
npm install, you integrate a third party - Inventory first: you cannot protect what you do not know (SaaS, packages, service providers)
- Score by impact × maturity: focus effort on critical, low-maturity third parties
- Ask for evidence, not declarations: a SOC 2 report is worth more than a "yes, we secure it"
- Automate where possible: SBOM, Scorecard and CVE alerts belong in CI/CD
- Expected evidence (SOCLE-FRN-GEN-2): supplier security assessment files for critical suppliers, backed by a tiering of third parties by criticality (SOCLE-FRN-GEN-1)
Knowledge check
Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: Responding to a supply chain incident: scope, containment, notification
A new full quiz with random questions
Work again only on the questions you missed