A vendor blocks threat-led penetration testing of a shared SaaS platform
Helios Life is a life insurer with 900 staff, EUR 14 billion of assets under management and 620,000 policyholders. Its policy administration, claims and premium collection run on a single SaaS platform provided by a US-headquartered vendor that hosts more than 30 European insurers in one regional cloud tenancy, with data replicated across two availability zones in a single Member State. The insurer has designated 6 of its 148 ICT providers as supporting critical or important functions. For its first threat-led penetration test, scoped to the SaaS platform, the vendor refused on-premise testing and offered a summary of its own penetration test instead, citing group security policy and the risk to other tenants. It also declined to let internal audit review the SOC 2 report control descriptions, offering an executive summary under NDA. The 2019 contract has no audit rights, no exit plan and no notification service level. The testing budget for the year is EUR 400,000 and the first TLPT must be completed within 14 months.
1. How should the insurer respond to the vendor's refusal, and what would be unacceptable?
Read the worked answer
The refusal is a third-party risk event, not a technicality, and it cannot be accepted as the end of the matter.
What the framework requires. TLPT must cover critical or important functions and include live production systems; the entity must have contractual rights requiring provider cooperation, and Art. 30 requires provisions on access, inspection and audit by the entity and by supervisors. A 2019 contract with no audit rights is the root cause of the refusal; the insurer cannot rely on goodwill.
Sequence:
- Escalate formally in writing to the vendor's risk and account executives, citing cooperation obligations and the supervisory expectation.
- Run the legal route in parallel: amend the contract to add audit, access, testing-cooperation and information rights, and make it a condition of renewal. Raising the matter through the competent authority is better than fighting alone, particularly where the provider is subject to the oversight framework.
- Explore pooled or coordinated testing where several entities share the provider; the insurer remains responsible for scoping its own critical functions and for the outcome.
- Assess substitutability and concentration: one tenancy, thirty insurers, one Member State. Quantify it, record it in the register, and begin exit planning even if exit is remote.
- Document interim compensating measures: the vendor's own test summary, independent assurance with a bridge letter covering the period, and the insurer's own testing of what it controls - integrations, access management, reconciliation, data extracts.
Unacceptable outcomes: treating the vendor's summary as TLPT-equivalent, or silently removing the platform from scope. Either record a reasoned risk acceptance at management body level with compensating controls, or pursue the contractual and supervisory routes - and record which, and why.
2. Design a testing programme you can deliver with EUR 400,000 in 14 months across six critical providers.
Read the worked answer
Constraint-first design. EUR 400,000 will not fund full TLPT across six critical providers plus a broad programme. Tier and sequence.
- Baseline (weeks 1-8, low cost): vulnerability assessments and scans on internet-facing systems, configuration review of the identity and access path into the SaaS platform, and a tabletop of a claims-processing failure. These are core testing obligations and cheap relative to TLPT.
- Criticality tiering: rank the six by function criticality, substitutability and concentration. The SaaS platform leads on all three. Allocate roughly half the budget to it, but only once the contract dispute is resolved or a compensating route is agreed; a test the vendor blocks burns money.
- Scenario testing (months 3-6): for the other critical functions, run scenario tests that need no production intrusion - failover of premium collection, restore of claims data from backup, reconciliation integrity across the settlement chain. These expose the same failure modes TLPT would.
- TLPT (months 6-14): engage testers meeting the independence and competence requirements, scope from the critical function inward so the insurer's own interfaces are covered even where the vendor's core is not, and obtain competent-authority approval of the scope where required. Budget for remediation and retest, not just the test.
- Governance: a testing plan approved by the management body, findings logged in the same register as incidents and audit findings, and a rule that no finding closes without retest evidence.
Measure coverage, not activity. Report the percentage of critical functions tested with defined scenarios and the age of open findings, rather than the number of tests performed.
3. Only 6 of 148 providers are designated as supporting critical or important functions, and no business impact analysis links providers to functions. How do you test that designation before the supervisory review?
Read the worked answer
The risk is under-designation, and the burden of proof sits with the insurer. Six out of 148 is not implausible, but it is not defensible without a dependency map.
Method:
- Start from business functions, not from vendors. List the functions whose disruption would breach the insurer's tolerance for claims handling, premium collection, policy servicing and regulatory reporting.
- Map each function to the providers it depends on, including indirect dependencies: sub-outsourcers, identity and access management, data replication, network and security monitoring. A provider supporting security tooling can support a critical function without appearing in a procurement list.
- Apply a disruption test: would failure of this provider impair a critical function beyond the tolerated time, or require an unplanned substitution? If yes, it is in scope.
- Document exclusions with reasoning. Supervisors challenge exclusions more often than inclusions, and an undocumented 142 is the weakest part of the file.
The single SaaS platform supporting policy administration, claims and premium collection alone suggests the number may be low, because one provider can support several critical functions.
Governance: update the register of information at least annually and on change, keep the assessment as a dated document approved by the ICT risk function, and align it with the testing plan and the contract remediation plan so that all three use the same critical scope. If the assessment changes the number after the review, say so with the analysis attached rather than quietly reissuing the register.