Domain separation in Privacy Management
Summarize
Summary of Domain separation in Privacy Management
Domain separation in the Privacy Management application within Governance, Risk, and Compliance (GRC) allows ServiceNow customers to segregate data, processes, and administrative tasks into logical groupings called domains. This separation ensures control over user access and visibility to domain-specific data, supporting multi-tenant use cases within a single ServiceNow instance. Domain separation is designed for organizations needing strict data segregation between business entities, customized processes per domain, and some global reporting or processes.
Show less
How Domain Separation Works in GRC
GRC supports data separation but does not fully separate business logic and processes. Records such as entities, controls, risks, and assessments are assigned the domain of the user who creates or generates them. Customers must ensure records are created at the appropriate domain level to ensure correct visibility and access.
For example, an entity that requires assessment by multiple subdomains should be created at a higher-level domain (e.g., Global) to enable access across those domains. Assigning records from a higher domain to users in lower domains is discouraged because those users may not have access, preventing assessment workflows from being initiated properly.
Key Features and Considerations
- Domain separation affects user interface elements, cache keys, reporting, rollups, and aggregations.
- By default, domain separation is applied to key tables like Task and Configuration Items, and can be extended to custom tables by adding a domain field.
- Platform tables (those with sys prefix) should not be domain separated to avoid unexpected behavior.
- Domain separation supports multi-tenancy within a single instance but shares some global properties and processes across domains (e.g., login page settings).
- Complete isolation of system properties requires separate instances rather than domain separation.
Practical Use Cases
Organizations can isolate GRC data by department or business area, ensuring that entities, controls, risks, and policies remain private to their respective domains. Users can toggle domain scope views to either restrict or expand visibility across domains as needed for cross-domain analysis or reporting.
For example, IT department GRC data can be separated from Finance department data, allowing independent control and privacy while still enabling consolidated reporting when appropriate.
Implementation and Setup
The instance owner is responsible for configuring the application to operate across multiple tenants, ensuring data flows into the correct domain at runtime. Proper domain assignment during record creation is critical for visibility and process execution. Domain visibility must be explicitly granted for users to access data outside their default domain.
This is an overview of domain separation and the Governance, Risk, and Compliance application Privacy Management. Domain separation enables you to separate data, processes, and administrative tasks into logical groupings called domains. You can control several aspects of this separation, including which users can see and access data.
Support level: Basic
- Business logic: Ensure that data goes into the proper domain for the application’s service provider use cases.
- The application supports domain separation at run time. The domain separation includes separation from the user interface, cache keys, reporting, rollups, and aggregations.
- The owner of the instance must set up the application to function across multiple tenants.
Sample use case: When a service provider (SP) uses chat to respond to a tenant-customer’s message, the customer must be able to see the SP's response.
For more information on support levels, see Application support for domain separation.
Overview of domain separation
- 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.
How domain separation works in GRC
- While GRC supports separation of data, separation of logic and process is not fully supported.
Many types of records in GRC are automatically generated through user processes. Entities, controls, risks, indicators, control tests, and processing activities are all fields that can be generated automatically. For records that are automatically generated (and for any GRC record that is manually generated), the domain of the record is the same as the domain of the user responsible for creating or generating the records.
Automatic generation should be kept in mind when working in a domain-separated GRC implementation. Users should be sure that they are creating or generating records at the right domain level so that they are visible to the right set of users.
For example, suppose you have a domain hierarchy that has Global at the top level followed by Top domain. Top domain, in turn, has two sub domains: Domain A and domain B.
- If you have an entity that you want to send a privacy assessment that must assessed by users in domains A and B, the entity should be generated or manually created at the global level. If the entity is created in Domain B, you will not be able to recreate the entity in Domain A due to indexing.
- If you have an entity that you want to be assessed by users in Top and Domain A, you can create the entity in Domain A.
Unless the entities are in the Global domain, users should not assign entities in a higher domain to users in a lower domain. In the example above, if you have an entity in the TOP domain, you should not assign it for privacy assessment to users in Domains A or B since those users would not have access to the assessment; thus the assessment questionnaire would not be generated.
Similarly, users should not assign control objectives 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
GRC data for IT can be separated from the GRC data of other departments. Each business area using the GRC application can have separate data that cannot be shared with other departments. Therefore each department can have its own entities, policies, controls, risks, and so on.
When looking at a control from the IT domain, the user can choose to expand the domain scope to show values from the Finance domain or collapse the domain scope to show only controls that match the IT 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.
[sys_dictionary]and
Dictionary Entry Override [sys_dictionary_override] tables) because it 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 you need complete and total separation of all system properties and do not require global reporting or global processes, separate instances are the best option.