Introduction
When Blackbaud failed to disclose the full scope of a 2020 ransomware attack, the SEC charged the company $3 million — not for the breach itself, but for inadequate disclosure controls. R.R. Donnelley paid over $2.1 million in a similar 2024 settlement. In both cases, the core failure was governance: nobody owned the decision about what to disclose, or when.
This is what fragmented IT GRC looks like in practice. Not a technical failure. A governance failure with a dollar amount attached.
That gap is what this guide addresses. It covers:
- What IT GRC is and why the definition matters for oversight
- How to build a framework that holds under regulatory and operational pressure
- Which standards apply — and how to choose between them
- What effective board and executive oversight actually looks like in practice
It's written for practitioners and directors who need governance that works beyond the policy document.
TLDR
- IT GRC integrates governance, risk management, and compliance into one auditable system — not three separate functions
- Ambiguous decision rights are the most common failure point, especially during incidents and regulatory reviews
- COBIT, NIST CSF 2.0, and ISO 27001 are the most widely used frameworks — and most organizations layer more than one
- 66% of public company boards discuss technology items at every board meeting — yet gaps in oversight remain common
- Board-level IT GRC requires clear escalation thresholds, trend visibility over time, and reporting that non-technical directors can act on
What Is an IT GRC Framework?
IT GRC — governance, risk management, and compliance — is the structured integration of three disciplines applied specifically to information technology. It covers digital assets, cyber threats, data handling, and technology infrastructure.
Where general corporate GRC addresses enterprise-wide risk and regulatory obligations, IT GRC focuses on the specific technical systems, security controls, and regulatory requirements that apply to those systems. The scope is narrower, but a failure here can trigger SEC enforcement, HIPAA penalties, or a ransomware incident that stops operations.
The framework has three pillars, and all three must connect.
Governance: Who Decides What
IT governance defines authority over technology decisions : who sets IT strategy, who controls budget, who owns risk tolerance, and how accountability is enforced. Without clear decision rights, security work sits in IT, hard calls bounce between leaders, and projects stall because nobody can confidently say yes or no.
In post-incident reviews, the absence of documented decision rights is one of the most consistent findings. As Tyson Martin describes it: when decision rights are vague, risk gets expensive fast.
Risk Management: What Could Go Wrong
The job of IT risk management is to find what could compromise systems, data, or operations — and act before it does. That includes cyber threats, third-party risks, cloud vulnerabilities, and operational technology failures.
The critical distinction: risk management should run continuously, not surface once a year for an audit. A quarterly review that reveals a risk that existed for nine months is not risk management — it's documentation.
Compliance: Meeting the Regulatory Floor
IT compliance ensures systems, data handling, and security controls meet applicable legal and regulatory requirements. Key examples:
- HIPAA Security Rule — electronic protected health information for healthcare organizations
- PCI DSS v4.x — payment card data for any organization that stores, processes, or transmits cardholder data
- SOX IT controls — internal controls over financial reporting for public companies
- SEC cybersecurity disclosure rules — material incident reporting and annual governance disclosures for public registrants
Compliance is a floor, not a ceiling. A mature IT GRC framework embeds compliance into governance rather than bolting it on as a separate function. The goal is a single, inspectable system: governance sets policy, risk management surfaces what could go wrong, and compliance confirms the minimum bar is cleared.
Common IT GRC Frameworks and Standards
Common IT GRC Frameworks and Standards
No single framework covers every dimension of IT GRC. Most organizations layer two or three based on their industry, geography, and risk profile.
The Core Frameworks
| Framework | Best Used For |
|---|---|
| COBIT 2019 | IT governance and management alignment across the enterprise |
| NIST CSF 2.0 | Cybersecurity risk management; the 2024 version added a Govern function |
| ISO/IEC 27001:2022 | Certifiable information security management systems |
COBIT (published by ISACA) is the right starting point when the board needs clear decision rights over IT — who approves what, and how IT choices connect to business outcomes. Organizations often adopt it first when governance accountability is the gap, not security controls.
NIST CSF 2.0 added a Govern function in its 2024 update, which is significant: it formally positions cybersecurity as a board-level risk discipline, not just a technical program. The six functions — Govern, Identify, Protect, Detect, Respond, and Recover — give executives a language for oversight that doesn't require deep technical fluency.
ISO/IEC 27001:2022 matters most when an organization needs external proof of security rigor — for customers, regulators, or acquisition due diligence. Certification requires a third-party audit, which makes it more demanding to pursue but more credible as evidence.
Industry-Specific Compliance Standards
Regulated industries must map multiple frameworks simultaneously:
- SOX IT controls — public companies need PCAOB-aligned internal controls over financial reporting
- HIPAA Security Rule — administrative, physical, and technical safeguards for ePHI; HHS proposed significant updates on December 27, 2024
- PCI DSS v4.x — 51 of 64 new v4.0 requirements became effective March 31, 2025
The goal is not framework compliance itself. Frameworks are a starting point — a shared vocabulary for identifying gaps, not a finish line. A healthcare organization, for example, might run NIST CSF as its primary risk structure, ISO 27001 for its security management system, and HIPAA as its compliance baseline simultaneously — all mapped to a single control library to avoid duplicating effort.
How to Build an IT GRC Framework
Building a functional IT GRC program requires five sequential steps. The sequence matters because organizations that jump to frameworks before clarifying scope and decision rights end up with documentation that doesn't reflect how decisions actually get made.
Step 1: Assess Current State
Inventory existing policies, controls, risk assessments, and compliance activities. Identify where governance is undefined, where risks are untracked, and where compliance is managed reactively.
Look specifically for these warning signs:
- Risk exceptions approved by email, with no expiry date
- Projects that go live without a documented security sign-off path
- Third-party risk with no single accountable owner
- Incident severity levels that exist on paper but no agreement on who declares them
This assessment produces the baseline — everything built after it depends on what you find here.
Step 2: Define Scope and Objectives
Align the IT GRC program to the organization's business strategy, risk appetite, and applicable regulatory requirements. Determine which business units, systems, and geographies are in scope.
Risk appetite needs to be specific and measurable — not a policy statement. Examples: "Our customer portal must be restored within 6 hours." "We accept up to $50,000 in confirmed fraud loss per quarter." Without defined thresholds, management has no way to know when to escalate.
Executive sponsorship at this stage is not optional. Without it, frameworks remain theoretical.
Step 3: Establish Governance Structures and Decision Rights
Clarify who has authority over technology risk decisions, what requires board-level visibility, and what thresholds trigger escalation. Every governance, risk, and compliance domain needs a named owner.
At minimum, document decision authority for:
- Risk acceptance (what thresholds require CEO, General Counsel, or board awareness)
- Policy exceptions (who grants them, for how long, with what compensating controls)
- Incident escalation (who declares severity, who notifies counsel and insurer)
- Budget tradeoffs within approved guardrails
This is where most programs break down. When an incident occurs, the absence of documented decision rights creates paralysis. Teams spend hours negotiating authority instead of containing damage.
Step 4: Map Risks to Controls and Compliance Requirements
Build a risk register that links identified risks to the controls designed to address them and the regulatory requirements they satisfy. This mapping eliminates redundant controls and highlights genuine gaps.
Avoid control sprawl. More controls are not better governance. A well-mapped framework shows which controls address which risks, which requirements they satisfy, and who owns them — nothing more.
Step 5: Establish Monitoring, Metrics, and Reporting Cadence
Define KRIs and KPIs that show trends over time. Five core metrics for board-level reporting:
- Top material risk scenarios — ranked, with movement over time
- Time to contain and recover — measured in business impact, not technical terms
- Critical control coverage — MFA on privileged access, EDR on key servers, patch SLAs
- Security debt burn-down — size, age, and closure rate of known gaps
- Third-party exposure — percent of critical vendors with current risk reviews
Set a reporting cadence: weekly executive checkpoint (30 minutes), monthly board or committee summary (one page), quarterly full governance review. Boards need trend intelligence and clear decisions — not compliance checklists.
A note on organizations without dedicated IT governance leadership: Building a GRC framework from scratch requires experienced leadership that most organizations don't have on hand during the moments they need it most.
Organizations navigating a CISO vacancy, M&A, post-incident recovery, or a technology transformation often bring in an interim or fractional CISO to design the framework, establish decision rights, and build the internal capability to sustain it. Tyson Martin works with boards and executive teams in exactly these situations. The typical engagement follows a 30-60-90 day structure: assess and stabilize in the first month, establish governance and reporting in the second, and hand off an inspectable, defensible program by day 90.
Common IT GRC Challenges and How to Overcome Them
Siloed Risk and Compliance Efforts
When governance, risk, and compliance teams operate independently, organizations end up with redundant controls, inconsistent risk ratings, and no unified view of exposure. The fix requires shared risk taxonomies, a centralized risk register, and cross-functional ownership models where business units own risk within their domain rather than pushing it entirely to IT or security.
Decentralized execution with central visibility means pushing control ownership to business units while maintaining oversight through consistent reporting. This avoids the bottlenecks of over-centralization without losing accountability.
Reporting That Generates Noise Instead of Signal
Boards regularly receive dense compliance reports that document activity without conveying risk posture. Effective IT GRC reporting looks different:
- Plain-language risk summary, not technical findings
- What changed since the last briefing
- Decisions required from the board
- A stable dashboard showing trend lines over 3-4 quarters — not point-in-time snapshots
Traffic-light status indicators without agreed thresholds create false calm. If a metric can't trigger a decision, it's probably noise.
Unclear Accountability and Decision Rights
When an incident occurs, organizations frequently discover that nobody owns the escalation threshold or the decision. The gaps show up in predictable places:
- Missing or outdated contacts in the incident response plan
- No clear authority over who can take systems offline
- Untested assumptions about when and how to notify vendors
- Escalation paths that exist on paper but were never walked through
The remedy is pre-defining escalation paths — amber triggers for worsening trends, red triggers for threshold breaches — and testing those paths before an incident demands them. As Tyson Martin puts it, the two worst words in incident response are "we assumed."
Keeping Pace with Regulatory Change
The regulatory landscape shifted substantially between 2023 and 2025. Key changes organizations are navigating now:
- SEC cybersecurity disclosure rules require public companies to report material incidents within four business days and disclose governance processes annually under Item 106 of Form 10-K
- CPRA and Virginia's Consumer Data Protection Act took effect January 1, 2023
- HHS proposed significant HIPAA Security Rule updates in December 2024
Manual tracking of regulatory change is unsustainable. A mature IT GRC framework treats regulatory monitoring as a standing function — assigning ownership, setting review cadences, and mapping new requirements to existing controls before an enforcement action forces the issue.
IT GRC Roles and Decision Rights: Who Owns What
| Role | Primary IT GRC Accountability |
|---|---|
| CISO | Operational cyber risk, security compliance, incident response |
| CIO | IT governance, technology risk, infrastructure decisions |
| Board / Audit Committee | Oversight, risk appetite approval, accountability for management |
| General Counsel | Regulatory obligations, disclosure decisions, legal exposure |
| Business Unit Leaders | Risk ownership within their domain |
In many mid-market organizations, these roles overlap or are unfilled. Security ownership fragments across IT, legal, product, and risk — with nobody who can break ties. ISC2's 2024 workforce study found 67% of organizations reported cybersecurity staffing shortages and 90% identified skills gaps on their security teams. The governance risk this creates is not just operational — it becomes visible to boards, regulators, and enterprise buyers.
The Board Oversight vs. Management Execution Distinction
Boards should not be managing IT risk — they should be overseeing it. The distinction matters:
- Board approves: Risk appetite, escalation thresholds, exceptions above materiality thresholds, incident disclosure decisions
- Management executes: Day-to-day controls, vendor management, policy enforcement, operational incident response
Unclear boundaries between these two functions are among the most common governance failures identified in post-incident reviews. Both Blackbaud and R.R. Donnelley demonstrated what happens when disclosure decisions lack clear ownership — the controls existed, but nobody was accountable for connecting the information to the decision.
The Translation Function
That accountability gap points directly to a function most organizations underinvest in: translation. Someone must convert technical IT and cyber risk into language boards and executives can act on. This is not a communications task — it's a governance function.
Effective translation connects risk findings to four business outcomes:
- Financial loss exposure
- Operational disruption potential
- Legal and regulatory liability
- Reputational harm
Whether that person is a CISO, a board advisor, or an interim executive, the job is the same: fewer surprises for the board, faster escalation when it matters, and decisions that hold up under scrutiny.
What Effective IT GRC Looks Like at the Board Level
According to NACD's 2024 survey, 66% of public company boards discuss technology items at every board meeting. CAQ's 2024 audit committee report found cybersecurity was a top concern for 69% of respondents — with 3 in 10 ranking it their number one priority.
Frequency of discussion, however, is not the same as effective oversight. A board that reviews compliance checklists every quarter is not necessarily governing IT risk well.
Mature board-level IT GRC oversight has four characteristics:
- Regular, plain-language risk briefings — what's changed, what it means, what management is doing, and what the board needs to decide
- A stable dashboard — 8 to 12 metrics, consistent over time, showing trend lines across 3-4 quarters
- Clear separation of decisions — what requires board action vs. what is delegated to management
- Pre-tested escalation thresholds — amber and red triggers that activate before a crisis, not during one
What "Inspectable Execution" Means in Practice
Every priority in the IT GRC program has a named owner, a measurable outcome, and a due date. Leadership can verify progress in a 10-minute monthly review without requesting a special report.
That's the practical difference between a GRC program that exists on paper and one that actually reduces risk:
- 30-day milestone: produces a risk narrative and a top-five risk list
- 60-day milestone: establishes repeatable governance structures
- 90-day milestone: delivers stable reporting and tested escalation paths
Tyson Martin works with boards and executive teams navigating leadership transitions, post-incident recovery, and regulatory scrutiny to build this kind of governance posture. That means clarifying decision rights, establishing credible board reporting, and creating IT GRC frameworks that hold when real incidents test them.
Frequently Asked Questions
What are the 5 principles of IT governance?
COBIT 5 defines five governance principles: meeting stakeholder needs, covering the enterprise end-to-end, applying a single integrated framework, enabling a holistic approach, and separating governance from management. These principles remain relevant in COBIT 2019, which builds on and extends them.
What are the 4 modules of SAP GRC?
The four core SAP GRC modules are:
- Access Control — detects and prevents access risk violations
- Process Control — monitors internal controls and compliance
- Risk Management — assesses how risk drivers impact business value
- Audit Management — automates internal audit procedures and improves audit quality
What is the difference between IT governance and IT GRC?
IT governance is one component of IT GRC — it defines the oversight structure and decision rights for technology. IT GRC integrates governance with risk management and compliance into a unified operating framework where all three disciplines connect and inform each other.
What frameworks are most commonly used for IT GRC?
The most widely adopted are COBIT for IT governance, NIST CSF 2.0 for cybersecurity risk management, and ISO 27001 for information security management systems. Regulated industries layer in HIPAA, PCI DSS, and SOX IT controls depending on their sector and applicable requirements.
How does a board effectively oversee IT GRC?
Effective board oversight requires plain-language risk briefings, pre-defined escalation thresholds, clear decision rights, and a reporting cadence that shows risk trend over time. The board sets risk appetite and approves material exceptions; management executes and reports back against those thresholds.
