PM-23: Data Governance Body

PM-23 requires you to formally establish a Data Governance Body with defined membership and defined responsibilities, then run it as an operating committee with documented decisions, escalation paths, and proof of oversight. To operationalize it quickly, charter the body, assign accountable roles, set meeting cadence and decision rights, and tie governance actions to data inventory, classification, access, and retention controls. ¹

Key takeaways:

• A “Data Governance Body” is an operating governance function, not a one-time org chart exercise. ¹
• Your fastest audit win is a signed charter plus recurring meeting minutes that show decisions tied to data risk. ¹
• Define decision rights and escalation so data ownership, exceptions, and risk acceptance are traceable. ¹

The pm-23: data governance body requirement sits in the NIST SP 800-53 Program Management (PM) family and is aimed at making data governance real, durable, and assessable. Assessors generally look for two things: (1) a formally established body with named participants and (2) evidence that the body actually governs data-related decisions across the system lifecycle. ¹

For a Compliance Officer, CCO, or GRC lead, the operational goal is straightforward: create a governance mechanism that can make and record decisions about data standards, data quality, data access and sharing, retention, and accountability. You also need to show how those decisions flow into technical and procedural controls owned by Security, Privacy, IT, and the business. ²

One practical point: the NIST text uses organization-defined parameters (ODPs) for PM-23 (the membership composition and the responsibilities/authorities). That means you must fill in those blanks in your implementation and keep them consistent across your SSP, policies/standards, and governance artifacts. If you leave the ODPs vague, you create an “unassessable control” problem even if good governance exists informally. ¹

Regulatory text

NIST SP 800-53 PM-23 (excerpt): “Establish a Data Governance Body consisting of {{ insert: param, pm-23_odp.01 }} with {{ insert: param, pm-23_odp.02 }}.” ¹

What the operator must do

1. Define the organization-specific parameters:

• pm-23_odp.01 (composition): who sits on the body (by role and, optionally, by named individual).
• pm-23_odp.02 (scope/authority): what the body does, what it can decide, and what it must oversee. ¹

2. Establish the body as a formal governance function with a charter, decision rights, and operating rhythm.

3. Generate evidence of operation: meeting agendas, minutes, decisions, and follow-ups that tie to data governance outcomes (standards, exceptions, risk acceptance, prioritization). ¹

Plain-English interpretation (requirement-level)

PM-23 expects a standing group that owns and coordinates data governance across the organization or system boundary. “Establish” means more than naming a committee; you need clear membership, clear responsibilities, and proof the group executes those responsibilities in a repeatable way. ¹

Treat this as a control plane for data: the body sets rules (standards), resolves conflicts (exceptions), and assigns accountability (data owners/stewards). Your security and privacy controls can be strong, but without governance you will struggle to justify why data is classified a certain way, why access exceptions were granted, or why retention rules differ across systems.

Who it applies to (entity + operational context)

PM-23 is commonly scoped for:

• Federal information systems and the organizations operating them. ²
• Contractor systems handling federal data, including environments where contractors process, store, or transmit federal information. ¹

Operationally, it matters most where:

• Multiple business units create/consume data and no single owner controls end-to-end handling.
• You share data with third parties (including SaaS, processors, and subcontractors) and need consistent rules for data sharing and restrictions.
• You run multiple systems that copy, transform, or export data (data lakes, analytics, ETL pipelines, AI/ML use cases).

What you actually need to do (step-by-step)

Step 1: Set scope and boundaries (system vs enterprise)

Decide whether the Data Governance Body is enterprise-wide with authority over the system, or system-specific with a narrower charter. Write the scope into the charter so assessors can see what is covered and what escalates elsewhere. ¹

Operator tip: If your organization already has an enterprise data council, you can map PM-23 to it, but you still must show how the system is represented and how system-specific decisions are made and tracked.

Step 2: Define composition (pm-23_odp.01)

Document required roles. A workable baseline composition pattern (adapt to your org):

• Chair (often CDO, CIO delegate, or equivalent)
• Security representative (CISO org)
• Privacy representative (if applicable)
• Data owners from major domains (HR, Finance, Customer, Product)
• Data steward or data management lead
• Legal/compliance advisor (non-voting is fine)
• Architecture/engineering representative (to make decisions implementable)

Record membership rules (quorum, alternates). Then maintain a roster.

Step 3: Define responsibilities and authorities (pm-23_odp.02)

Write responsibilities as decision outputs, not vague goals. Examples you can adopt:

• Approve and maintain data classification and handling standards.
• Assign and document data ownership for key datasets.
• Approve data sharing agreements/constraints for internal and third-party sharing.
• Approve retention, archival, and disposition rules (or route to Records for final approval).
• Review and disposition policy exceptions, with documented risk acceptance and expiry.
• Prioritize remediation for data quality, lineage gaps, and high-risk data stores.

Keep a short “decision rights” matrix:

• What the body decides vs recommends vs escalates.
• Who can approve risk acceptance when standards are not met.

Step 4: Create the operating procedure

Build a simple operating model that can run every cycle:

• Intake: how issues get onto the agenda (ticketing form, email alias, workflow tool).
• Agenda template: decisions needed, pre-reads, impacted systems/datasets.
• Minutes template: attendees, decisions, votes/approvals, action items, due dates, owners.
• Escalation: how unresolved disputes move to executive leadership.

Step 5: Tie governance decisions to control execution

PM-23 becomes “real” when decisions flow into:

• Data inventory and data mapping (what data exists, where it lives, who owns it).
• Access control processes (who gets access, how exceptions are approved).
• Data lifecycle controls (retention and disposal).
• Third-party risk decisions (what data a third party may receive, under what restrictions).

Create traceability: each governance decision should map to a downstream change (standard update, technical control change, contract clause update, backlog item, or risk acceptance record).

Step 6: Map PM-23 to an accountable control owner and evidence cadence

Pick a primary owner (often Data Governance Lead, CDO office, or GRC) and define recurring evidence to collect. This is specifically aligned to the recommended control practice: “Map PM-23 to control owner, implementation procedure, and recurring evidence artifacts.” ¹

Where Daydream fits naturally: Daydream can track PM-23 as a requirement with a named owner, a documented procedure, and a recurring evidence request schedule, so meeting minutes, charters, rosters, and decision logs are collected the same way every cycle and are ready for assessment.

Required evidence and artifacts to retain (audit-ready list)

Maintain these artifacts in a controlled repository:

• Data Governance Body charter (scope, authority, composition, quorum, decision rights).
• Membership roster with roles and alternates (and effective dates).
• Operating procedure (intake, agenda, minutes, escalation, documentation rules).
• Meeting artifacts: agendas, minutes, attendance records, decision log, action-item tracker.
• Decision outputs: approved standards/policies (data classification, sharing, retention) and revision history.
• Exception and risk acceptance records tied to governance approvals (with expiry/review triggers).
• Crosswalk evidence: PM-23 mapping to control owner, procedure, and recurring evidence artifacts. ¹

Common exam/audit questions and hangups

Assessors and internal audit teams tend to focus on:

• “Show me the charter. Who has authority to decide?”
• “Who participates? Is Security/Privacy represented for data handling decisions?”
• “Show evidence the body meets and produces decisions, not just discussions.”
• “How do you ensure actions get implemented? Where is the tracking?”
• “How do you handle exceptions and risk acceptance for nonconforming data stores?”
• “What is the boundary? Which systems/datasets are in scope?” ¹

Hangup to anticipate: If your minutes are only status updates, the body can look performative. Auditors want decisions, approvals, or documented escalations.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Charter exists, but no decision rights.
   Fix: Add a RACI-style decision rights table and define escalation authority.

2. Mistake: Membership is “whoever shows up.”
   Fix: Define required roles, quorum rules, alternates, and a maintained roster (with dates).

3. Mistake: Meetings happen, but nothing is recorded beyond a calendar invite.
   Fix: Standardize minutes and a decision log. Record approvals and action owners.

4. Mistake: Data governance is detached from third-party and system change processes.
   Fix: Require governance review for new data sharing with third parties and for new high-risk datasets or pipelines.

5. Mistake: ODP blanks never get filled in the SSP/control narrative.
   Fix: Populate pm-23_odp.01 and pm-23_odp.02 in your control implementation statement and keep them consistent with the charter. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat PM-23 as an assessment-readiness and control-effectiveness requirement rather than an enforcement-citation-driven one. ¹

Risk-wise, weak data governance typically shows up as:

• inconsistent classification and handling;
• undocumented data sharing with third parties;
• unclear ownership and delayed remediation for data quality and lineage gaps;
• ad hoc exceptions without expiry or risk acceptance traceability.

Those conditions increase the chance of audit findings, control gaps in system authorization, and security/privacy incidents that are hard to investigate.

Practical 30/60/90-day execution plan

First 30 days (stand up)

• Appoint the PM-23 control owner and executive sponsor.
• Draft and approve the Data Governance Body charter (include pm-23_odp.01 and pm-23_odp.02).
• Publish membership roster and quorum rules.
• Create templates: agenda, minutes, decision log, exception log.
• Schedule the first recurring meetings and define the intake mechanism.

Days 31–60 (operate and produce decisions)

• Hold meetings and produce minutes with at least one concrete decision per session (standards, ownership, exception disposition, or escalation).
• Build the initial governance backlog: highest-risk datasets, biggest gaps in ownership, largest third-party sharing flows.
• Define the “governance triggers” that require review (new dataset, new third-party sharing, major schema change, analytics/AI use case).

Days 61–90 (institutionalize and make assessable)

• Connect governance outputs to downstream change control (tickets, backlog items, policy updates).
• Run an internal mini-audit: verify artifacts exist, are versioned, and show traceability from decisions to implementation.
• Configure recurring evidence collection (for example in Daydream) so each meeting cycle automatically produces the audit package: roster, agenda, minutes, decisions, action tracker, and exceptions.

Frequently Asked Questions

Can an existing committee satisfy PM-23?

Yes, if you can show it meets the PM-23 requirement with defined composition and defined responsibilities, and you retain operating evidence like minutes and decisions. Update the charter to explicitly include the pm-23_odp.01 and pm-23_odp.02 elements. ¹

Do we need a Chief Data Officer for PM-23?

NIST does not require a specific title in the text provided. You need a Data Governance Body with clear authority and representation appropriate to your environment. ¹

What’s the minimum evidence an assessor will accept?

A signed charter, a roster, and a trail of meeting minutes/decision logs that show the body governs data decisions. If evidence does not show decisions and follow-through, expect questions. ¹

How do we handle data governance for third parties and SaaS?

Add explicit responsibility in pm-23_odp.02 for approving or governing data sharing rules and restrictions for third parties, then capture decisions and exceptions in a log tied to contracts and risk assessments. ¹

How do we prevent the body from becoming a “talking committee”?

Use an intake queue, require decision memos for agenda items, and maintain a decision log with action owners and due dates. Close actions in subsequent meetings and record closure in minutes.

Where should PM-23 live in our control framework and tooling?

Put PM-23 under your governance/control owner (often data governance or GRC) and track it like other assessable controls: owner, procedure, and recurring evidence artifacts. Daydream is a practical place to manage that mapping and evidence cycle. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5