In the second episode of our podcast, Risk Grustlers, we are putting the spotlight on GRC with Vignesh Kumar, Senior Manager of Security and Privacy at Microsoft. 

Formerly a project manager for one of the largest equipment manufacturers in the world, Vignesh shares what drew him to GRC and makes us view it through a lens of admiration rather than dread.

He offers a peek into the world of audits – both external and internal – and demystifies both processes. He also shares what an internal auditor should keep in mind when trying to establish a rapport with the teams they audit.

Watch the complete podcast here

Let’s dive right into it!

Aayush Ghosh Choudhary: You started off in a completely different field. Can you tell us what sparked your interest in GRC and led you to where you are today?

Vignesh Kumar: When I came to the US for my master’s in management information systems, I learned about big four risk management consulting. I was always drawn to careers involving uncertainty. Then, I got the chance to work for a company that wanted to handle things in-house instead of outsourcing their IP activities. I joined as a technical product manager, acting as the bridge between business and engineers.

I also managed a suite of applications, handling hygiene and compliance. This is where my practical experience with the GRC space began. I answered questionnaires from the testing team, which was quite interesting. These results were then shared with business unit leaders.

The work I did was at the company level, while I managed several applications with a small team. It got me excited about working on things impacting the whole organization and presenting results to business leaders, even the C-suite.

This is when my interest in transitioning to GRC sparked. And that’s how my journey in this field started.

Aayush Ghosh Choudhary: Very often, the remediation steps created by the GRC team are viewed as burdensome by the other teams. Even though you experienced this burden, it led you to have a fascination for GRC. Any reason why?

Vignesh Kumar: The process of implementing fixes to bring an application back in line with compliance can be tough. But, often, these fixes not only address issues but also make the application better, ultimately making your life easier down the road. So, it’s actually beneficial.

What I came to really appreciate about GRC was how it could positively impact my applications—those four or five I was responsible for. GRC’s ripple effects spread across the organization and ensured that hundreds of applications across three business units were compliant. 

The idea of the impact on the organization and the chance to dive into a suite of 100 applications, building relationships with business leaders from various parts of the company—it just seemed really intriguing and appealing to me. It felt really cool and sexy to me.

Aayush Ghosh Choudhary: I love that you used the word “sexy”, which isn’t typically associated with GRC. This brings me to the question, which part of GRC do you enjoy the most?  

Vignesh Kumar: I think what I enjoy the most is the opportunity to learn. So, there’s this whole realm of opportunities to dive into, understanding the applications driving the business. It’s like figuring out what these apps do, how they fit into the grand scheme of generating revenue, whether they’re on the cloud or on-premises, and spotting risks tied to those differences.

You really learn the most through people. Imagine sitting down, sipping coffee with the folks who own these apps and asking them how their system works. It’s way more effective than plowing through tons of dry documentation, right?

All this learning goes hand in hand with communication. You have to get across feedback, sometimes pointing out little hiccups without coming off like a nitpicker. It’s like you’re trying to give your engineering teams a hand, not play the blame game, even though, let’s face it, finding flaws is what we do.

But honestly, the drive to learn about every nook and cranny of your company, those different apps that prop up the whole operation—that’s what led me into GRC.

Aayush Ghosh Choudhary: What are some parts of it which felt a lot more difficult than you had originally anticipated?

Vignesh Kumar: From a project management angle, you’ve got to deliver things within a set timeframe. Sometimes it’s dealing with apps or processes you’re already familiar with, where you can chill a bit and focus on risk and control.

But then there are those times when you’re in the dark. You could be dealing with a new process, a new system that is maybe not even live yet. You’ve got to dive in, figure it all out, assess it, and still suggest fixes—all in a tight window.

Regardless of the system’s complexity, compliance isn’t patient. It’s all about hitting those time marks—like, “Did you check these boxes this quarter? Did you in these four weeks?” It’s a race, for sure.

Another hurdle is dealing with the repetitiveness. You’re learning the ropes with a new system, all pumped up. But then, it becomes a routine, like a broken record, doing the same routine over and over. That’s a challenge on its own, too.

Aayush Ghosh Choudhary: How do you deal with this repetitiveness?

Vignesh Kumar: I use my people-management skills to delegate work that I find repetitive. I assign the same task to different people to avoid any assumptions based on repetitiveness. I’ve seen external auditors stroll in casually like they’ve done this dance before. They expect things to be a certain way. Like, they’d ask for screenshots of past setups and replicate it. They assume it’s all good, but sometimes, things aren’t as smooth as they seem.

So, to keep things solid, even if it feels like a rerun, it’s crucial for GRC pros to go back to basics, ask the right questions, and make sure things are on point.

Aayush Ghosh Choudhary: In your experience, how do internal and external auditors vary?

Vignesh Kumar: It’s interesting how engineering teams tend to feel more at ease with internal auditors compared to the external ones. External auditors have a specific mission.They’re there for either your PCI, your SOC, your ISO, you name it. They stick to their set agenda and scope, focusing only on what they want to see.

They often miss the bigger picture, that sense of ownership. Now, internal auditors have a different vibe. They’re part of the company, driven to make things better and provide an independent view on controls. They don’t just box themselves into compliance checkboxes; they kick off with risk assessment.

They dive into enterprise risk management, understanding the big risks for the upcoming year. That’s how they set up their audit plan. They zoom in on specific systems and processes, wearing that risk-based hat. They dig into risk assessments, crafting a set of controls based on what the systems should ideally have, and then they go for testing.

So, the key difference is the sense of ownership. Internal auditors have that, while external auditors usually stick to compliance. It’s about being risk-based versus compliance-focused. 

Aayush Ghosh Choudhary: What’s been the typical response to you coming in for an internal audit?

Vignesh Kumar: The first time they’re usually super excited. They are excited to show how their systems work and hear our suggestions. The second time, even if it’s for a different application, they ask us why we’re back. By the third visit, they wonder, “Why us? Why always us?” And that’s when we say, “When we come back to you, it means you’re crucial for the company.” This creates a sense of responsibility and ownership.

Aayush Ghosh Choudhary: Do you first build chemistry with the respective teams, share a few drinks and make yourself look like an insider that’s there to help them and then eventually build up to the tougher part of the conversation? How do you make them comfortable?

Vignesh Kumar: When we start dealing with these stakeholders, our main focus is on building those relationships, right? But the thing is, the initial point of contact is all about that first audit.

If they can’t meet that 48-hour deadline, we’re cool with it, as long as they let us know in advance and explain why. This initial phase is mostly about learning, discovering the systems and processes.

Toward the end of the audit process, when we’re heading into that closing meeting with the C-suite folks – that’s when things can get a bit tense. The team that’s been working hand in hand with us throughout the audit, they’re right there too. And they start challenging  our observations. If the risk did not result in a security incident, they tend to question why we pointed them out.

That’s where education plays a role. We try to show them that the risk isn’t about what went wrong; it’s about what could go wrong. Now, things can get a bit heated during the reporting phase, but it usually smooths out in no time.

Aayush Ghosh Choudhary: How can internal auditors position themselves as helpful insiders?

Vignesh Kumar: It really boils down to people skills. We’re all human, after all. When it comes to the audit process, it’s not a gray area. It’s either you’ve got control or you’ve missed the mark – that’s just how it is. As auditors, we’re all about facts. We gather the data, lay out the evidence, and present it as it is. Now, when it comes to the report, it’s not about throwing someone under the bus. It’s more about how you convey the message and keep that relationship intact.

During a six-week engagement, the real distinction lies in the nuances. Everything else is about stating the facts, except for that relationship part, which isn’t something you can put a number on. That’s where things can get a bit tricky, especially for those starting out. But with experience, delivering these messages becomes smoother and more natural. It’s all about finding the right way to get the point across.

Aayush Ghosh Choudhary: What are some of the common challenges you face with stakeholders?

Vignesh Kumar: One of the big challenges I’ve come across is this lack of clear ownership. It’s like everyone agrees when you point out the number of vulnerable servers without proper patches – that’s just raw data, hard to argue against. But when it comes to who’s responsible, things get fuzzy.

For instance, take engineers managing a fleet of servers. They spot vulnerabilities and need help from the security team to address them. The hitch is, engineers are all about speed and the product. They’re not keen on disrupting their production servers for security’s sake. While security is all about, well, security. It’s a classic accountability gap.

At the end of the day, a vulnerable server means the company’s on the line. Reputation, security, potential fines – it’s all at stake.

Back in the day, it was a tussle between engineering, security, and the GRC team. Each guarding their turf. What we had to do was remind them it’s one company, one goal. I even pulled in the CFO once for a meeting, just to drive home the point: “Look, I don’t care whose problem it is. Just fix it. Our company’s security is on the line.”

Aayush Ghosh Choudhary: The idea of GRC seems to differ across the globe with different countries adhering to different regulations. So, do you think that the skills acquired as an auditor or a risk manager have a strong local context, or can they be applied across the globe?

Vignesh Kumar: Basically, it comes down to grasping the IT basics. You’ve got to understand system architecture and get a handle on those fundamental general controls.

Once you’ve got that down, it’s about making these things work efficiently in your environment – no matter what you’re dealing with, be it products, systems, or data. Whether it’s CCPA, GDPR, or any regulations, it’s like a skill set you can pack up and take anywhere.

Sure, the core competencies stay the same, but the way you apply them might shift depending on where you are. So, bottom line, these skills can be used all around the globe.

Aayush Ghosh Choudhary: What according to you is an ideal GRC solution?

Vignesh Kumar: What really matters is how much time your solution saves, right? From an industry perspective, it’s about pinpointing what we’re after. Let’s say, for instance, I need to convince our CFO that getting this certain tool is worth it. I’ve got to show them the return on investment, the cost benefit.

So, I paint a picture – implementing this tool cuts down on all these steps. That’s the time I can use elsewhere. And not just that, it hits multiple regulations. It’s a win-win for different teams – internal audit, security, you name it. Everyone benefits from putting it in place.