Kick-starting your ServiceNow Technical Governance journey – Part 3 – Data Management

Stephen Farrar
ServiceNow Employee
ServiceNow Employee
‎04-13-2025 05:24 AM

Hi, I'm Stephen Farrar, a Solution Architect with Expert Services at ServiceNow, based in Brisbane, Australia.

 

I’ve recently been working with a customer who is brand new to ServiceNow and, as part of their initial implementation, I’ve been working with them to establish their ServiceNow Technical Governance processes.

 

Throughout this process I’ve found that for a new customer it’s not easy to get started with all the myriad pieces that need to be understood for technical governance, for some areas there are great documents describing what is needed, but no samples to get you started, in other areas we might have a sample but no real guidance about why to do one thing or another.

 

In this series of blog posts I intend to explore the four technical governance domains: Environment Management, Platform Management, Data Management and Development Management. Working through each domain I’ll highlight the different areas you need to consider for each, point out useful white papers and sample collateral that can be used, and suggest some priorities in each area for getting started.

 

This post covers the Data Management domain. Be sure to also check out the previous posts on Environment Management and Platform Management.

 

But first, why should you care what I have to say?

  • I am a ServiceNow Certified Master Architect
  • I’ve been working in ServiceNow Professional Services (Customer Excellence Group/Expert Services) for 9 years.
  • I’ve worked across a number of different roles during that time: Technical Consultant, Platform Architect, and currently a Solution Architect.
  • I’ve worked across a number of different industries and digital transformation projects during that time, including both Commercial enterprise and Regulated organisations.

 

And what even is ServiceNow Technical Governance anyway?

ServiceNow Technical Governance is the part of your ServiceNow Governance framework that’s concerned with guiding technical decisions regarding the ServiceNow platform. In doing so the intent is to ensure that the platform remains stable, secure and aligned with the overall vision and strategy for the platform. This should also maximise value realisation by ensuring all solutions are consistent and fit for purpose.

 

The Technical Governance Board is responsible for overseeing the development of technical governance policies and standards within the four technical governance domains: Environment Management, Platform Management, Data Management and Development Management.

 

For this series of blog posts I assume that you have the charter defined for your Technical Governance Board and are ready to start developing your policies and standards. I also assume that you have defined your initial ‘Golden Rules’ or guiding principles that will be the high-level guidance for technical decisions that come before the Technical Governance Board.

 

If you have access to Impact (Advanced or Total) through your ServiceNow subscription, you may also want to consider executing the ‘Technical Governance’ architecture accelerator.

 

Data Management

This domain defines the standards and practices for owning and managing data assets created, stored, and/or processed on the Now Platform. It sets the foundational standards and controls needed to maintain high-quality data that your ServiceNow implementation can reliably and securely access and use.

 

This domain works a little differently to the other domains, within Data Management we refer to eight different data types that are created, stored, processed on the Now Platform, and for each of these data types we need to define:

  • Data Ownership
  • Data Management
    • How we will manage data in ServiceNow
  • Data Architecture
    • Guidance and standards for how data is structured
  • Data Security
    • How we will manage encryption, access, Personally Identifiable Information, and enterprise-wide security protocols.
    • Works in tandem with the Platform Security discussed in Part 2 (Platform Management).

 

 

The Eight Data Types

  • Reporting data
  • Transactional data records
  • Product setup data
  • Common service data
  • Foundational platform data
  • Platform configuration data
  • Platform maintenance data
  • Integrations data

 

Each of these data types needs to be covered by your Data Management policies but note that you shouldn’t need separate policies for each. The success insight noted below contains more detail on each of these data types and examples of each.

 

 

Data Ownership

Having defined Data Owners helps us to know who is responsible for a particular type of data. The Data Owner decides (with relevant stakeholders) what data is needed and how it will be consumed. This is then enforced by the relevant policy.

 

  • Use the table on page 3 in the ‘Data Governance’ success insight (linked below) as a starting point for your Data Management policy to define your data types and your Data Owners.
  • Extend this to be clearly aligned to people/roles/groups in your organisation (but note that an owner should roll up to a single accountable person!).
  • Define Data Stewards in addition to the Data Owners – the Data Stewards manage the data on a day-to-day basis, whereas the Data Owner is responsible for it. (like the relationship between a Process Owner and a Process Manager)

 

 

Data Management

Within Data Management we’re concerned with three key areas:

  • Data quality assessment and improvement
  • Auditing of data
  • Data lifecycle management

 

Data quality assessment and improvement

How will your measure your data quality, and how will you improve it?

  • Consider the processes and standards you need to ensure data quality, e.g.:
    • Setting mandatory fields on processes where that field provides critical data for the process. (e.g. setting the CI on an Incident before that can be moved to the Resolved state).
    • Most of the time there will be good ‘anecdotal knowledge’ where data issues occur, start by trying to address these in your policies.
    • Where you aren’t aware of specific issues, consider:
      • Surveying process/product owners on their opinion of data quality within their process/product
      • Reviewing data quality dashboards that are available OOB (e.g. for CMDB Health)
      • These can help identify areas that need improvement, where the processes can be improved.
    • You may want to consider use of the ‘Data Certification’ plugin to create a regular checkpoint for data to be certified as accurate. The most obvious use case for this is within the CMDB, but this could be applied anywhere across the platform where data accuracy is paramount.
      • Note that some use cases may be able to be performed by the native CMDB Data Manger functionality now available, so be sure to review those capabilities against what you’re trying to achieve with Data Certification.

 

Auditing of data

  • Your policy needs to define how you will audit your data to track changes and potentially identify issues.
  • The most obvious area that requires this kind of auditing is Configuration Management (CMDB), given how this is integral to many processes on the Now Platform.
  • You can use the table in the ‘Data Governance’ success insight (page 6) as a starting point for an auditing cadence for Configuration Management
  • Consider what other data you are maintaining needs regular auditing and think about any industry or regulatory requirements might apply to your particular organisation.

 

Data lifecycle management

  • Here we’re concerned with ensuring that Data within the now platform is there for a purpose, is accurate and suitable for that purpose, and disposed of when no longer required.
  • Within your policy:
    • Consider any industry specific or regulatory needs for data retention.
    • Tie your data retention policy in with your data archiving strategy. By this I mean, when you understand your data retention requirements, ensure you define both archive timeframes and destroy timeframes. Doing this ensures not only that data that is not immediately required for the process (e.g. Incidents older than 12 months) is moved out of the main table to an archive table to improve performance, and then after the required retention period (e.g. 2 years), the data can then be destroyed – freeing up that platform storage.
    • Consider the need for storage of attachments within particular processes, this can be a much bigger concern from a platform storage perspective because some processes make much heavier use of attachments and may have longer retention periods – you may need an alternative storage solution outside of the platform for these attachments if your retention periods are high.
  • One possible example for a lifecycle management process/policy:
    • Operational Data – anything less than 2 years old, available in the main (e.g. Incident table) for fast access
    • Platform Archive – after the Operational Data period, retain in the platform archive for a period defined by the Product Owner (e.g. 1 year).
    • Off Platform Archive – this could be a custom solution where for example your store items that need to be retained e.g. for regulatory purposes for a long period, where you can move these to cheaper storage. This could be with or without easy means to retrieve these in case of an Audit or similar activity.
    • Offline Archive – pushing data to tape or other systems where it is no longer integrated or accessible via ServiceNow.
    • Deleted – the final step in the process, data that is no longer required is deleted, freeing up storage from ServiceNow or other systems it has been archived to.
  • See Data Archiving (Docs) for details on the Data Archiving capabilities within ServiceNow that can be utilised to realise your lifecycle management policy.
  • Be sure to consider all eight data types within your lifecycle management policy – often the biggest offenders I see within customers who are dealing with high storage use are Email (sys_email), Audit (sys_audit), and Attachments (sys_attachment).
  • There are some excellent considerations and guidance in the Optimize your ServiceNow estate Now-Create asset, this covers instance management, table management and data management.
  • The Platform Performance and Storage Optimization Now-Create asset gives further considerations of areas that can be targeted and how you can use platform features to assist.
  • You can find further deep dive information in Data Management - Archiving

 

 

Data Architecture

Data architecture is concerned with policies and standards for how data is structured. The key areas of focus here are:

  • The ServiceNow CMDB and the Common Service Data Model
  • Integrations and Data Synchronisation
  • Standards for shared tables / Foundation Data

 

ServiceNow CMDB and Common Service Data Model

This one is straightforward, your data management policy should define following ServiceNow best practices for implementing and using the ServiceNow CMDB and align with the Common Service Data Model. This one is a whole topic in itself, here I’ll point you to the following resources:

  • Plan your successful CMDB deployment ‘Success Insight’ on Now-Create – this walks through the stages of ensuring your CMDB is successful, having the right direction in place, the right team, building your configuration plan etc. Once you have these pieces in place, your configuration plan may become your policy for the CMDB, or it might be that the majority of pieces in your policy can point to your configuration plan.
  • You may also consider having a ‘Configuration Control Board’ – this is an extension of your Technical Governance Board specifically for managing your configuration plan and making decisions on how the CMDB will be managed, used etc. (this is further discussed in the ‘Plan your successful CMDB deployment’ success insight)
  • Full details of the Common Service Data Model can be found in the CSDM 4.0 White Paper (Draft) – the latest released version at the time of writing.

 

Integrations and Data Synchronisation

For this section we’re concerned with defining standards for how your ServiceNow platform integrates with other systems. Given this section is on Data Architecture our focus is on the data that is passing back and forth, however it’s important to look at integrations more holistically in their architecture – what patterns will be preferred and why? What principles do you need to apply to meet your organisational requirements and standards?

 

Your integration standards should define:

  • When MID Servers will be used (e.g. should all integrations go through MID servers wherever possible to keep traffic within your corporate network, or are point to point integrations with Saas providers preferred.)
  • How do you ensure that data that comes through integrations is clean?
  • What is the source of truth for data you are providing or consuming? What system owns that data, and who takes priority when there is a difference.

 

From a data synchronisation perspective, for situations where you’re not interacting in real time:

  • How often do you need to synchronise data?
  • Can data be batched, or does it need to be transmitted immediately

 

For your policy:

  • Define an ‘integration order of consideration’ to be ratified by the TGB and then used as guidance when integration discussions come up. Consider what is most supportable and quickest to implement, with least technical debt. The below image is an illustration I’ve used before:

Integration order of considerationIntegration order of consideration

 

  • Start with something like:
    1. Use of OOB integration mechanisms as the preferred choice whenever possible, e.g. IntegrationHub Spokes and Connectors, ServiceGraph Connectors
    2. Store Apps
    3. Third Party connectors (e.g. provided by a Third Party but not on the store – these have not been through the same ServiceNow certification process that store apps have, and may not have any support).
    4.  Custom Build
    5. Finally you might consider Robotic Process Automation, for systems where you can’t actually create an integration, but there is a need to automate a process.
  • The attached ‘Integration-Implementation.pptx’ from the previous Customer Success site, step 2b, contains more notes on this particular topic.
  • Have a look at the Integrations Workshop presentation on Now Create, this contains:
    • Leading practices for integrations that would be useful to include in your policy.
    • Different integration types that may need to be covered.
    • Integration patterns – contains a list of different integration scenarios your policy may need to cater to.
  • Consider what integration principles you need to define e.g. I would always recommend a principle of ‘least privilege’ e.g. the accounts and credentials created for the integration only have access to the minimum they need to be able to do their job. (and separate accounts must be created for each integration!)

 

Standards for shared tables / Foundation Data

Here we’re concerned with ensuring that there is a clearly defined process for how changes to core platform tables (e.g. core_company) and other shared tables, that are used by many different products on the Now Platform, are made. This becomes critically important as the platform expands within your organisation and different disparate parts of the business are relying on the same shared data.

  • The going in suggestion here is that your policy should define a list of core/shared tables, where any changes require a submission to your Technical Governance Board for approval to proceed.
    • Your TGB should contain stakeholders from across the organisation that may be affected by changes to the area in question.
    • At a minimum include the Core ‘Foundation’ tables defined in the Common Services Data Model: Company, Business Unit, Department, Locations, Users, Groups, Products (Models), Contracts, Business Process(es).
  • You may also want to consider other processes, e.g. auditing or automated scanning to track changes to these tables, in case these are made without approval.
  • Ensure you also include database views as these by design are often shared.

 

 

Data Security

Within Part 2 – Platform Management I covered Platform Security and various aspects there, this section builds on top of that section with specifics for Data Security. There are definitely overlaps here, and you may or may not want to have a separate policy specifically for Data – when you’re initially creating your policy, start with it integrated, and as the pieces get more complex then you can separate them out. Do note that when factoring in the eight data types, this can get complicated quickly. Try to stick to simple principles that can be applied across the board.

 

For Data Security we’re concerned with:

  • Encryption – do we need Encryption, for specific Data, for the whole platform?
  • Data Access Controls – both the use of Role Based Access Controls, as well as any other controls that need to be applied (e.g. if you need to separate data based on a users company for example), and auditing of changes to permissions and access
  • Personal Data – Personally Identifiable Information (PII) – will you be creating, storing or accessing this kind of data in your ServiceNow Platform? If so, consider what Enterprise, regulatory standards you need to abide by here, and whether there are any particular circumstances within ServiceNow that need additional controls.
  • Asset Data – e.g. technology systems in your CMDB, what standards does your organisation define for protection of this data?
  • Product specific, what specific security needs to be considered for the products you are deploying on your platform?
    • E.g. HR might have specific requirements on how you collect and store job applicant details and when you destroy that data.
    • The attached understanding-your-data.pdf file contains a good round up of considerations for different ServiceNow products.
  • Data sovereignty
    • What are the laws in the country where the data is physically stored
    • What Jurisdiction the data subject belongs to (e.g. GDPR)
    • You likely determined where your ServiceNow instance exists in terms of its datacenter pair during the purchase process and what this means for the data you are storing within it. This is worth reviewing if you’re not sure.

 

For your Data Security policy:

  • Review the resources from Part 2 – Platform Management – Platform Security.
  • Add areas for the items noted above.
  • Review the ‘Instance Definition Assement’ linked below for additional questions to answer.

 

 

How to get started?

  • Review the attached Define ServiceNow Data Governance (data-governance-definition.pdf) ‘Success Insight’ – this provides more details on all the areas noted above. (Unfortunately as the Customer Success site no longer exists many of the links in the document don’t work, you can always try to search for documents on Now Create however)
  • Work through the Instance Definition Assessment – this works through questions and additional details on the items noted above and gives you a starting point for what you already have defined and what you still need to answer.
  • Determine where you will store your Technical Governance policies – a ServiceNow Knowledge Base works well for this!
  • Use the ServiceNow Technical Policies Template to start documenting your policies
  • Consider the specific needs of your Industry, any existing data standards in your organisation, or the setup of your IT architecture.
  • Follow the individual steps noted in each section above.

 

 

That wraps it up for Part 3 – Platform Management, I hope this helps make it easy for you get started with defining your Technical Governance policies. Keep an eye out for Part 4 – Development Management coming soon, and if you haven’t already, check out Part 1 – Environment Management and Part 2 - Platform Management.

 

How have you found your ServiceNow Technical Governance journey? What resources have you found helpful? What do you wish you had known when you got started? Let me know in the comments below.

Preview file
108 KB
Preview file
5506 KB
Preview file
348 KB
  • 1,706 Views
3 Comments
Popular Blog Posts