When hackers accessed payment data affecting over 1.2 million people at Latvia's Road Traffic Safety Directorate (CSDD), the immediate question wasn't just "how did this happen?" It was "whose fault is this?" The agency's chief pointed to Tet, the telecom company managing parts of CSDD's IT infrastructure. Tet countered that investigators needed to determine exactly which systems failed before assigning blame. This finger-pointing highlights a question every GRC leader managing third-party IT services must answer: when your vendor's monitoring fails to catch an intrusion, who owns the breach?
The Question at Hand
Should government agencies and regulated entities treat third-party IT service providers as extensions of their own security posture, or as independent contractors with separate accountability? CERT.LV found that several mandatory cybersecurity requirements hadn't been met before the CSDD attack. The agency had a five-year contract with Tet covering IT infrastructure maintenance and monitoring, including firewall and incident-monitoring functions. Yet Tet didn't detect the intrusion. CSDD employees discovered it themselves and stopped it within hours.
The practical question: if you've contracted monitoring to a vendor, are you still responsible when they miss a breach? And how do you structure contracts and oversight to ensure you're not exposed?
The Case for Vendor Accountability
The argument for holding vendors accountable is straightforward: you're paying them to perform a specific security function. If they fail, they should bear the consequences.
CSDD's position reflects this view. The agency's chief noted that Tet was responsible for certain firewall and incident-monitoring functions but didn't alert CSDD to the intrusion. If you contract a service provider to watch for threats and they don't see one, that's a service failure. Your SLA should reflect this. Many organizations include breach detection timeframes in their vendor contracts, with financial penalties for missed incidents.
This approach aligns with how you'd handle any other contracted service. If your payroll provider miscalculates taxes, they're liable. If your cloud host suffers an outage that violates uptime commitments, you get credits. Why should security monitoring be different?
From a compliance perspective, this model also creates clearer audit trails. Under ISO/IEC 27001, control A.5.19 requires you to establish and agree upon information security within supplier agreements. If your vendor agreement explicitly assigns breach detection responsibilities to the provider, your Statement of Applicability can point to that contractual control. During a SOC 2 Type II audit, you can demonstrate that monitoring obligations were formally transferred and that you had processes to verify vendor performance.
The practical benefit: this shifts some operational burden. You don't need to duplicate every monitoring function in-house if you've got contractual coverage. For smaller agencies with limited security staff, this can be the difference between having monitoring at all or going without.
The Case for Agency Ownership
The counterargument is equally compelling: you can't outsource accountability. CERT.LV reported that the hackers exploited a vulnerability in a CSDD system exposed to the internet. No vendor contract changes the fact that CSDD chose what to expose, how to configure it, and whether to implement mandatory cybersecurity requirements.
Tet's position captures this: investigators need to determine how and when attackers gained access, which systems were compromised, and where security measures failed before assigning responsibility. The company manages only certain parts of CSDD's IT infrastructure, not the entire network. If the vulnerability was in a system outside Tet's scope, or if CSDD failed to patch a known issue, vendor monitoring wouldn't have prevented the breach.
This view aligns with regulatory reality. Under the General Data Protection Regulation, the data controller (CSDD) remains responsible for data protection even when using processors or service providers. Article 28 requires you to use only processors that provide sufficient guarantees, but you can't transfer your Article 32 obligation to implement appropriate technical and organizational measures. If CSDD had been subject to GDPR's 72-Hour Notification Requirement, they couldn't have avoided it by blaming Tet.
The NIST Cybersecurity Framework (CSF) 2.0 takes a similar stance. The Govern function includes GV.SC-03: "Cybersecurity and privacy supply chain risk management is integrated into acquisition and procurement processes." Notice it says "integrated into," not "replaced by." You're expected to manage vendor risk, not assume vendors manage it for you.
Practically, this means you need visibility into what your vendors are actually doing. If Tet was monitoring firewall logs, did CSDD review those logs independently? Did they require regular reports on threats detected and blocked? Did they test Tet's response to simulated incidents? If the answer is no, then CSDD didn't validate that the contracted service was working. That's an oversight failure, not a vendor failure.
Where Practitioners Actually Land
Most GRC leaders adopt a hybrid model: contractually assign specific functions to vendors, but maintain independent validation and ultimate accountability.
Here's what that looks like in practice. Your vendor contract specifies exactly what the provider monitors, what constitutes a reportable incident, and what the notification timeline is. You include the right to audit their performance and review logs. You require monthly or quarterly reports showing threats detected, response times, and any gaps in coverage.
Then you build your own controls around that. You don't duplicate their monitoring, but you do validate it works. You run periodic penetration tests without telling the vendor when, to see if they detect the activity. You review their incident reports against your own asset inventory to confirm they're watching the right systems. You maintain a Computer Security Incident Response Team that can act independently if the vendor misses something.
This approach satisfies auditors because you can demonstrate both contractual controls and validation controls. It satisfies regulators because you haven't abdicated responsibility. And it gives you practical protection: if your vendor misses a breach, you've got a second chance to catch it.
The CSDD incident shows what happens when validation is missing. CSDD employees discovered the attack themselves, which suggests they had some independent monitoring capability. But if they'd been routinely testing whether Tet's monitoring was working, they might have found the gap before attackers did.
Our Take
You can't outsource ultimate accountability for cybersecurity, even when you've contracted specific functions to vendors. The regulatory frameworks are clear on this. GDPR, NIST Cybersecurity Framework (CSF) 2.0 2.0, and ISO/IEC 27001 all place responsibility on the organization, not its suppliers.
But that doesn't mean vendor accountability is meaningless. Structure your contracts to create enforceable obligations. Include specific detection and notification requirements. Build in financial consequences for failures. Then validate that the vendor is meeting those obligations through independent testing and review.
The mistake CSDD made (based on available information) wasn't contracting with Tet for monitoring. It was apparently not validating that the monitoring worked. CERT.LV's finding that mandatory cybersecurity requirements weren't met suggests gaps in both vendor performance and agency oversight.
If you're managing third-party IT services, ask yourself: if your vendor missed a breach tomorrow, could you demonstrate to regulators that you'd done everything reasonable to prevent and detect it? If the answer depends entirely on what your vendor did, you've got a gap. Close it before someone else finds it.
