Domain separation and Vendor Risk Management

This is an overview of domain separation as it pertains to Vendor Risk Management (VRM) and how it relates to VRM data separation. Domain separation allows you to separate data, processes, and administrative tasks into logical groupings called domains. You can then control several aspects of this separation, including which users can see and access data.

Overview

Domain separation in this application is supported at the Data only level, meaning it supports the data security model of separating visibility of data from one domain to another. To learn more, see Application support for domain separation.

Domain separation is best for those customers who:
  • Need to enforce absolute data segregation between business entities (data separation).
  • Customize business process definitions and user interfaces for each domain (delegated administration).
  • Maintain some global processes and global reporting in a single instance.
These users can choose to expand or collapse the domain scope to show or hide data from other domains. For example, vendor data for Workday can be separated from the vendor data of other vendors. Each vendor using the VRM application can have separate data that cannot be shared with other vendors. Note: Users always have access to data from domains that have been explicitly granted to them by domain visibility.

How domain separation works in VRM

  • While VRM supports separation of data, separation of logic and process is not fully supported.

  • Many types of records in VRM are automatically generated through user processes. Profiles, controls, risks, indicators, control tests are all fields that can be generated automatically. For these records that are automatically generated (and for any VRM record that is manually generated), the domain of the record will be the same as the domain of the user responsible for creating or generating the records.

    When working in a domain-separated VRM implementation, this should be kept in mind. Users should be sure that they are creating / generating records at the right domain level so that it is visible to the right set of users.

    For example, suppose you have domains that look like:

    • Global
      • TOP
        • Domain A
        • Domain B
    • If you have a risk or control that you want to be assessed by users in domains A and B, the risk or control should be generated or manually created at the global level. If the risk or control is created in Domain B, you will not be able to recreate the risk or control in Domain A due to indexing.
    • If you have a risk or control that you want to be assessed by users in TOP and Domain A, you can create the risk or control in Domain A.
  • Unless the risks and controls are in the Global domain, users should not assign risks or controls in a higher domain to users in a lower domain. Using the example above, if you have a control in the TOP domain, you should not assign it for attestation to users in Domains A or B since those users would not have access to the control; thus the attestation or assessment questionnaire would not be generated.
  • Similarly, users should not assign policy statements and risk statements in a higher domain to attestations and assessments in a lower domain otherwise the attestation or assessment questionnaire would not be generated.

Use case: domain separation in Vendor Risk Management

Vendor data for Workday can be separated from the vendor data of other vendors. Each vendor using the VRM application can have separate data that cannot be shared with other vendors. Each vendor can have their own vendor contacts, vendor risk assessments, issues, tasks, and so on.

When looking at a vendor risk assessment from Workday domain, the user can choose to expand the domain scope to show assessments from the Amazon domain or collapse the domain scope to show only assessments that match the Workday domain.

By default, domain separation adds a domain field to the Task [task] and Configuration Items [cmdb_ci] tables and their extensions.

You can extend domain separation to any new tables you create by adding a sys_domain field to the table's dictionary definition. By default, the system-only domain separates platform and baseline application tables where appropriate.

Warning: ServiceNow does not recommend domain-separating platform tables (any table with the sys_ prefix such as the Dictionary Entry [sys_dictionary] and Dictionary Entry Override [sys_dictionary_override]tables) as this can produce unexpected results.

In this use case, client scripts, business rules, workflows, processes and so on can be domain-separated.

While the behavior offered with domain separation provides multi-tenancy support, multi-tenancy is still contained within a single instance. This means that some global properties, some global data, and some global processes are shared across all domains. For example, the system’s “Remember me” option on the login page is global and cannot be specified per domain.

If a complete and total separation of all system properties is needed and does not require global reporting or global processes, separate instances are the best option.