February 11, 2026
Cheri Hotman, Managing Partner of Hotman Group, and Peter Spier examine what it actually means to operationalize GRC — and why a mature Cyber GRC program is not a collection of audits, questionnaires, policies, green dashboards, or technology. Operationalized GRC is an operating model that connects governance, risk, compliance, ownership, technology, evidence, and decision-making to how the business actually works.
Watch Cheri and Peter discuss why customer pressure is forcing organizations to rethink GRC, what separates operational GRC from checkbox compliance, and how governance, ownership, risk, automation, quality assurance, and business alignment work together in a mature program.
Operationalized GRC means governance, risk, and compliance are embedded into the way the organization operates instead of appearing only when an audit, customer questionnaire, security review, or regulatory requirement creates pressure.
A truly operational program has defined ownership, repeatable processes, common terminology, risk-based decision-making, clear escalation paths, useful metrics, continuous monitoring, quality assurance, and technology that supports the operating model rather than defining it.
The objective is not to make everything green. The objective is to understand where risk exists, decide what matters, assign responsibility, take appropriate action, and give the business enough visibility to pursue its goals responsibly.
One of the strongest forces behind operational GRC is not regulation alone. It is customer pressure.
Prospective customers increasingly want assurance that a supplier, service provider, or SaaS platform can be trusted with their data and operations. That pressure shows up through security questionnaires, SOC 2 reports, ISO certifications, third-party risk reviews, contractual requirements, and increasingly detailed due diligence.
Those activities can influence whether a deal closes, how quickly it closes, and whether an existing customer remains comfortable with the relationship.
That makes GRC much more than an administrative compliance function. It becomes part of how the organization establishes trust and supports the business.
One of the easiest mistakes is assuming GRC has been operationalized because the organization purchased a platform and the dashboard is mostly green.
A green control may mean the evidence inside the platform supports a conclusion. It does not automatically prove that the platform contains the complete environment.
Endpoints can be missing. Locations can fall outside the configured scope. Relevant employees can be excluded. Irrelevant populations can be included. Controls may be split across multiple tools that do not communicate with one another.
“All green shouldn't help you sleep at night. It should keep you awake.”
— Peter Spier
There is no zero-risk environment, perfect control environment, or permanently mature program. The organization, technology stack, people, threats, suppliers, and external expectations continue changing. A healthy GRC program needs visibility into the yellow and red areas so it knows where to focus.
A compliance result is only as meaningful as the scope behind it.
When someone answers a questionnaire, provides an audit report, or reports that a control is operating, that conclusion applies to a defined boundary. If the reader does not understand that boundary, it becomes difficult to know what assurance the answer actually provides.
This is why strong GRC practitioners ask what systems, people, data, locations, applications, vendors, processes, and other dependencies were included before treating a conclusion as meaningful.
Organizations do not all have the same risk posture.
A rapidly growing SaaS company operating in a highly competitive market may legitimately accept more risk in pursuit of speed and innovation than a bank or other heavily regulated organization.
The purpose of GRC is not to force both organizations into the same operating model. It is to help each organization understand its risk, apply appropriate governance, and make defensible decisions that align with its objectives.
That is why risk assessment and risk-based decision-making matter more than simply accumulating compliance evidence.
Internal audit should not be treated as the enemy.
A finding or observation can create a useful conversation about what evidence exists, how significant the issue actually is, what the underlying risk may be, and what the organization should do about it.
An internal auditor can provide an independent perspective before an external auditor or regulator arrives. Maintaining that independence matters, but so does recognizing that both functions ultimately benefit when weaknesses are identified and addressed before they become larger problems.
The objective should not be avoiding findings. It should be understanding what the finding means and making the right risk decision.
AI and automation can help GRC practitioners spend less time on repetitive administrative work and more time applying judgment.
Cheri compares the difference to building with a screwdriver versus using a screw gun. The tool does not remove the person who knows how to build. It increases the amount of useful work that person can accomplish with the same time.
That only works when quality assurance remains part of the process.
“Quality assurance always matters.”
— Peter Spier
AI-generated analysis, automated evidence, and GRC dashboards still depend on the completeness and quality of the underlying data. The more organizations automate, the more important governance, validation, and human oversight become. The same principle applies to AI governance across the broader organization.
Third-party risk management is a good example of the difference between administering a process and operating a risk program.
A questionnaire can collect information, but experienced practitioners still need to evaluate the answers, identify unclear responses, understand the scope of the supplier relationship, and ask follow-up questions where necessary.
The problem appears when both sides reduce the exercise to moving questions and answers as quickly as possible. Customers ask questions they may not fully understand, suppliers send boilerplate responses, and each side checks the other's box without meaningfully evaluating risk.
Operational GRC replaces that cycle with skilled analysis, consistent terminology, appropriate review, and quality assurance.
Organizations can create unnecessary confusion when cybersecurity, internal audit, enterprise risk, legal, compliance, and business teams use the same words to mean different things.
A threat is not necessarily the same thing as a vulnerability. A failed control is not automatically the underlying risk. An “inactive account” may mean something different to one organization than another.
Different functions may also use different rating methodologies. Cybersecurity may call something high while enterprise risk calls it low and internal audit calls it medium.
Operationalization does not necessarily require everyone to reach the exact same rating. It does require a common methodology and enough transparency to explain how each function reached its conclusion and how those conclusions relate.
Governance creates the shared rules and structure that allow different parts of the organization to operate as one program.
Policies establish expectations. Standards create more specific requirements. Methodologies explain how decisions are made. Ownership establishes accountability. Escalation defines what happens when activity does not occur as expected.
Without that common playbook, every team can effectively be playing a different version of the game.
Operational governance does not mean forcing every function into the same perspective. It means giving the organization a common way to understand how those perspectives connect.
That governance foundation is a critical part of a strong Cyber GRC operating model.
A mature GRC program begins by understanding what the business is trying to accomplish.
Is the organization entering healthcare? Trying to close deals faster? Acquiring another company? Launching a new product? Expanding into a new market? Maintaining a steady-state business?
Each objective changes the risk environment and therefore influences how security and GRC should respond.
When GRC operates with different objectives from the business, security may appear to be an obstacle. When the objectives are aligned, risk information helps leadership understand how to pursue the same business goal with fewer surprises.
Cybersecurity has already learned that problems are easier to manage when security is considered earlier in the lifecycle.
The same principle applies to GRC.
Risk and GRC professionals should be involved early enough to influence decisions involving architecture, software development, procurement, acquisitions, change management, new technologies, regulatory scope, and other consequential business activity.
If GRC appears only after the decision has been made, the function becomes more likely to create friction because the remaining options are narrower and more expensive.
Several symptoms can indicate that the underlying operating model needs attention:
A GRC platform can be extremely valuable, but the organization needs to know what it wants the technology to accomplish.
“This is a process, not a platform.”
— Cheri Hotman
Organizations should first define their operating model, requirements, workflows, ownership, reporting needs, evidence strategy, escalation paths, framework structure, and desired outcomes.
Then they can select GRC technology based on the program they need to operate rather than allowing a vendor's feature list to determine what their program becomes.
The GRC function should not become the owner of every control and every risk in the organization.
Ownership needs to exist with the people and functions responsible for the underlying activity. Depending on the organization, that may include HR, IT, legal, security, finance, engineering, operations, procurement, or other teams.
The role of GRC is to establish the structure, help owners understand their responsibilities, provide workable mechanisms for completing those responsibilities, monitor the program, escalate when appropriate, and help improve weak processes.
Strong technology can automate reminders, workflows, and evidence collection so GRC practitioners spend less time chasing people and more time analyzing risk, solving problems, and improving the program.
Operationalized GRC is visible in the way the organization works every day:
Operationalizing GRC means embedding governance, risk, and compliance into normal business operations through clear ownership, repeatable processes, risk-based decision-making, appropriate technology, useful evidence, monitoring, escalation, and continuous improvement.
No. A platform can support an operational GRC program, but the organization still needs to define the program, requirements, ownership, workflows, governance, risk methodologies, evidence strategy, and desired outcomes.
A green status depends on the data, scope, population, evidence, and configuration behind it. Missing systems, assets, employees, vendors, or other scope elements can create a positive result without providing complete assurance.
Yes, when changes or development decisions can materially affect security, regulatory scope, compliance obligations, business risk, or customer commitments. Earlier involvement allows GRC to help shape decisions rather than reacting after they are effectively final.
AI can help automate analysis, administrative work, evidence processing, and other repeatable tasks, but GRC still requires human judgment, context, quality assurance, communication, risk prioritization, governance, and problem-solving.
Control ownership should generally sit with the people or functions responsible for the underlying activity. The GRC team helps define the structure, educate owners, monitor performance, coordinate evidence, identify issues, and escalate when necessary.
A useful test is whether the organization can operate its program consistently throughout the year without recreating it for every audit or customer request. Ownership should be clear, evidence should be available, risk decisions should be explainable, processes should be repeatable, and the program should continue improving as the business changes.
This article is based on a Hotman Group live session featuring Cheri Hotman, Managing Partner of Hotman Group, and Peter Spier on what it actually means to operationalize governance, risk, and compliance.
The discussion examines customer-driven assurance, risk, audit relationships, third-party risk, governance, policy, terminology, business alignment, GRC technology, AI, quality assurance, ownership, SDLC integration, escalation, and continuous improvement.
Rather than treating GRC as an administrative compliance function, Cheri and Peter explore how governance, risk, controls, technology, and people can operate together as a business-enabling system.
Organizations often bring in Hotman Group when the individual pieces of GRC exist but do not yet operate as one coherent program. HG can help when:
Hotman Group has helped organizations advance Cyber GRC operations by:
Hotman Group helps organizations design and operationalize Cyber GRC programs by connecting governance, risk, controls, ownership, evidence, workflows, technology, reporting, and continuous improvement to the way the business actually operates.
Get an outside view of how operational your GRC program really is
Hotman Group is a cybersecurity and Cyber GRC professional-services firm that helps organizations diagnose, design, build, remediate, implement, operate and mature cybersecurity programs. HG provides hands-on vCISO and vGRC leadership, supports multi-framework environments, and helps organizations select and implement GRC technology while connecting cybersecurity decisions to business risk and strategy.
Hotman Group helps organizations move beyond disconnected compliance activity by establishing governance, clarifying risk and control ownership, operationalizing evidence and workflows, improving visibility, aligning frameworks, and using technology to support scalable Cyber GRC operations.
The goal is not simply to make GRC faster. It is to build an operating model that gives the organization better information, clearer accountability, stronger assurance, and more capacity to focus human expertise on the risks and decisions that matter.