Back to Core Schema

Core Schema v1.1 Governance Playbook

This playbook establishes the governance framework for operating and maintaining the Core Schema v1.1 in Jira Service Management Assets. It defines who owns what data, how data quality is measured and maintained, when reviews occur, and how issues escalate through the organization.

📖 For Core Schema v1.1 ☁️ JSM Cloud with Assets 📅 Updated February 2026

Overview

Effective CMDB governance is foundational for CMDB success. Organizations must identify and empower owners who are responsible for data quality, process enforcement, and overall stewardship of the CMDB.

Who should read this playbook:

  • CMDB Administrators responsible for schema governance and data quality
  • Configuration Managers overseeing configuration item lifecycle
  • Data Stewards accountable for specific object type accuracy
  • IT Leadership establishing governance policies
  • Compliance Officers ensuring audit readiness
  • Process Owners integrating CMDB with ITSM processes

What this playbook establishes:

  • Clear ownership model for all seven object types
  • Data quality standards with measurable KPIs
  • Review cadences from daily operations to annual strategic reviews
  • Escalation paths for governance failures
  • RACI assignments for key activities
  • Change management integration
  • Audit and compliance procedures

Prerequisites:

  • Core Schema v1.1 deployed in JSM Assets
  • Familiarity with Best Practices Guide
  • Understanding of organizational structure and reporting lines
  • Access to JSM Assets with appropriate permissions

Governance Structure

The CMDB Governance Board

The CMDB Governance Board is the executive body responsible for strategic direction, policy approval, and resource allocation. Unlike operational teams that manage day-to-day activities, this board focuses on ensuring the CMDB delivers value to the organization.

Board Composition:

Role Responsibility Meeting Attendance
CMDB Owner (Chair) Strategic direction, budget authority, executive decisions All meetings
Configuration Manager Operational governance, process compliance, quality metrics All meetings
IT Operations Lead Infrastructure perspective, operational impact All meetings
Business Systems Lead Application portfolio, business process integration All meetings
HR Systems Representative Person and organizational data accuracy Quarterly
Finance Representative Cost center governance, chargeback accuracy Quarterly
Security Representative Access controls, data classification compliance Quarterly
Facilities Representative Location data accuracy, physical asset placement Quarterly

Meeting Cadence:

  • Monthly: Core governance team (first five roles)
  • Quarterly: Full board with all representatives

Decision Authority:

The CMDB Governance Board has authority to:

  • Approve changes to object types and attributes
  • Establish data quality targets and standards
  • Allocate resources for data remediation
  • Resolve cross-department data ownership disputes
  • Authorize integrations with external systems

Data Ownership Matrix

Every object type in the Core Schema has designated ownership. The Data Steward is accountable for data accuracy, the Source System defines the authoritative data origin, and the Update Authority specifies who may modify records.

Person Object Type

Aspect Owner Details
Data Steward HR Systems Administrator Accountable for accuracy and completeness
Source System HRIS (Workday, BambooHR, etc.) Authoritative source for employee data
Update Authority Automated import from HR Manual updates only for emergency corrections
Validation Owner Department Managers Verify team member accuracy during quarterly reviews
Archive Authority HR Operations Approve status changes to Terminated

Data Flow:

HRIS -> Scheduled Import (daily) -> Person Objects -> Validation Report -> HR Review

Governance Notes:

  • New employees should appear within 24 hours of HRIS entry
  • Terminations must trigger immediate status update (same-day SLA)
  • Manager relationships require second-pass import after all persons exist
  • External contacts (Employment Type = "External") may be manually created by vendor relationship owners

Team Object Type

Aspect Owner Details
Data Steward IT Operations Manager Accountable for team registry accuracy
Source System Manual (no authoritative external source) Self-managed within JSM Assets
Update Authority Team Leads, IT Operations Create/update own team records
Validation Owner Department Heads Verify team assignments during quarterly reviews
Archive Authority IT Operations Manager Approve status changes to Inactive

Governance Notes:

  • Teams must have a Team Lead assigned within 7 days of creation
  • Inactive teams cannot be deleted if they have historical ticket assignments
  • Team naming conventions enforced by IT Operations during creation
  • On-Call Rotation URL must be validated monthly during operational reviews

Department Object Type

Aspect Owner Details
Data Steward HR Business Partner Accountable for organizational structure accuracy
Source System HRIS or Org Chart System Authoritative source for hierarchy
Update Authority HR Operations Structural changes require HR approval
Validation Owner Department Heads Verify own department attributes annually
Archive Authority HR Operations Approve status changes to Inactive (post-reorganization)

Governance Notes:

  • Department hierarchy must mirror official HR structure exactly
  • Department Codes must be unique and stable (survive name changes)
  • Reorganizations require a structured migration plan
  • Cost Center linkage validated by Finance quarterly

Location Object Type

Aspect Owner Details
Data Steward Facilities Manager Accountable for physical location data
Source System Facilities Management System Authoritative for addresses and building data
Update Authority Facilities Team, IT Operations (cloud regions) Split authority by location type
Validation Owner Regional Facilities Leads Verify location data semi-annually
Archive Authority Facilities Manager Approve status changes to Closed

Governance Notes:

  • Physical locations (Office, Headquarters, Data Center, Warehouse) owned by Facilities
  • Cloud/virtual locations (Data Center type for cloud regions) owned by IT Operations
  • Remote locations owned by HR (aligns with remote worker policies)
  • Timezone validation required for all non-Remote locations

Vendor Object Type

Aspect Owner Details
Data Steward Procurement Manager Accountable for vendor registry accuracy
Source System Procurement/Contract System Authoritative for vendor and contract data
Update Authority Procurement Team, Relationship Owners Procurement creates; owners update contacts
Validation Owner Relationship Owners Verify vendor accuracy at review cadence
Archive Authority Procurement Manager Approve status changes (Inactive, Under Review)

Governance Notes:

  • Every active vendor must have an internal Relationship Owner
  • Vendor Risk Level assessment required before Active status
  • Last Review Date triggers automated review reminders
  • Support contact information validated during each vendor review

Application Object Type

Aspect Owner Details
Data Steward Enterprise Architecture Lead Accountable for application portfolio accuracy
Source System Application Portfolio Management (if available) Or self-managed in JSM Assets
Update Authority Business Owners, Technical Owners Update own applications; EA creates new entries
Validation Owner Business Owners Verify application accuracy during annual reviews
Archive Authority Enterprise Architecture Lead Approve status changes to Deprecated/Retired

Governance Notes:

  • All applications require both Business Owner and Technical Owner
  • Criticality assessment follows standardized framework
  • Dependencies must be documented before production deployment
  • Data Classification mandatory for applications handling user data

Cost Center Object Type

Aspect Owner Details
Data Steward Finance Controller Accountable for cost center accuracy
Source System ERP/Financial System Authoritative source for codes and status
Update Authority Finance Team Only Finance may create or modify
Validation Owner Cost Center Owners Verify assignments during quarterly reviews
Archive Authority Finance Controller Approve status changes (Inactive, Frozen)

Governance Notes:

  • Cost Center Codes must match ERP exactly (no deviation)
  • New cost centers require Finance approval before creation
  • Frozen status blocks new assignments until Finance releases
  • Department-to-Cost Center mapping validated quarterly

Data Quality Rules

Data quality is quantified through four key dimensions: correctness, completeness, timeliness, and relationships. Each object type has specific quality rules with defined validation methods and remediation actions.

Person Data Quality Rules

Rule Validation Action on Failure Priority
Email must be unique AQL: Group by Email, count > 1 Merge duplicates; investigate source Critical
Active persons must have Department AQL: Status = "Active" AND Department is EMPTY Assign to appropriate department High
Managers must exist and be Active AQL: Manager.Status = "Terminated" Reassign to active manager High
Terminated persons have End Date AQL: Status = "Terminated" AND "End Date" is EMPTY Set End Date to termination date Medium
Employee ID required for Employees AQL: "Employment Type" = "Employee" AND "Employee ID" is EMPTY Obtain from HR system Medium

Quality Target: 98% of Person records pass all rules

Team Data Quality Rules

Rule Validation Action on Failure Priority
Active teams must have Team Lead AQL: Status = "Active" AND "Team Lead" is EMPTY Assign lead within 7 days Critical
Team Lead must be Active AQL: "Team Lead".Status != "Active" Reassign to active person High
Active teams should have Email AQL: Status = "Active" AND Email is EMPTY Create distribution list Medium
Active teams should have On-Call Rotation AQL: Status = "Active" AND "On-Call Rotation" is EMPTY Document or mark as N/A Low

Quality Target: 95% of Team records pass all rules

Department Data Quality Rules

Rule Validation Action on Failure Priority
No circular hierarchy Automated check during save Block save; notify user Critical
Active departments should have Head AQL: Status = "Active" AND Head is EMPTY Assign department head High
Department Code must be unique AQL: Group by Code, count > 1 Resolve duplicates High
Active departments should have Cost Center AQL: Status = "Active" AND "Cost Center" is EMPTY Coordinate with Finance Medium

Quality Target: 99% of Department records pass all rules

Location Data Quality Rules

Rule Validation Action on Failure Priority
Non-Remote locations need Timezone AQL: Type != "Remote" AND Timezone is EMPTY Set IANA timezone High
Parent locations must be Active AQL: "Parent Location".Status = "Closed" Reassign parent or close child High
Data Centers need Region AQL: Type = "Data Center" AND Region is EMPTY Assign region Medium
Office locations should have Address AQL: Type = "Office" AND Address is EMPTY Add street address Low

Quality Target: 95% of Location records pass all rules

Vendor Data Quality Rules

Rule Validation Action on Failure Priority
Active vendors must have Relationship Owner AQL: Status = "Active" AND "Relationship Owner" is EMPTY Assign internal owner Critical
Relationship Owner must be Active AQL: "Relationship Owner".Status != "Active" Reassign to active person High
Critical vendors need Risk Level AQL: (provides Critical apps) AND "Risk Level" is EMPTY Perform risk assessment High
Vendors need review within cadence AQL: "Last Review Date" < threshold by risk Schedule review Medium

Quality Target: 95% of Vendor records pass all rules

Application Data Quality Rules

Rule Validation Action on Failure Priority
Active apps must have Owning Team AQL: Status = "Active" AND "Owning Team" is EMPTY Assign owning team Critical
Active apps must have Business Owner AQL: Status = "Active" AND "Business Owner" is EMPTY Assign business owner Critical
Owners must be Active persons AQL: "Business Owner".Status != "Active" Reassign to active person High
Critical apps require SSO AQL: Criticality = "Critical" AND "SSO Enabled" != true Implement SSO or document exception High
Confidential apps require MFA AQL: "Data Classification" in ("Confidential", "Restricted") AND "MFA Required" != true Implement MFA or document exception High

Quality Target: 95% of Application records pass all rules

Cost Center Data Quality Rules

Rule Validation Action on Failure Priority
Code must be unique AQL: Group by Code, count > 1 Resolve with Finance Critical
Code format must match ERP Regex validation Correct code format High
Active cost centers should have Owner AQL: Status = "Active" AND Owner is EMPTY Assign budget owner High
Owner must be Active AQL: Owner.Status != "Active" Reassign to active person Medium

Quality Target: 100% of Cost Center records pass all rules (financial data requires perfect accuracy)

Review Cadences

CMDB governance requires multiple review cycles at different frequencies. Each cadence serves a specific purpose and involves different stakeholders.

Daily Reviews

Purpose: Operational health monitoring and urgent issue detection

Activities:

Activity Owner Trigger Deliverable
Data quality dashboard check Configuration Manager Morning standup Exception report
New record review Data Stewards (each type) Automated notification Validation confirmation
Terminated person processing HR Operations HR termination event Access revocation confirmation
Orphan detection Configuration Manager Automated scan Orphan report

Automation Support:

  • Daily automated AQL scans for critical rule violations
  • Notifications to Data Stewards for records requiring attention
  • Dashboard refresh with quality metrics

Weekly Reviews

Purpose: Trend analysis and remediation planning

Activities:

Activity Owner Day Deliverable
Quality trend review Configuration Manager Monday Trend report
Remediation progress Data Stewards Wednesday Status update
Integration health check Systems Administrator Thursday Integration status
Escalation review CMDB Owner Friday Escalation decisions

Meeting: 30-minute weekly CMDB operations sync (Configuration Manager leads)

Monthly Reviews

Purpose: Strategic progress, cross-team coordination, policy compliance

Activities:

Activity Owner Week Deliverable
CMDB Governance Board meeting CMDB Owner 1st week Meeting minutes, decisions
Object type deep dive (rotating) Relevant Data Steward 2nd week Health assessment
Integration review Systems Administrator 3rd week Integration roadmap
Documentation update Configuration Manager 4th week Updated procedures

Metrics Report Contents:

  • Quality scores by object type (target vs. actual)
  • Record counts and growth trends
  • Integration success rates
  • Top 10 data quality issues
  • Remediation SLA compliance

Quarterly Reviews

Purpose: Full governance board review, ownership validation, strategic alignment

Activities:

Activity Owner Deliverable
Full Governance Board meeting CMDB Owner Strategic decisions
Ownership matrix validation All Data Stewards Confirmed ownership
Cost Center reconciliation Finance Controller Verified assignments
Department structure validation HR Business Partner Structure confirmation
Vendor review (Critical/High risk) Procurement Manager Updated risk assessments
Application portfolio review Enterprise Architecture Lead Portfolio health report

Critical Vendor Review Schedule:

  • Critical vendors: Reviewed every quarter
  • High-risk vendors: Reviewed every 6 months (2nd and 4th quarter)
  • Medium-risk vendors: Annual review (4th quarter)
  • Low-risk vendors: Annual review or at contract renewal

Annual Reviews

Purpose: Strategic planning, governance framework assessment, major improvements

Activities:

Activity Owner Quarter Deliverable
Governance framework review CMDB Owner Q1 Updated governance policy
Schema evolution planning Configuration Manager Q1 Schema roadmap
Full data quality audit External/Internal Audit Q2 Audit report
Stakeholder satisfaction survey CMDB Owner Q3 Survey results, action plan
Annual governance report CMDB Owner Q4 Executive summary

Escalation Paths

Clear escalation paths ensure issues are resolved at the appropriate level. Escalation is not failure; it is recognition that an issue requires different authority or expertise.

Escalation Levels

Level Authority Response Time Scope
L1: Data Steward Data corrections, routine updates 1 business day Single object type
L2: Configuration Manager Cross-type issues, process exceptions 2 business days Multiple object types
L3: CMDB Owner Policy decisions, resource allocation 5 business days Strategic issues
L4: Governance Board Major policy changes, budget decisions Next scheduled meeting Organization-wide

Escalation Triggers

Escalate to L2 (Configuration Manager) when:

  • Issue spans multiple object types
  • Data Steward lacks authority to resolve
  • Issue persists after two remediation attempts
  • External system integration is involved
  • Issue affects critical business processes

Escalate to L3 (CMDB Owner) when:

  • Configuration Manager requires policy decision
  • Resource allocation needed (budget, headcount)
  • Cross-department dispute requires executive resolution
  • Issue has regulatory or compliance implications
  • SLA breach occurs

Escalate to L4 (Governance Board) when:

  • Schema structural changes required
  • New object types or major attribute changes proposed
  • Integration with new enterprise system needed
  • Governance policy modification required
  • Issue unresolved after 30 days at L3

Escalation Procedure

  1. Document the issue: Record in designated tracking system (Jira issue recommended)
  2. Notify next level: Send email/message with issue summary, actions taken, recommendation
  3. Transfer ownership: Higher level acknowledges and assumes responsibility
  4. Track progress: Original reporter monitors resolution
  5. Confirm closure: Both levels confirm issue resolved
  6. Retrospective: For L3+ escalations, document lessons learned

Emergency Escalation

For critical data quality issues affecting production systems:

  1. Immediate notification: Contact Configuration Manager by phone/Slack
  2. Emergency assessment: 30-minute response SLA
  3. Emergency CAB: If change required, convene Emergency Change Advisory Board
  4. Resolution: Implement fix with proper change documentation
  5. Post-incident review: Within 48 hours of resolution

RACI Matrix

The RACI matrix defines Responsible (does the work), Accountable (owns the outcome), Consulted (provides input), and Informed (kept updated) assignments for key CMDB governance activities.

Object Type Management

Activity Configuration Manager Data Steward CMDB Owner IT Operations
Create new object type R C A I
Add attribute to type R C A I
Remove attribute R C A C
Change attribute type R C A C
Update allowed values R A I C
Archive object type R C A I

Data Quality Management

Activity Configuration Manager Data Steward CMDB Owner Business Owner
Define quality rules R C A C
Execute quality scans R I I I
Remediate data issues C R I C
Report quality metrics R C A I
Set quality targets C C A I
Approve exceptions C C A R

Integration Management

Activity Configuration Manager Systems Admin CMDB Owner Source System Owner
Design integration C R A C
Implement integration I R I C
Monitor integration R C I I
Troubleshoot failures C R I C
Approve data mapping A C I R

Governance Activities

Activity Configuration Manager Data Steward CMDB Owner Governance Board
Monthly metrics report R C A I
Quarterly ownership review R A C I
Annual governance review R C A A
Policy changes C C R A
Escalation resolution R C A I

Change Management Integration

Activity Configuration Manager Change Manager CAB Data Steward
Impact assessment R A C C
Pre-change validation R C I I
Post-change verification R C I C
Rollback decision C A R I
Documentation update R I I C

Change Management Procedures

CMDB changes must follow controlled procedures to maintain data integrity. Changes are categorized by risk and follow different approval paths.

Change Categories

Category Description Approval Examples
Standard Pre-approved, low-risk Auto-approved Add team member, update contact info
Normal Medium risk, follows process Configuration Manager New team, new location, new vendor
Major High impact, requires CAB Change Advisory Board New object type, schema changes
Emergency Urgent, production impact Emergency CAB Critical data fix, security issue

Standard Changes (Pre-Approved)

The following changes are pre-approved and do not require individual approval:

Person:

  • Update phone number, job title
  • Update location assignment (within same region)
  • Update manager (within same department)

Team:

  • Update description, Slack channel
  • Update on-call rotation URL
  • Update team email

Application:

  • Update URL, description
  • Update SSO/MFA status (to true only)
  • Add dependencies

Vendor:

  • Update contact information
  • Update support portal URL

Normal Change Procedure

  1. Request: Submitter creates change request in Jira
  2. Classification: Configuration Manager classifies change category
  3. Impact Assessment: Identify affected records, relationships, integrations
  4. Approval: Configuration Manager approves (or escalates to CMDB Owner)
  5. Scheduling: Schedule change window
  6. Implementation: Execute change
  7. Verification: Validate change successful
  8. Closure: Document and close change request

SLA: Normal changes completed within 5 business days

Major Change Procedure

  1. RFC Submission: Formal Request for Change with business justification
  2. Technical Review: Configuration Manager assesses technical impact
  3. CAB Review: Change Advisory Board reviews at next scheduled meeting
  4. Approval/Rejection: CAB provides recommendation; CMDB Owner approves
  5. Implementation Plan: Detailed rollout plan with rollback procedure
  6. Change Window: Execute during approved maintenance window
  7. Post-Implementation Review: Validate success; document lessons learned

SLA: Major changes follow CAB schedule (typically bi-weekly meetings)

Bulk Import/Update Procedures

Bulk data changes require additional controls:

1. Pre-Import Validation:

  • Row count verification
  • Duplicate detection
  • Reference resolution check
  • Required field validation

2. Sandbox Testing:

  • Import to sandbox environment first
  • Validate object counts
  • Verify reference resolution
  • Test AQL queries
  • Confirm automation triggers

3. Production Import:

  • Schedule during low-activity window
  • Import in dependency order
  • Monitor progress
  • Validate completion

4. Post-Import Verification:

  • Run quality scans
  • Verify record counts
  • Test critical queries
  • Confirm integrations functioning

Metrics and KPIs

Effective governance requires measurable outcomes. These KPIs align with industry-standard CMDB health metrics: completeness, correctness, timeliness, and relationship integrity.

Primary KPIs

KPI Description Target Measurement Frequency
Overall Data Quality Score Weighted average of all quality rules passed 95% Daily
Completeness Rate Required fields populated / Total required fields 98% Weekly
Accuracy Rate Records verified correct / Total verified 97% Monthly
Timeliness Records updated within SLA / Total updates 95% Weekly
Relationship Integrity Valid references / Total references 99% Daily

Object Type-Specific KPIs

Object Type Key Metric Target Measurement
Person Terminated within 24h SLA 98% Daily
Team Teams with assigned lead 100% Weekly
Department Hierarchy depth <= 5 levels 100% Monthly
Location Timezone defined (non-Remote) 100% Monthly
Vendor Review completed within cadence 90% Monthly
Application Ownership complete (all 3 roles) 95% Weekly
Cost Center ERP code match rate 100% Monthly

Operational KPIs

KPI Description Target Measurement
Orphan CI Rate CIs without valid references < 2% Weekly
Stale Data Rate Records not updated in 180+ days < 10% Monthly
Duplicate Rate Duplicate records detected < 1% Weekly
Integration Success Rate Successful syncs / Total syncs 99% Daily
Escalation Resolution Time Average time to resolve escalations < 5 days Monthly

Governance KPIs

KPI Description Target Measurement
Review Completion Rate Scheduled reviews completed 100% Monthly
SLA Compliance Changes completed within SLA 95% Monthly
Governance Board Attendance Member attendance rate 90% Quarterly
Policy Exception Rate Approved exceptions / Total requests < 5% Quarterly
Audit Finding Closure Findings resolved within 30 days 95% Quarterly

Reporting

Daily Dashboard:

  • Quality scores by object type
  • Critical violations requiring immediate attention
  • Integration status
  • Records modified in last 24 hours

Weekly Report:

  • Quality trend (week-over-week comparison)
  • Top 10 data quality issues
  • Remediation progress
  • Escalation summary

Monthly Report:

  • Full KPI scorecard
  • Trend analysis (3-month rolling)
  • Object type health assessment
  • Integration performance
  • Governance activities summary

Quarterly Executive Summary:

  • Strategic KPI performance
  • Year-over-year trends
  • Business value delivered
  • Resource requirements
  • Recommendations

Audit Readiness

Regulatory compliance requires maintaining audit-ready documentation and demonstrating controlled processes. A CMDB streamlines audit processes by providing a holistic and up-to-date view of all IT assets, their configurations, and historical changes.

Audit-Ready Documentation

Document Owner Location Update Frequency
Governance Policy CMDB Owner SharePoint/Confluence Annual
Data Ownership Matrix Configuration Manager This playbook Quarterly
RACI Matrix Configuration Manager This playbook Quarterly
Quality Rules Configuration Manager Documented in JSM As needed
Integration Documentation Systems Administrator Technical wiki As needed
Change Logs Configuration Manager Jira (linked issues) Real-time
Meeting Minutes Governance Board Secretary SharePoint/Confluence Per meeting

Evidence Collection

Auditors typically request evidence in these categories:

1. Access Controls

  • Who has access to modify CMDB data?
  • How are permissions assigned and revoked?
  • Evidence: JSM permission schemes, access reports

2. Change History

  • What changes were made, when, and by whom?
  • How are changes approved?
  • Evidence: JSM object history, Jira change requests

3. Data Quality

  • How is data accuracy verified?
  • What quality controls exist?
  • Evidence: Quality scan results, remediation tickets

4. Integration Controls

  • How is data synchronized from source systems?
  • What validation occurs during integration?
  • Evidence: Integration logs, validation reports

5. Governance

  • Who is responsible for data accuracy?
  • What review processes exist?
  • Evidence: Meeting minutes, ownership matrix, review records

Audit Preparation Checklist

Before an audit:

  • Update all governance documentation
  • Export 12 months of change history
  • Generate quality trend reports
  • Compile integration success metrics
  • Prepare ownership matrix with current names
  • Gather meeting minutes from governance sessions
  • Document any open remediation items
  • Prepare exception documentation
  • Brief Data Stewards on potential questions
  • Designate audit liaison

Common Audit Findings and Prevention

Finding Prevention Evidence
Undocumented data owners Maintain ownership matrix This playbook
Missing change approval Enforce change process Jira workflow
Stale data Implement review cadences Review records
Unvalidated integrations Monthly integration checks Validation reports
Unclear access controls Document permission model Permission schemes

Troubleshooting Guide

Common Governance Issues

Issue: Data Steward Unavailable

  • Symptom: Remediation tasks not addressed; quality declining
  • Cause: Staff change, vacation, overloaded
  • Resolution: Designate backup stewards for each object type; escalate to L2
  • Prevention: Maintain backup assignments in ownership matrix

Issue: Quality Scores Declining

  • Symptom: Week-over-week quality degradation
  • Cause: Source system issues, process breakdown, integration failure
  • Resolution: Identify root cause through trending; address specific failures
  • Prevention: Automated alerts when scores drop below threshold

Issue: Ownership Disputes

  • Symptom: Multiple teams claim (or disclaim) responsibility
  • Cause: Unclear boundaries, organizational changes
  • Resolution: Escalate to L3; CMDB Owner makes binding decision
  • Prevention: Document ownership boundaries; review during reorgs

Issue: Integration Failures

  • Symptom: Source system data not appearing in CMDB
  • Cause: API changes, authentication issues, network problems
  • Resolution: Systems Administrator troubleshoots; restore last known good
  • Prevention: Monitoring, alerting, scheduled integration health checks

Issue: Circular Reference Detected

  • Symptom: Error when saving hierarchical relationship
  • Cause: Parent/child misconfiguration
  • Resolution: Map hierarchy on paper; correct errant reference
  • Prevention: Pre-save validation rules

Issue: Bulk Import Failures

  • Symptom: Import completes with errors; missing records
  • Cause: Data format issues, reference resolution failures
  • Resolution: Review import logs; correct source data; re-import
  • Prevention: Sandbox testing, pre-import validation

Recovery Procedures

Data Corruption Recovery:

  1. Identify scope of corruption
  2. Stop any active integrations
  3. Export current state for analysis
  4. Restore from last known good backup (if available)
  5. Re-import from source systems
  6. Validate restoration
  7. Resume integrations
  8. Conduct post-incident review

Integration Recovery:

  1. Disable failed integration
  2. Review error logs
  3. Test connectivity to source system
  4. Resolve authentication/permission issues
  5. Run test import (sandbox)
  6. Resume production integration
  7. Validate data synchronization
  8. Document root cause

FAQ

Q1: Who decides when a new object type is needed?

Answer: The CMDB Governance Board makes decisions on new object types. The process is:

  1. Requestor submits RFC with business justification
  2. Configuration Manager performs technical assessment
  3. Governance Board reviews at quarterly meeting (or emergency meeting if urgent)
  4. Board approves/rejects based on: business value, maintenance burden, integration requirements
  5. If approved, Configuration Manager implements with appropriate testing

New object types should only be added to Core Schema if the data is true master data referenced by multiple domain schemas. Domain-specific objects belong in domain schemas.

Q2: How do we handle data quality exceptions?

Answer: Exceptions are handled through a formal process:

  1. Requestor documents exception with business justification
  2. Data Steward reviews and provides recommendation
  3. CMDB Owner approves/rejects exception
  4. Approved exceptions documented with expiration date (maximum 1 year)
  5. Exceptions tracked and reported to Governance Board quarterly
  6. Expired exceptions must be renewed or resolved

Exceptions should be rare. A high exception rate (>5%) indicates a process or rule that needs revision.

Q3: What happens when an organization reorganizes?

Answer: Reorganizations require structured migration:

  1. HR announces reorganization with effective date
  2. Configuration Manager creates migration plan
  3. Governance Board reviews (major reorg) or CMDB Owner approves (minor)
  4. Execute migration:
    • Create new departments/teams first
    • Update Person.Department references
    • Update Team.Department references
    • Set old departments to Inactive (do not delete)
  5. Validate post-migration
  6. Communicate changes to stakeholders
  7. Archive migration documentation

Critical: Never delete departments with historical references. This breaks audit trails and relationship history.

Q4: How do we measure governance success?

Answer: Governance success is measured through:

  • Leading indicators: Review completion rates, escalation counts, SLA compliance
  • Lagging indicators: Overall quality scores, audit findings, stakeholder satisfaction
  • Business outcomes: Incident resolution time (faster with accurate CMDB), change success rate, compliance audit results

Q5: What is the difference between Data Steward and Data Owner?

Answer: These roles have distinct responsibilities:

  • Data Steward: Operational accountability for data accuracy within an object type. Executes quality rules, performs remediation, reports issues. Example: HR Systems Administrator is Data Steward for Person.
  • Data Owner: Business accountability for specific records. Ensures their data is accurate and complete. Example: Business Owner for an Application ensures that Application record is correctly maintained.

The Data Steward sets the standards; Data Owners ensure their records meet those standards.

Q6: How often should we review the governance framework itself?

Answer: The governance framework should be reviewed:

  • Annually: Full governance framework review (Q1 activity)
  • After major incidents: If governance failure contributed to incident
  • After reorganizations: When ownership structures change
  • After audits: When findings indicate framework gaps

The annual review should assess: Are the right people involved? Are review cadences appropriate? Are escalation paths working? Is the framework enabling business value?

Q7: How do we onboard a new Data Steward?

Answer: New Data Steward onboarding:

  1. Review this governance playbook (required reading)
  2. Shadow current steward for 2-4 weeks
  3. Review data quality rules for their object type
  4. Attend Governance Board meeting as observer
  5. Gradually assume remediation responsibilities
  6. Full handover after Configuration Manager approval
  7. Update ownership matrix
  8. Announce to stakeholders

Onboarding typically takes 4-6 weeks for full competency.

Related Resources

This playbook is part of the Core Schema v1.1 documentation suite:

For platform documentation:

Version History

Version Date Author Changes
1.0 February 2026 Schema Forge Team Initial release for Core Schema v1.1
Previous Document
← JSM Forms Specification
Next Document
Automation Examples →