I’ve spent a good part of my career building, leading, and improving Identity and Access Management programs. And one thing I’ve learned is that knowing what a mature IAM program should look like and actually building one are two very different things.
We have plenty of frameworks, best practices, and vendor solutions telling us what IAM should look like. But what happens when you walk into an organization where the identity data isn’t reliable, provisioning is largely manual, applications aren’t integrated, and nobody seems to know who owns what? Where do you start?
That’s what this blog explores—practical approaches to IAM that go beyond the frameworks. I’ve found that some of the hardest decisions in IAM have very little to do with technology.
It’s deciding what to fix first when everything needs attention. It’s figuring out how to build a team that can both operate the environment and improve it. It’s getting the business to participate in decisions about access. And it’s knowing when a practical solution is better than a technically perfect one.
I’m a big believer in automation, strong governance, and effective security controls. But I’m also a believer in understanding the problem before jumping to a solution. Because implementing a tool doesn’t necessarily mean you’ve improved anything.
I’ve seen how easy it is to focus on completing projects without stepping back to ask whether we’re actually making the organization more secure or making access easier to manage. And I think we need to have more conversations about that.
I’m currently working on a book about building effective IAM teams and programs. As I’ve started organizing my experiences and lessons learned, I’ve realized there are a lot of individual topics worth discussing.
I’ll share practical perspectives on IAM strategy, identity governance, privileged access, automation, team structure, and the operational challenges that don’t always fit neatly into a framework.
I don’t claim to have all the answers. I’ve learned a lot by working through real problems, and I know other IAM professionals have approached those same challenges differently. I’d like to learn from those experiences too.
At the end of the day, I believe an effective IAM program should reduce risk, enable the business, and be sustainable.
That sounds simple. Getting there is where things get interesting.
So let me start with a question: What’s one thing you’ve learned about building an IAM program that you wish someone had told you earlier in your career?