Build an entity framework

Entity type scoping

Entity type scoping is the process of determining which dynamic categories are needed by an
organization for continuous monitoring. There are many approaches that an organization can take
when entity type scoping. These approaches vary based on the organization’s risk and compliance
area of focus. Most organizations will be IT or enterprise risk and compliance-focused.

To learn about two common entity type scoping approaches. Most customers will likely use a
combination of approaches.

Operational

Scoping is done at the specific object level, such as at the individual user, project, or CI level. This
approach is useful for industries or scenarios that can’t have any control failures, such as within the
healthcare industry.

Example:

 There is a policy requiring all point-of-sale (POS) devices to be examined once a month for
signs of tampering.

 Entities are generated using an entity filter with the source table: Point of Sale Device
[cmdb_ci_pos]. Additional filter conditions will only generate active, operational records
within the Point of Sale Device table.

Strategic

Scoping is done at a higher-level, such as using business processes or services. This approach doesn't
have the individual level of assurance found at the operational level.

Consider that an organization may have thousands of systems. Leaders may not want thousands of
controls to test configuration. Using fewer entities, they can strategically scope to ensure every
standard system configuration is identical from system to system.

Example:

 Customer-facing teams must follow many procedures and processes when handling
payments from clients.

 Compliance attestation and monitoring at individual employee level is not required.

 Entities are generated using an entity filter with the condition, cmdb_ci_business_process =
customer payment handling, from the source table: Business Process [cmdb_ci_pos].
Scoping with entity filters

Entity filters automate the process of creating entities. An entity filter looks at existing ServiceNow
data in a source table and generates entities that meet entity filter conditions.

Setting the source table

The first field defined on the entity filter record is the table. The table is the source location for
generating entities. Records within that table are the original pool.

Commonly leveraged tables when creating entity types often begin with cmn_ for common
tables, sys_ for system tables, cmdb_ci for cmdb tables, and core_ for core tables.

 cmn_location

 sys_user

 cmdb_ci_building_facility

 core_company

Setting the filter conditions

Filter conditions, added to the entity filter, further specify which records within the source table
should generate as entities.

AGT example

Aglow Travel Co. needs entity types for travel branches, customer-facing departments, and business
applications.

Each entity type has a source table and filter conditions to generate relevant entities.
Entity ownership

Entity owners are determined on the entity filter. Automation is available for keeping entity owners
in sync with a field on the source record.

For example, travel branch entities are generated from records in the Buildings
[cmdb_ci_building_facility] table.

 Entity ownership is assigned from the Managed by values on the Buildings table.

 When the Auto-update owner field is set to true on the entity filter, the entity owner will
update when the Managed by field value changes.

Entity ownership syncs with risk and control ownership

In addition to being able to sync the owner between the source record and the entity, it is also
possible to sync the entity owner with the controls and risks related to the entity. Customers can use
these two levels of synchronization together or independently. In the baseline, the synchronization
between controls/risk owners and the entity owner is active.

Take another example of AGT's Corporate Accounts entity type with its entities and associated
controls and risks.
Entity classes

Entity classes

Entity classes are used to add conceptual information about the entity, like a metadata tag. Entity
classes are stored in the Entity Class table [sn_grc_profile_class]. An entity can only be assigned to
one entity class. This is one reason why a company should take time to consider its entity class
taxonomy.

There is more than one way to create an entity class. An entity class can be created directly from the
Entity Class module or a class can be created during the process of defining an entity filter on the
entity type.

Entity class rules

Entities can be created manually. If using this method, entity class rules can be used to assign a class.

Entity class rules relate an entity class to a table. There can only be one entity class rule linked to a
table. If an entity is generated from a record within that table, outside of an entity filter, the entity is
assigned the entity class for which the entity class rule has been created.

Entity relationships

How are entity types and entities used to create controls and risks?

Entity scoping uses automation through entity types to map entities to a set of controls and risks.
Review how the relationships between entity types and entities automatically generate scoped
controls and risks.
Entities can be individually related to a policy or control objective. When entities are created and
associated individually, a control record is created for that entity alone.

New entities may get automatically added to an entity type as an organization grows. For example,
more servers may get added to the Windows Server entity type as new servers are added to the
environment. When these entities are created, controls for each new entity are also created. This
happens because the control objective has been scoped with the entity type and the "Creates control
automatically" field is set to true.

Just like the automatic generation of controls for new entities; risks are also automatically generated
when the entity type is related to a risk statement.

Entities can be individually related to a risk statement. When entities are created and associated
individually, a risk record is created for that entity alone.

Entities are also related to audits. When creating an audit engagement, individual entities are
selected to be included in the audit. Audits do not leverage entity types.
Entity types have dynamic capabilities

Since entities are generated for an entity type from a defined entity filter, new records created in the
source table that match the entity filter conditions generate new entity records within that entity
type.

The reverse is true too. If a source record no longer meets an entity filter condition, its entity record
is deactivated, and its associated risks, controls, indicators, and test plans retire. If the entity ever
gets reactivated again, the associated controls and risks revert to the Draft state.

However, it is important to note that if the entity is associated with more than one entity type and
different filter conditions were used, the entity may not be completely deactivated.

Risk identification

Risk identification is the process of finding, describing, and recognizing an uncertainty that may help
or prevent an organization from achieving its objectives.

Organizations build their risk registers based on industry, company culture, and other factors. The
risk teams talk to different stakeholders and business owners to identify the risks that could impact
their organization.

To streamline this process, ServiceNow provides a risk identification process as part of the advanced
risk product.

Using risk identification, the risk managers can design and send a questionnaire to respective
business owners. Based on the qualitative responses, the risk manager can identify and map the
relevant risks.

Risk identification questionnaire

Risk identification questionnaire is designed to gather information about an entity from the business
owners

Risk identification configuration

Select + to learn more about the Risk Identification configuration form.