The TPRM tragedy of commons
Without the right connective tissue between the two functions, risks are going to fall through the cracks. Third-party risk management (TPRM) has historically been one of the most common areas to get the short shrift from the disconnect, and that gap is poised to intensify in the post-Mythos era.
Further complicating the issue is that you’ve often got the vendor management office on their own island, and then the actual business owner who has the relationship with the third party but who may not see the security aspect as something they need to actively manage. All of these connections—without any clear line of security responsibility—contributes to this sort of tragedy of the commons where we all “own” this, but nobody really does.
The result is what we at Bitsight like to call the no-man’s land of TPRM. Before Mythos, this operational desert created regrettable inefficiency and elevated risky situations. Now, the no-man's land could potentially become the weakest link of cyber risk management. It will delay closing exploitable exposures in an era where attackers don’t distinguish between your internal systems and your vendors’ systems. If it's interconnected, then it’s all one exposed surface to them.
How the TPRM no-man’s land holds back cyber resilience
The shift to cyber resilience—especially in third-party exposure context—demands better coordination between the GRC and the SOC.
When these teams operate in separate systems with different vocabularies, the organization lacks a shared understanding of supply chain risk. Security teams end up playing whack-a-mole with individual issues as they surface rather than addressing root causes. What’s more, vendor ecosystems and relationships are constantly changing, as are supply chain exposure levels. Without cohesive, operational vigilance that’s backed by continuous monitoring of third-party systems, the entire supply chain is left decidedly non-resilient.
What needs to change
Boards of directors and CEOs are asking questions about how their firms can get their cyber risk infrastructure Mythos-ready. There's a lot of work to do on many fronts, but one of the big fixes starts with addressing the TPRM no-man's land. GRC is the natural setter of business context for the whole organization, so it makes sense for it to take the lead here.
SOC operators keep their fingers on the pulse of the threat environment, but they don’t know the nuances of which third parties and assets are most critical to business initiatives. GRC can help them answer the important questions that will direct where they prioritize their threat hunting and remediation, such as: What really matters to the business? Which vendors would cause serious disruption if compromised? Which relationships involve the crown jewels?
The real trick is mapping this knowledge out in a way that can be easily operationalized on the daily, ideally directly within the automations that modern SOCs depend on. This is no longer something that can be communicated by email or a dashboard.
Closing the translation gap
The SOC speaks in telemetry. They’ve moved way beyond the world of red, yellow, and green risk levels on the simplified dashboard presented to the board. If GRC leaders want to meaningfully drive better TPRM results on a continuous basis, they’ll need to communicate priorities with evidence and context, translating those priorities into the signals the SOC needs to watch out for and the workflows they need to trigger when critical vendors are exposed.
And communication has to run in both directions. GRC tells the SOC which vendors and systems are critical to business operations. It also has to be ready to receive information when the SOC identifies which threats are relevant based on internal activity and external threat intelligence they’re gathering. The SOC can also provide valuable context about what responses are underway. When the SOC shuts down an API to a critical third party’s ecosystem because of suspicious activity, that information should freely flow back to GRC so they can communicate with the vendor and adjust policies accordingly. GRC becomes the intermediary between security operations and vendor management, translating real-time threat response into supplier conversations.
AI can accelerate this whole process, including automating vendor assessments, triaging exposure data, correlating risks with active threats, and routing workflows to the right teams. But AI is only as good as the data feeding it. Without business context from GRC, it can't distinguish what's urgent from what's noise. Good data and good alignment between teams is key here.
Reframing the GRC role can be a real game-changer for chain resilience in a post-Mythos world:
- GRC sets the priorities.
- SOC executes on those priorities in real time.
- Vendor management gets the intelligence they need to have informed conversations with suppliers.
- And everyone operates from a shared understanding of what matters most.
Bitsight is investing heavily in this vision. We're building the connective tissue between GRC and SOC workflows, delivering threat intelligence in formats both teams can use, and enabling continuous validation of vendor controls. The goal is to help organizations move from managing risk in silos to building resilience across the entire supply chain.