Data governance is the framework of roles, standards, and processes that ensures institutional data is accurate, secure, accessible, and relevant — enabling informed, strategic and operational decision-making across the university.
This site explains the framework and shows how to apply it. Jump to what's most relevant to you.
Everything here describes data governance at the level of higher education as a sector: the shared concepts, roles, and practices common across institutions. It is meant to build a common understanding and vocabulary — a starting point, not a rulebook.
Your institution has its own policies, systems, authorities, and local context that determine how data is actually handled. Always consult your campus data governance experts — your data governance office, privacy office, and counsel — before acting on anything you read here. Where this guidance and your local rules differ, your local rules govern.
Every consequential decision this institution makes — who we admit, where we spend, how we retain students, what we tell accreditors — rests on data. Governance is what makes that data trustworthy. Without it, leaders are deciding on numbers no one can fully stand behind.
This is a short brief for sponsors and funders. Hand it to a president, provost, CFO, or CIO who needs the why in two minutes.
Ungoverned data isn't free — the cost is just hidden, paid in staff time, risk, and bad decisions.
Three offices report three enrollment figures to the board. Leaders lose confidence, and time is wasted reconciling instead of deciding.
FERPA, GLBA, and state breach laws carry real penalties and reputational damage. Unowned data is unmanaged risk.
Analysts spend more time finding and cleaning data than using it. The same report gets rebuilt five different ways.
Predictive models and dashboards are only as good as their data. Without governance, AI investments underdeliver — or backfire.
Funded governance pays back across mission, risk, and efficiency.
One trusted source of truth, so leadership debates strategy — not whose number is right.
Clear ownership, classification, and access controls that hold up to an audit or an incident.
Less rework and faster reporting — accreditation and IPEDS cycles stop being fire drills.
Governed, well-defined data is the precondition for analytics and AI that leadership can actually trust.
Reliable data underpins retention, equity analysis, and the interventions that help students finish.
Demonstrable stewardship of student and donor data protects the institution's reputation.
Enrollment pressure, tighter accountability, new privacy and AI regulation, and rising cyber risk all raise the stakes on data — at the same moment.
Governance is cheaper to build deliberately now than to retrofit after an incident, a failed audit, or an AI misstep. The cost of waiting compounds.
Pair this brief with the Implementation roadmap (the phased plan) and Metrics & KPIs (how we'll show progress) when you take it to leadership.
Every governance program meets the same handful of objections. They're worth taking seriously: most contain a grain of truth about programs done badly. Here's the honest answer to each — the version you can say in a meeting.
Notice the pattern: nearly every objection assumes governance means control. It doesn't. It means clarity about who decides — and that's what makes work faster, not slower.
Every objection above assumes governance is about control — more rules, more gatekeeping, more meetings. Reframe it as clarity about who decides, sized to the risk, and each objection answers itself. That reframing is the whole strategy of this framework.
Before any project applies governance, three things are fixed: the goals it serves, the objectives it pursues, and the principles every decision is measured against.
The measurable aims the program advances.
The lens every governance decision is weighed against.
There is no single correct amount of governance. A liberal-arts college of 2,000 and an R1 research university with a medical center need very different programs. Proportionality means scaling governance to fit the institution — its size, mission, risk, capability, and resources — rather than imposing one rigid model and hoping it sticks.
Over-govern, and the program collapses under its own ceremony: committees no one attends, policies no one reads. Under-govern, and risk goes unmanaged. Proportionality is how you find the level an institution will actually sustain.
Six dimensions calibrate how much structure a program needs. Weigh them honestly before adding any committee, policy, or control.
The same five components appear at every size — what changes is their weight. The right level is rarely the most elaborate one; it's the heaviest one you can keep running.
A small college, a single division, or a program in its first year.
A regional university with several schools and a growing data team.
An R1 system with a medical center, research data, and many funders.
Three questions keep a program proportional as it grows. If a proposed rule fails them, it's ceremony, not governance.
Proportionality is not a license to under-govern. Risk sets the floor. A small college still owes a single student record FERPA-grade protection, and one research dataset under HIPAA carries the same obligation whether you have a governance office or a single coordinator. Scale the ceremony — the committees, the cadence, the tooling — never the safeguards on your most sensitive data.
Data governance never operates alone. It shares borders with IT, security, privacy, risk, research, and more. Drawing those borders clearly prevents the two failures that quietly sink programs: gaps, where no one owns a decision, and turf wars, where everyone does.
A simple rule keeps the lines straight: data governance owns the data itself — its meaning, classification, ownership, and access policy. Neighboring domains own the systems it runs on, the uses it's put to, the risk it carries, or the people it concerns. Most friction is a boundary that was never drawn.
Each owns its own territory and shares a seam with data governance. The seam is where a handoff has to be explicit.
Every shared border resolves into one of three relationships. Naming which one applies is what turns an argument into a workflow.
Data governance is the common thread between these domains — the shared vocabulary and the table where their claims on data are reconciled. Give every shared boundary one accountable owner in the RACI. Where data governance isn't the lead, it's the consult; where it is, it convenes the others. That single discipline is what closes the gaps without starting the turf wars.
Research data is the single feature that most distinguishes a university from any other organization — and the place standard data governance most often gets it wrong. It carries authorities your governance program does not control: an IRB, a funder, an export regime, a principal investigator. Treat it like administrative data and you will either break the law or break the research.
The right posture is humility about the boundary: data governance provides the shared infrastructure and standards, and steps back where research-specific authority takes over. This page draws that line.
Four traits set research data apart from the student, financial, and HR data the rest of the framework addresses.
Data governance does not govern research data — it supports it. The split is clean once named.
Governance attention shifts at each stage — and the handoffs are where data is lost, leaked, or stranded.
When research authority and data governance disagree, research authority wins — the IRB, the funder agreement, and export law are not yours to override. Your job is to make compliance easy: governed infrastructure, clear classification, and a retention backbone the researchers can simply plug into.
The two are constantly confused, and the confusion is costly. Governance decides the rules; management carries them out. Governance is about authority and accountability — who may decide what; management is about execution — the hands-on work of moving, storing, and securing data.
A simple test: if the question is "who is allowed to decide?" that's governance. If it's "how do we make it happen?" that's management.
The "what" and "who". Sets policy, standards, definitions, and ownership — and holds people accountable to them.
The "how". The technical and operational work that delivers data according to governance's rules.
They're two halves of one system. Governance sets direction; management executes; results and friction flow back to refine the rules. Neither works alone — governance without management is shelfware; management without governance is inconsistent and risky.
In the DAMA-DMBoK model, governance sits at the hub of the wheel and the management disciplines — storage, security, integration, quality, metadata — are the spokes. This framework's five components are how that hub is operationalized; the management disciplines are where Custodians do the work.
These are the operational building blocks a project draws on. Every step of applying governance maps back to one or more of them.
These five mirror the components common to data-governance programs across higher education — spanning governance roles, metadata & cataloging, data access & security, data quality, and enabling technology. They align with widely cited data-governance decision domains and the role structure (trustees, stewards, custodians) reflected in sector guidance such as the EDUCAUSE data-governance work.
Compliance isn't a sixth component — it's a cross-cutting concern threaded through the five. The bridge is data classification: you classify data by sensitivity, the classification determines which laws apply, and those requirements flow into access, controls, and audit.
It's also anchored in the foundation — the Compliance & Auditing objective and the Security & Compliance principle — and accountable to the Data Trustee, with Advisory Teams confirming compliance before launch.
{{ cd.summary }}
{{ cd.detail }}
{{ s.intro }}
{{ cd.ownership }}
These roles are a representative model — campuses may add, rename, or combine roles to run the program in a way that fits their organization and structure. What matters is that two sets of core roles are accounted for; how they're staffed and titled is a local choice:
Before roles can be filled, an institution has to decide how to structure the program — including whether to fold it into existing IT governance or stand it up another way. Drawn from how higher-education institutions actually organize, four options recur, each trading control for autonomy differently.
Most programs blend these and shift over time — many also go hybrid, centralizing governance for high-risk data (student PII, FERPA-protected records) while decentralizing low-risk data.
{{ m.def }}
This framework is built as a federated model with IT-governance sponsorship.
A data governance committee provides oversight and executive backing, a Data Governance Work Group coordinates shared standards in the absence of a standing office, and Data Trustees own data within each domain. A program can begin embedded in IT governance and mature toward a standing Data Governance Office as it scales.
The named roles — Trustees, Stewards, Custodians — set and run the program. But every faculty member, administrator, student worker, and analyst who creates, uses, or shares data is a data citizen. The best policy fails if the person with the spreadsheet doesn't follow it.
End users don't need a title or training certificate to participate. They need to know a handful of everyday responsibilities — and where to go when a decision is above their pay grade.
Six habits that make governance real at the point where data is actually handled.
Recognize the classification of the data in front of you — and treat Confidential and Restricted data accordingly.
Pull from governed, authoritative sources — not a personal copy from three months ago — and use agreed definitions.
Share through approved access, not by emailing files. Don't paste sensitive data into external tools or AI services.
Keep credentials secure, request only the access you need, and speak up when you can see more than you should.
Report inaccurate data, and report suspected exposure immediately. Spotting issues early is the whole point of having many eyes.
When a decision is bigger than the task in front of you, escalate to the domain Steward instead of guessing.
Governance isn't a department — it's a continuum from setting the rules to following them. Everyone sits somewhere on it.
Most data choices never become a project. The two-minute task loop turns these six responsibilities into a quick, repeatable call anyone can make.
Maturity is a ladder, not a switch. This five-level scale is adapted from the Capability Maturity Model and Stanford's higher-education data-governance maturity model — moving from ad hoc practice to continuous improvement.
Rate your institution on each dimension below to see an overall level and where to focus next. Your ratings are saved on this device.
{{ l.desc }}
{{ matOverallDesc }}
Pick a level from 1 (Initial) to 5 (Optimizing) for each dimension. Your overall maturity and a focus for the next level appear here.
Grounded in the Capability Maturity Model (CMMI), Stanford University's Data Governance Maturity Model (2011) for higher education, and the DAMA-DMBoK reference framework — which places data governance at the hub of the data-management disciplines this assessment samples.
Governance earns its keep when it changes outcomes. Track a small, balanced set of measures across five pillars — each with a leading indicator (effort, early signal) and a lagging indicator (realized result).
Start narrow: one leading and one lagging metric per pillar gives leadership a view of both activity and impact without drowning stewards in reporting.
The minimum viable dashboard the governance committee can review quarterly — effort on the left, impact on the right.
Targets should be set per institution against a baseline — a metric without a baseline and a threshold is just a number. Review leading indicators monthly with stewards and lagging indicators quarterly with the governance committee.
Good governance starts with shared definitions. These are the terms used across this site and in day-to-day practice. Press ⌘K anywhere to look one up.
{{ versionStamp }}
The same governance framework scales from a campus-wide initiative, to a single project, down to an everyday task. Pick a level to browse worked examples — each one opens the full walkthrough.
{{ c.summary }}
Governance sets the rules; capability is whether people can actually work within them. That capability isn't one thing — it grows along a path from literacy (you can read and question data) through competency (you can do your role's data work correctly) to fluency (you reason and lead with data as second nature).
Not everyone needs fluency, and that's the point: the target level depends on the role. A faculty member needs literacy; a Steward needs domain competency; an analyst or data leader needs fluency. Naming the target is what makes training purposeful rather than generic.
Three stages, each building on the one before. People move up as their responsibilities grow.
Can read, interpret, and question data — and knows the rules that apply to it.
Can perform the data work their role requires, correctly and independently.
Reasons and leads with data instinctively — and helps others do the same.
Literacy is the floor for everyone who touches institutional data. Competency and fluency are reached by role — and they're a moving target as tools (and AI) change what "using data well" means.
What level each role should reach, and the specific competencies that define it. Set these as expectations, then train toward them.
This is the target; role training is how you reach it, and the scenarios are where it's rehearsed. Capability is also a maturity dimension — "Culture & Literacy" — so you can track it as the program grows.
Six roles carry the framework. Each module covers what the role is accountable for, the do’s and don’ts that matter most, a get-started path, step-by-step playbooks, worked scenarios from the use-case library, and a scored knowledge check. Pick a role to begin.
{{ c.mission }}
{{ trainDetail.mission }}
The knowledge, skills, and abilities that make someone effective in this role.
{{ trainDetail.authority }}
{{ trainDetail.escalates }}
{{ trainDetail.partners }}
Where this role most often goes wrong — and the cost.
Most governance failures happen at the seams between roles.
The same use cases from the library, seen from where you sit.
{{ s.lens }}
A practical path for someone newly stepping into this role.
The parts of the framework this role works in most. Tap to open.
The core procedures this role runs, broken into concrete steps.
Answer all questions correctly to complete this module.
{{ q.explain }}
Before any tooling or access, applying governance to a new initiative starts with a conversation. Work through these questions for each of the five components — beginning with the first one every effort shares: what data are we governing? Pick a project below to see every question answered for a real initiative.
{{ g.intro }}
With the checklist answered, this is the repeatable lifecycle every initiative follows. Each step calls on the components and roles from the framework. Follow one initiative through all seven steps — then switch to a multi-domain initiative to see what changes when the data crosses boundaries.
The starter is a ready-to-fill checklist and RACI skeleton for the selected initiative — open it in any editor and assign owners.
{{ exBlurb }}
{{ s.what }}
{{ s.detail }}
A single-domain project runs the lifecycle within one chain of accountability. The moment data crosses domains, the same seven steps still apply — but the Data Governance Work Group coordinates shared standards, a combined RACI, and cross-domain escalation so no element falls through the seams.
Most data decisions never become a project. A spreadsheet lands in your inbox, someone asks for a one-off export, a duplicate record turns up. The same framework still applies — compressed into a two-minute call. This is governance at the size of a single task, where it most often quietly breaks.
A new system, a data warehouse, a CRM rollout. Planned, sponsored, runs the full lifecycle over weeks or months.
A single request, a one-off export, a quality fix. Ad-hoc, unsponsored, decided in minutes — the same components, roles, and rules at a smaller scale.
Pick a situation to see the governed call — its classification, who decides, the rule, and exactly what to do.
{{ taskDetail.situation }}
{{ taskDetail.rule }}
A project stands governance up deliberately; a task applies it in the moment. Same components, same roles, same rules — the only thing that changes is the size of the decision. Govern the tasks well and the projects mostly take care of themselves.
Answer three quick questions about a dataset and get its classification tier, how to handle it, and who to ask. This turns the classification rules into a thirty-second decision you can make at your desk.
Guidance only — the Data Trustee for the domain makes the final call and records it in the catalog. When two answers point in different directions, the higher tier wins.
A combined dataset takes the highest classification of any field it contains — aggregating Internal data can produce a Confidential result. Re-run this when you merge sources. See the full Data classification reference for the complete handling rules per tier.
This is what the framework looks like in the open: a public Data Governance Portal listing the institution's major data initiatives. Each one has a public governance record — its purpose, domains, roles, classification, and how the five components were applied.
Open any initiative to see its public record, then sign in (top-right of the portal) to reveal the staff-only artifacts behind each component — the RACI charts, catalog entries, access policies, quality rules, and controls registers.
AI doesn't replace data governance — it raises the stakes. A model is only as trustworthy as the governed data behind it, and a system that acts on data autonomously needs every component of the framework working. The same five components apply; AI just stretches each one.
Governance doesn't move to a new home for AI — it reaches into the model lifecycle: the data a model learns from, the data it can touch at run time, and the actions it's allowed to take.
Traditional systems are deterministic and legible: a report runs the same query every time, and you can read exactly what it did. AI breaks those assumptions — six properties demand consideration that conventional data systems never required.
A SQL report is fully inspectable; a model's reasoning is not. Governance must require explainability, documented limits, and human review where decisions affect people.
Traditional systems are reproducible; generative models may not be. Governance needs versioning, logging of inputs and outputs, and testing against drift rather than a one-time sign-off.
A model can act on thousands of records in seconds. A small error or bias propagates faster than any human process can catch — so controls must be preventive and monitored, not just after-the-fact.
Unlike coded logic, models can produce capabilities and failures nobody designed — hallucinations, unexpected inferences. Governance must enumerate allowed actions and bound what the system may do.
A model trained on historical data can encode and amplify existing bias — high-stakes in admissions, advising, or aid. Governance must monitor for disparate impact across student populations.
Data fed to a model may be memorized, embedded, or used for training elsewhere — re-identifying individuals or exposing protected records. Governance must control what data reaches a model and where it goes.
Each component you already know extends naturally to models and the data that feeds them.
{{ c.ai }}
Picture an AI agent that reviews early-alert signals each morning and drafts advisor outreach — pulling from Student Records, Financial Aid, and Advising on its own. Agentic AI doesn't just answer; it reads data and takes actions autonomously, often across domains. That's exactly where governance has to be tightest.
Governance treats the agent like a powerful new Data Custodian — it executes, under bounded and delegated authority — while a human stays accountable for everything it does.
An agent can be delegated authority to act — but, exactly like a human Steward or Custodian, accountability stays with the Data Trustee. The framework doesn't change for AI; it's what makes acting through AI safe.
Every data element carries a classification. The tier sets who may see it, how it must be stored and shared, and what happens if it's exposed. When in doubt, classify up — the higher tier always wins.
Classification is assigned by the Data Trustee for a domain and recorded in the catalog alongside each asset.
A combined dataset takes the highest classification of any field it contains. Aggregating Internal data can produce Confidential results — re-classify when you combine sources.
Every policy has a named owner and a review cadence. A policy without a current review date is treated as out of date.
The charter: scope, authority, roles, and how decisions are made.
The four tiers and the handling rules for each. See the classification reference.
Who may request access, who approves it, and how it's reviewed and revoked.
How long each record type is kept and how it's securely destroyed.
What data the institution collects, why, and the rights individuals have.
Rules for using institutional data, including in AI tools and models.
A university holds student, employee, financial, health, and research data — each with its own rules. Governance doesn't replace these obligations; it's how the institution meets them consistently.
Orientation only — not legal advice. Your Office of General Counsel and Privacy Office determine what applies and how.
Does the EU AI Act apply to US higher ed? Not as a blanket rule — but it reaches US institutions situationally (EU-used output, EU learners, EU operations) much like GDPR, and education uses are largely high-risk under it. Treat it as both a possible obligation for global programs and a de facto benchmark. Counsel determines scope per system; this is orientation, not legal advice.
Each law maps to a classification tier, a retention rule, and an accountable Trustee. When you classify data and assign ownership, you're operationalizing these obligations — which is why the catalog records the governing regulation for sensitive domains.
Four standard requests cover almost everything people need from governance. Each routes to the right steward and follows a defined turnaround.
Ask to see or use a dataset, report, or system you don't yet have rights to.
Flag inaccurate, missing, duplicated, or out-of-date data.
Request a new report, dashboard, integration, or dataset.
Ask for a time-bound exception to a policy when a real need can't be met otherwise.
A data incident is any unauthorized access, loss, or disclosure. Speed matters most in the first hours — contain first, investigate second.
Suspected incident? Notify the Privacy Office and CISO immediately — do not wait until you're sure.
This playbook maps the institution's data-governance roles onto the standard incident lifecycle from NIST SP 800-61 (Computer Security Incident Handling) and the NIST Cybersecurity Framework functions — so a data incident is handled exactly like a security incident, with governance owning the data side.
Grounded in NIST SP 800-61r2 (Computer Security Incident Handling Guide) and the NIST Cybersecurity Framework. Notification obligations follow FERPA, GDPR where applicable, and state breach-notification law — your Privacy Office and Legal counsel set the binding timelines.
Which laws apply depends on whose data and what kind. Confirm the binding set with Legal — this is orientation, not legal advice.
You don't stand up governance all at once. Each phase delivers value while building toward the next. Most institutions spend 12–24 months reaching steady state.
If it contains Confidential or Restricted data, yes — share through governed access, not by emailing a file. Internal and Public data can be shared with a business need.
The Data Steward for that domain owns the definition, recorded in the glossary. One agreed meaning, used everywhere.
Only governed, appropriately-classified data, and never paste Confidential or Restricted data into external AI services. See AI & governance.
Check whether both pull from a governed source of truth. If definitions differ, raise it with the Steward — reconciling these is exactly what governance is for.
Submit a data access request with your purpose. The Trustee and Steward approve based on business need. See Requests & intake.
Governance scales to risk. Low-risk everyday work uses lightweight task triage; only high-stakes data and projects get the full process.
Governance is people, not just policy. Here's who owns what — fill in the names for your institution.
Sets direction and resolves cross-domain disputes. Ask them about policy changes and exception requests.
Senior owner (e.g. Registrar, CFO). Ask about access approvals and classification for their domain.
Your first call for definitions, data quality issues, and how a dataset should be used.
Ask about privacy rights, consent, and report suspected incidents here first.
Owns technical safeguards and leads incident containment. Report security concerns immediately.
Source of official metrics for accreditation and external reporting. Ask about authoritative numbers.
Universities aren't corporations. Authority is shared, data is scattered across decades of systems, and the culture prizes autonomy. A governance framework that ignores this context fails on contact — these are the realities it has to work within.
Naming the obstacles up front is what separates a framework that's adopted from one that sits on a shelf.
Faculty senates, deans, and administrative units hold real autonomy. No single executive can simply mandate data practices — governance must be earned through legitimacy, not imposed.
SIS, LMS, advancement, finance, HR, and research systems were bought independently over many years. The same student exists in a dozen systems under different IDs and definitions.
A person can be a student, employee, alum, and research subject at once. Governing identity and consent across those roles is a problem few other sectors face.
Education records, health, financial aid, and research data carry strict legal protection and real consequences for students when mishandled.
Enrollment decline, accreditation, outcomes reporting, and public scrutiny all demand trustworthy data — fast. Governance is now an operational necessity, not a nicety.
Few institutions have dedicated governance staff. The framework has to scale to risk and deliver value early, or it loses the attention it needs to survive.
Because authority is shared and resources are thin, this framework leads with legitimacy and value, not control: clear roles, lightweight task-level triage, and quick wins that earn the credibility to govern the high-stakes work. That's a deliberate response to the higher-ed context — not an accident.
There's no single right structure — only the right fit for your institution's size, culture, and risk. The three models trade control against autonomy in different ways.
A Data Governance Office sets and enforces standards for every domain. One accountable authority.
A central body sets common standards; domains and units govern their own data within them. The common middle ground.
Units set their own practices with little central coordination — often the de facto starting state, rarely a deliberate choice.
Match the model to your regulatory risk, institutional size, and culture. Most universities land on federated; smaller or highly-regulated institutions lean centralized. Whichever you pick, name it explicitly — the worst model is an accidental one. The public portal on this site demonstrates a centralized office in practice.
Governance starts by naming the domains and their systems of record. Every domain needs a Trustee; every critical element should trace to one authoritative source.
The grouping below follows the CAUDIT Higher Education Reference Models (HERM) — an internationally adopted reference model that organizes a university's capabilities and information around its mission: the academic mission (learning, research, engagement) and the enabling functions that support it.
Everything from prospect to alumnus — the student record at the core of the institution.
The full research lifecycle — funding, ethics, outputs, and the data they generate.
The institution's relationships beyond the classroom — alumni, donors, partners, and community.
The corporate and administrative domains every organization shares, plus the ones specific to running a campus.
For the core administrative domains, the authoritative source and typical Trustee — the starting point for assigning accountability.
Domain groupings follow the CAUDIT Higher Education Reference Models (HERM); Trustees and sensitivity tiers are typical defaults — confirm yours. The hardest data lives at the seams between domains (a student who is also an employee, an alum who was a research subject), which is why cross-domain ownership is defined explicitly in the framework.
Higher ed has shared data standards for reporting and system interoperability. Adopting them is how governed data moves between systems and out to the sector without re-mapping every time.
A standard is a shared definition — exactly what the catalog and glossary enforce internally. Adopting sector standards means your governed definitions already line up with federal reporting and partner systems, turning compliance and integration from a yearly scramble into a byproduct of good governance.
Nothing here is invented from scratch. This is a higher-ed-specific synthesis of established bodies of knowledge — recast in plain language and sized for institutions. The crosswalk below shows roughly where each part aligns with established standards, to help you orient the framework against what your peers already use.
These are high-level associations, not authoritative or certified mappings. They're meant to show roughly where this framework's ideas align with widely recognized standards — not to claim equivalence or compliance. Treat every entry as a starting point for your own review, and confirm specifics against the source material before relying on them.
— indicates the framework's scope does not address that area. CAUDIT HERM is a reference architecture (business, data & technology models), so it maps to the structural rows but not to governance controls such as access, quality, policy, or privacy.
When an auditor, accreditor, or new CIO asks “what is this based on?”, you can point to seven recognized references rather than an internal opinion. The crosswalk also makes it easy to adopt a peer institution's artifacts — the vocabulary lines up.
Policy on a page changes nothing until someone applies it to a messy, specific situation. These exercises put governance into everyday decisions — most are ordinary judgment calls, not crises. Some are group discussions, some you can do solo in five minutes.
There's rarely one right answer; the value is in surfacing who decides, on what authority, and where the framework applies.
Pick one, cast the disciplines around the table, read the situation, and work the questions together.
Facilitator tip: there are no trick answers. If your group reaches a different resolution than the framework suggests and can defend it on accountability and risk, that's a healthy governance culture — capture it and feed it back to the committee.
Five-minute judgment checks for the choices people actually face at their desks. Decide your answer first, then reveal the governed one. No table required.
{{ q.prompt }}
{{ q.answer }}
Role-specific training usually isn't a separate set of exercises — it's a lens. Run any case study above from a single role's seat: the learner answers only as that role, judged on that role's duties. Pick a role to see the questions it brings to every scenario, plus one exercise specific to it.
{{ lens.role }}
{{ lens.exercise }}
Download the facilitator pack — all six case studies plus the quick-call set, with roles, questions, curveballs, and answer keys, formatted for printing.
Concepts are only useful when someone can act on them. These are the working artifacts the framework refers to — ready to download, adapt to your institution, and put to use.
Each downloads as a ready-to-print PDF you can adapt to your institution. They're starting points, not finished policy — replace the bracketed placeholders and run them past your Counsel and Privacy Office.
{{ t.desc }}
Download every template together as a single starter kit you can drop into a shared drive.
This framework synthesizes established bodies of practice rather than inventing its own. These are the foundational sources — for those who want to go deeper or cite the basis.
The Data Management Body of Knowledge — the reference model placing governance at the hub of the data disciplines.
Research, toolkits, and the data-governance community of practice for higher education IT and analytics.
The 2011 higher-education maturity model underpinning this site's assessment dimensions.
The Association for Institutional Research — standards and ethics for data use in decision support.
The Cybersecurity Framework and incident-handling guide behind this site's protection and incident response.
The Capability Maturity Model lineage behind the five-level maturity scale used throughout.
The Higher Education Reference Models — capability and information models organizing the institution by mission. Basis for the data-domains map.
Links and citations are intentionally generic — add your institution's licensed editions and internal references. This framework adapts these sources to a higher-education context; it does not reproduce them.
This framework is meant to be shared. Any higher-education institution is welcome to use and adapt it for their own non-commercial purposes — under an open license, with attribution.
The conceptual framework, its structure, the selection of what to include and exclude, the sequencing, and the curation reflect the professional and scholarly judgment of Joe Sabado — a data governance practitioner and scholar.
Copyright in that original selection, arrangement, and expression is retained by the author. Joe Sabado | CampusAIExchange.com.
This website and its prose were developed with the assistance of AI tools used for drafting and production, under the author's direction.
The author directed the work, reviewed and edited the output, and is responsible for the final content. The intellectual structure and editorial decisions are the author's; AI was an assistive tool, not the author.
This framework synthesizes and adapts established bodies of practice — including DAMA-DMBoK, the NIST Cybersecurity Framework and SP 800-61, the CAUDIT Higher Education Reference Models, the Stanford data-governance maturity model, and EDUCAUSE community work. The original contribution is the synthesis, structure, and application to a higher-education context, not the underlying concepts, which remain the work of their respective authors (see Further reading).
You are free to share and adapt this material, provided you follow these terms:
Full license: creativecommons.org/licenses/by-nc-sa/4.0/ · This is a human-readable summary, not the license itself.
When you use or adapt this work, include a credit like:
For scholarly or formal reference:
The CC license covers the framework content. It does not grant rights to the author's name, "CampusAIExchange," or any logos, marks, or branding, which remain reserved.
This material is offered for general guidance and orientation. It is provided without warranty and is not legal, compliance, or professional advice. Confirm applicability and obligations with your own counsel, privacy office, and leadership.