Third-Party Risk
Assessing, contracting and monitoring the vendors your architecture now depends on.
5 to work through
-
beginner
A supplier provides an ISO 27001 certificate in response to your security assessment. What does the certificate actually tell you, and what does it not?
3 min answer -
intermediate
Your KYC verification vendor is down for six hours. Customer onboarding stops. The board asks why a vendor outage became your outage.
2 min answer -
advanced
A consumer finance platform depends on many third parties whose failures are its regulatory problem. What must the architecture provide?
2 min answer -
advanced
A supplier's compromise gives an attacker access to your systems. What should the architecture have done?
1 min answer -
advanced
In April 2022 a maintenance script at Atlassian permanently deleted 883 sites belonging to 775 customers inside 23 minutes, and the last customer was not restored until 18 April. Backups were fine and almost no data was lost. What made recovery the hard part, and what should that change in how you evaluate a vendor?
2 min answer
4 terms in this topic
Concentration Risk
The exposure created when many organisations, or many parts of one organisation, depend on the same provider - so that a single failure is correlated…
conceptFourth Party Risk
The dependencies of your dependencies, which you did not choose, may not know about, and remain accountable for.
conceptProcessor Instruction Boundary
The line at which a vendor stops acting only on your documented instructions and starts pursuing purposes of its own - which decides your lawful basi…
practiceThird-Party Risk Assessment
Evaluating the security, resilience and compliance posture of suppliers whose failure would become your incident.
Neighbouring topics
Regulatory & Data Protection Architecture
General material on designing under legal and regulatory obligation.
Privacy by Design
Data minimisation, default protection and purpose binding as structural decisions.
Lawful Basis & Purpose Limitation
Why you may hold the data, and why that forbids the second use somebody proposed.
Data Subject Rights
Access, correction, portability and erasure across systems that never planned for them.
Consent Architecture
Capturing, versioning and propagating consent to every system that acts on the data.
Data Residency
Keeping data within a jurisdiction, including backups, logs and support access.
Digital Sovereignty
Control over data, operations and the operator, beyond where the bytes physically sit.
Cross-Border Transfer
The legal mechanism that permits data to leave, and the architecture that respects it.
PCI-DSS Scoping
Segmentation and tokenisation to shrink what is in scope, because scope is the cost.
Healthcare Data Protection
PHI handling, minimum necessary access, and audit expectations in clinical systems.
Financial Services Regulation
Operational resilience, payment rules and supervisory expectations as design inputs.
Records Retention & Legal Hold
Keeping what must be kept, deleting what must go, and freezing both on demand.
Erasure vs Immutability
Deletion obligations against event logs, backups and ledgers designed never to forget.
Pseudonymisation
Separating identity from record, and the re-identification risk that remains.
Privacy-Enhancing Technologies
Differential privacy, secure enclaves and federated computation, and what each buys.
Regulatory Reporting Pipelines
Submissions with fixed deadlines, fixed formats, and a regulator who audits the lineage.
Sector Cloud Rules
Regulator expectations for cloud use, exit plans and material outsourcing notification.
Exit & Concentration Risk
Being able to leave a provider, and what the regulator asks when you cannot.
Geo-Restriction & Sanctions
Blocking access by jurisdiction, and the accuracy and evasion problems that come with it.