Linking automatically generated issues to a control in many-to-many relationship

  • Release version: Zurich
  • Updated July 31, 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 Linking automatically generated issues to a control in many-to-many relationship

    This feature enables ServiceNow GRC customers to link automatically generated issues, which originate from different controls, as related issues in a many-to-many (m2m) relationship to controls. It helps track and differentiate issues that are generated automatically due to control failures versus those created manually.

    Show full answer Show less

    Key Features

    • Originator Flag: A backend true/false flag that identifies whether an issue was automatically generated (true) or manually created (false). This flag is essential for tracking the source and managing multiple linked issues.
    • Automatic Issue Generation: Issues are automatically created when controls become non-compliant due to:
      • Control test failure (design or operational tests marked ineffective)
      • Control attestation failure (attestation respondent rejects the control)
      • Control indicator failure
    • Issue Source Tracking: The Issue source field captures tags such as Control Test Failure or Ad-Hoc to identify the reason for issue creation and is reflected in the control’s status widget as reasons for non-compliance.
    • Linking Across Controls: Automatically generated issues from one control can be linked to another control, but conflicts in issue source are managed via the Originator flag and aggregated issue source tags.
    • Issue Source Aggregation: When multiple control failures occur for the same control, the issue source field aggregates the reasons (e.g., both Control test failure and Control attestation failure) rather than creating multiple issues with Originator true.
    • Manual Issue Creation: Users can create issues manually using the New button in the Issues related list on a control form, which are distinguished by the Originator flag set to false.
    • Data Migration: Upon installing the latest GRC plugin, existing automated issues linked to controls are automatically flagged with Originator true in the many-to-many relationship records.

    Practical Benefits for ServiceNow Customers

    • Provides clear differentiation between manually created and automatically generated control issues, improving issue management and reporting accuracy.
    • Enables comprehensive tracking of multiple control failures and their impact on compliance status within a single issue record.
    • Facilitates linking of issues across controls while maintaining clear ownership and source traceability.
    • Improves visibility into reasons for non-compliance directly from control overview pages, supporting faster remediation.
    • Automatic handling of issue Originator flags reduces manual configuration efforts and supports seamless data migration during plugin upgrades.

    You can link an automatically generated issue that belongs to a different control as a related issue to a control. The Originator flag helps you to differentiate those control issues that were automatically generated from the controls that were manually created.

    Manually created and automatically generated issues

    Note:
    You can identify the origin of an issue whether it was automatically generated or manually created after you link the issue from one control to another only in a control form.

    You can create an issue manually for a control when you click the New button in the Issues related list of a Control form. For manually created issues, see Manually create GRC issues.

    However, issues are also automatically generated when there are:
    Control test failure
    If there’s a control test which is linked to a control and when one of the test is marked ineffective and closed, then the control becomes non-compliant. As a result, an issue is automatically generated. Control tests can be design test or operational test which can be marked ineffective and the tests can be common across all controls.
    Control attestation failure
    When the user who is an attestation respondent of a control rejects the control, then the status of the control becomes non-compliant and an issue is automatically generated.
    Control indicator failure
    Similarly, when a control indicator fails, the control becomes non-compliant and an issue is automatically generated.

    The source of the issue generation for one or more of the three failures can be tracked with the tags in the Issue source field of the Issue details. If there is a control test failure, the Issue source field is updated with a tag, Control Test Failure. If the issue was created manually, then the Issue source tag is Ad-Hoc.

    When a control's status moves to non-complaint, all the reasons for non-compliancy are pulled from the Issue source field and displayed as Reasons for non-compliance in the Status widget of the control's Overview page.
    Figure 1. Reasons for non-compliance
    List of reasons for a control's non-compliance.

    Handling more than one automatically generated issue while linking to a control

    You can add an automatically generated issue that belongs to another control, to a control in an m2m relationship using the Add button. However, adding an automatically generated issue from another control to a control with an existing automatically generated issue conflicts the source of the issue generation. To track the source of issue generation, a back-end flag, Originator, is used. It is a true or false flag and is false, by default. Originator is flagged true or false, if:
    • An automated issue of another control is associated to the current control, then the Originator is false.
    • It is a manual issue of the current control, then the Originator is false.
    • It is an automated issue of current control then the Originator is true.
    1. When there is an issue that exists with Originator as true, and if a control failure happens, the Issue source field of the issue is updated with the source of the issue. For example, there’s an issue with originator as true already present and the issue source is Control test failure. If another control failure happens, such as control attestation failure, then the Issue source is updated with two tags, namely Control test failure and Control attestation failure.
    2. When there is no issue present with Originator as true, and if one of the three control failures happens a new automated issue with originator as true is created. For example, if there's a control attestation failure for a particular control that has no issue linked to the control with the originator as true, then a new automated issue with Issue source as control attestation failure is created and the originator is true.

    Data migration

    The logic behind flagging an issue as automatically generated or manually created with the Originator flag is handled automatically when you install the latest plugin. For all automated issues linked to existing controls, the originator flag is true in the m2m records between the control and the issue.