Governance, risk, and compliance is not a department and not a product, however many vendors sell it as the second. It is the answer to a coordination problem that every organization above a few hundred people has: the board, the risk function, compliance, legal, IT security, internal audit, and the business units each keep their own list of risks, controls, obligations, and issues, in their own tools and their own words, and nobody can say what the organization’s total exposure is or how much of it has been tested by whom. A GRC framework is the set of structures, shared definitions, and processes that make those lists one picture. Where it works, the audit committee sees one issue log, one risk taxonomy, and one map of who gives assurance over what. Where it fails, the organization has bought a platform, loaded four inconsistent registers into it, and called the result integration.
This guide gives you the framework as something you can build or assess: the components with their owners and artifacts, the operating model as a three-lines RACI, assurance mapping as the practical core, the compliance obligations register, a technology selection method that avoids the integration trap, a phased implementation roadmap, a maturity model, the differences between financial services and everyone else, and internal audit’s role in assessing all of it. It was rewritten in September 2026 to reflect the Global Internal Audit Standards and the Three Lines Model, and it connects to the site’s guides on internal audit’s role in ERM and compliance risk, which cover two of the three letters in depth.
In this guide
- What GRC is, and what it is not
- The components: purpose, owner, artifact, maturity indicators
- The operating model: a three-lines RACI
- Assurance mapping: the practical core
- The compliance obligations register
- Technology: selection criteria and the integration trap
- Implementation roadmap
- A GRC maturity model
- Financial services versus everyone else
- Internal audit’s role: assessing GRC
- Common failures
What GRC is, and what it is not
Governance is how the organization is directed and held to account: the board, its committees, delegated authorities, policies, and the reporting that lets the board know what is happening. Risk is the identification, assessment, and treatment of uncertainty against objectives, which the ERM framework organizes. Compliance is the identification of obligations (laws, regulations, contracts, standards, the organization’s own policies) and the controls and monitoring that keep the organization within them. Each of the three has a discipline, a profession, and usually a department. GRC is the integration layer: a shared taxonomy so that a risk, a control, an obligation, and an issue mean the same thing in every list; shared processes for assessment, testing, issue management, and reporting; and a shared operating model that says which line does what. The word was popularized by OCEG’s Capability Model in the 2000s, and its useful content survives the vendor marketing: GRC is the capability to reliably achieve objectives, address uncertainty, and act with integrity, integrated across functions.
Three things it is not. It is not a tool; a platform can hold the integrated picture but cannot create the definitions and the operating model that make integration real, and most failed GRC programs are platforms bought before either existed. It is not a merger of the risk, compliance, and audit functions; the Three Lines Model keeps them apart for a reason, and integration is about shared language and shared data, not shared reporting lines. And it is not internal audit’s to own: the third line assesses the framework and uses its outputs, and a function that builds the GRC program has the same independence problem as one that runs ERM.
The components: purpose, owner, artifact, maturity indicators
| Component | Purpose | Owner | Key artifact | Indicators of maturity |
|---|---|---|---|---|
| Governance structures | Board and committee oversight with defined delegated authorities and escalation paths | Board; corporate secretary | Committee charters; delegation of authority matrix; escalation policy | Charters reviewed annually; DoA enforced in systems; escalations minuted with decisions |
| Shared taxonomy | One set of definitions for risk categories, control types, obligation types, issue ratings, and business units | Second line (risk), agreed with compliance and audit | Taxonomy document with mappings to each function’s legacy categories | Every register uses it; new entries validated against it; changes governed |
| Risk management (ERM) | Identify, assess, treat, and report risk against appetite | CRO or equivalent | Risk register; appetite statement; KRIs | See the ERM maturity rubric in the ERM guide |
| Policy management | Policies and standards that are current, owned, approved, communicated, and attested | Compliance or corporate secretary | Policy inventory with owners, review dates, and attestation records | No policy past its review date; attestation rates above 95 percent; policies linked to obligations and controls |
| Control framework | One inventory of controls linked to risks and obligations, with owners, frequency, and test results | Second line with process owners | Risk-control matrix; control inventory; see the RCM template | Every key control has a last test date; controls are shared across SOX, compliance, and operational programs rather than duplicated |
| Compliance obligations register | Every applicable law, regulation, contract term, and standard mapped to an owner, a control, and a monitoring activity | Compliance | Obligations register (below) | Register reconciled to regulatory change feed; each obligation has a control; monitoring evidenced |
| Issue management | Findings from all sources tracked in one log to validated closure | Second line, with audit’s own rows governed by audit | Single issue log; see the issue log template | One log; aging from original dates; audit closes its own; committee sees one number |
| Assurance mapping | For each key risk and obligation, who provides assurance, how, and when, across all lines | Internal audit coordinates; each provider owns its column | Assurance map (below) | Map refreshed with the audit plan; gaps and duplications reported; reliance decisions recorded |
| Monitoring and testing | Second-line testing of controls and compliance, coordinated with audit | Second line | Test plans and results in the shared inventory | Results visible to audit; audit relies where quality allows and says so |
| Reporting | Integrated board reporting: risk profile, compliance status, open issues, assurance coverage | Second line, with audit’s section | Board risk and compliance report | One pack, exception-based, decisions minuted |
The operating model: a three-lines RACI
The operating model says who is responsible, accountable, consulted, and informed for each GRC activity. The version below is the one most organizations should start from; the arguments it settles are the ones that otherwise recur every quarter, especially over who owns the control inventory and who may close an issue. R is responsible for doing, A is accountable for the outcome, C is consulted, I is informed.
| Activity | Board / audit committee | First line (business) | Second line (risk, compliance) | Third line (internal audit) |
|---|---|---|---|---|
| Set risk appetite | A | C | R | C |
| Maintain the taxonomy | I | C | A / R | C |
| Identify and assess risks (RCSA) | I | A / R | R (challenge) | I |
| Own and operate controls | I | A / R | C | I |
| Maintain the control inventory | I | R (their controls) | A | C |
| Maintain the obligations register | I | C | A / R | C |
| Test controls (second-line testing) | I | C | A / R | I (relies where justified) |
| Provide independent assurance | A (receives) | I | I | R |
| Track and close issues | I | R (remediate) | A (log); R (validate second-line issues) | R (validate its own issues); A for its rows |
| Maintain the assurance map | I | C | C | A / R (coordination) |
| Integrated board reporting | A (receives and decides) | I | R | R (its own section) |
Two cells carry most of the value. Internal audit coordinates the assurance map because it is the only function that reads every other function’s assurance, but it does not own the others’ columns. And issue closure is split: the second line closes second-line issues and audit closes its own, so that the “one log” principle does not become “the second line closes audit findings.” The Domain III guide covers the Standards’ independence requirements behind that split.
Assurance mapping: the practical core
If an organization builds one GRC artifact, it should be the assurance map, because it is the one that answers the audit committee’s real question: for each thing that could seriously hurt us, who has looked, how hard, and how recently? The map lists the key risks and major obligations down the side and the assurance providers across the top, and each cell records the nature of the assurance (management self-assessment, second-line testing, internal audit engagement, external audit, regulator examination, certification), its date, and its result. Gaps show where nobody has looked; duplications show where three functions tested the same control in the same quarter. The example below is for a mid-size manufacturer with a compliance function, an IT security team, and a four-person internal audit function.
| Risk or obligation | First line | Second line | Internal audit | External | Assessment |
|---|---|---|---|---|---|
| Financial reporting accuracy (SOX 404) | Control owners’ quarterly certifications | SOX team tests 180 key controls annually | Relies on SOX testing after re-performing 20 percent; audits ITGCs directly | External auditor’s ICFR opinion | Adequate; duplication removed by reliance |
| Cybersecurity | IT security’s control operation | IT security tests its own controls (not independent) | Cybersecurity program audit FY26; next FY28 | Penetration test annually; ISO 27001 certification audit | Second-line independence gap: IT security tests itself; audit frequency raised to annual for the highest-risk controls |
| Environmental permits and reporting | Plant managers’ monthly compliance checklists | Compliance reviews checklists quarterly | Never audited | Regulator inspections at two of six plants | Gap: no independent assurance; added to the FY27 plan |
| Product safety and recalls | Quality function’s inspections | Quality assurance audits of plants | Never audited | Customer audits; certification body | Adequate coverage by quality and external; audit to review the quality function’s own effectiveness in FY28 |
| Anti-bribery and third-party conduct | Business owners’ due-diligence forms | Compliance screens third parties; annual training | Third-party engagement FY25 (Medium findings, closed) | None | Adequate; the Third-Party Topical Requirement now requires coverage to be evidenced |
| Data privacy | Process owners’ data inventories | Privacy officer’s assessments | Never audited | None | Gap: privacy officer is part-time and reports to IT; independence and coverage both thin; added to the plan |
| Key vendor concentration | Procurement’s vendor scorecards | None | Procurement audit FY26 covered contracting, not concentration | None | Gap: no one assesses dependency on the top five vendors; scoped into the FY27 third-party engagement |
Maintaining the map is a coordination task, not a testing one: internal audit asks each provider for its plan and results twice a year and records them, and the assessment column is the CAE’s judgment. The map feeds the annual audit plan directly, which is where the gaps become engagements, and it feeds reliance decisions, which the Standards permit where the other provider’s work is competent and objective and where audit has evaluated it. A map with no gaps and no duplications has probably not been filled in honestly.
The compliance obligations register
The obligations register is compliance’s equivalent of the risk register, and in most organizations it does not exist as a single artifact: the obligations live in the heads of the lawyers, the compliance officers, the plant managers, and the tax team, and the organization discovers an obligation when it is fined for missing it. The register lists every applicable obligation with its source, the requirement in plain language, the business owner, the control that meets it, the monitoring that confirms the control, the regulatory change feed that keeps the entry current, and the consequence of breach. Its fields are the link into the rest of the framework: the control column points into the control inventory, the owner column into the governance structure, and the monitoring column into the assurance map.
| Field | Definition | Example entry |
|---|---|---|
| Obligation ID and source | The law, regulation, contract, standard, or policy, with citation | OBL-114: Fair Labor Standards Act, overtime for non-exempt employees, 29 U.S.C. 207 |
| Requirement in plain language | What the organization must do, in one or two sentences a manager can act on | Pay non-exempt employees 1.5 times their regular rate for hours over 40 in a workweek; classify roles correctly |
| Applicability | Which entities, locations, and processes it applies to | All US entities; payroll; HR classification |
| Business owner | The named executive accountable for compliance | VP Human Resources |
| Controls | The control inventory IDs that meet the obligation | PAY-07 (system overtime calculation), HR-12 (annual classification review) |
| Monitoring | The second-line or first-line activity that confirms the controls operate, and its frequency | Compliance samples 25 overtime calculations quarterly; the payroll analytics overtime outlier test runs monthly |
| Assurance | Internal audit or external coverage and date | Payroll audit FY26; external auditor’s payroll substantive work |
| Regulatory change source | How the entry is kept current | Employment counsel’s quarterly update; DOL rule tracker |
| Consequence of breach | Financial, regulatory, and reputational consequence, to size the risk | Back pay and liquidated damages; class action exposure; DOL investigation |
| Rating and last review | Inherent rating, residual rating, date reviewed | High inherent; Medium residual; reviewed March 2026 |
Internal audit’s test of the register is completeness first: compare it with the regulatory correspondence file, the legal function’s matter list, the licenses and permits the organization holds, and the contracts with compliance clauses, and list what the register lacks. The compliance risk guide covers how the register drives a compliance risk assessment, and the financial services guide the regulated-industry version, where the register runs to thousands of entries and the regulatory change feed is a function in itself.
Technology: selection criteria and the integration trap
A GRC platform is worth buying when the taxonomy exists, the operating model is agreed, and at least two functions are ready to put their registers into it under the shared definitions. Bought earlier, it becomes the integration trap: each function loads its legacy register into its own module, the modules do not share a data model, and the organization has spent a seven-figure sum to move its silos into one login. The selection criteria below are ordered by how often their absence causes the trap.
| Criterion | What to test in the evaluation | Why it matters |
|---|---|---|
| One data model across modules | Create a risk, link a control, link an obligation, raise an issue, and run a report that shows all four on one row; do it in the demo, on your taxonomy | Separate data models per module reproduce the silos |
| Configurable taxonomy without code | Load your categories, ratings, and statuses; change one and see where it propagates | A tool that imposes its taxonomy becomes the taxonomy |
| Issue workflow with role-based closure | Confirm that only designated roles can set closure statuses, that original due dates are immutable, and that changes are logged | The issue log rules must be enforceable |
| Control inventory shared across programs | One control tested once with results visible to SOX, compliance, and audit | Removes triple testing of the same control |
| Assurance map or coverage reporting | A report of risks by assurance provider and date | The artifact that justifies the purchase |
| Regulatory content and change feeds | Coverage of your jurisdictions and industries; how changes reach the obligations register | Empty content means the register is built by hand |
| Reporting and extract | Board-pack outputs configurable by your team; full data export in an open format | Reports built by the vendor’s consultants are reports you cannot change |
| Access, audit trail, and segregation | Role design, immutable logs, and the ability for audit to see everything and edit only its own | The platform is itself a control environment |
| Integration with source systems | Connectors for the ERP, HR, ticketing, and identity systems that feed KRIs and testing | Manual re-keying kills monitoring within a year |
| Total cost over five years | License, implementation, content subscriptions, internal administration, and the consultants nobody budgeted | Implementation typically costs one to two times the license |
An organization that is not ready for a platform can run the framework on well-governed spreadsheets and a document repository for years: the taxonomy is a document, the registers share a column structure, the issue log follows the four-sheet build in the issue log template, and the assurance map is a table refreshed twice a year. The platform then becomes a migration of working processes rather than a search for them.
Implementation roadmap
| Phase | Months | Work | Milestone | Pitfall |
|---|---|---|---|---|
| 1. Mandate and inventory | 1–2 | Board or executive mandate naming the accountable executive; inventory of every existing register, tool, taxonomy, and reporting line across risk, compliance, legal, IT security, and audit | Inventory document; sponsor named | Starting with a vendor selection instead of an inventory |
| 2. Taxonomy and operating model | 2–5 | Agree the shared taxonomy with mappings from each legacy set; agree the RACI; agree the issue log rules and the single issue log | Taxonomy v1 signed by risk, compliance, and audit; RACI approved | Letting the loudest function’s taxonomy win without mapping the others |
| 3. Registers under the taxonomy | 4–8 | Rebuild the risk register, control inventory, and obligations register in the shared structure; merge issue logs; retire duplicates | One control inventory; one issue log; obligations register v1 | Migrating legacy entries without cleaning them; duplicates survive in the new structure |
| 4. Assurance map and reporting | 7–10 | Build the assurance map from the registers and each provider’s plan; design the integrated board pack; run the first integrated report | First integrated board report with gaps and decisions | A forty-page pack that reports everything and asks nothing |
| 5. Technology | 9–18 | Select and implement a platform against the criteria above, migrating the working registers; integrate source systems for KRIs and testing | Platform live with one data model; spreadsheets retired | Implementation consultants configuring the tool to their template rather than your taxonomy |
| 6. Monitoring and continuous improvement | 12+ | Second-line testing on the shared inventory; regulatory change feeding the register; annual maturity assessment; audit assesses the framework in year two | Maturity profile with movement; audit’s assessment | Declaring completion; GRC is an operating capability, not a project |
A GRC maturity model
| Level | Description | Observable facts |
|---|---|---|
| 1 Fragmented | Each function keeps its own lists in its own words; the board receives separate reports | Three or more issue logs; no shared taxonomy; risks described differently by risk and compliance |
| 2 Coordinated | Functions meet and reconcile periodically; reporting is assembled by hand | A quarterly reconciliation of issue logs; an informal assurance map in the CAE’s files |
| 3 Integrated | Shared taxonomy, single issue log, shared control inventory, assurance map maintained; integrated board pack | The artifacts exist under one structure; reliance decisions recorded; gaps drive the audit plan |
| 4 Managed | Second-line testing and audit coordinated on the shared inventory; regulatory change feeds the register; KRIs from source systems | Testing results visible across lines; obligations current within 30 days of change; monitoring automated for major risks |
| 5 Embedded | GRC information changes decisions: strategy, budget, product, and vendor choices show risk and compliance analysis; incentives are risk-adjusted | Decision papers carry the analysis; the use test passes; board challenges the profile |
Most organizations that describe themselves as “having GRC” are at level 2 with a platform, which is level 2 with a login. Level 3 is the goal for the first eighteen months, and it is reachable without buying anything.
Financial services versus everyone else
In a bank or insurer the second line is mandated, the obligations register runs to thousands of entries with a regulatory change function behind it, examiners expect to see an assurance framework and test the independence of each line, and the integrated report goes to a board risk committee that regulators require to exist above a certain size. The GRC problem there is scale and consistency across many mandated programs (BSA/AML, consumer compliance, model risk, operational resilience, third-party risk, each with its own regulatory expectations), and the pitfall is thirty programs with thirty issue logs; the operational risk guide shows how one of those programs is structured and audited. Outside financial services the second line often does not exist as a function, compliance sits in legal, and the GRC problem is that the framework has to be built by people with other jobs. The components are the same and the sequence is the same; what changes is that the accountable executive is usually the CFO or general counsel, the taxonomy is smaller, and the assurance map is the artifact that persuades the board to fund the rest, because it shows in one page what nobody has looked at.
Internal audit’s role: assessing GRC
Internal audit uses the GRC framework every day, coordinating the assurance map and drawing on the shared inventory, and it assesses the framework periodically as it would any other governance process. The two roles need the same separation the ERM roles table describes: coordinating the map is a core role; designing the taxonomy or selecting the platform is advisory, with safeguards and a cooling-off period before the framework is assessed. The assessment program below runs 150 to 250 hours and produces the maturity level with its evidence and findings on the components.
| # | Objective | Procedure | Evidence |
|---|---|---|---|
| 1 | The framework has a mandate and an accountable owner | Inspect the mandate, the owner’s role description, and the governance forum’s charter and minutes | Mandate; charters; minutes |
| 2 | One taxonomy is used across functions | Sample 25 entries from each register and test category use; test the change process for the taxonomy | Registers; taxonomy change log |
| 3 | The control inventory is single and shared | Count controls tested by more than one program in the period; test 25 controls for owner, frequency, last test, and linkage to risks and obligations | Control inventory; test records |
| 4 | The obligations register is complete and current | Compare with regulatory correspondence, licenses, legal matters, and contracts; test 25 entries for owner, control, monitoring, and last review; test the change feed for three recent changes | Register; correspondence; change records |
| 5 | Issue management follows the rules | Confirm a single log or reconciled logs; recompute aging from original dates; test 25 closures for validation evidence and closure authority | Issue log; closure evidence |
| 6 | The assurance map is real and used | Reconcile the map to each provider’s plan and results; trace three gaps to plan responses; test three reliance decisions for the evaluation behind them | Assurance map; plans; reliance memos |
| 7 | Policy management operates | Test 25 policies for review date, owner, approval, and attestation rates | Policy inventory; attestation records |
| 8 | Integrated reporting produces decisions | Inspect four integrated board packs; trace five exceptions to minuted decisions; test three reported metrics to source | Packs; minutes; source data |
| 9 | The platform, if any, is controlled | Test access roles, closure permissions, audit trail, and the data model claim (one row across modules); see the ITGC primer | Platform configuration; access listings |
| 10 | Maturity and use | Score the maturity model with evidence; identify three decisions changed by GRC information in the year | Maturity workpaper; decision papers |
Worked example: getting to level 3 without a platform
MidState Beverage, the site’s running example, is a three-state distributor with 12 depots, two unintegrated acquisitions, a lean finance team, no second-line risk function, and a six-person internal audit function. Its FY27 ERM assessment scored governance and identification at level 2 and appetite at level 1, and the CAE’s report to the audit committee proposed a GRC build to level 3 in twelve months, owned by the CFO, with internal audit advising under safeguards. The phase 1 inventory found four lists that had never met: the controller’s risk register (31 risks, high/medium/low), the SOX-readiness control list built for the lenders (140 controls, in a spreadsheet, tested by the controller’s own team), the fleet manager’s DOT compliance tracker (48 obligations, none linked to a control), and IT security’s findings list (nine open items, in a ticketing tool). Internal audit’s own issue log held 14 open actions from FY26 and 11 from the route cash report. Nobody could say how many open issues the company had, and the board’s annual risk presentation drew on the first list only.
| Component | Before | After twelve months |
|---|---|---|
| Taxonomy | Four vocabularies; “IT risk” meant three different things | One taxonomy of 9 risk categories, 4 control types, 5 obligation sources, and the issue log’s status set; mapping tables kept for two years |
| Risk register | 31 risks, ratings unchanged for three years | 38 risks under the taxonomy, including integration and ERP replacement; criteria-based ratings; quarterly refresh by the executive team |
| Control inventory | 140 SOX-readiness controls in one spreadsheet; depot and fleet controls undocumented | 212 controls in one inventory linked to risks and obligations; 61 tested by the controller’s team, 40 by internal audit, with results visible to both; 18 duplicates retired |
| Obligations register | Fleet tracker only | 164 obligations across employment, fleet and DOT, alcohol distribution licensing, tax, environmental, and lender covenants; each with an owner and a control; counsel’s quarterly update as the change feed |
| Issue log | Three lists plus audit’s; 34 open items known to audit, 43 in total once merged | One log, 43 rows at merge, 27 at year-end; audit closes its own; original due dates restored from the source reports |
| Assurance map | None | Top 12 risks mapped; three gaps (fleet, privacy, acquisition systems) became FY28 engagements; external audit reliance on the SOX-readiness testing recorded |
| Reporting | Annual risk list to the board; separate audit and IT reports | Quarterly integrated report of eight pages: profile changes, appetite metrics, open issues by age, assurance gaps, decisions requested |
The build cost the company one part-time coordinator in the CFO’s office, about 300 hours of internal audit advisory time, and no software. The platform question was deferred to FY29 with a criteria list ready and the registers already in the shape a platform would want. Internal audit’s FY29 plan carries the framework assessment, a full cycle after its advisory role ended, with the disclosure in the charter.
Common failures
| Failure | What it looks like | Why it matters | Fix |
|---|---|---|---|
| Platform first | A tool bought before the taxonomy and operating model exist | Silos migrated into modules; integration never happens | Phases 1 to 4 before phase 5; the platform migrates working processes |
| Taxonomy by conquest | The risk function’s categories imposed on compliance and audit without mapping | The other functions keep shadow registers in their own words | Mapping tables for every legacy set; joint sign-off |
| Three issue logs | Audit, compliance, and risk each report open items; the committee adds them up | Nobody knows the total; aging rules differ; closures are inconsistent | Single log with role-based closure, or a governed reconciliation with one aging rule |
| Triple testing | SOX, compliance, and audit each test the same reconciliation control in the same quarter | Cost, auditee fatigue, and no one relying on anyone | Shared control inventory with visible results; documented reliance |
| Assurance map as decoration | A map built once for a board paper and never refreshed | Gaps reopen silently | Refreshed with the audit plan and at mid-year; gaps reported with responses |
| Register without a change feed | Obligations register complete on the day it was built and stale within a year | Compliance breaches from obligations nobody updated | Named change sources per obligation; quarterly currency check |
| Audit owns GRC | Internal audit designs the framework, runs the platform, and then assesses it | Independence lost; the third line becomes the second | Advisory with safeguards; management owns; cooling-off before assessment |
| Reporting everything | Integrated pack of sixty pages, every risk green, no decision requested | The board stops reading | Exception-based reporting; every exception carries a decision request |
The framework’s other components each have their own guide on the site: the risk register, the RCSA process, risk appetite, and the issue log; the Risk Library indexes the risk-stripe guides the assurance map points at, and every guide on the site is listed at All Guides.
Related guides
- Internal audit’s role in ERM — the roles table and the maturity rubric for the R
- Compliance risk — the C in depth
- GIAS Domain III: governing — independence and board oversight of the third line
- The issue log template — the single log’s fields and rules
- The risk-control matrix template — the control inventory’s structure
- The risk register — the ERM component’s core artifact
- The annual audit plan template — where assurance-map gaps become engagements
- Internal audit in financial services — GRC at regulated scale
- Operational risk — one mandated program, structured and audited
- Internal Audit vs SOX vs Compliance vs ERM: Who Does What — the four functions separated by mandate, reporting line and output
- Compliance Risk Assessment: Method, Scoring, Worked Example — obligations inventory, exposure scoring and prioritization that regulators accept
Leave a Reply