Create Operational vulnerability form
On the Create New Operational vulnerability form, fill in the fields.
|
Field |
Description |
|---|---|
|
Number |
Number of the vulnerability. This field is automatically set. |
|
Name |
Name of the vulnerability. For example, |
|
Description |
Description of the vulnerability. |
|
State |
Workflow state of the vulnerability. This field is automatically set to New. |
|
Type |
Nature or type of the vulnerability. This field is automatically set to Vulnerability Type. |
|
Severity |
Severity of the vulnerability. The choices are as follows:- Low
|
|
Sub-type |
Sub type of vulnerability. For example, Documentation Loss. |
|
Priority |
Priority of the vulnerability. The choices are as follows:- 1 - Critical
Note: The default value in this field is set to Planning. |
|
Primary entity |
Entity impacted by the case. Only the entities identified in the impacted areas are available for selection as the primary entity. |
|
Entity owner |
User who is the owner of the entity. This field is automatically set based on the entity selected in the Impacted areas related list. |
|
Personal information | |
|
Contains personal information |
Field to decide if the breach contains personal information. The choices are as follows:- To be decided: Select this option if you’re not sure if the breach has personal information.
|
|
Number of impacted individuals |
Number of people impacted by the case. |
|
Categories of data subjects/individuals impacted |
Define who is impacted by the case. The choices are as follows:- Customers
|
|
Assignment | |
|
Requester |
Person who reported the vulnerability. |
|
Assignment group |
Group assigned to the case. Note: The assignment group is preconfigured to the case type during configuration setup. |
|
Approvers |
Approvers of the vulnerability. |
|
Requested on behalf of |
Name of the person on whose behalf you’ve created the vulnerability. |
|
Analyst |
Analyst who will analyze and work on the vulnerability. The analyst is a part of the Assignment group. |
|
Watch list |
People who must be aware of the vulnerability. |
|
Primary origin | |
|
Location |
Location where the vulnerability occurred. For example, the location is Japan. |
|
Impacted business unit |
Business unit that is impacted by the breach. |
|
Sub-location |
Sub-location of the vulnerability occurrence. For example, the sub location is Tokyo. |
|
Source |
Source of the vulnerability creation. This field is automatically set to Manual when the operational vulnerability is manually created. If the operational vulnerability is reported from the Employee Center, the field displays the source as Employee Center. The Operational Resilience manager can update the source or add the new source to the related area. |
|
Impacted department |
Department impacted by the vulnerability. The choices are as follows:- Finance
|
|
Source table |
Source table from where the vulnerability is created. |
|
Source record |
Source record of source object from where the vulnerability is created. For example, if the vulnerability is reported from risk events, then this field displays the name of the risk event from which the vulnerability is reported. |
|
Schedule | |
|
Date of occurrence |
Date that the vulnerability occurred on. For example, the vulnerability may have occurred on 18-02-2024. |
|
Date of discovery |
Date that the vulnerability is discovered by you. For example, the vulnerability may have occurred on 18-02-2024, but is discovered by the user only on 12-03-2024. |
|
Due date |
Date that the vulnerability is due on. |
|
Closed date |
Date that the vulnerability is closed on. |
|
Reported date |
Date that the vulnerability gets reported on. |
|
Assessment start date |
Start date for the assessment or date that the vulnerability was analyzed on. |
|
Pending approval start date |
Date that the vulnerability was resolved on. |
|
Approved date |
Post case review date of the vulnerability. |
|
Findings | |
|
Treatment |
Decision made for the treatment. The choices are as follows:- Accept
|
|
Root cause analysis | |
|
Root cause |
Primary cause of the vulnerability occurrence. |
|
Activity | |
|
Work notes (Private) |
Notes or information regarding the vulnerability. |
|
Comments (Customer visible) |
Additional information regarding the vulnerability for the customers. |
|
|
Option to compose an email about the vulnerability to the stakeholders. |
|
Attachments |
Option to attach the PDF of the vulnerability. |
|
Action tasks |
Action tasks associated with the vulnerability. |
|
Primary origin |
Primary origin of the vulnerability. |
|
Impacted areas |
Impacted areas related to the vulnerability. |
|
Issues |
Issues related to the vulnerability. |
|
Approvers |
Approvers of the vulnerability. |
--- title: Create Operational vulnerability form description: On the Create New Operational vulnerability form, fill in the fields. locale: en-US canonical_url: https://www.servicenow.com/docs/r/governance-risk-compliance/create-new-op-vul-form.html release: brazil topic_type: reference last_updated: "2026-09-10" reading_time_minutes: 3 breadcrumb: [Report an Operational vulnerability from the module, Reporting Operational vulnerability, Managing Operational vulnerability, Manage, Operational Resilience, Governance, Risk, and Compliance] --- # Create Operational vulnerability form On the Create New Operational vulnerability form, fill in the fields. <table id="table_uj1_q5x_nvb"><thead><tr><th> Field </th><th> Description </th></tr></thead><tbody><tr><td> Number </td><td> Number of the vulnerability. This field is automatically set. </td></tr><tr><td> Name </td><td> Name of the vulnerability. For example, `Environmental vulnerability`. </td></tr><tr><td> Description </td><td> Description of the vulnerability. </td></tr><tr><td> State </td><td> Workflow state of the vulnerability. This field is automatically set to **New**. </td></tr><tr><td> Type </td><td> Nature or type of the vulnerability. This field is automatically set to **Vulnerability Type**. </td></tr><tr><td> Severity </td><td> Severity of the vulnerability. The choices are as follows:- **Low** - **Medium** - **High** - **Critical** </td></tr><tr><td> Sub-type </td><td> Sub type of vulnerability. For example, **Documentation Loss**. </td></tr><tr><td> Priority </td><td> Priority of the vulnerability. The choices are as follows:- **1 - Critical** - **2- High** - **3 - Moderate** - **4 - Low** - **5 - Planning** - **None** **Note:** The default value in this field is set to **Planning**. </td></tr><tr><td> Primary entity </td><td> Entity impacted by the case. Only the entities identified in the impacted areas are available for selection as the primary entity. </td></tr><tr><td> Entity owner </td><td> User who is the owner of the entity. This field is automatically set based on the entity selected in the Impacted areas related list. </td></tr><tr><td class="sub-head" colspan="2"> Personal information </td></tr><tr><td> Contains personal information </td><td> Field to decide if the breach contains personal information. The choices are as follows:- **To be decided**: Select this option if you’re not sure if the breach has personal information. - **Yes**: Select this option if the breach has personal information. - **No**: Select this option if the breach doesn’t have personal information. </td></tr><tr><td> Number of impacted individuals </td><td> Number of people impacted by the case. </td></tr><tr><td> Categories of data subjects/individuals impacted </td><td> Define who is impacted by the case. The choices are as follows:- **Customers** - **Employees** </td></tr><tr><td class="sub-head" colspan="2"> Assignment </td></tr><tr><td> Requester </td><td> Person who reported the vulnerability. </td></tr><tr><td> Assignment group </td><td> Group assigned to the case. **Note:** The assignment group is preconfigured to the case type during configuration setup. </td></tr><tr><td> Approvers </td><td> Approvers of the vulnerability. </td></tr><tr><td> Requested on behalf of </td><td> Name of the person on whose behalf you’ve created the vulnerability. </td></tr><tr><td> Analyst </td><td> Analyst who will analyze and work on the vulnerability. The analyst is a part of the Assignment group. </td></tr><tr><td> Watch list </td><td> People who must be aware of the vulnerability. </td></tr><tr><td class="sub-head" colspan="2"> Primary origin </td></tr><tr><td> Location </td><td> Location where the vulnerability occurred. For example, the location is **Japan**. </td></tr><tr><td> Impacted business unit </td><td> Business unit that is impacted by the breach. </td></tr><tr><td> Sub-location </td><td> Sub-location of the vulnerability occurrence. For example, the sub location is **Tokyo**. </td></tr><tr><td> Source </td><td> Source of the vulnerability creation. This field is automatically set to **Manual** when the operational vulnerability is manually created. If the operational vulnerability is reported from the Employee Center, the field displays the source as **Employee Center**. The Operational Resilience manager can update the source or add the new source to the related area. </td></tr><tr><td> Impacted department </td><td> Department impacted by the vulnerability. The choices are as follows:- **Finance** - **HR** - **IT** - **Marketing** - **Sales** </td></tr><tr><td> Source table </td><td> Source table from where the vulnerability is created. </td></tr><tr><td> Source record </td><td> Source record of source object from where the vulnerability is created. For example, if the vulnerability is reported from risk events, then this field displays the name of the risk event from which the vulnerability is reported. </td></tr><tr><td class="sub-head" colspan="2"> Schedule </td></tr><tr><td> Date of occurrence </td><td> Date that the vulnerability occurred on. For example, the vulnerability may have occurred on 18-02-2024. </td></tr><tr><td> Date of discovery </td><td> Date that the vulnerability is discovered by you. For example, the vulnerability may have occurred on 18-02-2024, but is discovered by the user only on 12-03-2024. </td></tr><tr><td> Due date </td><td> Date that the vulnerability is due on. </td></tr><tr><td> Closed date </td><td> Date that the vulnerability is closed on. </td></tr><tr><td> Reported date </td><td> Date that the vulnerability gets reported on. </td></tr><tr><td> Assessment start date </td><td> Start date for the assessment or date that the vulnerability was analyzed on. </td></tr><tr><td> Pending approval start date </td><td> Date that the vulnerability was resolved on. </td></tr><tr><td> Approved date </td><td> Post case review date of the vulnerability. </td></tr><tr><td class="sub-head" colspan="2"> Findings </td></tr><tr><td> Treatment </td><td> Decision made for the treatment. The choices are as follows:- **Accept** - **Avoid** - **Mitigate** - **Transfer** - **None** </td></tr><tr><td class="sub-head" colspan="2"> Root cause analysis </td></tr><tr><td> Root cause </td><td> Primary cause of the vulnerability occurrence. </td></tr><tr><td class="sub-head" colspan="2"> Activity </td></tr><tr><td> Work notes \(Private\) </td><td> Notes or information regarding the vulnerability. </td></tr><tr><td> Comments \(Customer visible\) </td><td> Additional information regarding the vulnerability for the customers. </td></tr><tr><td> Email </td><td> Option to compose an email about the vulnerability to the stakeholders. </td></tr><tr><td> Attachments </td><td> Option to attach the PDF of the vulnerability. </td></tr><tr><td> Action tasks </td><td> Action tasks associated with the vulnerability. </td></tr><tr><td> Primary origin </td><td> Primary origin of the vulnerability. </td></tr><tr><td> Impacted areas </td><td> Impacted areas related to the vulnerability. </td></tr><tr><td> Issues </td><td> Issues related to the vulnerability. </td></tr><tr><td> Approvers </td><td> Approvers of the vulnerability. </td></tr></tbody> </table>
| title | Create Operational vulnerability form |
| description | On the Create New Operational vulnerability form, fill in the fields. |
| locale | en-US |
| canonical_url | https://www.servicenow.com/docs/r/governance-risk-compliance/create-new-op-vul-form.html |
| release | brazil |
| topic_type | reference |
| last_updated | 2026-09-10 |
| reading_time_minutes | 3 |
| breadcrumb | Report an Operational vulnerability from the moduleReporting Operational vulnerabilityManaging Operational vulnerabilityManageOperational ResilienceGovernanceRiskand Compliance |