GDPR Is Only as Strong as Your IAM: Turning Compliance into Control

I'm going to give you a little bit of a twist of GDPR today. I'm looking at GDPR from an identity and access management perspective. And it's a little bit of a twist, so bear with me. But I hope that it will at least bring some thoughts in how we can align these areas moving further.

So, I work at a Nordic niche bank. We operate in Sweden, Denmark, Norway and Finland. We are an in-house identity and access management team.

So, we are responsible for all the identity platforms that we have within the bank. And of course, very highly regulated.

So, I've been working with identity and access management for almost 20 years. And the latest years I've been at the bank, building up the competence about identity and why identity is the new parameter for this. And when I began at the bank, identity was very low in the basement and has now trickled its way a little bit up above and into the management sectors, which is important, of course.

So, what I've noticed over the years is that I see it as GDPR doesn't fail because of missing policies. It fails where actually access isn't controlled. And that's what I want to talk to you about today. How we turn GDPR from compliance into actual operational control and where we can do it at scale.

So, we have somewhat the uncomfortable truth. So, it is a little bit uncomfortable. Most GDPR failures are not legal failures. They're access failures.

So, you bolt the door, but you leave the window open because you don't see it from a full perspective. On paper, everything looks okay. Policies exist. You have a data protection environment. You have people responsible. And you have your DPIAs ongoing. But in reality, you usually look at access being too broad. And you have problems in controlling the cross-border access. I will come back to that a little bit in a while. And when somebody comes up to you and asks for evidence, and that's what we all fear a little bit, is that question, how can we provide evidence?

So, I wouldn't say that GDPR breaks in documentation, but it breaks in execution. And with that, I mean execution when you want to make evidence of something.

So, what we have today is that we have a situation where data is everywhere. And almost for all companies today, we have a very decentralised way of handling data. It is not as it was before that we could close it within our own force. Now we have the cloud, we have different SaaS solutions. We have a lot of remote workforce. We also have vendors and the service providers for us. And of course, in the world that we're in now, we have the cross-border operations. And all of this exists and has data in different levels and in different perspectives.

But it also gives you an insight of how much you actually need to protect. So, I'd say that leadership, they have a couple of questions that they need to ask and answer, of course. Because if they can't come up with good answers, then compliance is very fragile.

So, can you, as a leader, can I, as an IAM responsible at our bank, can I stand tall and say, who can access personal data right now? Why do they have the access? Because it is necessary in some certain areas. And if they have the access, who approved it? And then this is really important. Can it be removed automatically? Or does it need to be handled by somebody in a manual state? And then when we get the question, can we prove it? And how long does it take us to actually prove it? Are we speaking minutes? Are we speaking hours, days, weeks?

Yeah, it depends a little bit. And I say it depends a little bit on your maturity.

So, we have some pillars in GDPR. And I've looked into them from the perspective of, okay, they are like the enforcement layer. They are the ones on the left-hand side. There are more than these, but I chose these five. And how can we look at those and translate it into an IAM system? Like translate it into an IAM perspective.

So, I see data minimization. Well, quite easy. It's least privilege. Are we good at least privilege? I don't think so, but we're working on it. And we want, a lot of us are driving zero trust projects and other things like that. But it's actually a way of securing that you can't have more data than you actually need. Accountability. That's one of the pillars of GDPR, of course.

Yeah, that means that we need named approvers. And this is something that I've been thinking about because a lot of the sessions are about AI, as you have seen and noticed. This is actually not so much about AI, but it actually is or will become a part of this in the future. And named approvers is something that will, of course, be a challenge. Security.

Well, in identity and access management, we love to say that MFA and conditional access, then we're secure. So, I thought that worked perfectly with the security pillar. Auditability.

Yeah, logs and reviews, the CEM, the SOC. We only need to make sure that we find the patterns that are interesting for us. And storage limitation.

Yes, that's a very good one. How many do we not have databases that we're not really sure what the retention period should be on these? On the information stored in the database.

So, we're talking join or move relievers, but we're also talking lifecycle automation on, for example, different storages. So, that's my take on translating the GDPR pillars.

So, next, I thought we'd move on to... Well, just some examples of where does GDPR actually break in real life.

So, I think that a lot of us would probably agree on when we speak about vendor access, it's a little bit of, let's give us some access just in case. We have it at the bank, we have a third-party provider, and they actually asked us to be global admin just in case. They weren't allowed, but they still asked for it because that was handy for them. And that meant when an incident happened, they didn't need to go ask somebody for an approval.

But yeah, so there's not the bad intent of it. It's more that the third-party provider, they lean on speed, convenience, and just in case means one thing, more access than GDPR actually allows.

So, we have another one, another example. This is quite classical, and this one, working with IAM, you've heard it a million times, internal role changes, old access days, the inheritance of accesses. And that's actually something that it's difficult because the organisation moves fast and access doesn't. And we need to change that over time. That's something that we've learned during the day so far. And this is not really an HR problem or an IT problem. It's more of a governance gap between how the business changes and how access is updated.

And at the bank, we've actually chosen so that if you change role with certain criterias, we actually delete all your access and you need to start over again. They're not very pleased, the ones that change roles, but at least we know they won't inherit any access.

Okay, third example. This one is, of course, the one that we're all a little bit scared of. The privileged access, the crown jewel, the key to the kingdom.

So, we have, as I mentioned, the global admins, we have other admins, we have operations, we have consultants needing different types of roles, where they actually can do more than they probably need. And the moment someone has privileged access, most GDPR assumptions stop holding. Because data minimisation, proportionality, purpose limitation, they depend on privileged access being time-bound, justified and auditable. And that's something we all struggle with, we know that. And if they're not that, if they're not time-bound, justified and auditable, they actually collapse over time.

Okay, so those were the three examples from real life. So, I'd say, what do we want to do about it? What can fix it?

Well, I think that we have a couple of IAM controls that actually can help out at least. And I'd say that control replaces trust.

So, we want to, more than today, we want to timebox access, so we work with the just-in-time. We want to be able to take context-based decisions. We want to, of course, automate joiner, mover, lever. And we need to govern privileged access. And we need to automate all of it. Because if compliance depends on manual discipline, it won't scale.

So, I say, but it's a little twist to it, but audits don't care about intent. They care about evidence. And you might not totally agree on that. But we need to, from the IAM perspective, we need to be able to show who accessed the data, why they had access, how long did it last for, and be able to actually show the reviews and logs for it. And that's difficult. And it can take time to bring up the evidence for it. And I say that this is actually when IAM maturity becomes a business advantage instead of just being an IT cost, which is what we've been working for for many years.

Okay, so I say, if your GDPR strategy depends on people doing the right thing every single time, then you don't have a strategy. You have hope. Compliance only becomes real when it's automated and structured.

And I say, from my perspective, that automation requires identity processes. So, that was my take on the GDPR and how we work with it in the bank. And if somebody wants to continue the conversation, please reach out to me.

Well, thank you very much. We have time for one question or two questions. Are there any questions?

So, I'm going to ask a question. If there was one capability that you think that an organisation could improve in this, what would your advice be? Where would you start, practically? It depends a little bit on your IAM maturity. But I'd actually say, go for the automation part, so that you can make it effective and trustworthy. Automation to make it effective and trustworthy. That's really good.

So, in a sense, privacy and security overlap. And your presentation has been about that. Because security is about preventing malicious act, whereas privacy is about controlling, if you will, intentionally good things. Do you have any thoughts on that?

No, not more than from the perspective of, I see them as like partners joining arms, because we need to look at it from both perspectives. And I really believe that the IAM maturity can help us make sure that we live the policies of GDPR. Thank you. Thank you so much. Perhaps we will show our appreciation to the speaker for this very nice presentation. Thank you.