Getting started: Gathering your foundation data

[Mary Hain]

One of the most important steps in any implementation journey for a ServiceNow risk product is preparing the foundation data.

In the enterprise risk management software space, data lays the groundwork for the success of the implementation. Having your data organized enables you (and your implementation partner) to hit the ground running.

Foundation data includes all the data that you need to support your risk program, including regulations, policies, and control objectives. Compiling foundation data helps you familiarize yourself with ServiceNow terminology.

Understanding the nuances around how your data fields map to those in ServiceNow products is the key to fully leveraging the platform and avoiding confusion. For example, ServiceNow uses the term “entity” to refer to any enterprise element for which controls and risks can be associated. You may define this as an asset, for example.

Investing in the integrity of your data enables the next step in implementation: making design decisions for assessments, processes, and forms. To proceed, you must recognize the attributes of your data to power your workflows.

Defining foundation data

As shown in the IRM business architecture image above, you will need to prepare several data components before the data can be integrated into the IRM workflows. All foundation data should be captured in a spreadsheet, consolidated, and ready to share with your implementation partner as you start operationalizing your ServiceNow product. This data includes:

• Authority documents - Regulations, certifications, frameworks, standards, and best practices that an organization chooses or are required for compliance with regulations. Authority documents are directly related to citations. The association of authority documents to citations is one-to-many.
• Citations - Records with the specific requirements cited by an authority document. The citation record relates authority documents and control objectives.  The association of citations to control objectives can be many-to-many.
• Policies - Documents that record high‐level principles or course of action to ensure both present and future decision-making is in line with the philosophy, objectives, and strategic plans of your organization. Policies also describe the consequences of failing to comply with the policy, the means for handling exceptions, and the way compliance with the policy is checked and measured. Policies are directly related to control objectives. The association of policies to control objectives is one-to-many. Through citation and control objective mapping, organizational policies are associated to regulations and specific regulatory requirements.
• Control objectives - Statements that describe what an organization will achieve when implementing a control to ensure the policy intent is met. They are often linked to industry-recognized practices, such as statutory, regulatory, or contractual requirements. Lastly, control objectives outline the actions necessary to protect the organization from risk or threats. The control objective record relates to policies and citations. The association of control objectives to citations can be many-to-many.
• Risk framework – An industry-approved or organizationally defined format and structure to identify, assess, manage, and monitor risks that could affect a company’s operations, assets, or objectives. Examples include the NIST Cybersecurity Framework (CSF) or Risk Management Framework (RMF). Risk frameworks are directly related to risk statements. The association of risk frameworks to risk statements is 1-to-many.
• Risk statements - General statements about potential risks or threats that could occur somewhere in an organization and disrupt business goals, objectives, or strategy. The risk statement record related is to risk frameworks and control objectives. The association of risk statements to control objectives can be many-to-many. The mapping of control objectives to risk statements should account for actions necessary to mitigate or protect the organization from the given potential threat.

Within the Now Platform, we refer to any element that requires risk management to be an entity.

• Entity - Any enterprise element for which the exposure to risk must be managed through control activities. In addition, an entity may be required to prove regulatory compliance and could be audited. For example: business units, servers, laptops, people, documents, or applications. Typically, these elements are tracked in the CMDB. An entity is also associated to authority documents, policies, control objectives, risk frameworks, and risk statements. When an entity is associated with a control objective, the system automatically generates a control that shows the control objective actions for that specific element. When an entity is associated with a risk statement, the system automatically generates a risk to show the potential threat for that specific element.
• Entity Class - Classification used to refer to a group of similar entities. For example: Asia/Pacific business unit, Linux servers, MacBook Pro. An entity class is associated with an entity to provide holistic reporting on organizational elements, risk, and compliance postures.

Additional foundation data is required for individual ServiceNow risk products.

Third-party Risk Management

• Third parties – The inventory of any external entity that is not part of the company but provides products, services, or support that the company relies on. Third parties can include vendors, suppliers, contractors, consultants, service providers, or any other external organization that interacts with the company in a business relationship.
• Third-party engagement – Data that documents the separate and distinct product or service provided to an organization by a third party. Each engagement requires different levels of risk data due to variations in the nature of the services provided, level of access to sensitive data or critical systems, and potential impact on your organization.

Privacy Management

• Information objects – Types of personal data that is exchanged between an application and a database, including:
  • Personal identifiers: Social Security numbers or other national identification numbers 
  • Contact information: Name, address, email address, phone number, IP address 
  • Financial information: Credit card numbers, banking information 
  • Health information: Information about a person's health 
  • Biometric information: Fingerprints, iris scans 
  • Media: Photographs or videos that include people              
• Processing activities - Records that document how an organization collects, processes, maintains, and shares personal data. These records can include business processes, applications, or other activities that involve personal data. 

Business Continuity Management (BCM)

• Business Impact Analysis (BIA) template – Data needed to identify the operational and financial impacts of disruptions to business processes, including natural disasters, cyberattacks, or other threats, as part of a template.
• BCM plan template – Data needed for a plan for maintaining or quickly resuming business operations following a disruption, as part of a template.

ESG Management

• Material topics – ESG themes your organization has prioritized to work on.
• Goals - Objectives that your organization wants to reach based on your topics.
• Targets – Metrics to track and measure the progress toward the goals.

A few tips to get you started

Here are a couple of tips to keep in mind as you prepare your data.

• Don’t be afraid to add or remove fields. Removing a field from the OOTB version is upgrade safe.
• Don't be afraid to request label changes. If you need that data to report

or to trigger visualization, it’s fine. You won’t break anything.

• It’s okay to create an entity even if it’s not in the CMDB.
• Your foundational data does not need to be fully defined and inventoried when starting your implementation journey. You can grow and expand all flavors of foundational data.

Once the data is uploaded and tested, you can begin making decisions about design, assessments, workflows, notifications, and reports. Now the fun part begins!

To learn more about any of these concepts or to read more about configuring your ServiceNow risk product, visit the ServiceNow Product Documentation website. To learn about tools to help you in your implementation journey, visit the Now Create website.