Building a GRC Program the Business Follows

My last post was about what makes an audit come back with zero findings, a management system that keeps controls true over time, not a policy written once and left alone. This post is about something upstream of that: what actually makes a GRC program something people follow, rather than something they route around.

I’ve seen this play out in genuinely different ways across the same company.

When Authority Has to Do the Work

By the time I joined Tokopedia in 2021, the organization had become one where security was structurally non-negotiable. Our CTO could, and did, stop a product shipment if the security review hadn’t been completed. That wasn’t a policy line item. It was a deciding factor every department understood and planned around, because everyone knew the shipment simply wouldn’t move without it.

That kind of authority doesn’t appear by accident. Indonesia’s e-commerce sector went through a hard reckoning around data security in the years before I arrived, most visibly with Tokopedia’s own widely reported 2020 data breach affecting an estimated 91 million accounts.

I wasn’t there for that period, so I won’t claim firsthand knowledge of what led to it. But the organization I joined afterward had clearly internalized the lesson: when growth outruns security investment, the cost shows up eventually, and it’s larger than the cost of slowing down earlier. Top-down enforcement, a CTO with real stop-ship authority, was the mechanism that made sure that lesson stuck.

When the System Does the Work Instead

What changed after the ByteDance acquisition was different in kind, not just degree. Controls increasingly moved into the technical layer wherever possible. Access provisioning, review cycles, deployment gates, a growing share of what used to require someone in a room saying “no” became something the system itself wouldn’t allow to proceed. Business flows were designed with the control already built in, so compliance stopped depending on anyone remembering to invoke it, or on a senior enough person being available to enforce it.

This is the real maturity jump. Top-down authority is a forcing function, powerful, but it depends entirely on the person holding it staying consistent and available. Automation removes that dependency. A control embedded in the deployment pipeline doesn’t care whether the CTO is in the room. It’s followed because bypassing it isn’t a practical option, not because someone senior said so today.

The Failure Mode Neither One Prevents

I’ve also seen a different pattern, in environments where a control’s underlying design was weak, and the response was to compensate with more documentation rather than fix the design itself. More sign-offs, more evidence logs, more paper trail, all layered on top of a control that still wasn’t actually effective. It looked more rigorous on paper. It wasn’t more secure in practice. That’s the specific trap both top-down authority and embedded automation are meant to avoid: documentation is supposed to evidence that a control works, not substitute for one that doesn’t.

What Actually Makes a GRC Program Stick

Neither, because they’re not really competing against each other. Top-down authority is what you reach for when the systems aren’t built for control yet, it’s a stopgap that works immediately but doesn’t scale past the person enforcing it. Embedded, automated control is what you’re building toward, because it holds regardless of who’s in the room.

What connects them, and what makes any GRC program actually stick, is the same principle from my last post: a program the business actually follows is one where following the control costs less than working around it, whether that’s enforced by a CTO’s authority today or by architecture that makes the shortcut simply unavailable tomorrow. Documentation without either is the version that looks like governance and isn’t.

About Me