The CISO’s Blind Spot: When Policies Look Perfect And Still Fail
Your policies are beautifully written.
Your auditors are satisfied.
Your teams pass the annual training.
Then something breaks, and you are forced to confront an uncomfortable reality. You may not actually know whether what is written in your policies is what your organization is doing day to day.
That gap between polished documents and messy operational reality is where real risk lives. It is also where the next generation of GRC is being defined.
At industry events, you can hear this frustration from experienced practitioners. One of them is Sahar Dahan, co‑founder and CEO of GoComply, a longtime GRC team lead and ISO 27001 auditor. He sums up his journey this way:
In his words, “I was the player and I was the coach to get here, and I’ve seen it firsthand. Now I see people are doing it in the wrong way.”
For CISOs, that “wrong way” is often treating GRC as a checkbox exercise.
Sahar is direct about the root problem:
As he puts it, “GRC never should be just compliance. GRC should be comprehensive. You should govern your risk. You should control them. People see just the “C” part.”
When GRC is reduced to meeting audit demands, organizations optimize for documentation instead of durability. Policies look impressive, but they are not tightly connected to how systems are configured, how identities are managed, or how incidents are handled.
He captures this clearly: “People think that, give me the paper policy and that’s it, but there’s so much more.”
You can feel the cost of that disconnect in a story I shared with Dahan.
Years ago, I deployed a well‑known GRC tool that produced a set of neatly packaged policies. My CIO asked a simple question that cut through the appearance of control. He said, “You gave me 25 policies. Are we actually doing what the policies say we’re doing? Are we doing what’s in the policies?” I didn’t know and couldn’t tell him.
That is the core of the CISO’s blind spot. Most frameworks and tools can generate policies. Far fewer can show, in near real time, whether those policies are being followed across modern, fast‑changing environments.
The usual reaction is to add more process: more reviews, more spreadsheets, more attestations. Sahar’s view is that this simply reinforces reactive compliance. What is needed is a shift to proactive, enforced GRC.
He explains, “The problem that we are solving is enforcement of policies, not just what is stated on the paper. That’s our goal, to shift from reactive compliance to proactive GRC, proactive security, like it should be.”
The key idea is that policies should not just exist; they should be continuously testable and enforceable. That means:
- Writing policies specific enough to translate into technical checks or workflows
- Continuously validating those checks via automation where possible
- Treating deviations from policy as signals that demand response, not as minor paperwork gaps
For CISOs, this frames a useful mental model: treat policy drift the way your SOC treats suspicious activity. When what your environment does diverges from what your policies require, that is a risk event.
To make this concrete, think about a few familiar policy areas:
- A password management policy that defines rotation and complexity rules
- An access review policy that specifies cadence and owners for privileged account review
- A data loss prevention policy that restricts where sensitive data can reside
If identity systems, SaaS tools, and infrastructure do not match these expectations, the gap is not theoretical. It is a live exposure. The question is whether you see it in time.
Sahar outlines two main mechanisms his platform uses to answer that question. The first is well known to most security leaders.
He explains, “The first one, and everyone knows it, is with API integrations. We’re gathering Read Write permissions, or very specific and granular permissions.”
APIs expose the truth of how controls are configured. They can verify whether MFA is required, which users hold which roles, and how data‑sharing settings are applied. For a CISO, this is where GRC starts to intersect with identity governance and configuration management.
The second path he mentions reflects the broader shift toward control interfaces that do not require heavy integrations.
As he notes, “The second is the MCP calls. So these days, you don’t necessarily need to make full API integrations. I can send your call to your product to understand, ‘okay, you see this, but what is written?’, ‘let me know if it’s enforced, and ping me back.’”
The specific mechanism matters less than the direction of travel. GRC tools that cannot interrogate reality programmatically will remain stuck in static, point‑in‑time assurance. In his words, “that’s why is the right time to do it with way more precision, more accuracy and quicker.”
Sahar is blunt about the cost of staying in checkbox mode.
He states, “For so many years, we’ve been doing it in the wrong way. From my end, that’s why so many companies get breached, so many have data leakage, so many ransomwares – because people are just checkboxing.”
For global giants, a breach is rarely existential. For many mid‑market organizations, it can be. He puts it plainly:
“When you’re talking about small or medium enterprises, one leakage could be game over.”
That is the real audience for proactive GRC. Not just regulators and auditors, but customers, partners, and leadership teams who understand that survival may hinge on whether controls are truly enforced.
This same theme appears in how he talks about incident response and continuity. Plans and procedures are necessary, but they are not sufficient.
Speaking about incident response plans, he asks, “Okay, you’ve got your policies, and you’ve got your, I don’t know, response team, and their backup team. But do these individuals know what they should do when things mess up? Not necessarily.”
For CISOs, the lesson is simple:
- Tabletop exercises and technical simulations should validate both policy and practice
- Findings must flow back into policy documents, risk registers, and training
- GRC cannot sit apart from operations; it must be in a feedback loop with the SOC and engineering
Late in the conversation, I asked Sahar a difficult question about the October 7 attacks and signals intelligence. His answer points to another, deeper layer of risk: culture.
“There were so many egos involved out there, because the junior scouts and some, let’s call them ‘fresh’, female soldiers told their commanders something has happened, and the answer that came back was, shut your mouth. You’re just a female or a junior soldier. You don’t know anything.”
The details are specific to a national tragedy, but the pattern is universal. People close to the signals saw trouble early. Their warnings were dismissed for reasons unrelated to the data itself. Hierarchy, bias, and overconfidence overrode evidence.
Inside enterprises, the parallels are easy to see:
- Analysts whose alerts are brushed aside because they are junior
- Compliance staff whose repeated findings are labeled as “obstructive”
- Engineers who spot risky shortcuts but are told not to “slow the roadmap”
No GRC platform can fix a culture that punishes early, uncomfortable truths. Culture is itself a control surface. It either enables honest reporting of risk, or it hides it until it becomes a headline.
That brings us to what CISOs can do now. In concise terms:
- Ask your own version of my earlier question: “Are we doing what are in these policies?” Require system‑level evidence, not just sign‑offs.
- Rewrite critical policies so they can be tested and enforced programmatically wherever possible.
- Treat policy deviations as signals. Track, triage, and remediate them as you would any other important alert.
- Connect GRC to operations. Align policy with SOC data, engineering workflows, and incident reviews.
- Exercise your plans. Validate not only technology but also coordination, decision‑making, and understanding.
- Build a no‑ego culture around risk reporting, where junior voices are heard and rewarded for surfacing gaps early.
Sahar’s own vision is clear. In his words, “We are not just letting you know if policies are implemented. Our goal is to enforce them for you across your tech stack.”
The call to action for CISOs is just as clear. Stop accepting “checkbox green” as proof of safety. Close the gap between what your policies say and what your systems and people actually do.
Turn your policies into living, testable constructs. Give your teams tools and authority to detect and correct drift quickly. Shape a culture where bad news can travel fast enough to matter.
So the next time your CIO asks, “Are we actually doing what are in these policies?” you do not have to say, “I think so.”
You can show the evidence.
And you can show it on demand. Learn more at GoComply – The Ultimate GRC Management Platform
About the Author
Pete Green is the CISO of Anvil Works, a ProCloud SaaS company and co-author of “The vCISO Playbook: How Virtual CISOs Deliver Enterprise-Grade Cybersecurity to Small and Medium Businesses (SMBs)”. With over 25 years of experience in information technology and cybersecurity, Pete is a seasoned and accomplished security practitioner.
Throughout his career, he has held a wide range of technical and leadership roles, including LAN/WLAN Engineer, Threat Analyst, Security Project Manager, Security Architect, Cloud Security Architect, Principal Security Consultant, Director of IT, CTO, CEO, Virtual CISO, and CISO.
Pete has supported clients across numerous industries, including federal, state, and local government, as well as financial services, healthcare, food services, manufacturing, technology, transportation, and hospitality.
He holds a Master of Computer Information Systems in Information Security from Boston University, which is recognized as a National Center of Academic Excellence in Information Assurance / Cyber Defense (CAE IA/CD) by the NSA and DHS. He also holds a Master of Business Administration in Informatics.
