Workflow of risk identification for business applications

  • Release version: Yokohama
  • Updated January 30, 2025
  • 3 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Workflow of risk identification for business applications

    This workflow outlines the process for identifying and assessing risks within business applications in ServiceNow Governance, Risk, and Compliance (GRC). It ensures that applications are properly evaluated for risks before they are fully integrated into GRC, enabling organizations to systematically manage risks associated with their business applications.

    Show full answer Show less

    Key Steps in the Workflow

    • Application Creation: A business application is created in the Business Application table, either automatically or by an application owner.
    • GRC Entity Creation: The GRC system detects the new application through a scheduled background job and creates a corresponding GRC entity.
    • Risk Identification Record: A risk identification record is generated for the application, initiating the risk assessment process.
    • Information Gathering: A questionnaire is sent to the application owner (who must have the appropriate role) to collect detailed information about the application.
    • Review and Feedback: The IT Risk Manager reviews the application owner’s responses; if unsatisfactory, the questionnaire is sent back for further clarification.
    • Inherent Assessment and Risk Mapping: Upon satisfactory responses, the system performs an inherent risk assessment, maps associated risks, citations, and policies, and executes a recommendation engine.
    • Control Mapping and Management: The IT Risk Manager maps recommended controls, while the application owner manages the control lifecycle and performs attestations.

    Configuration and Customization

    The workflow and approvers involved in the risk assessment are determined by settings in the Risk Identification Configuration form. Risk managers can modify configurations to tailor the process, though some fields become locked after publishing. A flow designer action allows reinitiating risk identification if needed.

    Life Cycle of Risk Identification Records

    Risk identification records progress through these states:

    • New: Initial creation of the record.
    • Information Gathering: Collecting application details.
    • Review: Risk Manager reviews gathered information.
    • Inherent Assessment: Performing inherent risk assessment.
    • Risk Mapping: Mapping risks, citations, and policies.
    • Monitor: Ongoing risk monitoring.
    • Retired: Risks are retired and the record is closed.

    Once the risk identification configuration is retired, no new risk identification records are created for related applications, rendering the configuration invalid.

    When assessing an application for risks, the application goes through various stages of risk identification and assessment. You can define the identification and assessment workflow based on your requirements.

    Before the risks of an application are assessed, the application must be created in the Business application table and brought to GRC. After the application comes to GRC, a risk identification record is created. The application owner provides information about the application to the IT Risk Manager. The IT Risk Manager then maps the recommended risks, citations, and policies.

    Consider the following example to understand the workflow of risk identification and assessment for a business application. A new business application is introduced into your organization. This new application is a part of the Business Application table. The new application has two owners:
    • IT application owner
    • Business owner: This user must have the sn_grc.business_user role.
    Note:
    Your organization can use different roles.
    At this point, the application is not a part of GRC. It must be brought to GRC as an entity before its risks can be assessed. The new application must also have information objects associated with it.

    The workflow and approvers of the application risk assessment are determined by the settings in the Risk Identification Configuration form. Refer to Set up risk identification integration to understand the process of defining the workflow. To reinitiate risk identification, a flow designer action is provided.

    When assessing a new business application, the workflow of the risk identification is as follows:
    1. A business application is created either automatically or by an application owner in the business application table.
    2. GRC detects the new business application. A GRC entity is created for the new application. The detection is handled by the GRC Profile Generation scheduled job that runs in the background.
    3. A new risk identification record is created for the application.
      Note:
      The Risk Manager can modify the configuration record and determine the workflow of the assessment. After a risk identification configuration is published, the risk manager can modify only some fields in the configuration record.
    4. A questionnaire is initiated and sent to the application owner to collect details about the application.
    5. The application owner responds to the questionnaire.
    6. The IT Risk Manager reviews the responses. If the responses are unsatisfactory, the manager sends the questionnaire back to the application owner.
      Note:
      If the questionnaire is sent back, then the new responses are reverted to their original form.
    7. Based on the configuration, after the IT Risk Manager is satisfied with the responses, the system initiates the inherent assessment.
    8. GRC maps the risks and compliance objects based on the entity types.
    9. The IT Risk Manager reviews the information object mapping.
    10. The system executes the recommendation engine based on the algorithm selected in the configuration.
    11. The IT Risk Manager reviews and maps the recommended risks, policies, and citations based on the associated information objects.
    12. The IT Risk Manager maps the recommended controls based on associated citations, policies, and risks.
    13. The application owner manages the control life cycle and attests the controls.
    The following figure represents the workflow of the solution.
    Figure 1. Solution workflow of the GRC and APM integration
    Integration of APM and Advanced Risk Assessment

    States of the risk identification record

    After the risk identification configuration moves to the Published state, a risk identification record gets created for the related entity.

    The risk identification record moves through the following states:
    • New: A new record is created
    • Information Gathering: The information about the application is collected.
    • Review: The Risk Manager reviews the information.
    • Inherent Assessment: The Risk Manager performs inherent risk assessment.
    • Risk Mapping: The Risk Manager maps the necessary risks, citations, and policies.
    • Monitor: The risks are monitored.
    • Retired: The risks are retired as necessary.

    After the risk identification configuration moves to the Retired state, the configuration becomes invalid and risk identification records are not created for related entities.

    In terms of its life cycle, a risk identification record goes through the following states:
    1. New
    2. Information Gathering
    3. Review
    4. Inherent Assessment
    5. Risk Mapping
    6. Monitor
    7. Retired