Stop the Paperwork, Start the Engine
A CISO’s Guide to Using GRC as a Strategic Superpower
Think about the last time you sat in a board meeting. Did the directors lean in when you talked about firewall throughput or packet offsets? Probably not. But they definitely sat up when you talked about risk appetite, business objectives, and regulatory assurance.
Many leaders view Governance, Risk, and Compliance (GRC) as a “boring” necessity or a mountain of tedious paperwork. But according to G Mark Hardy and Steve McMichael on a recent CISO Tradecraft episode, GRC isn’t the weight dragging the ship down; it’s the control system that allows your organization to reach top speed.
If you want to move from being a “technical wingnut” to a strategic business leader, you need to master the GRC blueprint. Here is how CISOs can transform their GRC function from a checkbox exercise into a high-performance engine.
1. Shift Your Mindset: Brakes Aren’t for Stopping
The most common mistake CISOs make is viewing security as a series of hurdles. Hardy offers a better analogy: What allows a car to drive 200 miles an hour? It isn’t just the supercharged engine; it’s the better brakes.
You won’t feel safe pushing the limits of business growth if you can’t stop effectively or control your trajectory. GRC provides that control. As a CISO, your job is to frame GRC as a strategic interface that helps the business make decisions aligned with its risk appetite. When your GRC is functioning correctly, it provides the “due diligence and due care” needed to show the organization wasn’t negligent if a bump in the road (like a security incident) occurs.
2. Hire for “T-Shaped” Talent (Not Just Technical Wizards)
Stop looking for unicorns who are experts in everything. Instead, build a team of “T-Shaped” professionals. This means hiring individuals who have a broad general knowledge (the top of the T) but go very deep into one specific domain (the vertical stem).
McMichael’s own journey proves this: he broke into the field from an accounting background by going deep on Identity and Access Management (IAM) and Sarbanes-Oxley compliance. Because he was a “resident expert” in one area, he built a “reservoir of trust” with his more technical colleagues, making it easier for him to learn other domains like networking or site reliability.
CISO Action Item: Look for “pivot” candidates from finance, healthcare, or legal who understand the business value at risk. They often possess the critical thinking and communication skills that technical experts sometimes lack.
3. The “20% Rule”: Knowledge Over Pedantry
You don’t need your GRC analysts to be “technical wizards” who can decompose a packet from memory. McMichael cites expert Kip Boyle’s “special number”: you only need 20% depth of knowledge in each technical domain to be effective in GRC.
This 20% allows your team to see the big picture that functional experts might miss because they are too focused on their specific “swim lane”. It gives your team enough “shop talk” to ask performing questions and ensure they don’t get the “wool pulled over their eyes” by consultants or vendors.
4. “Protect the Goalie”: Use GRC to Support Operations
Your GRC team should not be an island. They need to be the connective tissue between your technical teams and the business. McMichael emphasizes a “help mentality”—GRC should be there to “protect the goalie” (the incident response team).
How do you do this?
Clear Policies: Don’t write vague policies that leave your SOC team hanging. When a policy has “teeth” and is specific, the incident responder has the leverage they need to handle uncomfortable conversations with business users.
Audit Efficiency: Respect the technical team’s time. GRC should manage the “alphabet soup” of audits so engineers don’t have to answer the same question twice for ten different regulators.
5. Move from Decision-Making to Decision Support
As a CISO, you are a compass and a conduit, not a “No” machine. GRC is about decision support. When the business wants to move fast on a risky project, your GRC team shouldn’t just say “stop.” Instead, they should:
Identify the calibrated risk level.
Calibrate that against the company’s risk appetite.
Ensure the right level of management is “eyes wide open” and signs off on the risk.
This socializes the responsibility and ensures that security is seen as a business enabler rather than a roadblock.
6. Cultivate an “Immersion Mindset”
Dry technical material is hard to retain, but emotional engagement accelerates learning. If you want your GRC team to truly understand threats, connect the dry concepts to real-world outcomes.
For example, don’t just study Server Message Block (SMB) protocols; study how the WannaCry exploits used SMB to cripple organizations. When your team sees how a vulnerability directly impacts the “treasure” an adversary is after, their learning becomes “commitment” rather than just “compliance”.
7. Leverage Low-Cost, High-Impact Tools
You don’t need a million-dollar budget to start a world-class GRC program. McMichael suggests using free or open-source tools to build a portfolio of “artifacts” that prove your controls are working.
NIST CSF 2.0: Use this framework to organize your complexity into just six functions.
Notion/GitHub: You can build GRC databases or contribute to open-source projects like the NIST CSF Profile Assessment Database without writing a single line of code.
Final Word: Never Disqualify Your Team
The biggest barrier to a strong GRC program isn’t a lack of tools, it’s imposter syndrome and “limiting beliefs”. Hardy’s favorite piece of advice is: “Never disqualify yourself”.
Encourage your team to embrace the “ambiguity” of the field. Look for people who are curious, persistent, and adaptable. By building a GRC function that acts as a strategic compass, you won’t just be securing the business; you’ll be enabling it to go faster than ever before.