Shift Left: Turning Checkbox GRC into Embedded Risk Management

Kaila: Hello, everyone, and welcome. I am really excited for today's session. This is a topic that comes up too often across conversations with GRC and security leaders: compliance is still happening way too late in the process. It becomes a last-mile, high-effort exercise where teams are scrambling to pull evidence, engineers get pulled away from actual product work, and by the time gaps are identified, they are already expensive to fix.

So today we are here to dive into what it actually looks like to shift GRC left. How do you move from a compliance checkbox, audit-driven model to something that is continuous, embedded, and actually improves risk posture in real time?

Our guest today is a GRC product manager at Adobe. She has led product strategy for enterprise GRC platforms, driving initiatives across audit automation, access reviews, and developer enablement — all focused on reducing manual overhead and embedding compliance directly into how teams work.

I am really excited for her to walk us through this important topic. With that, I am going to hand it over to Akshita Gangrade to introduce herself and lead us through today's workshop.

Akshita Gangrade: Thank you, Kaila. Hi, everyone. I am Akshita Gangrade. I work as a GRC product manager at Adobe and have been doing this for around five years now. I work at the intersection of risk, compliance, engineering, and product, and I focus on streamlining how these pieces work together efficiently.

Over the last five years, I have worked closely with all of these teams and have seen how compliance actually plays out inside large organizations. I am really excited to be here. It is also Women's History Month, so thank you, Kaila, for hosting these sessions.

I will be talking about GRC-related automation and engineering, and also touching on the role of AI — which I am not sure if you have heard about. Let us get started. I have a few slides prepared. I will start with what compliance looks like today, then dive deep into how we can automate it and how we can use AI.

So, GRC should ideally happen throughout the entire development process. It is not something that should happen after security systems are built. GRC influences what security controls need to be built, how strict those controls need to be, and it plays a critical role in cybersecurity overall.

But if you look at how most organizations actually work today, everything depends on the audit cycle. GRC shows up very late. An audit cycle begins and suddenly everything becomes urgent. Evidence requests start flowing from audit teams to product teams, engineers get pulled into audit-driven work, nobody knows who owns what, and engineers are asked to provide evidence — logs or other forms of control testing — from months or even a year in the past. That means going back through old logs, which is extremely time-consuming and requires a series of follow-up questions.

A lot of time gets spent reconstructing decisions that were made long ago. It is reactive when it needs to be proactive. This is what I call compliance as a checkbox exercise.

Our current model is one where compliance is something we prove toward the end rather than something we build into the system. It is a point-in-time process. Evidence is collected manually, everything is aligned to a single audit cycle that happens at the end of the year, and success is defined as passing the audit.

What is missing in this model is continuous monitoring of gaps, real-time visibility into compliance posture, and real-time risk awareness. Auditors are doing their best, but they have an enormous amount of evidence to review, and it is the most painful and time-consuming part of the process. From an auditor's perspective, they have to slow down and check every detail: is this the right system, does the screenshot contain the right timestamp, was it taken during the audit period, was the person who took the screenshot even authorized to do so? And those are just the common problems. Beyond that, auditors may be reviewing 100 gigabytes of data and thousands of screenshots. Just passing an audit does not mean you are managing risk effectively. It is not just reviewing screenshots — it is performing forensic analysis of data.

So let me call out a couple of specific problems with the current model.

First, there is engineering inefficiency. Engineers are repeatedly asked to pull screenshots and evidence from their systems for past events, and these compliance activities are not integrated into their workflows at all.

Second, there is late risk discovery. Control gaps are identified after systems are deployed, which causes confusion, back-and-forth, and significant disruption as teams try to go back and fix things after the fact.

Third, there is limited visibility. When compliance testing is performed and evidence is provided, it is a point-in-time snapshot. You are trying to understand the full picture from a single moment, and that does not tell you everything. We are optimizing for audit outcomes rather than for risk detection and mitigation.

This is not a new problem. Whenever there is new technology or a major industry shift, many fields within tech face the same challenge. Take security as an example. There was a time when most companies were doing all security validation toward the end of the development process, and vulnerabilities were discovered late — resulting in a lot of back-and-forth and a process that was not scalable. Security evolved. Teams started doing threat modelling early, doing penetration testing early, so that risks could be mitigated before they became expensive. That shift reduced late-stage surprises and improved overall system resilience. Security adopted the principle of failing early and not in production, moving from reactive to preventive.

That is what shifting left means. To use a simple analogy: think of it like packing for a trip. If you pack the night before, everything is calm — you know what is ahead of you. If you start packing ten minutes before you have to leave for the airport, it is chaos. You are hunting for your passport, figuring out what clothes to bring, not sure what the weather will be. That is what we want to avoid. We want to plan ahead, anticipate what risks might arise, and have a plan ready to mitigate them.

For GRC, that means compliance needs to be part of the system, not an afterthought. It cannot be a yearly activity or a one-time event. It has to become embedded into the systems themselves. And when it is, it also helps with risk management — the process will have real visibility into how systems are being operated, so you can determine whether policies are still accurate, whether versioning needs to be updated, and so on.

So what does embedding compliance into the software development lifecycle actually look like? Every company will need to do some homework here. For whatever compliance requirements and control testing apply to your organization, you need to figure out which controls can be tested at earlier stages of the development lifecycle. For example, threat modelling can be done during the design phase. Other controls can be addressed during the build and deploy phase.

Let me take source code control testing as a concrete example. Whenever there is a code change, it can trigger all of the relevant control testing automatically. That way, you do not have to rely on engineers to provide screenshots from the past. You have direct access to the system. If branch protection is not enabled, you can trigger a warning before anyone proceeds — asking engineers to fix their processes before moving forward. You are catching issues at the point of creation rather than discovering them months later.

Similarly, when you are deploying, you can embed control checks directly into CI/CD pipelines. In many compliance scenarios, you are required to provide logs — so instead of asking product teams for them later, you design systems to generate those logs automatically as a byproduct of normal work. The signals are visible in real time, without causing any disruption to engineering teams who already have tight timelines.

To summarize: you move away from reactive audits to continuous compliance. In the current model, audit governs how evidence is collected — a company spends three months heavily focused on audits, following mostly the same script every year, reaching out to engineers for evidence, reviewing enormous amounts of data. A survey I came across indicated that auditors spend 50 to 60 percent of their time just reviewing evidence — checking whether screenshots contain valid timestamps, whether the information is accurate for the audit period. Then comes gap identification, then outreach to product teams for remediation. It is a long process involving a lot of back-and-forth, and much of it can be automated.

When I talk about automation, I do not mean flashy dashboards. The goal is to improve the process for your team and your organization. And it does not mean eliminating humans. The purpose is to streamline so that people can make better judgments — spending their time not on evidence analysis but on remediation, on evaluating whether a control is actually accurate, on determining what improvements need to be made. Automation benefits product teams, security teams, audit teams, and risk teams alike.

There are three categories of automation worth covering here.

The first is rule-based automation — the simplest and easiest to implement. This is deterministic logic: if X is true, it passes; otherwise, it fails. A good example is encryption: is it turned on or not? Yes or no. If yes, you are good. If no, that is a gap to remediate. Rule-based automation works really well when you have clear logic already defined. It reduces human toil on repeatable tasks and keeps things fast and consistent. You can also use it to automate outreach — sending reminders, triggering follow-ups — so think about where you are doing the same manual steps over and over and where those could be automated.

The second is AI-based automation. Not everything in GRC is deterministic — in fact, most of it is not. You have to use judgment. The evidence you receive is unstructured: screenshots, logs, configuration files, some of which can be five gigabytes or more. Imagine going through that line by line to evaluate gaps. That is an enormous amount of time that could be spent on actual risk analysis, control improvement, and — especially now — addressing the added complexity of AI risk on top of human risk.

AI can help with unstructured data. You can ask it to read a screenshot and summarize what it shows, or to parse a long configuration file. It does not replace judgment, but it handles cognitive load — for auditors, for risk teams, for GRC teams — so that human attention can go toward what actually requires it.

The third category is agentic workflow automation, which is the most advanced and the most interesting space people are exploring right now. Unlike simpler automation that handles one task, agentic AI can do reasoning across multiple steps and then take action. Instead of a human orchestrating manual workflows, the system can handle the coordination — pulling information from different sources, deciding what needs to happen next, mapping new controls to industry compliance frameworks. A lot of teams are still doing this work very manually, and moving toward automated workflows frees up people to focus on judgment and strategy.

To put it plainly: instead of auditors asking whether MFA is enabled in a screenshot, they will start asking whether a control meaningfully reduces risk in the environment — and what happens if that control fails. Auditors and risk triage teams will work together using judgment to prioritize risk going forward. When you start thinking this way, GRC stops being paperwork and starts being more like engineering.

That is what the future of GRC should look like. Developers are using AI for development, which means the volume and complexity of what compliance teams need to assess is growing rapidly. Manual approaches are not scalable. You have to use the right tools to achieve the right goal — and success should not be defined as passing the audit. Success is what risks you were able to surface, how you responded, and how you mitigated them. Audit becomes a validation layer, not the finish line.

Kaila: Thank you so much, Akshita Gangrade. This was a really great session, especially as we close out Women's History Month.

I think one of the biggest takeaways here is that when compliance is happening late, you are not actually managing risk — you are just discovering it after the fact. What this means for teams is that they need to start taking proactive steps to embed GRC into how they build, so that risk can be surfaced much earlier, manual overhead is reduced, and there is a much clearer view of what is actually happening across the environment. The piece you brought up around automation and AI is really important too — not just making processes faster, but helping teams focus on what matters instead of spending their time collecting and validating evidence.

We appreciate you walking us through both the conceptual shift and what it looks like in practice. Do you have any final closing words before we wrap up?

Akshita Gangrade: One question I hear often — or something I have observed when talking to people in the GRC space — is: where do we start? My advice is to start small. Pick one high-impact manual task, automate it, and see how it goes. A good candidate is access management, where compliance teams often ask users to provide screenshots of identity and access management systems. That process can be integrated and automated directly — screenshots cannot capture the full picture anyway, and automating the validation is much more reliable.

You do not need to boil the ocean to see the value. Even working on a single control, you will see quickly how much time you are saving.

One more thing I want to leave you with: before jumping into automation, first work on unifying your process. You need to know what a control is, why you are doing it, how you want to implement it, and where you can get the data from. Answer those foundational questions first, and your automation efforts will be much more effective.

Kaila: I love that. Thank you so much again. And for everyone who joined us today, thank you for being here. I encourage you to connect with Akshita Gangrade on LinkedIn and reach out if any follow-up questions come up. The replay will be available shortly after we end this session, and we are always hosting new sessions, so keep an eye out for future ones. Thank you again, everyone.

Akshita Gangrade: Thank you so much. Feel free to reach out to me directly if you have any questions.

Kaila: Amazing. All right, bye everyone.

‍