Mark Fetches, CTO of Spinnaker Support – Interview Series

Mark Fetches is Chief Technology Officer for EMEA at Spinnaker Support, where he advises enterprise organizations on technology strategy, security, cloud, AI, and large-scale transformation initiatives. With more than 30 years of consulting and leadership experience across Accenture, Deloitte, and PwC, Mark has worked closely with C-suite executives and boards to modernize complex enterprise environments and align technology decisions with long-term business objectives. Based in the UK, he specializes in helping organizations navigate legacy technology challenges, operational risk, and digital transformation with practical, business-focused guidance.

Spinnaker Support is a leading global provider of third-party software support, managed services, and security advisory for enterprises running Oracle, SAP, JD Edwards, and other mission-critical platforms.

You’ve spent more than 20 years advising enterprises at Accenture, Deloitte, and PwC before becoming CTO at Spinnaker Support. Looking back across that journey, what are the biggest misconceptions executives have consistently had about technology risk, and how has the rise of AI changed those conversations?

I think the biggest misconception has always been that technology risk sits somewhere off to the side of the business and can be managed as a specialist issue. I’ve never really seen it that way.

Most of the serious risk I’ve seen comes from leadership choices. How much complexity you tolerate. How dependent you become on old platforms or key vendors. How hard you push for speed. Whether you really trust the data the business is running on. Technology is where those choices show up, but it usually isn’t where they start.

Over the years, I’ve seen a lot of executives focus on the obvious things such as cyber, compliance and cost reduction. Those are real issues, of course. But the risks that tend to catch companies out are often quieter than that. It’s the platform everyone knows is brittle but keeps postponing its replacement. It’s the data problem no one quite owns. It’s the outsourced dependency that looks efficient until it becomes a bottleneck. Those are the things that can sit in the background for years and then suddenly become very visible when something breaks.

I also think there’s been a longstanding habit of confusing compliance with resilience. They’re not the same thing. You can pass an audit and still be much more exposed than you think. A checklist doesn’t tell you how the business will respond under pressure, how quickly it can recover, or whether leaders are actually seeing the problem clearly enough to act.

What AI has changed is the level of attention. These conversations used to sit further down in the organization. Now they are right in the middle of discussions in the Board room about growth, trust, productivity and brand. This is a very good thing. But it has also introduced a new simplification, which is the idea that the AI model being used is the risk. Usually, it’s bigger than that. The harder questions are about the data and governance around it, the decisions it influences and the point at which human judgment still has to matter.

So if I had to sum it up, I’d say technology risk has never really been about the technology alone. It has always been a reflection of leadership judgment. AI has just made that much harder to ignore.

Security teams now have access to more vulnerability intelligence than ever before, yet organizations continue to struggle with prioritization. Why do you believe the industry has a signal-to-noise problem rather than a detection problem?

I’d put it quite simply, the industry is not short of vulnerability data. It is short of clarity.

Most security teams already have more than enough inputs, scanner output, threat intelligence, severity scores, patch advisories, exploit reporting. The issue is not whether they can find weaknesses. It is whether they can separate the few that could genuinely hurt the business from the many that are technically interesting but less consequential.

That is why I see it as a signal-to-noise problem. Detection has improved enormously. What has not kept pace is the ability to apply context. A vulnerability only becomes a real priority when you understand where it sits, how exposed it is, how critical that asset is, what compensating controls exist, and what the business impact would be if it were exploited.

In practice, many organizations still fall back on the metrics that are easiest to produce like severity ratings, patch counts and aging reports. Those are useful, but they are not the same as human judgment. A high-scoring issue in a low-value internal system may matter far less than a lower-rated weakness sitting on something customer-facing or operationally critical.

So, I don’t think this is fundamentally a visibility problem. It is a business prioritization problem that needs to be learned by the security teams. We have become very good at generating findings. We are still less consistent at translating those findings into a short list of actions that leadership can back with confidence.

And from my perspective, that is the real shift the industry still needs to make, a move away from measuring how much we can detect towards deciding what truly matters in terms of business impact.

At the board level, this is really a question of risk translation, can the organization convert technical exposure into a small number of clear, actionable business priorities? The ones that can do that well are the ones that move from noise to signal.

Many cybersecurity vendors claim that AI can automatically prioritize vulnerabilities and predict threats. Where do you see the gap between the marketing narrative and what AI can realistically deliver today in enterprise environments?

I think the easiest way to put it is that the marketing around this tends to promise a level of certainty that real enterprise environments simply do not allow.

Vendors often describe AI as if it can rise above the noise, take in everything and reliably tell a security team what matters most and what is likely to happen next. It is a compelling pitch because every security leader wants less clutter and more confidence. But once you get inside a large organization, things are rarely clean enough for that promise to hold in such a straightforward way.

AI can absolutely help. It can pull patterns together, reduce some of the manual sorting, highlight anomalies and help teams work through volumes of information that would otherwise be difficult to manage, and this has real value. But there is a difference between helping a team move faster and actually knowing, with any dependable precision, what should matter most in that specific environment.

That is where the gap shows up. Most enterprises are full of uneven context. Asset inventories are incomplete. Ownership is not always clear. Business criticality shifts. Controls vary from one part of the estate to another. Data quality is mixed. If the underlying picture is patchy, then the AI’s output will be patchy too, however polished the interface may look.

I think this is especially true when vendors talk about prediction. There is a meaningful difference between saying, “this pattern looks risky,” and saying, “this is what will happen next.” The first can be useful. The second is where the language often runs ahead of reality.

So, for me, AI is best understood today as an amplifier, not an authority. It can help teams sort, correlate and focus. What it cannot do consistently is replace the need for human judgment, local knowledge and a clear understanding of what the business actually cares about.

That is really the divide. The narrative suggests certainty. The reality is more modest and more useful than the hype if you are honest about it. AI can improve the quality and speed of analysis, but it does not remove the messiness of enterprise security decision-making.

Spinnaker Support works extensively with Oracle, SAP, and JD Edwards deployments. What makes highly customized ERP environments particularly difficult for AI-driven security tools to understand and assess accurately?

What makes these environments difficult is that, after enough years, they stop behaving like standard software that the AI has been trained on and start behaving more like a record of how the business actually works.

I have seen this to be especially true in heavily customised Oracle, SAP, and JD Edwards estates. On paper, you may still be looking at a known platform. In reality, you are often looking at years of local adaptations, custom code, inherited integrations, permission structures, reporting logic and workarounds built for very specific operational reasons. To an AI-driven security tool, I believe that this can be hard to read with any real confidence.

A lot of these tools work best when the environment is relatively consistent and the patterns are easier to compare. Highly customised ERP environments are rarely like that. The logic is more tangled. The documentation is often incomplete. Ownership may be spread across teams. What looks unusual may be perfectly intentional and what looks routine may turn out to support something genuinely critical in finance, supply chain, or operations.

This is where the difficulty lies. The tool is not just being asked to spot a vulnerability or a misconfiguration. It is being asked to understand what that issue means in the context of a business process, a custom dependency or a control structure that may not exist anywhere else.

And that is a much harder problem than the marketing usually implies. AI can help surface patterns, reduce some of the manual analysis and point people towards areas worth a closer look. But if the estate is only partially documented, shaped by years of exceptions and deeply tied to the way the company operates, there is a limit to how accurately an automated system can interpret it on its own.

So, I think the real issue is not whether AI can see something. It is whether it can understand enough of the surrounding context to judge it properly. In heavily customised ERP environments, that is still where human expertise makes the difference.

One of your key arguments is that human expertise is not a bottleneck to eliminate but an essential part of the security process. Can you share examples where human judgment identified risks that an AI-driven prioritization engine would likely have missed?

Yes, absolutely. And to me this is where the limits of automated prioritization become very obvious.

Some risks only make sense once you know the environment well enough to understand what sits behind the data. A system may not look especially important from the outside. The vulnerability score may be unremarkable. But someone who knows the estate may know that it supports payroll, quarter-end reporting, a fragile integration or a business process that the company simply cannot afford to interrupt. The signal in the data may look ordinary. The real-world consequence is not.

I have also seen cases where the control picture looks better in theory than it does in practice. An AI engine might assume a risk is reduced because segmentation is in place, or because access is restricted or because a monitoring control exists. But a person close to the environment may know that one control is inconsistently applied, another is bypassed when operations are under pressure and a third has quietly stopped being reliable. That kind of gap does not always show up cleanly in the system of record.

The same thing happens in customized environments. A script, a workflow or a permission model can look routine if you are scanning for patterns at scale. To somebody who understands how that system has been adapted over time, the same detail may stand out immediately as a real source of exposure.

Timing matters as well. A vulnerability may look manageable in isolation, then become far more serious because the business is in the middle of a migration, an acquisition, a regulatory deadline or a peak operating period. That kind of shift is not always easy for an automated engine to interpret with the right weight.

So, when I talk about human expertise, I am not talking about instinct in some vague sense. I mean local knowledge. Memory. Judgment. The ability to see when a small technical issue is attached to something much more consequential.

That is why I do not see human expertise as a bottleneck to remove. I see it as the part that prevents false confidence. AI can help sort and narrow the data. But the risks that matter most are often the ones that only become obvious when someone understands how the business really works.

As organizations rush to adopt AI across security operations, what are the biggest risks of over-automating vulnerability management and exposure assessment?

The biggest risk I see is that you create the appearance of control without the reality of actually understanding that you are in control.

Vulnerability management is one of those areas where automation is obviously valuable. At enterprise scale, you need automation to find issues, correlate data, prioritize at volume and keep the whole process moving. No serious organization can manage that manually.

But the danger comes when automation starts to drive the program without enough human challenge around it.

The first obvious risk is false prioritization. If you rely too heavily on automated scoring, you can end up treating technical severity as if it were the same thing as business risk. It isn’t. A critical vulnerability on an isolated or compensatingly controlled asset may matter less in practice than a lower-rated issue sitting on a highly exposed system tied to a critical business process.

The second risk I see is loss of context. Automated programs are only as good as the asset data, ownership data, dependency mapping and exception handling behind them. If that information is incomplete, and in most enterprises some of it usually is, then the automation can become very efficient at moving flawed decisions through the system.

The third risk is behavioral. Once people begin to trust the workflow too much, they stop interrogating its outputs. Teams assume that what rises to the top must be what matters most and what doesn’t rise to the top can wait. That’s understandable, but I believe dangerous. Because it shifts the culture from informed risk management to passive acceptance of machine-led ordering.

And then there’s a broader strategic risk, which is that organisations start confusing throughput with security improvement. Closing a high volume of vulnerabilities looks good operationally. It creates dashboards, metrics, and a sense of momentum. But if you’re not reducing the exposures that matter most to the business, you may simply be getting faster at looking busy.

So, my view is that automation should absolutely be doing the heavy lifting. But it should support judgment, not replace it. Otherwise, you end up with a process that is efficient, measurable and scalable, but not necessarily safer.

You’ve worked extensively in IT transformation and enterprise architecture. How should CISOs balance the need to patch vulnerabilities quickly against the operational risks of disrupting mission-critical business systems?

Great question, as this is one of those areas where the easy answer is usually the wrong one.

Of course you want to patch quickly. No CISO is going to argue for sitting on known vulnerabilities any longer than necessary. But in a real enterprise, especially one running critical systems, speed on its own is not the goal. If you patch badly and take down something the business relies on, you have solved one problem by creating another.

So, the balance is really about understanding which risks are live, which are theoretical and which systems can tolerate change without causing trouble somewhere else.

Some vulnerabilities genuinely do need urgent action. If something is exposed, exploitable and sitting in a part of the estate that matters, then you move. But a lot of the time, the decision is less absolute than people make it sound. You may have other controls around the issue. The affected system may be tightly contained. The operational risk of making the change today may be higher than holding the position for a short period and doing it properly.

That is why the better CISOs tend to be the ones who can have an adult conversation with the business. Not just, “This is critical, patch it now,” but “Here is the exposure, here is what could happen, here is what could go wrong if we intervene badly and here is the safest way through it.” That is a more credible form of leadership than treating every vulnerability as if it exists in isolation.

I also think these moments expose something deeper about the estate itself. If an organization is constantly afraid to patch core systems because any change feels dangerous, that usually tells you the environment has become brittle. Too much hidden dependency, not enough testing confidence, too little resilience in the architecture. In that situation, the patching debate is really a symptom of a much older problem.

So yes, patch fast where the risk is real and the path is clear. But where the environment is sensitive, the job is to reduce risk without creating a bigger mess. This is the balance.

And to be honest, most experienced CISOs already know this. The challenge is applying their decision under pressure, when the clock is ticking and nobody wants to own the consequences of getting it wrong.

Spinnaker’s approach combines AI-driven analysis with expert validation. What specific tasks should AI handle, and which decisions should remain firmly in the hands of experienced security professionals?

I think the dividing line is actually pretty straightforward.

AI should be doing the work that benefits from speed, scale and consistency. Going through large amounts of data, pulling signals together, spotting patterns, flagging things that look off, helping people narrow the field, this is exactly the kind of work machines are useful for. It saves time, it reduces manual effort and it gives security teams a better starting point.

It is also well suited to the repetitive parts of the job. The first layer of triage. Summarising findings. Connecting similar issues. Tracking repeat exceptions. Pointing out where certain types of control weakness keep appearing. None of that replaces expertise, but it does make better use of it.

Where I would be much more careful is when you move from analysis to decision-making.

The important calls should still sit with experienced security professionals. Is this actually a serious risk in this business or does it just look serious in the abstract? Is this a genuine control failure or is it a messy but understood exception? If we fix this now, what else might we disrupt? If we wait, what are we really accepting? Those are judgment calls.

And that is before you even get into the more human side of it. Why does this keep happening? Is the organization knowingly carrying this risk or has it simply stopped noticing it? Is this an isolated issue or a sign of something cultural underneath? That kind of interpretation still matters a great deal.

So, I would let AI do the sorting, the clustering, the first pass, the heavy lifting. But I would not let it decide what the business should care about most or what action should be taken without human review.

Because once a decision has consequences, either operationally, financially or reputationally, you are no longer just processing information. You are making a judgment.

And in security, I believe, that still should be a person with actual intelligence.

Many organizations still focus heavily on vulnerability counts and severity scores. Why do you believe genuine exposure management requires a broader view that includes compensating controls, access restrictions, system architecture, and business context?

It requires a broader view because a number on its own does not tell you much about how much trouble you are really in.

Severity scores have their place. Vulnerability counts have their place. They help you size the problem. They help you organize the backlog. But they are not the same thing as understanding exposure, and that is where I think a lot of organisations still get this wrong.

A vulnerability can look severe in theory and still be relatively well contained in practice. If access to the system is tightly limited, if there are other compensating controls around it, if it sits in a part of the environment that is hard to reach through access restrictions, then the actual likelihood of that issue causing harm may be quite different from what the raw score suggests.

And then you get the opposite case, which is often the more interesting one. Something lower down the list can turn out to matter much more because of where it sits. It touches a critical service. It is easier to get to. It sits in a part of the system architecture where one compromise gives you room to move. That is the kind of thing a simple severity ranking will not explain well.

So, when people talk about exposure management, to me it must mean more than just sorting vulnerabilities by score and working down the pile.

You need to know what sits around the issue. What controls are already there. Who can reach it. Whether the system is isolated or connected to something more important. And if it is exploited, what really happens next.

Otherwise, you end up managing the picture of risk rather than the risk itself. The dashboard improves. The ticket numbers move. The reporting looks better. But you are not necessarily safer.

I think part of the reason this happens is that numbers are comforting. They look objective. They give people something tidy to present. They create the sense that the problem has been reduced to something measurable and under control. But real exposure is usually much messier than that.

It sits in the overlap between the flaw, the controls around it, the architecture it lives in, and the business consequence if something goes wrong.

So yes, use the scores. Use the counts. Of course. But do not confuse them with understanding.

If you want to know where the real exposure is, I believe you have to look at the whole environment, not just a number attached to it.

Enterprise software environments are entering a period of significant change as organizations modernize legacy systems while simultaneously adopting AI technologies. Looking ahead over the next three to five years, how do you see the relationship between AI, cybersecurity, and enterprise platforms evolving, and what should technology leaders be preparing for today?

I think the next three to five years are going to be pretty defining.

Mainly because companies are trying to modernise old enterprise estates at the same time as they are bringing AI into the mix and neither of those things is easy on its own. Doing both together raises the stakes.

What changes first, I think, is that AI stops being a side experiment and starts becoming part of the way the business actually runs. It shows up in workflows, support, development, security operations and platform administration, not as a novelty, but as part of the plumbing.

And once that happens, the cyber conversation gets more serious. You are not just asking whether the tool is useful. You are asking what it can reach, what it can influence, what data it is feeding on and what the consequences are when it gets something wrong.

I also think we are going to see security and architecture become even harder to separate. In a lot of older environments, the thing that looks like a security problem is often really an architecture problem wearing a security badge. Weak identity design, too many dependencies, unclear ownership, brittle integrations, poor visibility, those are the things that tend to sit underneath the visible issue. AI will not smooth that away. If anything, it may expose the mess faster.

So, the organizations that handle this well I believe, will be the ones that stop treating AI adoption, cybersecurity and platform modernization as three separate workstreams. They are increasingly the same conversation.

If I were advising technology leaders now, I would start with visibility. You need a much clearer handle on what you have, how it connects, who has access to what, where sensitive data moves and where your real control points are. Without that, layering AI on top just increases the number of things you do not fully understand.

The next thing is governance, but not the performative kind. Real decisions. Where can AI be used? Where does human review need to stay in place? How are outputs checked? What data is off limits? Who owns the consequences if the system drives the wrong action? Those questions need answering now, not later.

And honestly, simplification matters more than a lot of people want to admit. The more tangled the estate, the harder it is to secure, the harder it is to modernize, and the harder it is to use AI without creating fresh uncertainty.

Then there is the people side of it. The better organizations will be the ones that know how to combine automation with judgment. They will not just consume AI output because it is fast or polished. They will challenge it. Test it. Push back on it when needed.

So yes, over the next few years I think AI, cyber and enterprise platforms will become much more tightly bound together.

And I think the leaders who prepare well will be the ones who understand that this is not just a technology shift. It is a change in how decisions are made, how control is exercised, and how resilient their organization really is.

Thank you for the great interview, readers who wish to learn more should visit Spinnaker Support.