Workflow of risk identification for business applications

  • Release version: Xanadu
  • Updated August 1, 2024
  • 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 guides ServiceNow customers through the process of identifying and assessing risks for business applications using Governance, Risk, and Compliance (GRC) integrated with Application Portfolio Management (APM). The process ensures that new business applications are systematically evaluated for risks before they are fully integrated and managed within the organization.

    Show full answer Show less

    Risk Identification Workflow

    • A business application is first created in the Business Application table, either automatically or by an application owner.
    • The application must have designated owners, including an IT application owner and a business owner with the sngrc.businessuser role (or equivalent roles as defined by the organization).
    • The application is then brought into the GRC system as an entity through a scheduled job called the GRC Profile Generation.
    • Once in GRC, a risk identification record is generated for the application, with workflow and approvers defined by the Risk Identification Configuration form.
    • A questionnaire is sent to the application owner to collect detailed information about the application.
    • The IT Risk Manager reviews the completed questionnaire. If unsatisfactory, the questionnaire can be sent back to the owner for revision, reverting responses to their original form.
    • When the IT Risk Manager approves the responses, the system initiates an inherent risk assessment.
    • Risks, policies, and citations are mapped based on application-related information objects, with the IT Risk Manager reviewing and adjusting mappings as needed.
    • The recommendation engine runs according to the selected algorithm to suggest risks and controls.
    • The IT Risk Manager maps recommended risks, controls, policies, and citations, while the application owner manages control lifecycle and attestations.

    Risk Identification Record States

    The risk identification record moves through specific lifecycle states reflecting the progress of risk assessment:

    • New: Record creation stage.
    • Information Gathering: Collecting information about the application.
    • Review: IT Risk Manager reviews the gathered information.
    • Inherent Assessment: Performing inherent risk evaluation.
    • Risk Mapping: Mapping risks, citations, and policies to the application.
    • Monitor: Ongoing monitoring of identified risks.
    • Retired: Risks are retired when no longer applicable, and risk identification records cease to be created if the configuration is retired.

    Configuration and Workflow Customization

    Customers can tailor the risk identification and assessment workflow through the Risk Identification Configuration form, allowing flexibility in defining approvers and process steps. Reinitiation of risk identification is supported via a flow designer action.

    Practical Benefits for ServiceNow Customers

    • Streamlines risk assessment for new business applications ensuring they are evaluated systematically before operational use.
    • Enables collaboration between application owners and IT Risk Managers through structured questionnaires and reviews.
    • Automates risk mapping and recommendations using configurable algorithms, enhancing accuracy and efficiency.
    • Supports ongoing risk monitoring and lifecycle management to maintain compliance and control effectiveness.
    • Allows customization of workflows to align with organizational roles and processes.

    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