Data governance for GRC teams: lineage, ownership and evidence
Data governance for GRC teams: ownership, lineage and evidence, with the records GDPR Article 30, EU AI Act Article 10, NIST and BCBS 239 expect.
A data governance framework for a GRC team answers three questions about every data set the program relies on. Who owns it? Where did it come from and where does it go? What record proves the controls operate? Regulators test all three, from GDPR Article 30 records to EU AI Act Article 10 training-data practices.
A data governance framework for a GRC team answers three questions about every data set the program relies on. Who owns it? Where did it come from and where does it go? What record proves the controls operate? Regulators test all three, from GDPR Article 30 records to EU AI Act Article 10 training-data practices.
Why data governance sits inside GRC, not beside it
Data governance started as a data management discipline. DAMA International describes the DAMA-DMBOK as 11 knowledge areas with data governance at the center, and defines governance as the work that "establishes accountability, policies, and decision rights to ensure data is managed properly" (DAMA). ISO/IEC 38505-1:2026 places it in the governance hierarchy: the governance of data is a domain of the governance of IT, which is itself a domain of corporate governance (ISO).
For a GRC team the pull is regulatory. GDPR Article 5(2) makes the controller "responsible for, and able to demonstrate compliance with" the six processing principles (EUR-Lex). You cannot demonstrate purpose limitation, accuracy or storage limitation without knowing which data you hold, who answers for it and how it moves. The same logic now reaches AI systems and bank risk data. Data governance is therefore a control domain, and the GRC team needs its own view of it, built on the three parts below.
Ownership: one accountable person per data set
Ownership is the first thing an auditor or supervisor asks about, because every other control hangs off it. Three primary sources describe the role in similar terms.
- BCBS 239 Principle 2 asks banks to set "roles and responsibilities ... as they relate to the ownership and quality of risk data" for both business and IT functions, with owners ensuring data is "correctly entered ... kept current and aligned with the data definitions" (BIS, paragraph 34).
- The NIST Privacy Framework 1.0 subcategory ID.IM-P2 inventories "owners or operators" of every system that processes data, and GV.PO-P3 and P4 establish privacy roles for the workforce and align them with third parties (NIST).
- GDPR Article 30(1)(a) starts the record of processing with the name and contact details of the controller, any joint controller, the representative and the data protection officer (EUR-Lex).
In practice the GRC team keeps an ownership register with one named owner per data set, the steward who maintains definitions and quality, and the system owner who runs the platform it lives in. Those are three different people more often than not; our guide to data owners, system owners and process owners sets out the split.
Lineage: where the data came from and where it goes
Lineage is the documented path of a data set from source to use. Regulators do not usually say "lineage", but they describe it.
NIST ID.IM-P8 asks that "data processing is mapped, illustrating the data actions and associated data elements" for each system, including component owners and third-party interactions (NIST). EU AI Act Article 10(2) requires providers of high-risk AI systems to document "data collection processes and the origin of data" and the original purpose of any personal data. It also requires a record of every preparation step, such as labeling, cleaning, updating, enrichment and aggregation (European Commission AI Act Service Desk). BCBS 239 adds the structural side: integrated data taxonomies with metadata, and single identifiers for entities, counterparties, customers and accounts. It also asks for "a single authoritative source for risk data per each type of risk" (BIS, paragraphs 33 and 36).
A GRC lineage record needs five fields for each data set. These are the source system, the transformations applied, the downstream consumers (reports, models, vendors), the legal basis or purpose attached at collection, and the date the map was last confirmed. Build it on top of the inventory described in how to build a data inventory, rather than as a separate artifact.
Evidence: the records that prove governance operates
Ownership and lineage are design. Evidence shows the design runs. Each regime names the record it expects.
- GDPR Article 30 requires a record of processing activities covering purposes, categories of data subjects and personal data, recipients, international transfers, erasure time limits and security measures. It must be "in writing, including in electronic form" and available to the supervisory authority on request. Organizations employing fewer than 250 persons are exempt unless processing is likely to result in a risk, is not occasional, or includes special categories (EUR-Lex, Article 30(3) to (5)).
- EU AI Act Article 10(2) lists eight data governance practices, (a) to (h), from design choices through bias examination to identifying data gaps and how they are addressed. Documented practices are the evidence a market surveillance authority will read (European Commission AI Act Service Desk).
- BCBS 239 Principle 1 expects aggregation and reporting practices to be "fully documented and subject to high standards of validation", with validation independent of the first line (BIS, paragraph 29).
- NIST CT.DM-P8 asks that audit and log records are "determined, documented, implemented, and reviewed in accordance with policy" (NIST).
The pattern is the same each time: a register, a date, a named reviewer and a trail of changes. Evidence that lives in a spreadsheet nobody dates fails the "demonstrate" test in GDPR Article 5(2) even when the underlying control works. Our GRC data quality guide explains why owners, statuses and relationships decide whether a record counts.
A framework the GRC team can run
Put the three parts together and the framework is five linked registers, each with an owner and a review date.
- Data inventory. Every system, product or service that processes data, the categories of individuals, the data actions and the data elements (NIST ID.IM-P1 to P7).
- Ownership register. Owner, steward and system owner for each data set, with the privacy and AI roles aligned to third parties (NIST GV.PO-P3 and P4; BCBS 239 paragraph 34).
- Lineage map. Source, transformations, consumers, purpose at collection, last confirmed date (NIST ID.IM-P8; EU AI Act Article 10(2)(b) and (c)).
- Records of processing and training data. The GDPR Article 30 record for personal data, and the Article 10 practice record for every high-risk AI data set.
- Control tests and findings. Scheduled checks on accuracy, completeness and timeliness, with independent validation (BCBS 239 Principles 3 to 5), and findings routed to the owner.
Link the registers rather than copying between them. A finding should point at the data set, the data set at its owner, the owner at the system, and the system at the lineage map. That is what lets a Chief Privacy Officer or Chief Data and AI Officer answer a supervisory question in one query rather than a week of reconciliation.
How SmartSuite supports the framework
The Privacy Management suite holds the data inventory, the Article 30 record and the ownership register as linked tables. A change to a data set then updates its owner, its processing record and its open findings together. AI Governance adds the Article 10 practice record to each AI use case, with the training-data lineage, bias checks and data-gap actions kept against the system that uses them. The platform keeps a dated change history on every record, which is the evidence trail the sources above describe.
Key facts
| Fact | Value | Source |
|---|---|---|
| GDPR record of processing: items a controller must record | Seven, Article 30(1)(a) to (g) | EUR-Lex |
| GDPR Article 30(5) exemption threshold | Enterprises employing fewer than 250 persons, with three exceptions | EUR-Lex |
| NIST Privacy Framework 1.0 published | 16 January 2020; five Functions; three parts (Core, Profiles, Implementation Tiers) | NIST |
| NIST Inventory and Mapping subcategories | Eight, ID.IM-P1 to P8 | NIST |
| EU AI Act Article 10(2) data governance practices | Eight, (a) to (h) | European Commission |
| EU AI Act high-risk obligations apply from (Article 113 as amended in 2026) | 2 December 2027 for Annex III systems; 2 August 2028 for Annex I systems | European Commission |
| BCBS 239 published; number of principles; G-SIB deadline | 9 January 2013; 14 principles in four groups; January 2016 | BIS |
| ISO/IEC 38505-1 current edition | Edition 2, August 2026, 20 pages; replaces the 2017 edition | ISO |
| DAMA-DMBOK knowledge areas | 11, with data governance at the center | DAMA |
FAQs
Does a GRC team need its own data governance framework if the data office already has one?
Yes, but as a view rather than a rival. The data office owns quality, architecture and modeling across all 11 DAMA-DMBOK areas. The GRC team needs the subset regulators test: ownership, lineage and evidence for data that carries legal or risk obligations. Share the inventory, add the control fields, and route findings to the same owners.
What is the difference between a data owner and a data steward?
The owner is accountable for the data set and signs off its purpose, access and retention. The steward does the day-to-day work: definitions, quality checks and corrections. BCBS 239 paragraph 34 describes the owner role, including keeping data "aligned with the data definitions". NIST GV.PO-P3 asks that both roles are established in writing.
Is a data lineage map required by law?
No regulation uses the word, but several require its content. NIST ID.IM-P8 asks that data processing is mapped with its data actions and elements. EU AI Act Article 10(2)(b) and (c) require documented data origin and preparation steps for high-risk systems. GDPR Article 30 needs recipients and transfers, which a lineage map supplies.
Which organizations are exempt from the GDPR Article 30 record?
Enterprises employing fewer than 250 persons, under Article 30(5). The exemption falls away if the processing is likely to result in a risk to data subjects, is not occasional, or includes special categories under Article 9(1) or criminal conviction data under Article 10. Most organizations with regular customer or employee data therefore keep the record.
When do the EU AI Act data governance rules in Article 10 apply?
Article 10 is a high-risk obligation. After the 2026 amendment to Article 113, Annex III high-risk systems must comply from 2 December 2027 and Annex I product-embedded systems from 2 August 2028. Providers who process special categories of personal data for bias detection also follow the new Article 4a conditions.
Sources
- Regulation (EU) 2016/679 (GDPR), Articles 5 and 30. EUR-Lex: https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Regulation (EU) 2024/1689 (EU AI Act), Article 10 "Data and data governance", Article 4a and Article 113 as consolidated at 27 July 2026. European Commission AI Act Service Desk: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-10, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4a, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113. EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0, 16 January 2020. https://doi.org/10.6028/NIST.CSWP.01162020
- Basel Committee on Banking Supervision, Principles for effective risk data aggregation and risk reporting (BCBS 239), 9 January 2013. https://www.bis.org/publ/bcbs239.htm (PDF: https://www.bis.org/publ/bcbs239.pdf)
- ISO/IEC 38505-1:2026, Information technology, Governance of data, Part 1: Application of ISO/IEC 38500 to the governance of data, edition 2, August 2026. https://www.iso.org/standard/87195.html
- DAMA International, What is data management? (DAMA-DMBOK knowledge areas). https://dama.org/about-dama/what-is-data-management/
Related
- Category: Privacy & Data Governance
- Data owners vs system owners vs process owners in GRC
- How to build a data inventory that supports privacy, AI, cyber and GRC
- GRC data quality: why owners, statuses and relationships matter
- What is: Data governance in risk management
- Frameworks: GDPR, NIST Privacy Framework v1.0
- Product: Privacy Management suite, AI Governance
Reviewed by: [reviewer name and credential to be added before publication]
Linked Articles
Learn how to map privacy obligations to policies, controls, evidence, owners, issues, remediation, and dashboards in a Connected GRC program.
Learn how to govern sensitive data use in AI and third-party tools by connecting data inventories, owners, vendors, AI reviews, controls, evidence, issues, and dashboards.
Learn how to prove data retention controls operate by connecting retention rules, data inventories, systems, vendors, AI tools, evidence, issues, deletion, and dashboards.
Learn what privacy evidence to retain for audits, regulators, and customers, including ROPAs, DPIAs, vendor reviews, DSARs, incidents, controls, issues, and approvals.
Learn the difference between data owners, system owners, and process owners in GRC, and how to assign accountability across privacy, AI, cyber, vendors, controls, and incidents.
Learn how to build a connected data inventory that supports privacy, AI governance, cyber risk, third-party risk, controls, evidence, incidents, and GRC reporting.
Learn what AI governance evidence to collect before approval and after deployment, including intake, data, vendor, risk, controls, monitoring, issues, and approvals.
Learn the difference between privacy incidents and security incidents, and how Connected GRC links incident intake, data impact, notification, evidence, issues, and remediation.
Frequently Asked Questions
Answers to the questions readers ask most about this topic.
Evidence should connect to the control, obligation, policy, period, test, owner, reviewer, audit request, regulatory inquiry, issue, or remediation action it supports. Evidence without context is just a file.
The Connected GRC data model includes risks, obligations, policies, controls, evidence, tests, issues, remediation, validation, vendors, contracts, systems, data, AI use cases, incidents, critical services, risk acceptances, exceptions, dashboards, and board items.
Each AI use case should link to data categories, sensitivity, data owners, systems, vendors, retention rules, controls, evidence, incidents, and issues in the data inventory.
Connected GRC improves AI governance evidence by linking AI use cases to owners, data inventories, vendors, contracts, reviews, controls, evidence, approvals, monitoring, issues, remediation, risk acceptance, dashboards, and decisions.
The biggest mistake is treating AI approval as the only evidence. AI governance also requires evidence of data review, risk tiering, controls, vendor terms, monitoring, issues, remediation, validation, reassessment, and change history.
Monitoring evidence proves the AI system remains within approved performance, risk, control, and usage expectations after deployment. AI risk can change as data, users, model behavior, vendors, or business use changes.
Vendor evidence may include vendor assessment, contract terms, data-use restrictions, model provider details, prompt and output retention terms, training restrictions, subprocessors, security evidence, privacy evidence, deletion terms, incident notification terms, and open issues.
AI governance evidence is the documentation, records, assessments, approvals, logs, monitoring outputs, test results, vendor artifacts, control evidence, issue records, remediation evidence, and decision history that prove an AI use case is governed before approval and after deployment.
Put Connected GRC into action with SmartSuite
Map controls, collect evidence, run assessments, manage remediation, and report readiness - all from a single connected system.