In this interview with Help Net Security, Nichole Windholz, CISO at Onspring, talks about the limits of automated GRC systems and continuous control monitoring. She explains why color-coded dashboards can hide nuance, how teams can check the data feeding their tools, and which risks resist measurement, such as insider behavior and vendor concentration.
Continuous control monitoring tools tend to produce a green-yellow-red mosaic that flattens nuance. When a CISO walks into a board meeting with that mosaic, what gets lost between the telemetry and the conversation?
A green-yellow-red view is a great, and in many cases, a highly necessary starting point, but it’s not comprehensive. The problem is that, without context, color-coded dashboards can make very nuanced issues look equivalent.
A red indicator might mean a control is completely missing, but could also mean evidence is stale, a business owner missed an attestation, a system changed without a corresponding update, or a threshold was crossed for a low-impact asset. Those are not the same risk. They don’t require the same response.
When nuance is flattened, the CISO is forced into a defensive posture. Instead of explaining what matters and what action is needed, the conversation becomes a debate about why something is red or whether the dashboard is “good” or “bad.” That’s exhausting for security leaders and not useful for directors.
A better board conversation starts with three things: what changed, what matters, and what decision leadership needs to make. Control telemetry should support that discussion, not replace it. The CISO needs to be able to say, “Here are the top risk movements this quarter, here is the evidence behind them, the business exposure, and where we need executive support.”
Automated GRC systems are valuable when they preserve that trail from control activity to business impact. They become less valuable when they only produce a heat map. Boards need context, trend lines, ownership, and a clear view of which risks are accepted, which are being addressed, and which are worsening.
When an automated GRC tool ingests data from a misconfigured source, the output looks authoritative but is wrong. How do you audit the auditor?
This is one of the most important questions organizations should ask before they lean too heavily on automation. A polished output doesn’t make the underlying data true. If a source system is misconfigured, incomplete, or mapped incorrectly, automation can make a bad assumption move faster and look more credible.
Auditing the auditor starts with data lineage. Security and risk leaders need to know where the data came from, who owns the source, how often it refreshes, which field mappings are used, and what has changed since the last review. If the organization can’t explain that chain, it shouldn’t treat the output as authoritative.
The next layer is control validation. Automated GRC shouldn’t be a “set it and forget it” system. There needs to be periodic tests against source systems, spot checks of evidence, reconciliation between systems of record, and clear alerts when integrations fail or data stops refreshing. The organization should also define what can be automated and what still requires human judgment.
The goal is not to distrust automation, but to avoid false confidence. When a dashboard shows an unexpected improvement, security leaders should be just as curious as they are when it shows a decline. Did the control improve, or did the data feed change? Did a business unit remediate the issue, or did an asset fall out of scope? Those questions prevent automation from turning bad data into a board-ready narrative.
There is a category of risk that resists telemetry: insider behavior, vendor concentration, geopolitical exposure, an executive’s decision to skip a control review. How do automated GRC systems handle what they cannot see, and how should boards be told about that blind zone?
Every automated GRC system has a line of sight. The responsible question is where that line stops.
Some risks create data naturally. Patch status, access reviews, control evidence, vendor attestations, and incident response activities can be tracked and monitored. Other risks are much harder to measure in a clean, automated way. Insider behavior, geopolitical exposure, business dependency, executive decision-making, and vendor concentration often require a mix of qualitative assessment, judgment, and scenario planning.
Automated GRC systems can still address those risks, but leaders need to be clear about what the system captures. A strong system can document assumptions, connect vendors to critical processes, flag concentration risk across high-value business functions, and track whether reviews, exceptions, and risk acceptances happened on time. Access to this record is critical because many of these decisions otherwise live in email, spreadsheets, or informal conversations, making them harder to revisit when conditions change.
What it can’t do is eliminate the blind spot. No platform can perfectly read intent, predict every geopolitical shift, or determine whether a senior leader will override a control in a moment of pressure.
Boards need to understand this. A mature CISO shouldn’t walk into the boardroom pretending every risk has a sensor attached to it. The better message is, “Some risks can be monitored continuously, while others require human review and judgment. Here are the assumptions behind our assessment, how we are testing them, and where the business has chosen to accept exposure.”
That transparency helps the board understand the limits of the data, rather than treating every risk as equally measurable. It also protects the CISO from becoming the lone translator of risk. Security risk is business risk, and the board needs to understand which parts are measured, which are estimated, and which require leadership judgment.
Pick a breach from the last three years that became public. If the victim had been running a top-tier automated GRC platform, what would have changed, and what would not have?
The 2024 ransomware attack on Change Healthcare is a useful example because its impact extended well beyond one company. It disrupted claims processing, pharmacy operations, and payments across the healthcare system. Public reporting and congressional discussion also highlighted issues many organizations struggle with, including legacy technology, access control, multifactor authentication, business continuity, and third-party dependence.
A top-tier automated GRC platform could have exposed certain gaps before the attack, especially if a critical access point lacked multifactor authentication. It could also have connected those gaps to business impact by showing which processes, customers, and downstream partners depended on the affected systems. That would have helped leadership see the issue as more than a technical control gap. It was also a risk to operational resilience.
This type of GRC system would also have improved the record for each control. If a control was marked as implemented, the system should have required current evidence from the source rather than relying on a stale attestation. If an exception existed, it should have shown who approved it, when it expired, and what compensating controls were in place.
What would not have changed is just as important. Automated GRC would not have stopped ransomware on its own or replaced identity security, segmentation, endpoint protection, backup readiness, or incident response execution. Its value is more realistic than that. It helps organizations identify weak signals earlier, connect technical findings to business consequences, and establish accountability before an incident becomes a broader disruption.
Five years out, where do you think this category is overinvested, and where is it underinvested?
The category is overinvested in presentation and underinvested in trust.
Too many companies are investing in better dashboards without fixing the operating model behind them. A dashboard can look polished and refresh constantly but still create false confidence if the data is incomplete, ownership is unclear, or the supporting record is weak. The real test is whether risk reporting helps the board truly understand what has changed, where the business is exposed, and which decisions need attention.
There’s also too much emphasis on automating broken processes. If an organization has unclear control ownership, inconsistent standards, or disconnected systems, automation won’t solve those problems. It may amplify them. The strongest organizations will know which workflows deserve automation, which decisions require experienced risk owners, and which signals matter most.
The trust layer behind GRC deserves more attention. Security leaders need systems that preserve the story behind a risk signal, not just its status. That means showing whether the data is current, whether the right owner reviewed it, and whether the decision being presented to the board is supported by a reliable record.
CISOs are also shouldering too much of the translation burden alone as they navigate technical findings, control evidence, executive expectations, and board-level accountability. Automated GRC should reduce that burden by creating a shared record of risk decisions so security leaders aren’t the only people responsible for turning scattered signals into business context.
Apply now: Simplify security management with CIS SecureSuite Platform
