Workflow of risk identification for business applications

  • Release version: Washingtondc
  • Updated February 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

    The workflow for risk identification in business applications involves several stages, beginning with the application's creation in the Business Application table and its integration into Governance, Risk, and Compliance (GRC). After integration, a risk identification record is initiated with input from the application owner and the IT Risk Manager, who then maps relevant risks, citations, and policies.

    Show full answer Show less

    Key Features

    • Application Creation: Applications can be created automatically or manually by an application owner.
    • GRC Integration: New applications must be integrated into GRC to enable risk assessment.
    • Risk Identification Configuration: The workflow and approvers for risk assessments are defined in the Risk Identification Configuration form.
    • Questionnaire Process: A questionnaire is sent to the application owner for details about the application, which the IT Risk Manager reviews.
    • State Management: Risk identification records transition through specific states, from creation to monitoring and potential retirement.

    Key Outcomes

    By following this structured workflow, ServiceNow customers can effectively identify and assess risks associated with their business applications. The process ensures a systematic approach to risk management, enabling organizations to monitor and retire risks as necessary, thus maintaining compliance and enhancing overall governance.

    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