Controls and Risk extend from the Items table. Specifically, Control extends from sn_grc_item.

The correct answer is B. Common controls from UCF (Unified Compliance Framework) are imported into the ‘sn_compliance_policy_statement‘ table, which represents control objectives within the ServiceNow GRC module. This table stores the details of the controls themselves. See GRC: Integrated Risk Management (IRM) Implementation – San Diego P.17

Entities can belong to one or more entity types. An entity can belong to many entity types, but it can have only one entity class. GRC: Integrated Risk Management (IRM) Fundamentals Course, Lesson 3: Create an Entity Framework.

Classification, Category, and Type are the most common choice lists configured on the Control Objective Table form. They allow for categorizing and classifying control objectives for better organization and reporting. Reference and Description are string fields and are not choice lists.

The correct answer is D. ′Tablename.config′ (lowercase) displays the configuration list view of the table in the Content Frame. If it was ′Tablename.CONFIG′ (uppercase), it would open in a separate browser tab.

System administrators have elevated privileges to modify record states. Compliance managers are responsible for overseeing compliance activities and have the authorization to transition controls into the Monitor state. According to ServiceNow documentation, all compliance managers can move the control from review to monitor.

Qualitative risk assessment primarily uses Likelihood and Impact to determine the level of risk. SLE and ARO are used in quantitative risk assessment, where numerical values are assigned.

Entity is a required field on Risk and Control records. Risk & Control auto generated from entity type mapped to respective risk statement & control objective & while generation system automatically populate entity & entity owner to risk & control.

Entity Types are applied to Risk Statement, Control Objective, and Policy records. This allows for categorization and association of these records with specific entities, providing a structured way to manage and track entities within the GRC platform.

After migrating to advanced risk assessment, a new related list called ‘Aggregated Risk‘ is displayed on risk statement and entity records. This list contains values such as Risk assessment methodology, Residual rating, Inherent rating, Control effectiveness, Residual ALE, Inherent ALE, Contributing risk assessments, and Risk rollup status, derived from various risk assessments.

Entity class rules define the mapping between database tables and the corresponding entity classes, ensuring the correct class is assigned when an entity is created from a table. ‘Entity type rules‘ does not exist.

The consolidated assessment feature allows users to group similar risk assessments and control attestations, reducing repetitive responses. It is applicable to classic risk assessments and control attestations.

The table ′sn_risk_m2m_risk_definition_profile_type′ stores the links from the Entity Type (Profile Type) to Risk Statement (Risk Definition). ServiceNow naming conventions make this clearer, reflecting the m2m relationship between risk definitions and profile types. The table name indicates a many-to-many relationship between risk definitions and profile types.

The indicator failure factor is a component used in calculating the Calculated ALE (Annualized Loss Expectancy). The Calculated Risk Factor is derived from (Indicator failure factor + Control failure factor) / 2. This risk factor is then used to adjust the ALE from Residual to Calculated. Calculated ALE = Residual ALE + ((Inherent ALE – Residual ALE) * (Calculated Risk Factor / 100))

Risk managers utilize entity types and entities primarily for monitoring risk exposure, performing risk assessments, and generating risk reports. These functionalities enable a more structured and comprehensive approach to risk management by providing a framework to identify, analyze, and report on risks associated with specific assets and areas within the organization.

The minimum role required to bulk initiate risk assessments using the risk assessment scheduler is sn_risk.manager. A risk manager can identify entities and risks within those entities for bulk initiation of assessments using the scheduler.

ServiceNow will create a duplicate control without notifying the control owner. Since the original control was created manually, the automatic creation process will not recognize it and will create a new duplicate control. No notification is sent.

Control Objective[sn_compliance_policy_statement] doesn‘t seem to have a lifecycle attached, while Policy[sn_compliance_policy], Policy Exception[sn_compliance_policy_exception] and control[sn_compliance_control] all have a lifecycle. You can verify this by running .do against those tables in a PDI. You can see the lifecycle on all but Control Objective[sn_compliance_policy_statement].

A many-to-many relationship means that multiple instances of one entity can be related to multiple instances of another entity. Controls can address multiple Risks, and a Risk can be addressed by multiple Controls. Control Objectives and Entity Types can be related in this way as well as an Entity Type and Entity relationship.

The SOX content pack can be found and obtained from the ServiceNow Store.

Understanding the customer‘s regulatory requirements, existing GRC processes, and history of audit failures are fundamental to successfully implementing a GRC program that addresses their specific needs and gaps.

The ServiceNow classic risk score types are Calculated, Inherent, and Residual. These are used in calculations such as Inherent/Residual SLE, ARO, ALE and Scores, as well as Calculated ALE and Scores, as per the ServiceNow documentation.

Entities represent concrete objects like facilities. An entity type would represent the category ‘Facility‘ itself. Because Santa Clara Facility and Boston Facility are two examples of ‘facility‘ entity, they are an ‘entities‘.

Risk and Control tables directly extend from the Item (sn_grc_item) table in ServiceNow GRC. Policy extends from Document.

A core GRC implementation team should include ServiceNow platform experts, business analysts, risk and compliance experts, and the CMDB process owner. These roles ensure the platform is correctly configured, requirements are met, compliance is addressed, and underlying data is accurate. The video in the IRM implementation course in the module titled ‘Identify implementation stakeholders and Team‘ at the 1:51 time stamp confirms that this team is variation or the exact name selected.

When a Risk Statement is associated with an Entity Type, a Risk record is automatically created for each Entity within that Entity Type. This sets the stage for assessing and managing risks associated with those entities based on the defined Risk Statement. Risks are automatically generated when you make associations between risk frameworks or risk statements and entity types. All risk frameworks or statements are associated to the entity type and a risk is created for every risk statement against every entity in the entity type. https://docs.servicenow.com/en-US/bundle/vancouver-governance-risk-compliance/page/product/grc-risk/task/t_GenerateRiskFromFramework.html

Issues are automatically created when an Attestation result is Not Implemented and when an Indicator result is Failed or Not Passed. A Control Test Issue is created when a control test is closed complete with the control effectiveness set to Ineffective.

Risk criteria define different levels of impact (the severity of the consequences if a risk event occurs) and likelihood (the probability that a risk event will occur). These two factors are fundamental in assessing and categorizing risks.

Performance Analytics usually pertains to a specific tool or methodology used for analyzing and visualizing data in ServiceNow, particularly for performance management, but it is not categorized as a type of key compliance indicator.

Entity Types often have a many-to-many relationship with Risk Statements and Controls in GRC implementations. Risk Statements can be associated with multiple Entity Types, and similarly, Controls can apply to various Entity Types. While Policies and Risks are related to Entity Types, the relationships aren‘t always a direct many-to-many.

The policy exception target table is a mandatory field that must be specified in the integration registry form to enable other applications to request policy exceptions. This defines the table (e.g., Problem, Incident) from which policy exceptions can be requested. Refer to ServiceNow documentation on enabling other applications to request policy exceptions from any table.

The Risk Response task is automatically progressed through the states using a workflow.

When a Control is in the Draft state, all compliance users (sn_compliance.user role) can modify the control.

Indicators may be scheduled to be triggered while in the Monitor state. This allows for continuous monitoring of risk and compliance.

The Risk Manager role is responsible for reviewing the risk response and moving the Risk record to the Monitor state at the appropriate time. This role has the necessary permissions and responsibilities to manage the risk lifecycle effectively. While the Risk User might interact with the risk, the Risk Manager‘s review is crucial before the transition to the monitoring phase. Risk Reader only has read permissions. The Risk Owner focuses on managing the risk itself, while the risk manager handles state transitions.

Entity Scoping is used to create, assign, and manage controls and risks across an enterprise (Textbook P73).

The components within the SOX content pack are automatically linked after installation. This automatic linking establishes the relationships between policies, controls, and risks, facilitating a cohesive compliance management system. The app is automatically installed onto your instance. https://docs.servicenow.com/bundle/tokyo-governance-risk-compliance/page/product/grc-sox-compliance-content-pack/concept/sn-store-SOX-governance-risk-compliance.html

The UCF (Unified Compliance Framework) contains Authority Documents, Citations, and Controls. These elements are integral to compliance and risk management, providing a standardized way to understand and manage regulatory requirements. Compliance administrators can leverage UCF content as GRC authority documents, citations, and controls. Sources: https://docs.servicenow.com/bundle/vancouver-governance-risk-compliance/page/product/grc-ucf-import/concept/c_UCF.html

As GRC maturity increases, organizations implement a single risk and control framework (A), establish continuous real-time monitoring of control performance (C), and implement cross-functional process automation (D). This signifies a shift towards proactive and integrated risk management.

The scheduled jobs ‘GRC indicator nightly run‘ and ‘GRC Profile Generation‘ within the GRC: Profiles scope are responsible for managing the population of Entity records. The other options belong to a different scope.

The correct formula for calculating Annualized Loss Expectancy (ALE) is Single Loss Expectancy (SLE) multiplied by Annualized Rate of Occurrence (ARO). Therefore, SLE × ARO = ALE is the correct statement.

The Risk states are Draft > Assess > Respond > Monitor > Retired. While in the Assess state, a reviewer can either answer the assessment, moving the Risk to Respond, or set the Risk back to Draft.

The Citation table is linked to the Control Objective table through the [sn_compliance_m2m_statement_citation] table. This is a many-to-many relationship that manages the relationships between control objectives and their related citations. While other options might have relationships, Citation is the explicit many-to-many relationship table asked for.

According to the ServiceNow documentation (https://docs.servicenow.com/bundle/utah-governance_risk_compliance/page/product/grc_risk/task/configure_ram.html), all assessment instance records must be deleted to edit the factor guidance of a published risk assessment methodology (RAM).

Policies are generally automatically published after the policy has been approved by all required approvers. This ensures that the policy has undergone the necessary review and is ready for implementation.

HITRUST and HIPAA are the two most relevant regulations/frameworks when scoping for entities in healthcare. HITRUST provides a certifiable methodology, and HIPAA provides data privacy and security provisions for medical information.

The overall goal of Entity Classes is to provide specific information about an Entity, such as who owns the Entity. They are used to add conceptual information about the entity or to tag the entity. They are used to classify the entities and they represent a collection of entities that have the same attributes. Entity classes help classify entities and provide additional information about them.

The minimum role required to create a policy acknowledgement campaign is sn_compliance.user. This role allows users to set up the campaign, schedule it, and extend the valid-to date. Documentation also confirms that the Compliance User role is required.

The classic risk score types that ServiceNow tracks are Inherent, Residual, and Calculated. ServiceNow provides a variety of risk scoring mechanisms, including Inherent SLE, Residual SLE, Inherent ARO, Residual ARO, Inherent ALE, Residual ALE, Inherent score, Residual score, Calculated ALE, and Calculated score.

The risk scoring logic of a published RAM can only be edited when there are no active assessment instances. This means all assessment instance records must be either deleted or canceled to ensure that changes to the risk logic do not invalidate existing assessment scores.

Authority Document and Policy both extend from the Document table. Citation and Control Objective extend from Content.

The ′sn_risk.admin′ role is the minimum role required to create a Risk Assessment Methodology (RAM) in ServiceNow. The documentation confirms that admin rights are required to create or copy RAMs.

The table sn_compliance_m2m_policy_policy_statement stores the links between a Policy and its related Control Objectives (Policy Statements). Options A and D link Policies/Control Objectives with Profile Types, and Option B is not related. Note that option C is slightly mistyped, the correct table is sn_compliance_m2m_policy_policy_statement.

Entity Classes are created to define and display relationships between various tables and objects within ServiceNow that do not inherently exist. This enables customized relationship mapping for enhanced monitoring and reporting of specific items or processes. The primary function is relationship definition, not direct generation of risks or controls based on entities. Textbook – Create entity Classes to show relationships between tables or objects you are tracking that don‘t otherwise exist anywhere in ServiceNow.

The risk register is a central repository for all potential risks that could occur at any time, anywhere in the organization. It contains all identified risks and is a key component of risk management. See: https://docs.servicenow.com/bundle/utah-governance-risk-compliance/page/product/grc_risk/reference/r_RiskRegister.html

SLAs are designed to track the time required to complete a task and thus its completion. Workflow editor defines and automates a series of tasks but the tracking of completion is more directly achieved through SLAs. Refer to textbook page 68 for more details.

Risk Management applications are specifically designed to identify and assess vulnerabilities and exposures across an organization. Therefore, using a Risk Management application would be the most appropriate choice to determine where an organization is most vulnerable.

Inherent risk represents the level of risk before implementing any controls. Residual risk represents the level of risk that remains after implementing controls to mitigate the inherent risk. Therefore, Inherent Risk = Before; Residual Risk = After.

Interview, Walkthrough, Control Test, and Activity are specific tasks performed within the Audit module to gather evidence and evaluate controls. Control Attestation may happen outside of the audit and Remediation comes after deficiencies are found.

Based on the available expert comments and reviewing Out-of-the-box (OOB) notifications related to Audit Tasks (sn_audit_task), notifications are triggered upon task expiration and reassignment of the audit task. Therefore, Expiration and Reassignment are the correct answers.