A smaller team doesn’t mean harder work: How lean GRC teams can work smarter

A growing compliance program does not always come with a growing security or GRC team.

One person may be responsible for controls, evidence, audits, customer questionnaires, access reviews, and increasingly, AI governance. That's not just a workload problem, but it's key-person risk: when one person holds all the context, reminders, and evidence trail, the program has a single point of failure as much as a capacity problem. If that person is out for two weeks, does the audit trail still hold up?

So how do lean teams keep up without making compliance a second full-time job for everyone?

That was the question at the heart of Scrut’s recent webinar, “Running a Lean GRC Program: What to Own, Automate, and Hand Off.” Scrut’s CEO and Co-Founder, Aayush Ghosh Choudhury, was joined by Senthil Kumar Iyyappan (SKI), CISO & SVP of IT at Ocrolus, and Sanket Naik, Founder & CEO of Palosade, to discuss what lean teams should keep close, what they should automate, and where they should bring in help.

The discussion offered a practical answer: lean GRC is less about doing more work and more about deciding where human attention actually matters.

First, stop making security responsible for every decision

A common problem in lean programs is that the person running GRC becomes the default owner for everything.

But there is an important difference between owning the compliance program and owning every risk decision.

Security can identify risks, explain their impact, recommend controls, and monitor whether those controls are working. Leadership still needs to decide what risks the business is willing to accept, based on priorities, budget, and customer commitments.

That distinction can take a huge amount of pressure off a lean GRC team. Instead of becoming the team that has to make every call, security becomes the team that gives the business enough visibility to make informed decisions.

And that is a much more scalable role.

Then, automate the work that keeps pulling people away

The panel was not advocating for automation simply because a task can be automated.

Sanket made an important point: teams need to understand a process before they automate it. Otherwise, they risk making a bad or unclear process run faster.

Once the process is understood, the best candidates for automation are often the least interesting parts of the job: reminders, evidence collection, recurring checks, follow-ups, spreadsheets, and repetitive questionnaire work.

SKI put it simply:

The payoff is not just fewer manual tasks. It gives a small team more time for the work that actually requires expertise: understanding risk, reducing exposure, strengthening governance, and working with the business.

What about the work you can’t automate? Know when to hand it off.

Not every GRC task belongs with the security team.

Sometimes another team has the right context. Sometimes a specialist has the expertise. And sometimes external support is the most practical option.

But the panel drew an important line: handing off execution does not mean handing off accountability.

The webinar’s “take it or leave it” exercise brought this to life through situations such as missing audit evidence, excessive access, and security issues discovered just before a product launch.

The lesson was consistent: know who has the authority to make the decision, make sure the right person is involved, and keep ownership of the outcome clear.

Sanket offered a useful rule for working with other teams:

That means GRC should not simply send another team a request and wait. It should explain what needs to happen, why it matters, and what the specific ask is.

The result is less friction and stronger ownership across the organization.

And when AI enters the picture, visibility comes first

AI adds another layer to the challenge.

Employees are already experimenting with AI tools across engineering, sales, operations, and other functions. For lean security teams, the challenge is figuring out what tools are being used, what data is going into them, and where the actual risk lies.

The answer isn't necessarily another policy or a blanket ban.

There’s a real difference between someone using an AI note-taker for internal productivity and AI embedded directly into a customer-facing product; the latter carries significantly higher risk.

Classify data into three buckets: customer data, company-confidential data, and public data, and communicate what can’t be shared with an AI tool.

Require a simple gate before use: employees write down which tool and the business reason for using it. That small amount of friction alone eliminates many unnecessary requests.

Sanket summed up the approach:

That mindset applies beyond AI, too. Good GRC should make it easier for the business to operate safely, rather than becoming another layer of friction.

The goal isn't to build a bigger GRC team. It's to build a better system.

A lean team will always have limited time. The answer is not to turn every member into an expert in everything.

It is to make deliberate choices about where their attention goes.

Aayush captured the broader idea during the discussion:

Those questions are at the heart of building a GRC program that can scale without making the team behind it work harder every quarter.

Want to hear how experienced security leaders make these calls in practice?

Watch “Running a Lean GRC Program: What to Own, Automate, and Hand Off” on demand for the full discussion, including the panel's real-world scenarios, automation lessons, and practical advice for lean teams, from a CISO, a founder, and Scrut's own CEO.

‍