Nuno Teodoro (ex-VP Cybersecurity at Solaris)

We talk with Nuno Teodoro about how a hands-on security leader builds real defenses inside a cloud-native bank while regulators, auditors, and the business all demand speed. We dig into what changes when a fintech becomes a bank, how to use compliance to fund security maturity, and why AI-driven fraud is raising the stakes.
• career path from computer engineering to application security and penetration testing
• shifting from consultancy to leading security inside companies across telecom, insurance, and fintech
• difference between VP of Cybersecurity and CISO roles across the three lines of defense
• selecting vendors through hands-on POVs and POCs instead of only RFPs
• protecting customer funds as the core cybersecurity goal in regulated banking
• balancing compliance work with risk-based security priorities
• navigating major frameworks and regulations like PCI DSS, SWIFT, ISO 27001, ISO 22301, PSD2, and DORA
• using regulatory requirements to justify investments and close real security gaps
• scaling security culture in a cloud-based AWS bank while managing control expectations
• friction points in secure software development life cycle and blocking risky pull requests
• communicating cyber risk to the board through business impact and clear narratives
• focusing on DORA implementation plus the rise of AI-enabled fraud and account takeover threats

Transcript

From Computer Engineering To Cyber

SPEAKER_01 0:02

Welcome to the Unicorn CISO podcast. This is Pedro from 33N. In this podcast, we discuss with CISOs of companies reaching unicorn status, working on the frontier of cyber while balancing business speed. Let's get started with today's episode. Alright. Hello everyone. Thanks for taking the time and joining again the first episode of the Unicorn CISO podcast. This time we have Nuno Teodoro. We'll be having some fun together. Nuno, welcome to the pod. Thank you so much. Thank you. It's a pleasure to be here. Amazing, amazing. We'd like to start the pod to with a bit of a personal background. So many listeners might be curious how you got into cyber. I mean, you obviously have a lot of experience with uh uh starting with telecom and then insurance, now fintech. So just curious how you how you went into cyber and uh um how how did you see the different experiences over your uh 15-year career?

SPEAKER_00 1:12

Sure. Uh that's actually a very, very good question. Um I I think it all started when I was in my bachelor's degree in computer engineering. Um so I've started to to work uh in in the interim of the of the of the of the elective years, and basically one of the things that I very soon understood was that I don't want to be a programmer. And bear in mind we were talking we are talking about around 16, 17, 18, 19 years ago, right? So 18 to 19, because I have already 16 years of cybersecurity, so more or less I would say 19, 19 years ago. Uh so one thing for me was very certain, I didn't want to be a programmer, a developer, right?

SPEAKER_01 1:58

And at the time given the how how the context is evolving and developing code.

SPEAKER_00 2:04

But but I think it was also because of two main reasons. First of all, I didn't quite like it, and second of all, I was not very good at it. So it kind of forced me into something else different from the development side of things. So I think basically with that in mind, I started to see like what were also the other courses that I had in my degree uh that I really liked. So I had I think like three or four security uh uh security lectures uh on my degree, most of them on network security, I would say, network and security architecture. Uh, but also on by the end of the bachelor's, it was more on application and security. So I started to get like uh um an understanding and a feel for for the security side of things. And again, at that time there was no cybersecurity buzzword, right? So it was like IT security, network security, like it wasn't much more than that. Um, we are talking about uh uh let's say the the the early the the early uh um 2000s, right? So it was very different from what we are seeing at now uh right now at the market. So long story short, I understood I what I didn't want, I liked the security side of things. So before my master's, I eventually talked with a professor that was in the OWASP chapter and was uh dealing with all this applicational security stuff, and I told him, Yeah, I think I already know what I want to do professionally, so I want to already start working on my master's thesis on applicational security. So I did like a Portuguese overall security assessment on a couple of uh public-facing uh uh portals like from the military, from banks, from uh education institutions. So that was my master thesis on application security testing, like automated and penetration testing. Um, so it started there basically. I understood, okay, I like this one. Um let me pursue the career in this because it's something that I like, it motivates me, it makes me wake up in the morning, and basically I grew from there. So I started. I uh first of all, I think I worked like one or two years maximum outside of the cybersecurity area, and then I when I was already like taking the masters, I decided no, let me also pursue professionally this as soon as possible. So I started um at the time as a penetration tester. Um, so I did a couple of years of pen tests, more technical security assessments. Eventually I migrate I migrated to a big four where you kind of have like this technical stuff, but you are also forced to go into a different perspective of the of the information security business. Um and I spent a couple of years, not a couple, uh several years in the consultancy side of things. And eventually I also saw the the opportunity and the need to grow internally as a cybersecurity officer or a CS or someone that was leading security inside the company, not as a consultant. Um, and I shifted from one side to the other. And basically my career evolved from, like you said, uh telecom, manufacturing, uh uh financial institutions, insurance, more recently, fintech, and uh yeah, what is more to come, I will go more into uh uh let's say pharmaceutical cybersecurity side of things, but I've spent the last three years building uh cybersecurity function as the VP of a German bank and basically setting up all the requirements for the upcoming regulations and so forth. So all started uh very naturally and evolved also, I would say, quite quick, but in a very steady, uh steady way.

SPEAKER_01 5:49

Amazing. Uh um, I mean, coming from uh non-regulated industries into then uh uh fintech and uh and and solarisbank, I'm sure has a lot of uh learnings there. I was curious, maybe as uh as a context, right? What is the role of of the CISO of Solaris Bank, right? So how are you protecting here?

SPEAKER_00 6:09

So uh the most important definition here is I was not the CISO, right? I was the VP of cybersecurity. Why? Because my role was on the first line of defense. So I had all the responsibility to implement, to monitor, to fine-tune, to actually on a technical level deploy the measures that protect uh the bank and the customer, the customers' funds. Let's let's say it that way, because in the end of the day, what you want to protect is the business, right? Uh so the CISO, there was not a CISO per se in Solaris, there was uh an information security officer. This comes from the uh BAIT uh regulation from BAFIN, uh which basically mandates that uh uh the financial institutions have an ISO that reports directly to the chief risk officer that needs to be uh on the board. So my role was on the first line of defense, then the CISO or the information security officer is on the second line. So if you go to other banks, um also depends on the on the on the structure, but usually per regulation you have this uh the CISO or the information security officer is on the second line, reports to the chief risk officer, and then you have third line the audits and so forth.

SPEAKER_01 7:24

Right, understood. Uh so I mean this already explains how how complex, right, with with Buffin and the other regulations you have to be uh regarding structure, right? Uh and who in this uh this uh uh group of people is is more focused on on the tech side, right? On on uh selecting vendors. Is it the first line of defense, as you mentioned?

SPEAKER_00 7:44

Yeah, yes, it's the first line. So the first line basically, and this this was actually one of the things that I liked the most because I I mean already being in a VP position or a CSEL position I had or the CISO positions in the in the past, but I never wanted to let go of my hands-on side of things, right? So I really like to be hands-on to coordinate the choice of the technology to actually investigate, to do the POVs, the POCs, of course, with the support of the team, right? But I don't want just to issue an RFP and then get the results back. I really like to uh get the nitty-gritty of things, and this is basically I would say one of the things that attracts me on the first line of defense or more on the practical side cybersecurity stuff, instead of the information security or cybersecurity risk management, which is more on the second line, um second line of defense. So I was responsible to select vendors to do RD, to know what is in the market, what what exists in the market, to test the technologies, to do the POVs within the bank, to select the best provider, um, and of course to implement it and to uh get the support also from my team to implement uh that that's one of one of the key things is of course to have a very good team surrounding you.

Choosing Vendors And Staying Hands-On

SPEAKER_01 9:03

Obviously, obviously. Um you you obviously saw different uh topics and within those topics different vendors, right? All all through your experience uh with the bank. I'm curious. I mean, in the context of the bank, what are the topics that for you were kind of uh core or where you spent a bit more time and uh and that you saw were uh uh uh maybe the challenges, right? Or part of the big challenges of uh of uh the security of the bank.

SPEAKER_00 9:30

Yeah. Oh that that's a complex one because there were times where also because of the regulatory environment that we were we were acting, and also we we had a particular case because we were under the direct scrutiny of the supervising authority with allocated uh uh um special auditors in place dedicated to the bank. Um so in Germany uh had has a very strict regulatory landscape environment. Um and as soon as you have a couple of non-conformities that are, let's say, that caught the catch the eye of the supervising authority, if it's relevant enough, they will allocate a special auditor to you that stays with the bank for whatever time they deem necessary in order to correct or to elevate the bank's maturity to the level that the supervising authority um uh thinks it's it's good enough already. Um so we had a very close eye of the supervising authority and the special auditors, and this basically creates an ecosystem and an environment where you can, I would say, more easily justify some investments in cybersecurity. Um but the areas overall that always the supervising and regulatory authorities are concerned with is protecting customer funds in terms of banking, right? So the goal of cybersecurity is to protect the business, is to try to minimize internal and external, let's call it, fraud also actually. Although we have this very clear separation between cybersecurity and fraud, but in the end of the day, they are, let's say, converging a bit. That's why you have these cyber fraud uh fusion centers nowadays. But um protecting customer funds is always the most important part, and this often comes from external and internal fraud, but then you have the other side of the coin, which is you have so many regulatory landscapes, so many certification requirements that in the end of the day, the cybersecurity function, at least my personal experience, is you sometimes need to think, okay, I I do believe that we should go a bit more to the right, but I need to comply with ABCD requirements that I mean, if you don't uh deploy the controls, you are infringing with whatever uh uh uh regulatory or certification requirements from certain certification schemes, so you need to shift a bit your priorities. I'll say the most important part is usually to have this broad uh scope where you tend to put the regulatory part and the compliance part at the same level, but never uh uh forgetting that you are there to protect the business and to protect uh the customer funds.

SPEAKER_01 12:17

Makes sense. Uh I mean I I hear uh from uh from uh many sisters the same that I mean just fine. I mean, you and in the end, compliance and and regulation are there, and they could marry have a good marriage with cyber, right? So that you can uh have the right controls in in place. How did you uh um was it always easy to balance uh this these two parts and uh and uh what were what were the the the topics where you did were able to to marry this, uh right? I I I think we discussed in the past uh uh around Dora, right? And a few of the regulations from there. Uh but I'm curious uh what are the topics that you were uh able to marry the two?

SPEAKER_00 12:57

Yeah. So on top of my head, I can think on the few requirements that we had. So PCI DSS certification, you need to have it, of course. Swift, you need to comply with the customer uh um uh security protection framework from Swift, Target 2, ISO 2701, uh ISO 22301 for business continuity management, and uh Dora, of course, right? So at least the six comes uh oh, and PSD2, uh, which will be eventually replaced by PSD3. But if you put uh and by the way, we had, and I think most of the the financial institutions have this, which is like let's say continuous monitoring of all the regulatory landscape, legal landscape, uh certification landscape, and so forth that is coming and appearing, then this is funneled to you as a function, cybersecurity function within the organization, and basically to understand if you are already or not complying with the all of the requirements. So it's a it's a ever-evolving game, and you always need to be on top of this. So we had at least, I don't know, six, seven uh schemes on regulatory and certification side that we had to comply with. But what I always say, and I still think the same way, is um it's not easy because sometimes you feel that you are only working for certification and compliance purposes, and moreover, put on top of this all the internal audit topics that you have as a bank in the third line, right? So there was a there there are times where you think that you are only working for audits and compliance uh schemes, but the trick is try to take that into has an advantage to you as well. So there are a lot of investments and a lot of uh, let's say, programs and and projects that were executed in the organization that came from the regulatory needs. So you also have uh a bit of an easy side of things to justify certain investments and certain changes in the organization because I mean, also you can read regulatory uh schemes more gently to your side, let's say it that way, right? So you you can make an interpretation that is more suited to what you actually want to do in the organization, um, and not to serve your own benefit or because you you want to test ABC technology, but because you believe in terms of the maturity landscape of your organization that it makes sense, so you use this interpretation of the the law or the regulation to your benefit. So this is what I've done. So um in certain cases, we understood okay, we have certain gaps in um not to disclose anything, but we have certain gaps in a certain area in the organization. Okay, let me reread all the certification schemes and the regulatory requirements and understand how I can turn these requirements into something that I know it's a gap in the organization and steer the investment towards this direction. So this is basically what my team, uh my team also did, and I think we've done it very well because at this point we do believe that with all of this regulatory schemes, especially with Dora, that is that that's very broad, we we are able to scope a lot of the cybersecurity controls that we wanted to put in place in the organization.

Protecting Customer Funds Under Scrutiny

SPEAKER_01 16:22

Very clear. Uh I mean touching on the organization piece, um one one of the biggest attack factors we always know is is uh people and not only on the security organization, right? And so um um I'm I'm curious what was uh with with the size of of uh of uh Solaris Bank and with the culture of being a uh a tech company, uh how is scaling security across uh uh uh uh organizational culture uh easier or or more difficult? Um I mean there's there's always this this perception that uh more uh technical safety uh organizations such as the tech unicorn would have an easier time uh in on on scaling security within the organization uh than than others, right? I'm curious what what was your experience and perspective there?

SPEAKER_00 17:15

Yeah, I mean for sure we have less legacies than major banks out there, right? So we don't have that much legacy, and uh I mean we we we are uh fully uh cloud-based uh bank. So our core banking sits in AWS, right? So everything basically in our infrastructure sits in AWS, which on one side makes it easier, right? Your your footprint is much smaller, you don't have those uh legacy systems that are uh uh super outdated and it will take years to to do a migration and and and uh a plan to to shift the the technology. Um but on the other side you also have this I would say that I would say that the biggest difficulty is culture because sometimes in fintechs and scale ups um the the perception is that you are a tech company, but in reality, as soon as you have the banking license, you are a bank. So you are audited, supervised as a bank, doesn't matter the type of bank, right? If you are a Solaris or a number 26 or a Deutsche Bank, you you are a bank. So you need to comply with the banking regulation. I and I think in terms of mindset, that that's the most difficult part because people need to really embed themselves in the culture of risk-based actions and uh banking control, change management, uh 4I principles, and everything surrounding these kind of controls that connect with the internal control uh framework of traditional these institutions of banks, right? Um, so I would say this culture of okay, we are a tech company, we are a fintech, we are a scale-up, whatever you want to call it, but you are also a bank. So you need to comply with the banking regulation. You need you need to think uh has a bank in order to take all of your internal operations, and this was actually a shift that um maybe maybe I saw it in in the last year, uh uh so after three years, maybe I started to see the shift in the organization, uh, which is good. But again, cultural shifts take a long time, um, and you always have this uh um perspective of oh, let's just do something quick uh and do some quick implementations and let's uh just um create new products and test new things, and because we need to scale the business, but we need to have uh a different perspective when you are talking about a bank, because you have this uh uh regulation that makes you need to um slow down a bit, rethink two or three times to go through certain processes, and sometimes this is not well received by the teams. Uh, things like oh, I don't know, a simple basic thing. Maybe you cannot be root of your uh uh endpoint and you cannot install whatever you think uh you need to install because it makes you more productive unless it's pre-approved by you by the organization. This is not well received by everyone, right? So when you go to to this kind of uh detail, technical details, uh really the control shift pays a uh a visit to you and you really need to revisit those topics.

Turning Compliance Into Security Investment

SPEAKER_01 20:36

Well, uh this is a very timely topic, right? Because as everyone is trying to embed uh from from uh sometimes with with CISO or CIO CEO approval, right? Embed uh automations and AI across every function of the business, right? So this balance between uh product speed and security is I think as timely as as ever, right? Were there times in which you or examples you you could mention in in which the the trade-off was uh very unclear, right? So that people were uh having a hard time giving uh security uh a voice uh versus getting product speed.

SPEAKER_00 21:11

Yeah, I would say mostly on this uh secure development lifecycle part. I think it's where where you feel this the most. Again, Solaris is a bank as a service, so basically we live and read APIs, we we sell banking services via APIs. I mean, our partners consume our APIs and provide financial or banking uh uh instruments or products to their own end customers. Um, so basically, we develop a lot of uh we develop a lot of software. Uh so the security of the development is really important for uh for a bank as a service. Um I would say that this embedding of security controls uh throughout the whole life cycle of the development um is where you usually feel more the friction between the teams, especially. Between the of course the development team, uh the architect team and the cybersecurity team. Um, so you really need to understand uh the pains on the other side, they also need to understand the whys or why the cybersecurity team is imposing certain guardrails, um and why, for instance, your PR, your uh pull request, right, is being blocked often and often and often again. And you really need to change something because otherwise it will not go to production. So these kind of things will of course also need some kind of cultural evolution within the organization. Um, and for sure this was one of the areas that we we could feel more friction between the teams.

SPEAKER_01 22:42

Uh this this is more of uh um uh a team uh concern, right? What what about the the at the board? I mean, we're talking here of a very uh um I'm assuming a very um uh um experienced board, I mean, talking about the CISO or or talking about the unicorn. Um but uh what what were the main uh the main concerns here, right? And how do you explain uh either to the sea levels or to the board that the concerns on uh beyond the regulation uh uh risk, also on on the security side?

Culture Shift From Fintech To Bank

SPEAKER_00 23:18

Uh yeah, that that's a very tough one. Um on one particular case, I was uh fortunate enough so that my board was very aware of the cybersecurity um relevance within within the within Solaris. Um and this is always a very positive sign, right? So when you have a cybersecurity uh officer or CISO or ISO, whatever the role it is that is leading either from a first or second line uh role, the information security or cybersecurity, and you are presenting to the board and you are in the board meetings and in the group risk committees, and you actually have dedicated uh uh steering committees for cybersecurity, this is already a very good sign, of course, and the board participates in this. Um I would say it's it's very different the way that you need to communicate, even with each element of the board. I I had elements of the board that were more on the business side that clearly understood certain KPIs or KRIs that I was presenting. I had other members of the board that were more on the risk side that understood other KPIs and other KRIs that I was presenting. So it's it's really you really need to create, in some cases, various abstraction levels when you are presenting to the board. Um, because in the end of the day, what they are concerned is uh regulatory risk, compliance risk, uh business risk, uh and everything around cybersecurity risk will affect the compliance risk, the regulatory risk, and the business risk. So it's not a direct relevance, I would say. So they are the the the relevance for the board is not um do you have control A, B, or C deployed, is more how secure are we? And what is the strategy that you are doing that supports our regulatory landscape and our compliance requirements? And are we okay to provide certain services to certain customers? And are we okay from a supervising authority perspective in terms of protecting our customer funds? Um, so I would say there's there's always this uh these these certain levels of abstraction that you need to create when you are presenting the cybersecurity indicators or key risk indicators or performance indicators or strategy uh to your management board because they are more concerned with these kind of business risks, compliance risk, uh regulatory risk, and so forth.

SPEAKER_01 25:51

It's clear. Um in this line of uh perspective, uh did you come to to talk about specific uh segments or or this this was more of a conversation you'd have with your teams, and uh unless uh it doesn't boil down to the level of expertise you can talk about uh I mean how identity is changing, how cloud security is changing, how how API security is changing with uh with uh with the board, right?

SPEAKER_00 26:20

Yes, so I I think if you can frame it in a way that that provides a clear message to the board in terms of the business impact, you will get your your way, right? So for instance, when you talk about identity, you cannot approach the board and say, oh, I think our uh identity security framework is not the best. You say, yeah, okay. But if you talk about things like our uh security controls around internal identity or the identity management of our um of our partners or end users, it's not set up in a way that we can detect fraud or prevent fraud or prevent account takeovers in a certain way that affects the business and can uh in the end of the day result in uh a loss of of uh funds to the customers and uh therefore in uh in inspections of the supervising authority, penalties and so forth, then if you create this narrative, this uh story within the organization, then you can present this and they will understand in a meaningful way what this represents. There are some topics that are very direct, like fraud. All of them, let's say, understand what fraud is, right? But if you go there and you say about, I don't know, cloud security, API security, identity security, they kind of understand that this might be relevant, but you are talking about a very niche topic, about a very uh, I'd say for them low-level topic that doesn't resonate with the main concerns that they have, which is again the business, the the compliance side of things, the regulatory uh side of things. So you need to create this narrative, you need to explain why this is important overall for the organization, for the business that they are trying to steer uh in the organization.

SPEAKER_01 28:05

I think it speaks a lot from the experience you had, right? Uh, this is already a very uh very uh hard-earned lesson there, I think it seems so so so um that that comes along very very well. Um in terms of topics, uh uh where have you been spending uh your last uh maybe year? Uh uh what were the topics that for you were a bit more uh uh either because they were new or because uh there was uh there was um something in in uh in that market segment that is changing. Where have you been spending a bit a bit more time uh in in this uh last few months or a year?

Secure Development Lifecycle And Delivery Friction

SPEAKER_00 28:44

So I would say definitely Dora. So uh um also depends on where you are as an organization, right? And again, consider that we already had all the PCI certifications, the SWIFT, the the ISO 27001. So we had all of this, and we were already aligned with the previous uh uh regulatory schemes of the AIT. Uh so we didn't have like a uh a blank sheet when we started this Dora uh initiative, but Dora really introduced a lot of changes. The the way that you need to implement uh incident management overall in the organization, the the the details on uh supply chain security, the details on risk management, the way that you approach uh risk in a certain way. Um, of course, depends how you have done this before in your organization, but we have spent um a long time, and we are still uh spending uh uh a lot um of time and capacity investment in implementing Dora end-to-end, I would say, because it's a very complex uh process that you need to uh implement in the organization because it touches all the areas uh within the bank, right? So it's a it's not something that touches cybersecurity or touches risk, so it touches everyone in the organization. Um and that's something that is law, right? So it's a requirement. Uh but also besides that, I would say that fraud and AI fraud is a topic that we are really starting to see a lot. Uh, not only us, right? Other banks will will probably say the same. Uh, you really start a lot, uh, we you really start to see a lot of threat actors that are uh uh targeting targeting you and your customers with much more capacity, much more capabilities, with different uh ways, and this all comes from AI, uh either on performing account takeovers in a different way or trying to bypass uh biometric validations, uh, whatever the topic is, you see AI and fraud combining and really playing a different role um in the organization, or let's say against the organization. This is something that we are we are also seeing um that is scaling a lot, and we are of course looking at this with with a lot of uh tension.

SPEAKER_01 31:05

I think this is uh uh an amazing uh point to to to end. Uh you ended up covering also the the most emerging uh topics you've been seeing the last few months. Uh and so I I hear this will only go in going the same, this is going the same direction of accelerating. So so really appreciate this. I mean any any final words, any uh uh uh topic that is top of mind that for you is is uh of uh of concern? And you can say AI and everyone will agree, right?

SPEAKER_00 31:35

Yeah, yeah. AI AI basically serves for everything nowadays. Um, no, I would say that with with the new regulatory uh landscapes that we are living, uh especially here in Europe, right? So um things are overlapping a lot. There's a lot of uh overlapping schemes, there's a lot of uh um let's say complexity that's being added into the the organizations. And DORE is very specific for the financial sector, right? But if you go to NIST2 and IS2, right, so you have a much broader uh coverage of other sectors. So when you put all of this and then new emerging threats, I think sometimes there might be a gap. Um doesn't mean that it's not relevant to completely uh focus and adhere to these regulatory schemes, of course, also because they they have low transpositions, but um what we need to also be always conscious about is that the threat landscape is constantly evolving. So that's why a proper risk-based approach, a pro a proper way to understand how the new threats will affect our business, is is really the the one-on-one that we should never forget. Um everything else also needs to be done, yes, but we need to continuously understand the threat uh landscape that is surrounding us and what we should do in order to protect our business. Um I would say that this is something that we have pursued always, but uh is becoming more and more challenging due to the speed of these ever evolving changes.

SPEAKER_01 33:11

A lot to unlock there. Uh Nuno, we'll have to keep that for another episode uh of the podcast. Really appreciate you joining and sharing the insights with us. Uh and with that, uh, thank you all and uh see you in the next podcast. Thank you so much, Bill.