Ritesh Patel (CISO Just Eat Takeaway)

We talk with Ritesh Patel about building security that keeps up with product velocity without becoming a blocker. We dig into AppSec, Third-party risk, fraud, and a practical four-part framework for AI security that holds up under real-world pressure.

• Building a CISO “tool belt” through a nonlinear career across ops, engineering, risk, and incidents 

• Defining security as a business capability tied to trust and outcomes

• Managing pace and agility in a consumer tech marketplace without becoming the department of no

• Bmbedding AppSec into platforms so teams ship secure-by-default 

• Engineering for the masses while detecting exceptions fast

• Treating supply chain security as an ecosystem problem that needs better visibility and real-time signals

• Focusing on identity and access as the perimeter, including OAuth scope control 

• Reframing fraud and account takeover as a shared trust problem across teams

• Applying a four-phase AI security model: build safe, run safe, defend with AI, control agentic AI

• Separating AI-first vendor value from AI-washing and chatbot wrappers

• Using NIS2, DORA, and other frameworks to improve risk posture, not just pass audits

Transcript

Welcome And What We Cover

Speaker 1 0:02

Welcome to the Unicorn CISO Podcast. This is Pedro from 33N. In this podcast, we discuss the CISOs of companies reaching unicorn status, working on the frontier of cyber while balancing business speed. Let's get started with today's episode.

Speaker 2 0:20

Okay, so welcome everyone to another episode of the Unicorn CISO Podcast. Today we're lucky enough to get to have Ritesh Patel in in the podcast. He's a CISO with Jet, with Just Eat takeaway. And I think we'll have an amazing conversation. Ritesh, thanks for joining. Pleasure to have you.

Speaker 0:38

Hey Pedro, how are you?

A Nonlinear Path To CISO

Speaker 0:41

Good, good.

Speaker 2 0:42

So we usually start the podcast with kind of an overview of the evolution of the CISO into the current role. So I was curious, you you have an unique experience, right? Getting to where you are today. So I was curious how did you get to the to the role you're today? And how does your did your path to to getting here shape the way you think about security today?

Speaker 1:04

So honestly, the answer to that is my path was not at all linear, right? A lot of people think that you kind of do this linear approach to becoming a leader in any area. Mine is absolutely a non-linear path. I think of it as a strength, to be honest with you. I didn't follow a textbook route. I moved from disciplines, picked up skills in engineering, risk, product, security, operations. I've done pretty much each different step along the way. And each one added a different, what I like to refer to is a toolkit, something to the toolkit, and uh, you know, a tool in the toolkit. I think of it as uh less of a career ladder than building that tool belt. Each role gave me a new instrument or a new tool that I could use and reach for when the situation needed it, really. So that's how you know it wasn't a direct path, is the short answer to your question there. It gave me a practical lens on things, you know, and I think I'm not a purely, I'd like to think I'm not a purely theoretical security leader. I've done, I've been down in the weeds in the past, I've managed those incidents, I've been the responder on those incidents, I've been the resolution manager on this incident, I've shipped products all the way through. So those 2 a.m. calls, I've been there, done them, taken them. I you know, it's not a standalone discipline, is security, but as something that fits inside of a business, and and that's always the key part. Honestly, we continue to learn.

Speaker 2 2:44

Very clear. Before joining Jet, you were with with BP for a huge amount of your career, right? So how big what were the roles you had there?

Speaker 2:51

And yeah, so I started looking after the trade floor, uh, BP, I was an operations guy. I moved along through my career through BP, and it you know, start it started with operations on the trading floors. I got into a lot of compliance and regulatory control. That was the entry point of into security. I I owned endpoint controls for a while, email controls, managed a lot of operations during that space, vulnerability, uh obviously governance is a part of what you do. So moved all the way through. I could probably go on for hours. I was there for 20 odd years.

Speaker 2 3:34

When you got then in into transitioning into jets, I mean, can you share a bit about just the takeaway and and what's the scope of your role?

Security Scope At Just Eat Takeaway

Speaker 3:45

So I think the honest answer is you know, people think of just jet as a you know, you as a as a consumer, you only see one side of it, right? You see the the food getting delivered and you think it's a restaurant, but there's an immense amount of technology, it's ultimately a technological organization. You think about every step in that process, and it involves a huge logistical element, and you don't often think of that. So it's actually an engineering capability that JET has, and that's a strong part of what we do at Jet. My role is being responsible for end-to-end delivery of security functions. We don't just uh set security, I'm sorry, we don't just set the strategy, uh, but it's making that strategy uh be available and we can execute upon it. That means everything from uh application security, infrastructure security through to data protection, incident response, and everything in between, which you know, it's so it but it's absolutely the execution of the strategy that's associated. So just the you know, we've got 12,500 employees. That that's a large number of people to that all are in some way involved in technology that enables that delivery, that end user customer experience, making every time a customer sees a just each sign, they recognize that brand and they associate it with trust. And that's really what we do. You know, the technical perimeter is just one part of what we look at, and that's what the external world sees. I own that relationship between security and the rest of the business as well. So we've got multiple sets of customers: engineering, product, legal, compliance, these are all different customers that I own that relationship with, and we're starting to build lots of strong relationships. We don't just we don't we don't protect a business if we work on our own in a silo. So that's something that I am keen to to build upon as part of the role that that I do here at JE.

Speaker 2 5:57

Before you've worked in in big global organizations, right? But is there something different from a large corporate versus a consumer marketplace business that is fundamentally different in terms of security?

Speaker 6:10

I find this, I find that

Pace Agility And Business Focus

Speaker 6:12

this question that's been asked of me before. I find this question genuinely interesting, right? And the reason it's really interesting is the honest answer is it's a surprise to some people because there are differences that are less dramatic than people would expect. But where they do exist, those differences, they matter enormously. The big similarities, if we are if I talk about what's similar, and you don't you don't expect this, is actually the adversary, the threat actors. They don't care about the org chart, the size often of the company. They don't care who's responsible, which team is responsible for a risk. They don't care about a change, um, a change window, they don't care whether it's in prod or non-prod, ransomware phishing, supply attacks, uh supply chain attacks, the universe where they go across the board. The principles have to stand strong, right? So that's the consistency. Those are the similar similarities. What the differences for me that I've seen as I've come in here, I think the there's three things that stand out. The first one is pace, the pace and the velocity of product delivery is extraordinary. Constantly shipping, dozens of engineering squads moving in the same direction. The security posture that we maintain has to keep up with that without becoming a deployment becoming a blocker. And that's really difficult because you know, uh, if we're honest, security teams are often seen as the department of no. We really need to go from no, you can't do this because to becoming an area of yes, you can do this if we have these guardrails. Right? We've become an enabler for the business. I think that's the first one. Secondly, I think agility, business priorities change quickly, and we may experiment and move. Experiment and move. It could be a new market, a new partnership, a change in the platform. The security program has to be adaptable. I think that's something that we have to adapt very quickly. Your three-year roadmap can't be carved in stone. We have to evolve. And finally, I think focus. Focus is the big, the third big difference for us that I see. This is a business that I work in that is totally focused on a goal, value creation. So our security investments, be in time, financial, all of our investment, have to be clearly tied to the outcomes that support those focused goals of the business. We can't hide behind that jargon anymore.

Speaker 2 8:57

Very, very clear. I mean, uh obviously the the speed is is the speed, the balance between security and speed is part of why the job

AppSec Guardrails That Do Not Block

Speaker 2 9:06

is interesting, right? Especially at working at the tech company. What were the the discussion here is what are acceptable risk levels and what are non-negotiables, right? And for me, the the obvious area where this becomes very relevant is is AppSteck, right? I think you were even in a few weeks, I saw you were reporting about how the engineering team was super agile at releasing new features and building platforms. I think it was two engineers in 10 weeks working in three amazing platforms. And funnily enough, they they found a way to not take away the security guardrails, right? How did this how does this balance on the appech side is maintained, right?

Speaker 9:43

And sorry to interrupt you, but I I I I I'm really passionate about this. That that was an exercise in absolute brilliant execution by the team. I think there's a key fundamental underlying and it's almost unspoken rule, which is we're all on this bus together. Right? Security isn't just the security team's problem. Our engineering teams are looking at this and they're saying, okay, security are doing this, but we are part of that team. This is a jet problem or a jet solution, it's a jet way forward, and we are working together in the same direction. And I think that's immense. So when that team developed that in in the and we saw it with the application security, then the applications then built, they built this in into the product. We didn't actually have to have hours of conversations with them, so we didn't slow them down.

Speaker 2 10:38

So share for the listeners what was what was this this exercise?

Speaker 10:42

Uh, just for the those that didn't didn't read this piece of news about uh so they've developed um a number of platforms in a very quick time in way to leverage AI. So a big part of our focus is around leveraging AI. So, how can we leverage and create platforms that will use AI, but we do it securely and we do it consistently across the organization, in short. So they the the team went out, we didn't have some of these systems, they went out and they wrote these things, they worked with various customers to see what we might want and produce an MVP. But at the same time, when they did so, they've done it securely, they've built security into it. So if anybody else comes along and uses any of those those functions that we've delivered or the team we've delivered, they'll get security as part of it. They don't have to come and do another security assessment, although they will do some kind of security. But the basics are done whilst we're doing it. AppSec is a great example of that, where we're, you know, SAST, for example. If you're doing the scanning along the way, then you're hopefully not going to find anything in your desk solution or in your pen tests later on. It's about finding it earlier and reducing that potential exposure window. So we need to get to a position of not releasing vulnerable code, right? But if we build it into the system, it makes it a lot harder not to. So I used to call it doing the right thing and making it easy to do so.

Speaker 2 12:08

And how how does this work in practice, right? Because I'm sure there were times in which there were trade-offs between what what the engineering teams were doing, even in in small groups, uh trying to release and and and do small FPs. So were there cases that in which the guardrails were not maintained or there were kind of uh alerts that we had to deal with?

Speaker 12:27

Yeah, and we also don't want to stifle innovation and experimentation. So people want to experiment something. We've got to be agile enough to say, right, we're gonna experiment in a very controlled way. Yeah, we'll really sandbox this environment. So let's go and do that. So they so the team built a platform that they can do that in, and we can help do a lighter touch security view on that. But again, building it in so we know that when we're as we move through the various production of various environments, we know that we're getting a secure product. There are there will always be elements of exceptions where people haven't followed a process. But the the key there is we need to be able to detect that as well. So we we engineer for the masses, but detect for the exception. And that's where the this becomes a team sport, right? So it's not just about AppSec doing that. What other areas of the security organization are picking up on these? How are we surfacing this information where the exception occurred without approval to the right areas so they don't go into that again and again and again, and maybe even think about constrained engineering to stop that exception happening again?

Speaker 2 13:42

Very clear.

Supply Chain Risk And Visibility

Speaker 2 13:43

I wanted to to cover also another area which that that to me seems also very relevant in in food delivery platforms, which is the the supply chain, right? And and how you interact with different uh vendors, I mean employees that just eat, or or delivery people, especially when you're looking into different operations in different countries, right? This seems an enormous problem and a big a big potential area of attack. How do you think about about this this problem? I mean, supply chain attacks, third-party uh security.

Speaker 14:18

Um it's a massive area. Firstly, I mean, without a shadow of a doubt, that's such a huge area. The where do we even start to look at this, right? So do we start with a third party? Do we start with our employees? If we start with a third party, so firstly, we need to know what we're defending, right? I mean, you can't defend what you don't know, so that visibility has to be there. The ones that the the real threats that keep us honest are the ones that we just don't know about. Similarly, if we don't know that that asset is available on the internet, then actually we've got a problem here. Those are the ones that we talk we we need to worry about. The industry talks a lot about ransomware, nation-state attacks, things like that. They're real, they're very real. But the vectors are consistently underestimated. And and they sit on the on that kind of in the seam in the seam of the organization. Third party supply chain is the one that I would probably call out right now. We're seeing lots of these attacks happening all of the time. And more and more are happening. And if you think about some of the most recent high-profile attacks, they've often been third-party supply chains. Most platforms are an ecosystem, as is no different, right? Of different vendors, APIs, open source dependencies, SaaS tools that we all use. Our attack surface isn't necessarily just what we've built to stitch those all together. We need to understand better as an industry that it's actually actually everything that we depend on. So the adversary community has figured this out that there's gaps in some of this sometimes, and they they're absolutely taking advantage of that. So we need to stitch that all together and look at it as a complete overview. So I I think the attackers are slightly ahead of us in this because everyone's is different, everyone's slightly different in that stitching, I think. I would say it's uh it's a change. So the annual questionnaire of you know how do we assess this this third party has changed, right? I I don't know if that's necessarily still valid. It does tick a box in many instances, but it doesn't match the pace at which vulnerabilities and attackers are working and the flow is working, and that's where we need to evolve more. And that's as an industry not. I I wouldn't say it's uh a jet problem, that's an industry problem. So, how do we make that that more realistic, more real-time? Then alongside that, you've got the traditional problems of identity. The identity is still absolutely the perimeter, you know. But you've got the next layer coming through their supply chain. Uh I I heard a phrase the other day, I thought was fan, you know, actually summed it up, and I've heard it a few times. But the attackers aren't hacking in. The hackers aren't, they're actually logging in. Right? So once they've logged in, what else? So they and they're not necessarily logging into your system to get to your system, they're logging into all of the rest of the third party as well, because we've given them access of some kind. The you know, the recent Vasel attack was a very simple attack that you know could happen to anyone. So, how are we responding to that? How are we how are companies making sure that their OAuth permissions and their scopes are minimized and things like that?

Speaker 2 18:00

I think the the other topic that also connects here very naturally is fraud prevention.

Fraud Converges With Security

Speaker 2 18:06

And again, to consumer business, this is also a big part of it. To me, I think why the reason why this is even more interesting in the case of Jet is there's probably different markets that are more prone uh to fraud and and simple small fraud, right? I'm thinking of Brazil, for example, that I heard a lot. There's a lot of uh creativity and and and different attacks versus other markets that are a bit less different. So I was curious in in how the how does how do the different teams work at chat to kind of uh address this? Is this like different teams and and different uh areas of of expertise closer to the markets? And so the operations team in each market is more uh adapted to to understand how fraud cases will will be will be starting.

Speaker 18:51

It's not like anyone else has a fraud area that looks to stuff. The one thing you know, if I were gonna change anything across the industry, and we're already starting to do this in in in JET, right? Is the attacker doesn't care about your org chart. Right? Fraud it ultimately ends in a loss for the company somewhere, and we should all be a part of that solution to stop that. They don't, you know, our attackers the the the attackers don't care about the org chart, our defenses absolutely shouldn't either when it comes to fraud. So that I think that's absolutely a part of it. Accounts being taken over, so be it internal or customer accounts being you know being taken over, they can lead to a trust problem. The future is a unified trust that we we get to, but it account takeover is an identity takeover, it's a security and an engineering and a an infrastructure problem. And sometimes we put a fraud label on it, but it's something that we need to address as a team. I think there's a convergence that's happening more and more as a lot more fraud becomes very digital.

Speaker 2 20:07

Indeed. But here, I mean, that in the end, also the legal frameworks to kind of go after uh fraudsters, etc., they're probably specific to every country, and so it makes sense that there's also a localized approach, right?

Speaker 20:18

Yeah, that there will there was there's got to be a localized approach to each one. And you know, some some I I I was talking to a another company recently, and they had a quite a high tolerance to it because actually, you know, their their focus was on something else that had a greater income, actually, um, which I thought was quite interesting. But it you know, similarly, companies have a risk tolerance and a risk appetite that they work towards.

Speaker 2 20:47

Okay, cool.

A Four Part Framework For AI

Speaker 2 20:48

Any other we talked about AppSec, third-party supply chain, fraud, any emerging topics or tools that that you've been paying a bit more attention that are very relevant?

Speaker 20:58

No, I yeah, this is a good qu this is a good one, right? Because I think we've I don't I think we've been talking for I don't know, no, 15 minutes, 20 minutes, or 10 minutes, I can't remember. It feels like it was been a very short time, but I don't think we've actually mentioned the famous two letters, right? AI. And if we have, then I missed it and I said it without knowing. Right? But I'm very proud of myself that we made it this far into a conversation without talking about AI, when actually that is the sole focus of everything, let's be honest right now. So AI for means in the cybersecurity world, it's is an evolving world. It's an evolving world. We as a company are absolutely investing in what we use AI with and how we use it. We we're at we are using it in every single way possible to in multiple in multiple ways. For me in security, I've got I'm kind of looking at it as my my my framework that. I'm building around this is that four-phased approach. It's not layers, actually, but you could be layers. I look at it as let's build it safe. First layer, build it safe. When the developers are using coding assistance, let's make sure that they're building secure code and use AI to do that as well. Right. So then building AI solutions. Yeah, let's make sure that we do that safely. It changes your app sec model a little bit, and we might we need to adapt to that. We need to think about training data, the poisoning all of these things in an automated scanner than maybe A to A drive. So build it safely. Secondly, we move on to the next layer, which is run it safely, securing it at runtime. Yeah. So when you've got models that are in production and interacting with different users and data, it's a new attack surface, completely new attack surface. So how do we make sure that the basic prompt injections, the data extraction models, uh the data output models aren't being abused, jailbreaks, bypasses, etc. So that's the new vulnerability classes that I kind of call them, which is the run it safe. So we build it safe, then we run it safe. This is where I think my kind of really favorite part of this is the use it to defend as well. So we build it, we run it, it's yeah, but we need it to defend as well. So this is the opportunity, AI native threat detection. How do we use that? And you know, how do we use it to become a forced multiplier for us within areas that some of some areas stand out very naturally? So you we often talk about the security operation centers around the world doing automatic alert triage, predictive vulnerability management. So those are the obvious ones. But I think there's more, there's more productivity multipliers for a security team that take intelligence and making it cheaper and faster, changing how we operate as an as a as a team. And finally, I'd say the fourth layer, we have to control it when it's act when it's acting alone. So the with the agentic world. That I think we need to make sure that as the organization and organizations everywhere move towards AI agents that take autonomous actions or browsing, writing code, API calls, all of these things, security implications could be huge. So we need to make sure that we get those guardrails, excuse me, get those guardrails in place up front. I think those are the four kind of my my my foundation, my basic views, but I think AI is it's it's absolutely going to be our false model.

Speaker 2 24:52

Your conversations with with vendors, where do you feel the the vendors are earlier, right? Where you haven't seen, I mean, uh tools that that actually solve the problem, or or you've seen them, but you you haven't seen them tested with kind of a multitude of customers. So what are the areas where you you thought there's still market of solutions is still evolving, in all honesty?

Speaker 25:15

I think there's two there's two sets of vendors actually at the moment. There's some vendors that are just throwing AI on top of everything. So they got an existing solution, and we just well, everyone's doing AI, so I need to add some AI to this. And I'm not sure if that necessarily gives all of the value that's claimed, if I'm honest. The question, I heard this somewhere else, I can't take credit for this. Is if the AI model disappeared from your product, what would happen to your product? If the product stops working, then it's actually AI driven. If the product, and then you know, and often a lot of companies will say, no, no, we can carry on because we still have this working. It's not AI driven, it's not AI bill. So that's kind of one way I look at this. And the AI first companies that are coming through now, and the the traditional companies that are building it into the core fundamental DNA of their products are the ones that are showing a real difference rather than making a layer over the top of it or putting a chatbot over the top of it. So the you know, the kind of four layers that I saw we spoke about earlier on, I think those are the areas that I I would you know I'd probably look to see value from in products.

Speaker 2 26:32

In those four areas, any any one, any area where you or or the engineering teams are experimenting more? I mean, they're testing more vendors, they're a bit more advanced eager to kind of uh trial new solutions.

Speaker 26:44

In the security space, I think there's definitely we talked about the stock operations areas, right? How do we use AI better there? I think there's general operations, including security operations, how can we help people make decisions quicker? Be it security or security related, or even assessing whether an investigation needs to go into a further level of detail. So I think those are the that's an obvious one. The adversarial kind of pen testing, we've you know, the other buzz buzzword that we've just you know completely walked past is the the frontier models of mythos at the moment and 5.5, all of these, they are going to make a difference, right? So, how are we gonna use it to defend? Right, we need to figure that out until we see some more evidence come out of those. It's gonna be hard, but those are the ones that we're gonna be keeping a close eye on. Everyone seems to have a solution for mythos and all of these frontier models, but I think adversarial or continuous adversarial pen testing or red teaming, I think I think there's a category that's appearing now around, I think they're calling it car or cart, and that makes sense, I can see that because you need to at the rate at the rate at which companies are now shipping, we need to be able to get to continuous testing, and it's becoming more and more sophisticated. There's companies out there that I think that they are going to again help us defend a lot better. The LLM security areas, I think they're going to be big as well. I haven't got any companies that are looking at them.

Speaker 2 28:30

In in in all these four layers, I mean, any any for for for JET as a business, is is compliance, is the legal framework also relevant in in touching the security investment?

Compliance That Improves Risk Posture

Speaker 2 28:44

So are there apart from the gener generic generic niss to or this kind of regulation, any anything that is specific for you as a as a security practitioner?

Speaker 28:56

Honest answer, yes, all of it, right? So we are financially regulated, so we we have to provide this compliance levels. I am a firm believer that we can't just do these as tick boxes. I I you know sometimes you do one of these things, uh yeah, we we okay, we're nice to okay, brilliant. There's a reason for these things to exist, and they are to help us secure our posture, right? And some of these questionnaires that we see in people, yeah, we can do that, we can do that, we can do that. Absolutely agree, we can do all of that. What does it actually mean to our risk posture for the organizer? How are we protecting our customer data better? Those are our crown jewel assets. So I I think they're all valid, and they are all frameworks that we need to adhere to to a lesser or greater degree. So I haven't got an honest single one that I can give you an answer to, but you know, uh being able to say that we are completely compliant to NIST2 or Dora, each one of these has a different benefit. So they have overlap, but they also have individual areas which you should go and learn from. So we we should be actually applying, I think everyone should be applying many, many of these frameworks.

Speaker 2 30:18

When you're meaning, just to clarify, when you're meaning that mentioning that you're financially regulated, it's not that you have to abide to like a financial institution that has to abide to to the regulators, the the the Bank of England kind of regulations or or others, right? So it's not in that sense.

Speaker 30:33

Yeah, exactly. Sorry, should have made that clear.

Speaker 2 30:36

Yeah, no, no, no. Very clear, very clear. Amazing. Ritash, I think we're up uh uh on on uh the time for the episode. Really insightful, really appreciate you you joining and spending that insight with us. Thank you very much for your time. Speak to you soon.