“Our vendor handles that” should start a conversation….not end it.
“We have a vendor handling that.”
I have heard that sentence many times over the years. Sometimes it reflects a well-managed partnership. Other times, it leaves an important question unanswered:
Who inside the company is making sure it is actually being handled?
Recently, while listening to one of the exceptional CISO Series podcasts, I heard someone bring up shared responsibility. I cannot recall the speaker or episode, so I am paraphrasing the point as I remember it… bringing in a third party to perform work does not remove your organization’s responsibility for oversight.
It resonated with me because I have said much the same thing for years. In today’s IT and cybersecurity landscape, that reminder feels more relevant than ever.
We depend on outside providers for infrastructure, applications, monitoring, security, backups, and support. Those partnerships can be essential. But someone inside the organization still needs to understand what is covered, verify performance, and act when something requires attention.
A delivered service and a protected business are not automatically the same thing.
The FBI example… and the question it raises
In October 2026, Reuters reported that the FBI removed a contractor following a breach. An FBI official attributed the incident to a contractor’s failure to apply a security patch. Reuters’ sources identified the contractor’s organization as Accenture and the platform as Oracle PeopleSoft; the FBI did not publicly identify either. Accenture said it would continue supporting the FBI.
That reporting raises the oversight question at the heart of this article.
If a contractor was responsible for applying a critical patch, how was completion verified? What process would identify an overdue patch? Who would receive the escalation, and who had the authority to act?
Those are questions, not conclusions about what happened inside the FBI. Public reporting does not give us the complete picture.
But my view is straightforward… the contractor should answer for any failure within their responsibilities, and the organization should examine whether its oversight was sufficient.
Removing a contractor may address an individual failure. The organization also needs to understand whether the surrounding process can catch the next one.
The buck still stops with leadership when it comes to governing the organization’s risk.
Target–> a vendor entry point, an internal responsibility
The 2013 Target breach offers another example.
A Senate Commerce Committee staff report, drawing on public reporting and expert analysis, described attackers entering through stolen vendor credentials. It also identified apparent failures involving internal network separation and responses to security alerts. The report used qualified language because aspects of the incident remained unconfirmed.
The lesson I take from it is that third-party risk extends beyond evaluating the third party.
Your organization also controls what access it grants, what that access can reach, and how suspicious activity is handled.
A vendor can become the entry point. Your internal controls still matter to what happens next.
Where I believe shared responsibility breaks down
The gaps do not always make headlines. They can develop quietly in everyday operations.
A monitoring provider watches the endpoints it knows about. Your team deploys new devices but never confirms they are enrolled.
A backup service reports successful jobs. Nobody tests whether the business-critical application can actually be restored.
A vulnerability provider sends its findings. The report arrives, but nobody owns remediation or verifies that the fix worked.
In each example, someone may have completed an assigned task while the larger objective remains unmet.
That’s why “they’re handling it” needs a follow-up… What are they handling, what remains ours, and how do we know both sides are doing their part?
What I believe meaningful oversight looks like
Oversight does not require repeating every task the provider performs. It requires enough visibility to make informed decisions.
At a minimum, I want clear answers to these questions:
- Coverage: Which systems and services are included, and which are excluded?
- Ownership: Who owns each responsibility on both sides?
- Verification: What evidence shows that the work is complete and effective?
- Escalation: What happens when a deadline is missed or a control fails?
- Follow-through: Who tracks corrective actions through closure?
- Change: How do new applications, locations, and acquisitions enter the process?
The answers need to remain current after the agreement is signed.
A monthly report helps only if someone reviews it. An escalation helps only if someone responds. A finding helps only if someone makes a decision and follows through.
Accountability ALWAYS runs both ways
Providers have real obligations. They should deliver the agreed service, communicate problems, and answer for failures within their scope.
Customers also need to participate.
We cannot leave urgent recommendations unanswered, fail to disclose new systems, or withhold necessary approvals and expect the relationship to work.
Nor can leadership assign an internal owner without giving that person sufficient time, authority, and access to information.
Shared responsibility needs named owners and a working process. Otherwise, assumptions can fill the space where accountability should be.
Your company still has to lead
When an incident happens, your employees and customers will look to your organization for answers and action.
The provider’s role will matter. So will your organization’s preparation, decisions, and response.
That is why I believe outsourcing should strengthen our ability to manage risk while preserving active internal oversight.
Bring in the expertise. Build strong partnerships. Hold providers to their commitments… and keep your own.
The work may be outsourced, but the responsibility to understand, verify, and lead stays with your organization.
