Confused! which product to use for CMDB audit or compliance?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-27-2025 12:55 PM - edited 07-27-2025 12:57 PM
Confused! which product to use for CMDB audit or compliance?
ServiceNow provides following plugins
- Desired State Certification (com.snc.certification_desired_state)
- Activate: Architecture Compliance (com.snc.architecture_compliance)
- Activate: Data Certification (com.snc.certification_v2)
- And then we also have Policies (CI attestation, Certification) in CMDB workspace.
Still how many solutions ServiceNow provides? which solution to pick and when?
Every product looks the same.
(1) Which of the above actually shows data in CMDB health dashboard?
(2) If anyone has clarity on above list of products as to when to choose which, please share the details.
Thanks a lot in advance!!!!
PS - I have already gone through many community links and I couldnt find answer to above two questions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2025 02:21 AM
- All tools aim to validate data or compliance, but they work differently—some are automated, some are manual, some are lightweight, and some are governance-focused.
- They also overlap in UI and terminology (e.g., "certification", "attestation", "policy").
Final Tip
- If you're unsure or just starting:
- Use CMDB Workspace Attestation/Policies for lightweight needs.
- Choose Desired State Certification for automated compliance enforcement.
- Use Data Certification for formal periodic manual reviews.
- Use Architecture Compliance when aligning to enterprise architecture standards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2025 07:35 AM
Hi @Suggy
As per my understanding , here the details which might helps you.
Product / Plugin | Purpose | Typical Use | Shows in CMDB Health Dashboard? |
Data Certification (com.snc.certification_v2) | Periodic certification (attestation) of data by process/CI owners | E.g. "Verify server owner & location quarterly" | Does NOT directly update CMDB Health dashboard |
Desired State Certification (com.snc.certification_desired_state) | Automated, rule-based check of whether CI data is compliant with defined “desired state” | E.g. "All Windows servers must have antivirus installed" | Does NOT directly show in CMDB Health dashboard |
Architecture Compliance (com.snc.architecture_compliance) | Ensure solutions / designs comply with architectural standards | Used by enterprise architecture teams | Separate use case; not CMDB completeness / correctness |
CMDB Workspace Policies (in Data Manager) | Staleness, Completeness, Correctness, Compliance rules | Directly affects CMDB Health dashboard | Yes: these feed into CMDB Health dashboard submetrics |
1. Which one actually shows data in CMDB Health Dashboard?
* Only CMDB Workspace Policies → Staleness / Completeness / Correctness / Compliance
* They are configured under:
CMDB Workspace → Data Manager → Policies
* Scores roll up to:
CMDB Health Dashboard → Completeness, Correctness, Compliance, Staleness submetrics
The others (Data Certification, Desired State Certification, Architecture Compliance) do NOT directly impact CMDB Health dashboard scores
2. When to choose which?
Need | Best Fit |
Automatically evaluate CI data quality (mandatory fields, duplicates, staleness) and see on Health dashboard | CMDB Workspace → Policies (Completeness / Correctness / Compliance) |
Ask CI owners / app owners to periodically review and manually certify CI data | Data Certification |
Validate CI data against business rules / desired state, e.g. "All Windows servers must be domain joined" | Desired State Certification |
Validate architecture designs or projects before implementation against standards | Architecture Compliance |
They can co-exist:
* CMDB Workspace policies → keep CMDB data clean & healthy
* Data Certification → human attestation
* Desired State Certification → policy-driven technical checks
* Architecture Compliance → design governance
As per my understanding summary:
* For CMDB Health Dashboard → only CMDB Workspace Policies matter.
* Data Certification & Desired State Certification are additional governance layers, but do not feed CMDB Health scores.
* Choose based on need: health metrics, human attestation, rule enforcement, or design review.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Suggy,
For CMDB Health Dashboard, we use failure results from Desired State Certification, both the Desired State Audits using desired state templates and Desired State Scripted Audits as well.
Desired state allows for an automated way of resolving failures, where as Data Certification is 100% manual. We are transitioning away from Data Certification and have new products such as Data Manager to help you manage your CMDB more effectively.