In February 2025, a certificate authority moved an internal archive from behind a VPN to a publicly accessible network without reviewing the resulting attack surface. This exposure went undetected for over a year until June 2026, with a fix implemented the following month. During this time, customer names, business contact details, and sensitive documents like passports and driver's licenses were exposed.
If you're a Vendor Due Diligence Analyst, the question isn't whether this could happen to one of your vendors. It's about determining the level of scrutiny a vendor's infrastructure change requires and when to apply it. This guide provides a decision path to help you make informed choices.
The Decision You Are Facing
When a vendor informs you, or you discover, that they've migrated a system holding your data, you must decide how thoroughly to investigate. This could be through a questionnaire update, a release note, or an attestation refresh. You have three options: accept the vendor's attestation, request targeted evidence, or trigger a full reassessment. Each choice involves costs in analyst time and vendor goodwill. Over-reviewing wastes resources; under-reviewing can lead to prolonged exposure, as seen in the case of the unintentional registration endpoint.
Key Factors Affecting Your Choice
Consider these four questions before deciding on a path:
1. Did the change alter network exposure? Moving a system from private to public access is a significant event. In this incident, accessibility changed without a security review. Any change in who can access a system should be treated differently from changes in its operation.
2. What data is involved? Sensitive documents like passports and utility bills increase the stakes. Such documents can be used for identity verification, making the potential for downstream fraud a critical concern.
3. Does the system have inherited controls? In this case, the self-registration feature wasn't intended for an archive system, leading to accounts without multifactor authentication. Controls that depend on a system's original context may not survive a change. Verify what the vendor assumed was protecting the system and whether those assumptions remain valid.
4. Can the vendor detect misuse? Detection took over a year, and the initial conclusion was incorrect. A vendor's monitoring and triage capabilities determine how long an exposure persists.
Path A: Accept the Attestation and Note the Change
Choose this when the change is internal, network exposure is unchanged, and the system holds low-sensitivity or no personal data.
Then do this: Log the change, confirm the vendor's existing assurance still reflects the architecture, and schedule a review for the next cycle.
What drives it: Your Criticality Classification of the vendor. SR 23-4 expects risk management to scale with the criticality of the activity, ensuring effort is proportional.
Warning sign that moves you off this path: If the vendor can't clearly state whether exposure changed, escalate to Path B.
Path B: Request Targeted Post-Change Evidence
Choose this when network exposure changed or might have changed, the system holds personal data or identity documents, or the vendor supports a critical function for you.
Then request:
- Evidence of a security review of the new attack surface
- Confirmation of authentication paths and multifactor authentication application
- A statement on system monitoring and alert mechanisms
- A description of web application firewall or equivalent controls
What drives it: ISO 27036 requires ongoing security controls through changes, and the EBA Outsourcing Guidelines expect continuous oversight. Use your Right to Right to Audit if the vendor resists providing evidence.
Decision point: If the vendor provides clear evidence, return to normal monitoring. If the evidence is lacking, move to Path C.
Path C: Trigger a Full Reassessment and Contain
Choose this when exposure is confirmed, no pre-migration review occurred, or your data is in a system now known to be exposed.
Then do this:
- Invoke Vendor Breach Management and start Incident Escalation
- Compare your contract's Notification Timeline with when the vendor informed you
- Conduct a full reassessment of the vendor, focusing on change management
- Advise stakeholders on downstream risks
- Decide if Wind-Down Plan triggers or Substitutability questions are relevant
What drives it: If the vendor supports a critical function, regulatory expectations on incident handling may apply. Confirm with compliance.
Summary Matrix
| Factor | Path A: Accept | Path B: Targeted Evidence | Path C: Full Reassessment |
|---|---|---|---|
| Network exposure changed | No | Yes or unclear | Confirmed exposure |
| Data sensitivity | Low or none | Personal data or ID documents | ID documents or regulated data affected |
| Pre-change security review | Not required | Requested | Absent or unproven |
| Vendor detection capability | Established | Verify | Failed or delayed |
| Analyst effort | Minimal | Moderate | High |
| Primary reference | SR 23-4 proportionality | ISO 27036, EBA Outsourcing Guidelines | Vendor Breach Management, Notification Timeline |
| Next step | Log and schedule | Evidence review | Escalate and reassess |
The lesson from this incident isn't just that one vendor failed. It's that a single unreviewed change in network exposure, combined with a control that didn't adapt, exposed identity documents for over a year. Build your vendor change notice intake around this trigger, and prioritize assessing exposure first.
