Written by: Kamil Ponicki, Director of Talent Acquisition, Digital Colliers
The negotiator case is unusual in the headline but ordinary in the underlying control gap. A trusted third party held privileged access during an incident, and the bank's log trail treated that access as one undifferentiated blob of activity under a retainer contract. If your vendor-risk data model still looks like that, the conviction should worry you more than the ransom did.
This is a financial services problem specifically because DORA has been in force since 17 January 2025, and it puts ICT third-party risk squarely on the board. The regulator is going to ask who did what, on whose behalf, under which contractual purpose. If the answer requires a human to reconstruct it from Slack messages and a PDF SOW, you don't have a control. You have a story.
The negotiator case is a vendor-access logging failure
Strip out the drama and you have a straightforward pattern. A firm engaged a specialist under an incident response retainer. That specialist was granted elevated access to systems, wallets, or communications during a live event. The access was logged in the sense that the SIEM saw the sessions. It wasn't logged in the sense that anyone could later answer three questions:
- Which contract authorised this session?
- Which named human at the vendor performed the action?
- What business purpose was this action tied to?
Most banks I talk to can answer question one at the retainer level, not the session level. Question two collapses to a shared service account. Question three lives in someone's inbox.
That's the left-behind risk. It sits in the gap between your vendor management system, your IAM, and your SIEM. Nobody owns the join.
SIEM alone doesn't tell you what happened
SIEM tools are good at what they do. They collect events, correlate them, and flag anomalies. What they don't do, out of the box, is tell you that the session at 02:14 UTC was performed by an incident response contractor under retainer number 4471, for the purpose of ransomware negotiation, with a scope that did not include wallet key access.
Without owner-and-purpose tags on every privileged session, your SIEM is producing evidence you can't cross-examine. When the regulator or a court asks whether the vendor exceeded scope, you need to show scope as data, not scope as prose in a signed PDF.
The patching numbers already tell you how fragile the vendor perimeter is. Only around 3 to 5 percent of publicly disclosed vulnerabilities get patched within 30 days. Your third parties are running that same lag against you. If a compromised vendor session is the entry point, you want the forensic answer to be a query, not a war room.
The joins you actually need
At minimum, a defensible vendor access trail joins four things:
- The contract or SOW record, with a scope-of-work field that is machine readable, not a blob of legal text.
- The named individual at the vendor, tied to a per-human credential, not a shared account.
- The session log from the target system, with the credential ID as a foreign key.
- A purpose tag, set at session start, that pins the activity to a specific engagement or ticket.
Build those four joins and a lot of downstream problems get cheaper. Your DORA register queries stop being a quarterly fire drill. Your GDPR exposure gets easier to bound, which matters when fines run up to 20 million euros or 4 percent of global turnover. The SCHUFA ruling has already shown how aggressively courts will read data processing scope in financial contexts, and vendor access is processing.
What operators shipping this in 2026 tend to do
The pattern I keep seeing at firms that get this right is boring, and that's the point. They treat vendor identity as a first-class data model, not an afterthought bolted onto procurement. Every privileged session carries an owner, a purpose, and a contract reference before the session starts, enforced at the access broker.
The engineering effort is real but bounded. It's mostly schema, plumbing, and a few well-placed guardrails on the IAM side. The hard part isn't the code. It's getting procurement, security, and the ICT third-party function to agree that a retainer is not a single line in a spreadsheet.