GRC Is an Engineering Discipline. Not a Checklist.

Raj Krishnamurthy (00:01.0)
Hey, hey, hey, welcome to another episode of Security in GRC Decoded. I’m your favorite host, Raj Krishnamurthy. And today we have the honor of having awesome Akhila Chitrupalu, Chiti Prolu. Sorry Akhila, sorry about that. We have Akhila Chitiprolu joining us today. Akhila has 10 plus years of experience in security, risk and compliance. It’s great to have you on the show, Akhila.

Akhila Chitiprolu (00:28.384)
Likewise, Raj, great to meet you and excited to be talking with you today.

Raj Krishnamurthy (00:32.708)
And so, Akhila, maybe why don’t we start with your journey? What made you come into security and GRC and what has this journey been so far?

Akhila Chitiprolu (00:43.192)
security, risk and compliance journey. I started off as any other engineering background and in computer science back in India. I started my career with developing CRM and ERM systems while in consulting for my customers. And then I moved into information management, got into exploring security assurance.

took some courses and my master’s at University of Washington and landed into this world of security and compliance still very much in like more tech tech space and such but ever since applying engineering principles and system thinking from the get-go even 15 years ago has been way how I’ve approached DRC so far and that’s kind how I got into it.

Raj Krishnamurthy (01:37.008)
I love it, love it. And I think we need more of you, Akhila. And why do you think systems thinking and systems engineering as a discipline is important for GRC?

Akhila Chitiprolu (01:48.628)
Great question. Systems thinking for me is there is a purpose, there is an objective of getting an output, right? And what are the inputs going into it and who requires that output is how we should think about anything we do in life, whether that is GRC or security or just even plain old application development and now AI development.

For GRC, it may not come across as very obvious because we think of it in terms of standards and frameworks and controls and things to prove and things to justify. But ultimately there is an input. It is the company that you’re working in, the product, the service that they have, and the output is that who are requiring this input to be secure, to be compliant, to be able to launch in EU or to…

satisfy a healthcare customer or a fintech customer. So the input and output mechanisms are very clear, but how that machine runs internally as a GRC function is the core of applying system thinking.

Raj Krishnamurthy (02:59.88)
I have spoken like a true engineer, Akhila. And I think one of the challenges that I come across is that engineering is a very concrete discipline. Like rightly said, I graduated in instrumentation engineering. Control systems used to be in different things than what we are in compliance right now. But it is all about thinking about those inputs, the process, the outputs, and the reconciliation, and the feedback loop.

But the challenge that we see typically when we talk about compliance or risk framework is that they are too abstract, it feels like. And many times as engineers, we struggle to figure out what to do with it. How have you faced this and what is your perspective on this?

Akhila Chitiprolu (03:47.586)
going into going in deep at the beginning. I like it. I in terms of controls and systems, the

how each individual or each auditor regulator or customer perceives the control is different. And now we’re going into like, yes, input and output from the company, the product, the service, and the output, the customer or the auditor. The control again is differently perceived by each individual who receives the output. And that’s where the depth occurs. Like you might say, Akhila, tell me you do vulnerability management. The GRC tool says,

X company does vulnerability management, but it’s up to the GRC professional to know that I need to apply vulnerability management differently for a software application to a network, to a firewall, to a container, to cloud. The auditor or like a general SOC 2 criteria might say, do X, but it’s not going to define it for the company. The GRC tool will not know that.

That’s where the, if audits are the UI layer for that external facing persona, the controls and the GRC professionals are almost like the, the GRC professionals are the middle layer translating it. And the controls are like the infra. It has to work for the company before it even works for a given audit or that UI. So that’s.

Raj Krishnamurthy (05:17.2)
Love it. Love it. You almost made GRC look like a model view controller. I love it. I love the analogy. And that makes absolute sense. And so what you’re basically saying is that you can have a high level sort of guideline in terms of what needs to be accomplished. That thou shall make sure that your vulnerabilities are remediated within a policy. But what is that vulnerability? How critical is it? And what policy should it be?

Should it be five days? Should it be 10 days? And what is the process it takes you to remediate this very contextual is what you’re saying. That varies from app sec to infrastructure security, on and so forth. But how do you translate as a GRC professional? And you seem to understand this. And you say that GRC is a middleware, which means that you are translating a lot of these requirements. What typical challenges that you run into as you translate these requirements and how you make them concrete?

Akhila Chitiprolu (06:16.536)
The translation, the challenges in the translation are twofold. One is in which industry is the company operating in? You wouldn’t apply the same kind of rigor or controls similar in a healthcare versus a retail company. The rigor on some aspects may differ from in a healthcare versus in a retail. The second one is more a cultural aspect, which is where like the

overall like broader GRC picture comes into play where shifting that momentum, shifting that kind of cycle in cultural acceptance is a challenge. And then the third one is sometimes the audits and frameworks itself might not align in a very direct way. maybe this is a wild example, but maybe software and PCI are saying the opposite things.

or approach it in an opposite way, which then becomes a challenge. It’s like, I might say from a security standpoint, automated code reviews is something that’s possible and that security believes it, the company believes it, but if an audit or a framework has not up-leveled to understand the principles or trust that principles by default, then that’s where the translation, the middleware layer occurs.

Raj Krishnamurthy (07:39.285)
You have worked with companies, you started with T-Mobile, you worked with Expedia, you moved into Stripe, and you are in Sierra, right, which is a customer experience, AI software development company. Very different companies. And so what has been your experience as you went through these companies, and you’ve been managing security compliance teams and risk teams all along, what does that transition look for you?

Akhila Chitiprolu (08:08.482)
Yeah, I have been fortunate to experience large enterprise, traditional approaches to GRC, both because of when I worked there versus like also that how old or big that company was to all the way to like a very highly regulated FinTech space and then more recently into AI. I’ve seen a B2C environment where customer forward or consumer and privacy

forward nature is very inherent in some of like the B2C nature. In FinTech, I’ve seen not just traditional logos of certifications like a SOC 2 PCI ISO, but also speaking with financial partners, banks, regulators in India or Malaysia or Ireland, and then on top of it also do the general.

compliance logo standards that like a baseline company might require. The approach I would say I’ve seen from our traditional, this needs to be exactly this way. This is exactly what PCI says or SOCTU says. And then not maybe necessarily fully understanding what the system or product is trying to do and kind of blindly applying that as inherent to GRC, like where you’re trying to run.

run the train of the audit is coming or like I need to get the report by certain date. So I need to make something happen and that occurs and that’s the hard reality sometimes. And all the way through, let’s think about how to automate it. Let’s think about how to improve productivity efficiency for the teams that we work with so that the machine can run not just during the audit, but more continuously.

and understanding the pain points of, is it evidence automation? Is it because I don’t know the system enough that I’m applying the controller, designing the control in an incorrect way that is not scalable all the way to let’s just use automation like tooling to, or just outsource that kind of a control, especially I’ve seen traditional data center, call center kind of experience in key rooms.

Akhila Chitiprolu (10:31.99)
all the way to now that we have cloud service provider, a lot of our traditional compliance obligations are outsourced to a CSP and now new forms of controls and testing in our AI world of what does agent development lifecycle mean and what does AI lifecycle mean. So it’s been a journey across different industries.

Raj Krishnamurthy (10:51.704)
No, no, makes sense. when you think about, and you talked about outsourcing some of these, and I think we used to run infrastructure, now you have somebody else running the infrastructure. Do you ever see a world where you’re running compliance and somebody else is co-running compliance with you or running risk management with you?

Akhila Chitiprolu (11:16.718)
Co-running compliance, maybe not risk is still very inherent to the company. Using a cloud service provider or using a vendors is possibly where you would outsource some compliance obligations, but you measure it differently. You still need to pick the right vendor, the right service provider. You’re kind of sharing that responsibility, but in a different way. So the control oversight or the compliance oversight that you would have.

on a direct physical piece of infra-physical hardware versus on a cloud service provider that they’re doing compliance in a certain way, boils down to reviewing their report. So it’s differently applied, but it’s outsourced or delegated in a way.

Raj Krishnamurthy (12:04.755)
to go back to the earlier question you said, which is that I think we all get stuck in the audit calendars and audit cycles. And it is imperative for GRC professionals to take a step back and look at it from an automation perspective. And maybe it’s a very obvious, naive question. What is the purpose of GRC?

Akhila Chitiprolu (12:22.53)
The purpose of GRC is to bring together the security and the control mechanisms that apply to what the company, what the employer is trying to service to sell in a way that the end consumer or the end customer can trust, can operate and believe while also satisfying

that particular like employer, that company, the product to run the business in a said country, in a said region, in a said forms of data or processes that they touch. But how do we build that trust across the different persona, the different customers is what GRC is. But the more importantly, it’s how do we do that? How well do we do that? How do we keep up?

with how fast the business may be growing or where it is going next and who are those kind of customers or auditors that we need to be working with. So kind of balancing that equation is what GRC is.

Raj Krishnamurthy (13:34.878)
Beautifully said. So GRC is the keepers of trust of companies and products, right, of the company that you work with. But what, as a leader, have you faced with a challenge in terms of explaining or building a case on why GRC needs to be automated, where the focus is not just on audit, but on assurance as well?

Akhila Chitiprolu (14:03.692)
Yes, automation, yes. And the inertia that it requires or it takes for companies sometimes is similar to like maybe you’re waiting to fix something in your car and you know that you’re running out of oil or something and you just maybe in the last mile I’ll figure it out. And sometimes that’s okay. That’s you’re taking a high risk approach, but in…

Compliance, sometimes it happens where we don’t want to invest in this problem soon enough or spend enough time because it’s running, it’s working. I’m still getting my report. I’m still able to onboard customers. So why fix it? And the initial momentum sometimes comes with learning the pain points or learning how the customers or the stakeholders internally that we are working with.

are feeling or facing the kind of work that they need to be doing. So it’s understanding that and using that inertia to say evidence collection in a certain way is painful. How do we get out of that? So it’s maybe in a very traditional way, we’re taking a sample and you have hundreds and thousands of PRs and maybe they say take 100 PRs if not a thousand PRs and the only way the

say the auditor might say, I take 100 screenshots and maybe someone is manually doing that in a company, but maybe there is automation to say, I can take 100 screenshots for you in a millisecond and a micro, in a nanosecond, but is that automation is, or is that automation kind of slapping on an automation on a very manual process anyway?

for me is like who is opening those hundred thousand screenshots of PRs. If the purpose is your author and reviewer of each PR is different, if the purpose is to verify which ones, know, where the review was completed or someone said yes, you know, the review is complete, maybe just measure those and put it in our spreadsheet, you know, export it into a spreadsheet. It doesn’t feel like automation because you’re exporting a list of PRs.

Raj Krishnamurthy (15:59.956)
Totally.

Akhila Chitiprolu (16:24.322)
but verifying in a simple sheets formula that author and reviewer was different and review happened before release. And then saying 99 % of my PRs did go through this change management control. That’s also automation. It may not be a fancy tool. It’s still more efficient in a way. Yeah, I mean, that’s like one example, guess.

Raj Krishnamurthy (16:51.795)
No, I think that’s a great point. what I’m hearing you say is that, look at this common sensically. Joe’s just don’t try rushing to automation. To your point, automating screen shots, is that the right level of automation, is the fundamental question that you’re asking. While we have APIs to connect to, there are much more sophisticated ways in which you can try and measure the intent of what you’re trying to do, or the risk that you’re trying to avoid. Makes absolute sense. One of the challenges that I’ve always heard from engineers, and I’m, as an engineer myself,

I face the wrath of this on the other side is that when we deal with security teams, when we deal with compliance teams, the noise that gets generated, and maybe these are well-intentioned controls producing data, but when I’m working on till 1 a.m. to ship the next release, you come back to me and throw a bunch of things, right, that I have to go fix or I have to go respond, I have to go take a screenshot, whatever that is, right? It is so boring and so uncool.

How do you deal with this engineering toil in your experience?

Akhila Chitiprolu (17:55.47)
It comes in two fold right where.

It’s also part of inherently part of that side engineering team or engineering or engineer to also work with the company to help run the business, to help build that trust for customers, to, SOC 2 is not because GRC wants it or solely in a company, right? It’s because the company needs to run as a business because we need to get the next customer. Yes, selflessly, we need to be secure and we need to still.

ensure that we’re doing things in a trustworthy manner. But A, think automation is important, but also fundamentally for product teams, infra teams, security engineers to accept that we are doing this collectively for a company as a shared objective, as a shared responsibility. But B, if some of that is painful or

not something they feel as productive in a way, then work with that GRC person or GRC professional to find better ways. Maybe the GRC professional is asking for something, say I’m saying, show me how you apply access management to your system. Maybe it’s not the right engineer or maybe that…

that engineer doesn’t know or maybe he’s just making up a document because he thinks that’s the only way out of it, right? So it’s also, it’s a two-way street of the GRC professional going to the engineering and saying, this is my objective. This is what the outcome is. How can we best do this? Maybe we do it in a manual way now or just get over the line for now.

Akhila Chitiprolu (19:50.006)
right after this audit, can we work on it together? it may, you the future you is thankful that you’ve automated this or you’ve built a repeatable process for something. But that kind of conversation should kick off in a, with that engineer, with that, with that team. And that’s how we will get out of the engineer feeling, I need to make a release and at 1 a.m. versus submitting like some evidence for an

Raj Krishnamurthy (20:17.906)
I love the word future you. I love the word future you. Totally makes sense. Now, when we started, one of the points that he made was that you were talking about, for example, the SAS tooling and some of the scanning that can be done. And another point you were trying to make is that the GRC team needs to get on board with some of the technology and the changes that are happening within the enterprise and the adoption that is happening in the enterprise. How technical?

does the GRC team.

Akhila Chitiprolu (20:53.966)
The easy or the cop-out answer is it just depends on the company that you’re working with, the kind of engineers that you have and the culture that you have. you think of, need every team in a company, whether that’s GRC or a product team or even a sales or a GTM team wants to be somewhat self-sustainable, wants to be able to operate.

without the only way to function is ask of things of other teams. You want to still be able to run the machine, so to speak, run that process somewhat self sustainably. You may use tools or you may do something manually, even in a HR or a sales or a GTM world. You can say, I don’t need an HR tool. I’m going to onboard every new customer.

or every new employee individually in a spreadsheet, or you will get a tool. Does that mean like an HR is also an engineer? It’s adoption of tooling and adoption of automation as a principle should apply to any team in this era of tech and AI. But in a GRC world where it becomes more obvious is

When either we aren’t able to build that culture of partnership and two-way street yet, a GRC engineer can help create that momentum more quickly. But the idea is not for the GRC or the GRC engineer to be working in isolation. There is no individual security engineer or a GRC engineer that can operate on their own by writing a piece of code and pulling evidence. There needs to be context.

And the context is available only with that team that’s working on a particular product on a particular feature. So even if a security engineer says, a product security engineer says, we need to think about threat model for this feature, they cannot just see the code and run the threat model. They are talking to the product team, right? So is it manual that this product security engineer is speaking with?

Akhila Chitiprolu (23:11.842)
the said product engineer, that’s not manual. And where vendors are marketing saying, get your sock too, without ever talking to an engineer, think that’s not true. You still need to understand it. Maybe you talk to the product engineer or to the product security engineer or read a doc, but you’re still doing something in that format. The GRC engineer comes from, yes, the security engineer is running,

cloud security, understanding vulnerabilities in your cloud environment. But maybe the GRC engineer objective is, I want to be able to satisfy that from a PCI lens or a SOCTO lens. the, say the dashboard or the observability that they need to have has a different lens. Maybe the GRC engineer will say 10 systems across five different.

you know, regions for a company have vulnerabilities posture this way. But I want to tie to, you know, requirement 11.3 in PCI in a certain way, you know, a SOC 2 criteria in a different way that mashing together of like that end framework that, that the audit has to what this company is doing is where the GRC engineering function can come in. It’s not to say that any other engineer could do it, but

Maybe it just helps mindset wise and role wise that that’s their responsibility. So that’s where I would say GRC engineer comes in, but never to be working in isolation of GRC now has an engineer, so they don’t need to talk to anybody else in a company. You know, feels like working backwards of after having built all these bridges to say GRCs should be on incorporated security should be incorporated into your tech stack. And now saying.

No, we should not talk. I mean, that’s, think, working backwards.

Raj Krishnamurthy (25:06.442)
I actually love because you consistently keep insisting GRC engineering as a discipline, GRC engineer, and that is phenomenally fantastic. I know there is a movement that is happening. I want to shout out to some of those fantastic folks, right? I, Fondi, Charles Nauto, bunch of others who have actually started this just in Pagano. And I know you are an integral part of the GRC engineering sort of community as well. But one thing that I have noticed, think what GRC is slightly unique and interesting and different.

in the sense that you on one hand, you need to understand the underlying infrastructure, AWS, Azure, so on and so forth. The other level, you have to understand the security practices, right? The third, have to understand the business context or the product context that applies, that is applicable for the security practices. Then you have to understand the regulations and the standards and the requirements, right? VCID, SIS, or FFIEC, or whatever industry you are in.

and then you have to figure a way to mash all of this together. It seems like a very very complex problem to solve. Right? So you have to be multifaceted so the balance seems to be between depth and breadth. How deep do you go and how broad do you go? How do you think about these things as a GRC practitioner?

Akhila Chitiprolu (26:24.802)
The balance is important. like I said, depending on where the company is at in the business, where, who the customers are that we are serving, if it’s B2C and an end consumer, it’s differently applied. Like I said, you’re more maybe, yes, inherently secure, but more privacy focused for that consumer.

The depth also comes or the rigor also comes in defined because of the kind of data you’re processing. Maybe it’s health information or financial information versus back in system information. So it just depends on what that industry is, what kind of vendor you are for your customers, how do you fit in into the larger ecosystem for that customer as a vendor? So the rigor, the depth.

is defined based on that business. And it’s also iterative for an early company to expect set mature processes like an enterprise is different than when you’re going through your 50th audit of a company where the expectations are higher, or maybe it’s just more complex because you’re a much larger company. The depth also comes from, or the complexity comes from, you just have one product line or 10, do you?

have acquisitions and do you, does that mean you have to now manage multiple tech stacks and operating in different kind of regions. So that’s where the depth also comes in. But the balance aspect is informed by both the speed and the, of the velocity of the product and the customer growth that the company might have.

Raj Krishnamurthy (28:11.41)
Got it. I think I want to go back to what you said earlier about the GRC. When you started with the systems engineering and GRC as a control discipline, inputs, process, outputs, feedback, right? Plan, do, check, act. If you can use the denim cycle. the question then becomes that you take inputs, you process, and you create some outputs. And you also talked about helping the future you of the engineer, which means that to some extent,

you’re helping them reduce the noise, which to me means that you’re actively taking part in some sort of remediation, right, or correction. How do you think about this as a GRC engineer or as GRC practitioner, right? Because you don’t have the depth as much as the engineer does in the product teams or the application security teams. So what role does the GRC team have to play with remediation and reducing the noise?

Akhila Chitiprolu (29:06.56)
The first aspect I would say is, yes, understand the system enough when they say vulnerabilities don’t apply in a certain way because the tech stack is different. Understand what that means. There are no hosts and they are containers or there’s no physical servers to think about, or there’s no, the traditional firewalls to think about. But now we have like security groups per se. So understand the tech stack, understand that functionality and how it is applied.

And then measure that through where the objective of that audit of that regulation is coming from and be open to hearing from the engineer of why does not certain things apply differently or don’t apply. And then based on that, make a judgment call of what will satisfy the auditor. It’s two part. The engineer may understand it and you may not understand it. So that’s on you to understand.

but it’s also on you to then be able to explain to the auditor. So that’s where the auditor fit comes into play. all auditors can approach the same tech stack in the same way. So where there is flexibility, choose an auditor, try to pick an auditor that works for you, works for the company. Maybe they need to be, the auditor themselves need to be tech forward, or maybe you need to educate that auditor as part of your onboarding of that process.

Raj Krishnamurthy (30:12.977)
Where did it work?

Akhila Chitiprolu (30:35.328)
Right. And keep up with like those changes and inform them ahead of time of thinking of this differently. And, you know, what, what are your thoughts or, you know, learn from the industry, I guess. So it’s yes on you, but then also it’s just inevitable that even if the auditor gets it, maybe there is some customer or some segment of customers and their audit teams that don’t necessarily understand why you’ve made this kind of decision. So it might come to you.

differently, even though you’ve accepted it. So it’s not that security engineer or a product engineer or an infra engineer’s job to then maybe justify it to those end customers. It becomes your responsibility. So how much do you know that you can justify that? And sometimes it’s inevitable and we give in to some kind of requirements because there’s no other way. It’s not great, but that’s the part where more of like the broader industry advancement.

should have come.

Raj Krishnamurthy (31:34.482)
Okay, now auditors, and no offense to them, right, the auditing as an industry is based on number of hours spent, right? So inherently there is a conflict of incentives in terms of automation, right, and trying to sort of automate this as much, because you’re basically saying that you have to automate yourself out of a job, right, if you’re an auditor, as much as you can. How do you sort of feed,

How do you, when you choose your auditor, how do you balance these sort of possible conflicts that the auditor faces? What questions do you ask them? How do you make sure that they are the right auditor? How do you go through an evaluation process of the auditor, if you can share?

Akhila Chitiprolu (32:20.59)
Just maybe at a high level, would say understanding the kind of tech stacks that they worked in or their principle or approach to a given criteria or a requirement or a control. Testing their view of or principles from like an audit standpoint is what I would verify and maybe generally fit.

in terms of personality, that they can be put in front of other engineers or other teams in a company. It can also be amount of experience and depth that they can go in. It’s very high level of what I would try and work with an auditor. And sometimes it’s not directly possible, like I said, but that goes a long way into making

the audit goes smoother, not from the sense of the auditors is going to pass me, but from the sense of they’re going to test and put that rigor in the right places in the right way, in a tech forward way.

Raj Krishnamurthy (33:30.706)
Got it, got it. And if for somebody who’s listening to this and who’s trying to sort of get onto this bandwagon of GRC engineering, right, and the idea that GRC is an engineering discipline, we need to automate more. I don’t think nobody will disagree with that. But how would they go about trying to build that business case with their leadership team to say, I need to go build this capability within the GRC organization? Any advice in terms of how people should

Akhila Chitiprolu (33:46.209)
Mm-hmm.

Raj Krishnamurthy (34:00.558)
about this.

Akhila Chitiprolu (34:04.236)
I would say as far as like GRC teams go, do an, ironically, do an audit of who you’ve been meeting with, what is the purpose of those meetings? How has the audit life cycle been? Where have the pain points been? Has it been in the engineers not understanding where you’re coming from? Has it been during evidence collection or is it because we haven’t maybe designed the controls in the right way to begin with?

So audit, look back and do an audit of like what’s been happening. And maybe you already know like where those challenging points are or what those set challenging conversations may have been, or maybe where you know that the evidence is not high quality or the control needs a lot more maturity. Identify those points and then build like what’s the golden path I guess of

what would this have been in an ideal world? So maybe like the evidence collection of like taking screenshots was the pain or maybe this particular team is newer or it’s come through an acquisition and they’ve not been subject to the same rigor for a certain reason. So maybe it’s the people part. it’s not, it is automation, but it is also how you apply the efficiency may be different. It could be culturally and the people and the learning and the awareness aspects.

It could be, there is like an engineering problem of maybe two systems don’t talk and the output that GRC is expecting at that they need to talk. And you just have like broken information audit over audit cycle over cycle. But if you don’t do that audit ourselves and find those gaps, it’s, it’ll be harder. So maybe the, the way to say the GRC engineering function can dig into a lot more of such problems.

and then say, yes, maybe system A and system B should talk with each other or this new API connection is needed or that the output generated in a certain way is helpful. And then say, maybe you don’t even start with the GRC engineer in the first place. Maybe you work with your engineering best friend who can build something and then you have enough momentum going on of like, I have these pilots in place that every engineer has.

Akhila Chitiprolu (36:30.168)
built some small piece of automation that made their life easy. And maybe that’s, we can centralize that part into a function in itself is also one way to.

Raj Krishnamurthy (36:40.4)
No, love it, love it. So, crawl, walk, run, you’re basically saying the idea is that try to automate and find a place where you can start easy and then figure a way on how we can consolidate for efficiency, right? And your point is not just about systems, you have to also look at cultures and people and some of those other variables that come in as well. think great, points, great points, Akhila. What in your experience, Akhila, especially with IT and cybersecurity controls,

If you were to put into buckets of the controls, number of controls that are implementable, the percentage of controls that you can truly automate where no user has to touch, the percentage of controls where you collect data or configuration and you have some human in the loop, and then percentage of the controls that are just no system interaction, just plain human interaction. If I give you those buckets, what do you think the spread is going to look like?

in your experience.

Akhila Chitiprolu (37:38.894)
putting a lot of equations of like, have great, I’ve been fortunate to work, I would say, where manual GRC was not necessarily inherently a problem. But even if it was, it was coming from a place of systems weren’t talking to each other. So it was still on on some pieces of engineering aspects. So considering that, and then also considering the aspect of

Audits and regulations inherently want you to say, show me what you do, show me how you do it, and then show me live that you’re actually doing it and you know what you’re saying, right? So there’s like three aspects of yes, know, documentation, a live walkthrough, and then also some take-home evidence for the auditor, right? So some aspects cannot be automated, like you rightly said. For most, in maybe like my experience that I have seen, I would say,

It’s mostly 50 % of it cannot be automated for various reasons. Business constraints, technical constraints, just people constraints. But I would say in an ideal world, at least 70 to 80 % can be automated by way of still making that last mile happen. But sometimes that last mile automation is maybe not worth it for a company because there’s so much change expected in a certain place.

But yes, I would say 7030 is the automated.

Raj Krishnamurthy (39:10.929)
70 % can be automated. And by automated, you also mean there may be human in the loop, but you’re doing a lot of the toil of evidence collection and data gathering without the human having to do. Is that a fair thing to say? That’s beautiful. Yeah.

Akhila Chitiprolu (39:20.003)
Mm-hmm.

Akhila Chitiprolu (39:25.122)
Yes. Yeah. Like you’re automating log reviews and you have a simple, someone’s actually reviewing the output, right? So you’re not manually reviewing every log line that you know that.

Raj Krishnamurthy (39:33.916)
Totally. Or at least flag the exceptions and manage by exceptions. That makes sense. I think one of the fundamental challenges that I typically come across is that people have this analysis paralysis in GRC because most people want to do the right thing. The challenge is that you look at the forest and it is daunting and it is overwhelming. Right? And sometimes you don’t know where to start. Right?

Akhila Chitiprolu (39:37.4)
Yeah.

Raj Krishnamurthy (40:01.057)
And this is one of the biggest problems with GRC engineering, because the answer seems to be status quo versus doing something, and the doing something is very ambiguous at first. Have you faced this situation before, and how have you overcome

Akhila Chitiprolu (40:17.69)
It can be daunting, especially if a large company where they are subject to anywhere between 50 to 200 audits and regulations in a given year. It’s daunting to say, should I be automating my, my sub two or my FedRAMP or PCI or in a way that I talk with the regulator? Like where do I start? Do I start from a audit perspective that needs automation? Do I fundamentally automate how my controls operate?

And if I do, how does it still meet the audit intent? Because I can’t be working in separate, separate the two equations. The way I would think it will work without seemingly daunting is pick one or two audits that are most important for your company, for your employer. Maybe it’s foundationally SOC 2.

But also if it’s not the most painful and it’s most baseline and that folks have figured out how to stand that up very quickly today, maybe it’s something else unique for that company. And start with identifying, I would say typically the configuration management, change management, like infra and like security aspects where security engineers still have fundamentally the same objective of a JRC team.

So maybe even starting there and selecting that family of controls for that audit can be like one place to start and then iterate on it. But wanting to say 100 % of my FedRAMP or PCI audit is automated as an objective feels like a hard battle to win. But when you say, want to automate infrastructure security or cloud security and apply that.

automation in a way for two audits in the next quarter and then five more in the next, you know, how you build that is as a program is what’s needed.

Raj Krishnamurthy (42:22.993)
crawl, walk, run, and keep iterating, right? And maybe start with a few security domains or control specific controls that give you the greatest grief and then go from there, right? What do you see as the efficiencies of the common controls framework? There are a bunch of them out there. How effective in your opinion they are in satisfying multiple audits?

Akhila Chitiprolu (42:50.05)
They can be effective, but if you would think that all the audits and viewpoints and scope is very much the same, I might want my PCI audit to be scoped very minimally to say sensitive parts and cardholder data touching parts. it can be de-scoped in a way that every product doesn’t come into scope. Then saying,

I will still do the common control and still apply my infrastructure security or vulnerability control and give my auditor everything that A is not useful, B like adds more, makes the audit slower or more expensive or like less valuable in a way. And in the same way, if we say I will treat all my systems equally or then we kind of not.

using the company resources effectively, would say. So common controls with a grain of salt is maybe what works and how I’m seeing it. And if you have complex product lines and tech stacks, then common controls, the value of it may show up differently.

Raj Krishnamurthy (44:07.874)
ok and differently as an.

Akhila Chitiprolu (44:10.466)
differently as in it might not be common across a different, right? So less valuable.

Raj Krishnamurthy (44:15.352)
Okay, it’s no longer common. Okay. I think traditionally, GRC, pardon me for saying this, and I’m part of the community as well, has been a very boring space, right? And 25 years, and primarily the tools in the last 20 some years have been sold as a replacement for Excel spreadsheets. But yet, we continue to see Excel spreadsheets galore in every place. What do you see as the maturity of the GRC tooling?

Akhila Chitiprolu (44:29.262)
Mm-hmm.

Akhila Chitiprolu (44:47.138)
The maturity of GRC tooling is GRC professionals subscribing a lot more to their existing security engineering tools. They are ultimately asking for the same thing. GRC does not require its own vulnerability management tool, its own asset management tool. It does not require its own cloud security tool. You’re already running vulnerability management with a certain vendor, with a vulnerability scanner.

The compilation of all of that in one place to make it easy for GRC professional is fine. But if you’re not already using those tools or learning or knowing about like what to integrate with, then that’s not necessarily, it’s like tool duplication or creating inefficiencies in a company. So I don’t see GRC tooling as like a thing that will happen of like there’s more types of GRC engineering tools.

Raj Krishnamurthy (45:37.423)
the

Akhila Chitiprolu (45:46.134)
is probably just the bringing together and so that there wouldn’t be more ways I would think.

Raj Krishnamurthy (45:51.889)
So sort of an orchestration, right, of different security tools. that’s a brilliant point. I think you made that point very clear as you were talking about the need for thinking about GRC as a systems engineering discipline as well, right? It is about bringing data from all these different toolings and applications and infrastructure that exist today to satisfy the specific purpose of GRC, right? However, what do you also think of the current state of GRC platforms?

Because most of them don’t seem to go into the depth of evidence collection or controls testing. Do you see that as a gap or is this something that is needed? How do you feel about and how do you think it is maturing as a community? How are we maturing in this?

Akhila Chitiprolu (46:38.826)
Right, there is one.

Bringing together everything into one tool can be any team’s dream of, want to see how all the systems or networks or infra is working together in one fancy, good looking dashboard. But ultimately, if I have three or five, can I still work with it? Maybe yes, right? So while GRC platforms can…

bring the most of it together. It’s okay to have three or four more dashboards in different systems to see how your controls are operating. And maybe the translation or bringing that piece together doesn’t have the same ROI. That does not mean you don’t have automation and measuring through how much this one unique vendor tool that should work for across.

multiple companies and trying to force fit that, I don’t see value necessarily in trying to go that last mile. If it works for the most part and for your foundational elements, great. But if it doesn’t have an inherent connectivity, API connectivity into that tool, then that’s fine. And that’s where the GRC engineer role comes in to continue to stitch together a little bit more.

Raj Krishnamurthy (48:09.296)
I’m with you, I’m with you. And I think no conversation is complete without talking about generative AI and large language models. So how do you see the role of GEN-AI in GRC and how do you see GRC dealing with generative AI?

Akhila Chitiprolu (48:29.902)
AI, like when cloud happened in the 2000s, it was maybe something the security world took some more time to accept and understand, but now we all have grown to adapt and love shared responsibility from our cloud service providers. In the same way, using AI is inevitable and it’s already here. And if you think of

How GRC should view AI? Definitely with a different lens. How we think of traditional software development lifecycle will be different from how we do AI development. How we write code, what kind of AI vendors we use, or even from like an inherent building of AI agents and testing their outputs. Agents can think, reason, take action, but they might all, the output is not always the same, so we’ll have to.

think of new ways of testing and we call it simulations. So testing it is going to be different. So how do you apply that kind of testing to an ISO standard or to a SOC 2 will be something GRC professionals will have to learn and apply and reapply. But using, not forgetting first principles, but applying it through to AI is what.

Yeah, it is what GRC professionals will need to do.

Raj Krishnamurthy (50:02.49)
We are approaching the end of the segment, Akhila, and maybe this can be my last question to you. I think one of the things that we have to do collectively better as a community is having more women in security and GRC, particularly in leadership roles.

What can we do? And maybe it’s not just women. Maybe I’m not trying to sort of bucket. But I think particularly women have a certain set of challenges given their representation in this community. What can we do better to be more inclusive, to bring more women into security, particularly into GRC?

Akhila Chitiprolu (50:40.832)
Women, I think inherently, I don’t be afraid to take up like new forms of working new ways of industries and applying similar to women in engineering initiatives. There’s a lot more women in security and women in GRC initiatives as well. So first I would say, don’t be afraid to take on something new. I’ve seen GRC folks come from different…

backgrounds and different industries. They’ve not traditionally had an engineering background or a science background, right? I’ve seen folks from arts and psychology and some of the early folks I worked with came from philosophy also in terms of backgrounds. GRC is a place where there is people context to have and process and technology and there’s culturally like being able to build relationships internally and externally.

and understanding of tech. So it’s a unique space to be. I would actually think it’s something for anybody to be able to take on and learn along the way. But also particularly if women are inherently maybe not exploring GRC or tech from a place of this is not for me, I would say the opposite that.

This is an area where we should continue to have more women.

Raj Krishnamurthy (52:14.2)
And I’ve seen women in cybersecurity voices, and there are a bunch of such organizations, is there anything particular with GRC, anything that folks should know about that you know of that you’re a part of? Or is it the same group?

Akhila Chitiprolu (52:30.542)
Why is this is what I was going to say as well, but even otherwise just the GRC engineering podcasts or communities that you mentioned your podcast here, even listening and learning through those spaces and reaching out to individuals or folks that they look up to or liked what they said, I think is a way to start inculcating their experience and building those relationships with GRC folks.

Raj Krishnamurthy (52:56.27)
And especially for the young women that are graduating out of college that want to be the next Akhila, can they reach out to you? And if so, how can they reach out to you?

Akhila Chitiprolu (53:08.278)
Yes, they can reach out to me. I’m on LinkedIn. Akhila. T.T. Prolu. That’s how you can find me.

Raj Krishnamurthy (53:14.008)
Okay, got it. Akhila, this has been a fascinating conversation. Thoroughly enjoyed this conversation. Thanks for coming on the show. Sincerely appreciate it.

Akhila Chitiprolu (53:20.184)
Yeah. Thank you. Thanks, Raj.