👟 Your GRC Program Needs a Product Manager, Not Another ex-Auditor

TLDR:

1. Your GRC program should not be audit driven 🔍

2. Customers are cooler than stakeholders 💷

3. Bake iteration into your GRC program 🔄

4. We found Excel’s SeQueL 📊 => 🐬

5. Continuous Control Monitoring isn’t a gym membership 🏋️‍♂️

You should treat GRC as a product 🗺️

In a classical GRC setting, you would run your audit cycle in a yearly or quarterly cadence. You test the controls in scope throughout the year, ensure they are all operating effectively and that the design satisfies the control objective.

Then you go into audit mode for a couple of months and craft the right scope, narrative and environment to limit nonconformities. After sweating for a bit, you have your certification/attestation and can breath for a bit… until the next audit cycle!

The issue with that vision is that the goal is to stay alive until the next year. Improvements on minute details or using shared google sheets to share info isn’t moving the needle at all.

Having a product approach distances yourself from the audit as the result of your work. The audit is only about checking your work periodically to ensure you have covered your basis.

Here are 3 reasons why you should think Product when you think about your GRC program.

1) Not being audit driven 📋

Imagine a world where your work would not be based on annual audits or board risk reports. Instead you would be focused on making your compliance and risk program the most effective at capturing the state of your company security posture.

Then you just have to showcase artefacts to auditors a couple of times per year and keep building your program.

It seems counter intuitive to have a GRC program not focused on one of its core pillars. It’s exactly the reason why you should change your approach.

Regulators, customers and legal teams care about compliance. None of your technical/security stakeholders really care.

Keeping the lights on shouldn’t be a strategy, it should be an externality.

2) Product has customers, not stakeholders 🤝

As a GRC professional, compliance has very rigid stakeholders, let’s give a non-exhaustive list:

• Auditors

• Control owners

• Legal

• Risk owners

• Executives

This list is the reason why your influence is dwindling as you collect additional certifications. Your company values your contribution but that is an expected outcome of GRC.

To get your program forward, you need to provide unexpected output with the same input. One great way to do that is to change your key stakeholders landscape. Think about it this way:

• Auditors

  • Walkthroughs => Provide async answers to questions

  • Populations => Share results from API calls with auditors

  • Exceptions => Craft rationale for automated controls

• Control owners

  • Software Engineers => Reduce toil

  • Security Engineer => Provide support to key initiative

  • Infrastructure => Provide support on IAM

These are just examples. The goal here is to see GRC as a product who needs to support its customers through understanding their pain points. If you create win-win situations, you improve your program and your influence at the company all-at-once.

We manage stakeholders but we satisfy customers.

3) Iteration is baked into a Product 🔄

An MVP, Minimum Viable Product. This product concept is completely foreign to us in GRC.

This is because compliance is a static process to showcase adherence to a set of standards.

This is also because risks are a static list of high-level scenarios your company should think about.

How can you iterate on static outcomes? Where’s the stretch goal there? Getting bored faster? Your incentives aren’t aligned with iteration. To align them, you need to think product instead.

Think about your GRC program as versions (v1, v1.1, etc.). Similar to a NIST CSF Maturity scale, benchmark your key processes against your ideal state. Think full automation, accurate scope, complete visibility, live metrics and automated remediation.

Where are you on that journey? Even if you’re just starting, just thinking about your program this way and build a roadmap of what you want to achieve next year.

You can iterate on a product, you can’t iterate an audit (it would be too easy).

📣 Featured section 📣

Interested in partnering with the GRC Engineer and reaching Security GRC executives and seasoned practitioners? We are on a mission to build the weekly newsletter for every GRC professionals and their [compliance ≠ security] managers.

=GRC.BREAK(“Week”) 🤣

## Every week, a fun section to discuss the limitations of our industry, how to infuse more engineering into the way we do GRC.

SELECT * FROM Excel_SeQueL 📊 => 🐬

If you didn’t know, the tech world invented something even cooler than Excel, it’s called SQL 🐬 (it even predates Excel!) , it works almost as spreadsheets do, look at that!

CREATE TABLE spreadsheet_inventory (
    id VARCHAR(255) PRIMARY KEY,  -- "audit-smpl-pop.xlsx"
    owner VARCHAR(100),           -- "the ISMS person"
    last_updated TIMESTAMP,       -- "last SOC 2 audit"
    purpose TEXT,                 -- "Tracking evidence"
    location VARCHAR(255),        -- "Shared GDrive"
    version VARCHAR(50),          -- "Final_v5_ACTUAL_2"
    backup_location VARCHAR(255)  -- "free dropbox acct"
);

-- Error: Duplicate entry 'Q4_2024_Final_v3_FINAL_actual_final.xlsx'
-- Error: Foreign key constraint fails (password protected zip)
-- Error: Column 'actual_data' missing in production

Dear GRC professionals: You're already building databases. They're just trapped in Excel. Think about it:

• Your VLOOKUPs? That's a JOIN

• Your pivot tables? GROUP BY queries

• Your filter views? WHERE clauses

• Your data validation? CHECK constraints

• Your linked sheets? Foreign keys

• Your macros? Stored procedures

Pro tip: Databases were literally built for this. They track relationships, maintain data integrity, and won't crash when you try to filter more than 1M rows.

Plus, they play nicely with APIs, unlike that Excel file that takes 5 minutes to load because the VBA script is older than your compliance program.

If you’re convinced, SQLBolt is a great place to quickly learn the basics of SQL directly from your browser.

Philosophical quote 💭

Resources to dive deeper 📚

• GRC Engineering Podcast episode with Charles Nwatu, we talked over how GRC could be seen as more of a product-driven team with some comparisons between GRC and Quality Assurance.

• The GRC Engineering manifesto has a section on treating GRC as a product with some additional insights worth looking at!