Breaking Down Organizational Silos With a Common Risk Language

Megan Phee: Hi, I'm Megan Phee and this is GRC& Me, where we interview industry thought leaders in governance, risk and compliance on hot topics, industry specific challenges, trends and more to learn about your methods, solutions, and outlook in the space. Today we sit down with Dimitrios. Dimitrios is the director of information Security at Wayflyer. But Dimitrios' career stems from roles such as a CISO at Modern Times and the CISO at Trustly. He has spent most of his career working in technology companies and today we talk about his opinions on risk quantification, his view on global standards. And he talks about what are the necessary and important actions that folks can take in a new role within an organization. Here's my conversation with Dimitrios. Hi Dimitrios. Welcome to an episode of GRC& Me.

Dimitrios: Hi Megan. Thank you for inviting me.

Megan Phee: Yes, I'm excited for our discussion today. I know when I first met you I thought, oh, this is someone I want to have on the podcast. You're really knowledgeable about this space, you're very funny and you've got a lot of insights into risk quant and other aspects of cybersecurity. So I think what a great place to start today would be if you would share with me and the listeners a little bit more about your background in governance, risk and compliance. How did your risk journey lead you to your current role as the director of information security at Wayflyer? That would be great to learn.

Dimitrios: Absolutely. Absolutely. So I think I need to add some background. I started working in my career as what you would call today a system or a network engineer. And then I transitioned to what probably today we call inaudible security and I was doing a lot of hands- on things. Eventually I moved into information security and I started very early to realize two things. One is that we need to work with more things than just technology if we want to keep the company safe in any shape or form. But also I also realized that we don't seem to have a single source of truth. So back then when I started, maybe we had one or two standards, PCI was in its beginnings and we had a precursor inaudible called BS 77-99 or something. And it was obvious that no one had a really straightforward way to go. So I started trying to understand what it is that we are trying to achieve. So if you forget for a moment that all these people have standards and they're good to be followed, what it is that makes sense for us. And I think that started leading me down the path of, I think we would call it inaudible today, but more try to be risk- based. Try to understand what it is that I'm trying to protect, why I am doing the things I'm doing. Fast forward a few more years, and then privacy, at least in Europe, became a very big thing with the introduction of GDPR. So suddenly companies not only had to care about security, but also privacy became an integral part of what we do and maybe not as security professionals, but we started working very close in tandem with our legal professional colleagues, with compliance people who came maybe from more financial regulations or whatnot. So the whole GRC idea started to converge. Because right now we don't talk just about security, we talk about the privacy aspects, the compliance aspects, the regulatory aspects, even the legal aspects to a standard extent. So this is what I have been doing the last, I should say, maybe six, seven years. And that is how I ended up being at Wayflyer at the moment where I work as the director for information security, but working almost extremely close with privacy council and the compliance officer trying to make sure that whatever we do, it addresses the issues holistically, not just in our own silos.

Megan Phee: I love what you just mentioned that because that's what we hear from our prospects and our customers today is how do we break down silos? How do we have better communication? You're trying to think about what are we trying to achieve here as a business? What are you really trying to achieve holistically as a business? Where can we get to a single source of truth or at least align on the way we define risk within an organization? And so that leads me to think about risk quantification because risk quantification is all about that, quantifying risk in a common language, a financial language. And it's been a really kind of hot topic in the GRC space for a while now. And in talking to folks, there's a varying degree of maturity or awareness of what risk quantification is and how it can help an organization. But tell me a little bit about the challenges that you perceive or experience implementing risk quantification at an organization.

Dimitrios: So risk quantification was always kind of the holy grail. I mean there have been attempts from as far back as I can remember, talking about things like the annual loss expectancy and the single loss occurrence, especially within professional organizations like ESAC, (ISC)². The problem is that although these formulas are very simple to understand, you really, or at least I should talk about myself, I really have no idea what they mean. Maybe I can estimate the actual quantifiable value if our service is down. I can say in one minute we're losing that much money. But then when it comes to our service was breached, I have no idea. I'm really sorry to say that the first actual valuable quantification came from the GDPR side where they started to talk about specific fines in relation to data breaches. At that point I was able to start talking about things like if we lose our whole database, it's going to be 2% of our turnover, 4% or whatever the number might be there. And that is the closest we have gotten to. So it's easy enough when we are addressing availability risks. It's extremely difficult to quantify things when it comes to confidentiality and integrity risks. And the problem with that is we eventually need to translate the risk registry into actions. And these actions do come with money and they come very easily with money. And what I mean with that is if I tell the CTO that we need to do something, that means for him 10 hours and he knows how much he pays his people, so that's 10 man hours to do the activity. Or if I decide that I need a product to fix the problem, I know how much the product costs. And then the question becomes does it make sense for this risk to spend either the man hours or the vendor money? Very few times I actually have the answer there, to be honest. So unfortunately most of the times I have to refer to risk being qualitative. So if this risk materializes, it's bad and if this materializes, it's even more bad. So maybe we should treat the even more bad first and the other one second. But I do understand that this doesn't really add an extreme amount of value because how much money we should spend treating it, God knows.

Megan Phee: So on that lens, if you can quantify risk correctly or if it's implemented well throughout an organization, what kind of value do you think an organization can benefit from?

Dimitrios: So I think even if we are not able to say this risk will cost us exactly$ 1, 000, we can still use the risk management process to identify things that worry us and have an informed discussion based on the same parameters for all of us. So if something worries me as a security professional, the CTO can add the technical aspect of it. For example, the finance, the CFO, can add the financial impact then maybe the brand or public relations people, they can add the impact from brand reputation perspective. So it allows us, all of us, to have a talk about the same thing kind of within the same parameters.

Megan Phee: I like that.

Dimitrios: The second value it touches that even if I'm not able to say this risk will cost us a thousand dollars, I can still say that if this happens is going to be bad. And that means that we can drive a number of activities based on that risks, even if they're not quantifiable, we can go with a bit of a bad feeling. We can ask our peers and see how much they spend on to treat a similar risk and go forward with that. And the third thing that it does is it's not going to be possible for us to say we have zero risks because we can't quantify them. So we still need to present to external entities that they care about how we work, how much we thought we put into this activity. And at the end of the day we demonstrate that we did our best with the qualitative approach. And if we can quantify something, we will. But at least we can show that we are not ignorant and we are not just sleeping on it.

Megan Phee: That's super helpful for us and thank you for breaking that down. And from what I've read and talked to customers about and even GRC professionals like yourselves, is that risk quantification is kind of emerging as a new standard for translation. Translation of the financial impact of risk. But when we think about standards, I know we've talked about this offline, that standards are challenging, kind of frustrating at time. There's multiple global standards in flight right now and will continue to probably emerge. Expand a little bit about your perspective on that and when it comes to standards globally.

Dimitrios: Sure. So I'm going to start by saying that I definitely see a value in standards and I see the value in two main areas. One is if you don't know where to start, a standard will definitely either give you a starting point, depending which one you choose, or it'll give you a much more evolve point, not exactly tailored for you, but at least they're not going to nudge you in the wrong direction in the sense of the controls you will apply. Maybe it'll cost you way more than it should, but you're not going to do the wrong things. So from that perspective, I do see a value in standards. The second value they bring is that they allow you to demonstrate to external entities that you are doing something. And we could argue what SOC two or 9027-001 certificate means in terms of actual security value. But I don't think anyone would disagree with the idea that having one of these or any similar accreditation like PCI or whatever, it shows that you're doing something so you're not at level zero for sure. Maybe you're not doing enough and I'm willing to concede that, but you're doing something. And the more well- known, the standard, the easier is for people around you to understand how much it is that you are doing. So if you're doing an ISO certification, it's very easy for people to understand that you have addressed a hundred out of the hundred and 14 controls or whatever the number, and that gives them an idea about your posture, and then maybe they don't need to spend the time to come and inaudible with you themselves because they can rely on that piece of paper. So that's the good aspect of it. For me the more, I'm not going to say problematic, but the aspect I question is I don't fully understand why we have so many at this point. So I already mentioned SOC 2 and ISO and PCIDSS, and if you're into medical, you're doing HIPAA probably. And I'm sure there are some more specific ones. And my question is, or my thought process is, how much do they actually differ? So how much differently would you protect credit card data versus medical data? And I understand there might be differences in access and what do we call it, the retention period and all of that. I understand, but will the controls really differ? Wouldn't you want to vet your employees no matter what data? Wouldn't you want to have a strong onboarding, off onboarding access control process? So there comes the trick. Because while this time they have a lot of commonalities and there is a lot of organizations out there that they have worked to map one to the other, the thing still remains that you need to hire the dedicated auditors, go through the dedicated process, address the findings in a very specific way. For example, if you're doing SOC 2, you need to have a section three that describes your system. If you are doing ISO, you maybe have a scope document. So what I would like to do is maybe if we could homogenize or at least make some standard out of this common pieces and then PCIDSS could be 10 closes just specific for credit cards and HIPAA and other five just for the medical differences and go down that path. Because right now we do maintain a lot of documentation that is specific to its standard. And although there are tools out there that help, the thing is you still need to ensure that your mappings are correct, that they don't require more or less, that you have addressed the proper things. And it just feels frustrating and I'm not sure I understand the reason why.

Megan Phee: Well, I hear you. And even what we see in the US, we're seeing local, state level creating their own versions of privacy or other aspects. So yeah, I can see that. And I can see for folks who are living and breathing this role that how do you get your arms around all that? And you mentioned it a minute ago, if you can find technology to enable you in the work to ultimately help you assess once and satisfy many and just see clearly where are you against other frameworks, that is going to be very helpful. I know that's where we focus our time and energy to help our customers with, because that's the thing, unfortunately today there are a lot of standards and frameworks out there, and depending on your business model and the markets you serve and the products you serve, you might need many, many, many frameworks. So yeah, then your clients require it too. Yeah. Well that's interesting. Thanks for sharing your feedback on that and your perspective on that. And one other perspective I'd love to get from you is, so you'd mentioned your role there at Wayflyer and you've been in the role... This year you were new to that role and a lot of the folks that are listening to this in this year might have taken over or taken a new role within a new company. I'm just curious, what were the first five things that you wanted to do within Wayflyer to make an immediate impact or to understand? What were some of the critical aspects that you want to just roll up your sleeves and really get to know right away?

Dimitrios: Sure. So, very first thing is I went to the legal department and I asked them to see everything that we have done for GDPR. And the reason for that is that while most of the standards, they're kind of, let's call them optional, GDPR is not optional. It's a law in Europe, which means that as a company starting 2018, we were forced to prepare things. And a lot of the things that were prepared for the GDPR scope, they are applicable to security, like which are some of the core systems we process data on, what are the data flows, who has access to them, how are they managed? So that used to be a difficult thing to figure out when you went into a company, unless they had some amazing asset management. With GDPR it became a bit easier. So using that as a starting point, and then I started reaching out to the departments responsible for managing some of the systems. So I reached out to corporate IT to understand how we work with the systems that managed mostly employee data. And you can think of systems like email file, HR system, accounting, those type of things. I reached out to engineering to understand how we manage our production systems. So the things that we have developed internally. And I reached out to the platform team, which manages our cloud service. So again, they were the best source of people to tell you what kind of services we use in the cloud, how they connect to each other and what the problem is. The next thing is I reached out to my compliance department and they're safe keepers of the risk registry. So that also gave me a good starting point of what we have already identified that worries us and do we see any quick wins, any quick fixes, changes, controls that we can apply to mitigate any of these risks or are they in a more longer project of risks? And then the next thing was to take a discussion with management and some key engineers and ask where it is that we want to go. So we are where we are and that's great, but what are we aiming for here? Are we aiming for an internal program that satisfies our needs, but it's not really demonstrable to anybody outside? Are we aiming for some accreditation because that will allow us to build a program and also demonstrate it. Are we aiming to be accredited against everything? Because there might be a need for that. If you're Google or Microsoft or Amazon, you certify against everything. And based on that understanding of where we are today. And understanding of where we would like to be in six, 12 months from now, I started working with some smaller projects so that will give some quick wins and they couldn't really ruffle a lot of feathers in the company and then started planning for the bigger projects that will require process changes or introduction of tools or even removal of things that people have today.

Megan Phee: I love that. Thank you for walking us through that. And on that, I love that you've kind of tackled some immediate value for the business and some quick wins and then you look at longer term, maybe more cross- functional decisions. Right? And so how do you, that second phase when you get into more cross- functional value considerations, for example, the consideration of maybe investing in technology to automate processes and procedures, how do you go about creating a business case for those type of bigger projects or maybe more cross- functional business value drivers? How do you go about building a business case? Or how do you go about getting executive support for that? For those bigger items or those bigger either resource costs or just initiatives, like you said, might ruffle some feathers.

Dimitrios: So it all starts from, I would say kind of two different places, but it's kind of the same source. So one place is an executive will to do something. So typically that manifests as, we want the company to accredit because most of our customers ask for that. If you start from that point, then the management obviously already understands that that will have to happen if we want to keep doing business, and that means investment, maybe re- prioritization, some sort of changes. The other source is the risk registry. So if the management has already reviewed the risks and they agree that there are risks and they believe they're risks, then they're more willing to lend support. So some of the risks might come from the management team themselves. Some will be elevated or escalated from people closer to the wire where they understand what we are actually doing and hit up the management. And what I've seen, my role is this, is to make sure that when that risk registry hits, the management is as full of information as possible and that the management makes an informed decision. And if management decides to fix something, that kind of implies, although we do state it as well, that wanting to fix something means you're going to give us the resources to fix it, or the management might decide to accept the risk, in which case that's fair again. But then they also accept the responsibility that if this goes wrong, we kind of need to deal with the aftermath of that. There are very little cases where management didn't offer support. So if you either try to do something that they want you to do or you explain to them why you're trying to do something, most of the management I have worked with was very understanding. I do have to admit that I work mostly for digital companies, which means that the management is digitally educated or digitally trained to a certain extent. I don't know if my experience would translate if I went to a traditional brick and mortar company where the online world may not be the first thought, but if everything you do is online, you understand enough to know that when your security people say, " We should address X," that you shouldn't just sweep it under the rug.

Megan Phee: Yeah, that's so interesting. I think for a lot of the folks on the line that are maybe more in traditional use, traditional industry on manufacturing or banking, where to their core effort is they're on this journey of risk awareness and digital optimization awareness, and you are in a fortunate spot where you've worked for companies in your career that, that bit is at least addressed because I like what you said, they're digitally educated. They understand the value of technology, they're kind of onboarding with it and the nature of their business is to leverage it. And now it's more about the, " So what, who cares? What do we benefit from it in this scenario?" Which is really interesting. Well, thank you so much. So that's a lot of great information, just a little bit of, I think for the listeners to think about how do you, as a new joiner to a company, how do you identify opportunities for the small wins and the larger more strategic decisions? And then how do you just have that education? It sounds like you are, I love your role, which is you see your role as really the aid in helping management make strategic decision- making. And you do that by bringing them as much information as you can. So that's really great. All right, so the last question I have for you is just kind of a fun one. So when you're not doing all that important work about helping cross- functional team members and also working with management to keep them in the know about the risk and the compliance posture within the organization, where are you spending your time on the weekends or offline to kind of recharge yourself?

Dimitrios: How do I want to say this? It's going to sound extremely cliche, but I'm sure you have heard the phrase, if you love what you do, you never work a day in your life. And we also, we have spoken offline and that I live in Stockholm in Sweden, which means that right now it gets dark at three o'clock.

Megan Phee: Yes.

Dimitrios: So I will admit I don't spend that much time outside or doing extremely fun stuff. I do enjoy what I do, which means I spend a lot of time on the internet. Some of them is work, some of them is private education, some of them is seeing what happens in the world around us. Some of that is networking and talking to my peers, but I see it as a fun activity and that's what I do for hobbies. I sit on my computer, I play some video games, I talk to people, I play with technologies, I break things, I curse-

Megan Phee: inaudible.

Dimitrios: Yeah. So it's not extremely active. I'm rafting and then I'm hiking and then I'm climbing kind of situation.

Megan Phee: Well I love it. I mean, you put it best. When you love what you do, that's where you spend your time, right? It's your hobby, it's your passion. It consumes us, right? The day, the working day, consumes most of our calendar and most of our life. So I love that. Follow your passion and invest in your time. And I know that's why when I saw and met you, I said, " Oh, this guy gives to the community around GRC." And I was like, you're going to be a great guest for sharing your knowledge. So thank you so much Dimitrios for joining us today on another episode of GRC& Me.

Dimitrios: Thank you, Megan. Thank you for having me. I really enjoyed our chat and enjoy your weekend.

Megan Phee: Thanks so much. Cheers. To learn more about how risk cloud can support your cyber risk and security initiatives, follow us on LinkedIn or visit logicgate.com. And until next time, this is Megan PHee with GRC& Me.