The GRC Operating Model Is the Program

Category: Operating Models Author: Cody Swidler Tags: operating model, GRC, program design, governance, organizational design

Most governance, risk, and compliance programs fail for the same reason: they're built around frameworks instead of operating models.

You can have the most technically sound control library in the industry. You can map every obligation to NIST, ISO 27001, SOC 2, and OCEG. And still, the program underperforms — because nobody owns the work, the teams aren't aligned, and the data never gets where it needs to go in time to matter.

The framework isn't the problem. The operating model is.

What an Operating Model Actually Means

An operating model answers four questions that most GRC charters never ask:

1. Who does what? Not at the policy level — at the actual work level. Who runs the BIA? Who owns vendor reviews? Who escalates to the board and under what conditions? 2. How does work flow between teams? GRC doesn't live in one department. It touches Legal, Engineering, Finance, HR, and Operations. If there's no defined handoff model, work falls through the seams — every time. 3. What does "done" look like? Most programs confuse activity with outcome. Running a tabletop exercise is an activity. Validating that your recovery assumptions are accurate is an outcome. Your operating model should define outcomes, not just tasks. 4. How does the program learn and adapt? Governance programs that aren't built to evolve become shelfware. The operating model needs feedback loops — from audits, incidents, control failures, and stakeholder input.

Why This Gets Skipped

The honest answer is that operating model design is hard and unglamorous. It requires difficult conversations about ownership, accountability, and resource allocation. It's much easier to buy a GRC platform, import a framework, and call the program built.

The other reason is organizational — most GRC leaders don't have the authority or the mandate to define how work flows across functions they don't own. So they default to influence and documentation, which only works until the first real test.

The Fix Isn't More Documentation

I've built or rebuilt GRC programs at organizations ranging from a regulated private bank to a hyperscale cloud communications platform. The pattern is consistent: the programs that perform well aren't the ones with the most comprehensive policies. They're the ones where everyone knows their role, escalation paths are clear, and the governance structure reflects how the organization actually makes decisions — not how it's supposed to on paper.

Getting there usually means three things:

Define ownership at the work level. Every significant GRC activity — risk assessments, control attestations, vendor reviews, regulatory submissions, tabletop exercises — should have a named owner and a clear cadence. Not a "team responsible" — a person.

Design for the organization you have. A 200-person SaaS company and a 10,000-person financial institution need fundamentally different operating models. One has a dedicated second-line function with formal IA oversight. The other has the CISO doing GRC work alongside three other jobs. Your model has to reflect reality, not aspiration.

Build for visibility. The operating model only works if leadership can see what's happening. That means dashboards, escalation triggers, and reporting cadences that surface risk before it becomes a crisis — not after.

Where to Start

If you're looking at an existing program and wondering why it's not working, start with the operating model, not the framework. Ask who owns each major work stream. Ask how decisions get made and where approvals stall. Ask what the escalation path looks like and whether anyone actually uses it.

You'll find the gaps faster than any maturity assessment will show you.

The framework tells you what to do. The operating model determines whether it actually gets done.

Cody Swidler is the founder of PivotRisk and a Principal Program Manager, Enterprise Resiliency at Apex Clearing. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.