Third party risk management: why accountability cannot be outsourced w/ Tom Edwards & Mark Domzal

When something goes wrong with a vendor, the regulator does not knock on the vendor’s door. They knock on yours.

That is the central truth of third-party risk management, and it is one that most organisations still handle less well than they think.

In this tenth edition of Behind the Controls, I sat down with Mark Domzal, a Chief Audit Executive based in Chicago with over 20 years of experience across financial services, manufacturing, and consumer products. His career has spanned Big Four accounting and industry internal audit, covering the full range of risk: financial, operational, technology, security, and compliance.

As organisations become increasingly dependent on third parties, whether that is a SaaS platform holding customer data, a payroll provider processing sensitive transactions, or a hyperscaler running critical infrastructure, the question of who is truly accountable when something fails has never mattered more.

Mark’s answer is unambiguous.

"If there is one thing to take from this conversation, it is this: you can outsource the service, but you cannot outsource the risk."

The four risks most organisations underestimate

When auditors and risk leaders talk about third party risk, the conversation typically leads to cyber. It is the most visible, the most discussed, and the one most likely to feature in board presentations. Mark argues that framing is too narrow.

He breaks third party risk into four distinct categories, each with a different profile and a different potential for damage:

• Resiliency risk: if a large financial institution has its entire customer transaction processing mainframe sitting with a third party, any disruption to that vendor could have a catastrophic effect on revenue and mission-critical operations.
• Information security risk: storing, transmitting, or processing customer data or sensitive company information, such as trade secrets, through a third party creates obvious exposure. Absent access controls, encryption, or monitoring can result in significant losses and lasting reputational damage.
• Compliance or regulatory risk: ERP systems like SAP, Oracle, or NetSuite, and procurement platforms like Coupa, for example, are deeply embedded in financial controls. A failure here can mean inaccurate financial statements and everything that comes with that.
• Execution risk: this one often gets overlooked. When you outsource a business process to a firm like Accenture, Infosys, or Cognizant, for example, you remain responsible for the quality and consistency of how those processes are performed. Errors in execution do not become the vendor’s problem simply because they are the ones doing the work.

"Cyber risk gets the most attention and it is definitely significant. But you cannot afford to overlook the other aspects. The impact of a vendor outage, a reporting failure or poor execution can be just as damaging."

The distinction matters because oversight tends to follow attention. If information security owns vendor monitoring, the compliance and execution risks may not receive the same scrutiny. Mark’s view is that organisations need to think across all four categories, not just the one that generates the most headlines.

When a third party fails, who pays?

Mark refers to the Equifax breach in 2017, a clear illustration of how accountability works in practice. A third party managing data on behalf of Equifax was not performing the required vulnerability scans. The data of over 140 million customers was compromised.

The fines were significant. The remediation costs were significant. The reputational damage was significant. And every one of those consequences landed with Equifax, not with the third party.

"The regulators are going to come to the organisation and hold them accountable. Even though you outsourced the service, you are responsible for the performance of those controls. Full stop."

This is not a subtle point, but it is one that organisations still handle inconsistently. The logic of using a well-known, reputable vendor as a proxy for adequate controls, the idea that choosing IBM or EY or Accenture, for example, provides assurance by association, only goes so far.

Mark acknowledges that established vendors with mature processes and a track record of audits do provide a level of confidence. Their controls have been tested. They often have dedicated customer success functions set up to respond quickly to standard monitoring requests. But confidence is not the same as oversight.

"Just because a vendor is well known or subject to audits does not mean the organisation can stop monitoring. Appropriate controls need to be in place regardless of how big the name on the contract is."

The onboarding trap

One of the most consistent patterns Mark has observed across organisations of different sizes and sectors is a mismatch between how seriously they treat vendor onboarding and what happens in the months and years that follow.

Onboarding tends to be thorough. Questionnaires go out. SOC reports are requested and reviewed. Interviews are conducted with the vendor’s information security function. There is genuine rigour at the point of entry.

Then the vendor goes live. And the rigour fades.

"You onboard them well. But once they’re in, a lot of organisations I’ve seen simply do not have periodic reviews in place. No request for updated audit results. No reassessment when the scope of services changes."

Two specific failure modes come up repeatedly. The first is the SOC report problem. Large vendors often provide multiple reports covering different service lines. An organisation might request a SOC 1 or SOC 2 during onboarding and treat it as sufficient assurance. But if the report does not cover the specific services being purchased, it is essentially meaningless as a control.

The second is the complementary controls gap. Mark uses SAP as an example. SAP maintains the infrastructure and produces a clean SOC report. But access provisioning is the client’s responsibility. If nobody has clearly defined who owns those complementary user controls, they fall through the gap between what the vendor covers and what the company assumes is handled.

Both failures share the same root cause: treating the vendor’s controls as a substitute for the organisation’s own oversight rather than a complement to it.

How often should you review a vendor?

According to Mark, review cadence should be driven by the risk profile of the vendor, not a default calendar applied uniformly across every supplier relationship.

For a high-risk vendor, one that meets the criteria for significant information security exposure, regulatory implications or material resiliency risk, annual monitoring is the baseline under normal circumstances. That might mean requesting an updated SOC report, a review by the information security team, or structured interviews with the vendor.

But normal circumstances is doing a lot of work in that sentence. Mark shared an example from his own experience:

"We had a vendor classed as high tier, high risk. Under full maturity with no deficiencies we would have reviewed them annually. But two deficiencies were identified, so we had check-ins almost every month until remediation was confirmed and we were satisfied it would hold."

The principle is straightforward: monitoring cadence should escalate in proportion to known problems. Remediation needs to be verified, and the sustainability of whatever fix has been implemented needs to be tested. Closing a deficiency on paper is not the same as closing it in practice.

Is it still a tick-box exercise?

Ten years ago, Mark says, the answer was often yes. Before a series of high-profile incidents brought third party risk into sharp focus, and before regulators in financial services began scrutinising it seriously, many organisations were going through the motions. Questionnaires sent and returned with minimal scrutiny. SOC reports filed without being properly reviewed. Onboarding treated as a formality rather than a genuine risk assessment.

The picture has improved, but unevenly.

"In organisations that are regulated, publicly held or subject to SOX, it typically is not a tick-box exercise anymore. There is genuine thought at onboarding and in ongoing monitoring. But you still see remnants of the old approach in less mature functions."

One pattern he flags is worth noting specifically. Some organisations delay third party risk management to the very end of the vendor onboarding process, completing every other step first. By that point, the business has often already committed. The vendor is expected to go live within days. A thorough risk assessment at that stage feels like an obstacle, because it is.

The problem is not the risk management process. It is where it sits in the timeline. When it is treated as a final formality rather than an early gate, it will always look like it is slowing things down.

Is third party risk management blocking innovation?

This tension comes up regularly in organisations trying to move quickly. The business wants to onboard a vendor fast. The risk process requires time, documentation and sign-off. Someone in procurement or a business unit decides the process is the problem.

Mark’s view is that the process is rarely the problem. The design of it often is.

"If you apply the same level of rigour to a low-risk caterer as you do to a SaaS provider handling customer data, of course it is going to feel like a blocker. The issue is not the oversight. It is the lack of proportionality."

A properly tiered approach means low-risk vendors move through quickly because the controls required at that level are light. High-risk vendors get the scrutiny they deserve, and that scrutiny is built into the timeline from the start rather than tagged on at the end.

The broader point connects to something that runs through every edition of this series. The relationship between audit and the business works better when the function is seen as part of the process rather than an obstacle to it. That requires good communication, clear policies, and an honest conversation about what the risk actually is before the procurement decision is already made.

What the next five years look like

Mark’s prediction for where third party risk management is heading combines three things: more automation, more regulation, and more fragility.

The monitoring piece will shift. Point-in-time assessments, the annual SOC review, and the periodic questionnaire will increasingly be supplemented by real-time visibility into what is happening with service providers. Organisations will have live access to the status of remediation, event notifications, and control failures as they occur rather than months later.

At the same time, consolidation of the vendor ecosystem introduces a different kind of risk. As more organisations concentrate critical operations with a smaller number of large providers, a single failure at one of those providers creates systemic exposure across multiple clients simultaneously. The efficiency gains are real. So is the concentration risk.

"As ecosystems become more consolidated, a failure could be more fragile than before. A high concentration of risk in a single provider means a single point of failure with a very long reach."

And then there is AI. It has come up in every edition of this series, and third party risk is no exception. ChatGPT, Claude, Microsoft Copilot, and the wave of AI tooling now being embedded into organisations are, in the most straightforward sense, third parties. They process data. They influence decisions. They interact with customers.

Mark is direct about what that means for audit:

"You would want to see monitoring in place. What is AI being used for? Are there policies and procedures? Who is monitoring compliance with laws and regulations? What is the quality of the data going in? AI cannot just go into a black box."

The governance questions around AI as a third party are the same questions that apply to any other high-risk vendor: who owns the monitoring, who is responsible for the controls, who is accountable when something goes wrong. The technology is new. The accountability framework is not.

If anything, the increase of AI tools in the enterprise makes the case for a mature, well-resourced third party risk function stronger, not weaker. The number of vendors with access to sensitive data, critical infrastructure and business processes is growing. The potential consequences of a failure in any one of them is growing with it.

Over to you

How mature is third party risk management in your organisation? Is it genuinely embedded in how you onboard and monitor vendors, or are there still traces of the tick-box approach? And how are you thinking about AI providers as a third party risk?

Drop your thoughts in the comments. I’d love to hear how different teams are approaching this.

Want more conversations like this?

Subscribe to Behind the Controls to stay ahead of what’s shaping Audit, Risk and Compliance leadership, and how top professionals are navigating it.