Update Observation HB page to USRM

| Role | Responsibility  |

| ---- | ------ |

| Observation Manager | Responsible for being the observation DRI through the observation lifecycle including verifying and fine tuning recommended remediation plans in order to meet legal and regulatory requirements. |

| Finding Coordinator | Responsible for being the observation DRI through the observation lifecycle including verifying and fine tuning recommended remediation plans in order to meet legal and regulatory requirements. |

| Remediation Owner | Validates observation, confirms assignee, due date, finalizes remediation plan and conducts remediation activity based on defined [remediation SLA's](/handbook/security/security-assurance/observation-management-procedure/#remediation-sla). |

| Managers to Executive Leadership | Responsible for escalation as necessary and resource allocation for remediation activity. |

## Procedure

### Lifecycle Overview

Observations are one risk source within the broader Unified Risk Management (USRM) procedure. For a comprehensive overview of the program structure and workflow, refer to the [USRM handbook page](/handbook/security/security-observations-risk-management/#procedure). This page focuses on the unique aspects of observations and how they may deviate from the standard procedure.

```mermaid

graph TD;

  A[Identified] --> B[Validated];

  B --> C[In Progress];

  B --> D[Stalled];

  B --> G[Blocked];

  C --> E[Remediated];

  E --> F[Remediation Accepted];

  B --> H[Risk Accepted];

```

### Observation Workflow Labels

### Unified Risk Management (USRM) Workflow Labels

These workflow labels indicate the observation issue within the lifecycle.

| Label | Description |

| ------ | ------ |

| Observation Workflow:: Identified | Initial review to determine validity of observation     |

| Observation Workflow:: Validated| Remediation owner has been assigned, but remediation has not started |

| Observation Workflow:: In Progress| Remediation owner has been assigned and remediation is underway |

| Observation Workflow:: Remediated| Remediation owner indicates the [remediation step](/handbook/security/security-assurance/observation-management-procedure/#observation-remediation) is complete|

| Observation Workflow:: Remediation Accepted| Indicated that the observation manager has reviewed remediation and agrees the issue is closed|

|Observation Workflow:: Risk Accepted| Observations that no remediation action will be taken and have been risk accepted by the remediation owner. Please tag `@madlake` in these issues.|

| Observation Workflow:: Blocked| Indicated that the observation is blocked - please indicate why in a comment|

| Observation Workflow:: Stalled| Indicated that remediation is stalled|

Please refer to the [USRM handbook page for workflow and required labels](/handbook/security/security-observations-risk-management/#required-labels).

### Observation Category Labels

| RiskRating:: High| Risk rating for security compliance observations - High|

| RiskRating:: Moderate| Risk rating for security compliance observations - Moderate|

| RiskRating::Low | Risk rating for security compliance observations - Low|

| ObservationManager::*** | GitLab team member managing the observation through the [observation phases](/handbook/security/security-assurance/observation-management-procedure/#lifecycle-overview). |

| Finding Coordinator::*** | GitLab team member managing the observation through the lifecycle. |

| Blocked:: Awaiting Remediation Owner Input    | This flag indicates the observation manager is waiting for a response from the remediation owner.   |

| Blocked:: Awaiting Observation Manager Input  | This flags the issue for the observation manager on the SecAssurance team                                                                                       |

| Blocked:: New tool implementation in progress | This flags the issue for pending completion of the new tool                                                                                                     |

1. Gap assessment activities

1. Ad-hoc issues

### Assigning Observations

The observation identifier is responsible for opening an observation in the GitLab Observation Project. The observation identifier fills out all necessary observation information, remediation recommendations and submits the observation to the Remediation Owner for validation. The Observation Manager is responsible for managing the observation through the observation lifecycle. This includes linking the observation to the associated control in GAS, validating the observation with the Remediation Owner, tracking all remediation progress and updating the GitLab issue with current information and status updates. Each observation has both a GitLab Issue (for Remediation Owners) and a GAS record (for Observation Managers). Each observation will be assigned a [risk rating](#risk-ratings), which should drive the priority of remediation.

### Drafting Observation Description Guidance

The Observation description should include the who, what, when, where, why, and how related to the observation. As a review step, if you knew nothing about this observation could you understand the finding, how it was identified, and the effect it has on objectives? Consider leveraging the 4C's model:

1. Condition - current state

1. Criteria - desired state based on policy, requirement, control, regulation, etc.

1. Cause - root cause of the observation

1. Consequence - actual or potential effect on objectives/assets

### Risk Ratings

Tier 3 information system risk ratings are based on the formula below.

### Observation Remediation

Once all remediation activities have been completed, the Remediation Owner is responsible for tagging the Observation Manager in the observation issue. If there is no Observation Manager assigned, tag `@gitlab-com/gl-security/security-assurance/security-compliance` in the observation issue.

Once all remediation activities have been completed, the Remediation Owner is responsible for tagging the Finding Coordinator in the observation issue. If there is no Finding Coordinator assigned, tag `@gitlab-com/gl-security/security-assurance/security-compliance` in the observation issue.

It is the responsibility of the Observation Manager to track the milestones, work progress and validation of the remediation activity. The Observation Manager will then validate the remediation activity for completeness, re-test the observation (as applicable) and close the observation issue. If re-testing does not result in a fully effective conclusion, the observation description and remediation recommendations may be updated to reflect the new findings and required remediation tasks.

It is the responsibility of the Finding Coordinator to track the milestones, work progress and validation of the remediation activity. The Finding Coordinator will then validate the remediation activity for completeness, re-test the observation (as applicable) and close the observation issue. If re-testing does not result in a fully effective conclusion, the observation description and remediation recommendations may be updated to reflect the new findings and required remediation tasks.

### Remediation SLA

- [GCF Control Lifecycle](/handbook/security/security-assurance/security-compliance/security-control-lifecycle/)

- [Observation Management Project](https://gitlab.com/gitlab-com/gl-security/security-assurance/observation-management)

- [Unified Risk Management](/handbook/security/security-observations-risk-management/#procedure)

## Contact & Feedback

1. (**Preferred**) Submit a [Risk Escalation issue](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/STORM/-/issues/new?issuable_template=risk-escalation) on the STORM Repo.

1. If the risk is identified within an issue, team members can tag the team directly by @ mentioning `@gitlab-com/gl-security/security-assurance/security-risk-team` on the issue or MR

When documenting risks, team members can leverage [Observation Description guidance](/handbook/security/security-assurance/observation-management-procedure/#drafting-observation-description-guidance) for existing issues/observations or [risk drafting guidance](#risk-drafting-guidance).

When documenting risks, team members can leverage [description guidance](/handbook/security/security-observations-risk-management/#drafting-finding-description-guidance) for existing issues/observations or [risk drafting guidance](#risk-drafting-guidance).

#### Risks identified during risk assessments

|:-:| :------ | :--: |-----------| :--: |----------------|

| 1 | [Compliance Observations](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-compliance-commercial-and-dedicated/observation-management/-/issues) | Sec Compliance | Phase 1 | Observation Manager | Existing or USRM |

| 2 | [Security Policy Exceptions](https://gitlab.com/gitlab-com/gl-security/security-assurance/governance-and-field-security/governance/security-governance/-/issues?sort=created_date&state=all&label_name%5B%5D=ExceptionRequest&first_page_size=100) | Security Governance | Phase 1 | @davoudtu | Existing |

| 3 | [Product Risk Register](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/storm-risk-register/-/issues/?sort=created_asc&state=opened&label_name%5B%5D=Department%3A%3AProduct%20Security&first_page_size=100) | ProdSec | Phase 1 | TBD | Existing or USRM |

| 3 | [Product Risk Register](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/storm-risk-register/-/issues/?sort=created_asc&state=opened&label_name%5B%5D=Department%3A%3AProduct%20Security&first_page_size=100) | ProdSec | Phase 1 | @jrinaudo | Existing or USRM |

| 4 | [TPRM Security Notices](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/third-party-vendor-security-management/-/issues/?sort=created_date&state=opened&label_name%5B%5D=TPRM%3ASecurity%20Notice&first_page_size=100) | Sec Risk | Phase 1 | Risk Manager |  Existing or USRM |

| 5 | [Vulnerabilities](https://gitlab.com/groups/gitlab-com/gl-security/product-security/vulnerability-management/-/issues/?sort=created_asc&state=opened&label_name%5B%5D=bug%3A%3Avulnerability&first_page_size=100) | Vuln Mgmt. | TBD | TBD  |  TBD |

| 6 | Incidents | SIRT | TBD |  TBD | TBD |

| 7 | [Red Team Recommendations (~RTRec::)](https://gitlab.com/gitlab-com/gl-security/security-operations/leadership/-/wikis/OffSec-Recommendations-Dashboard) | Red Team | Phase 1 | @madlake | USRM |

| 8 | [Inventory findings](https://gitlab.com/gitlab-com/gl-security/product-security/inventory/-/issues) | Sec Architecture | TBD | @kylesmith2 | TBD |

| 9 | [Wiz Findings](https://app.wiz.io/p/production) | InfraSec | TBD | TBD | TBD |

| 10 | [Threat Intel Recommendations (~TIRec::)](https://gitlab.com/gitlab-com/gl-security/security-operations/leadership/-/wikis/OffSec-Recommendations-Dashboard) | Threat Intel | Phase 1 | TBD  | TBD |

| 10 | [Threat Intel Recommendations (~TIRec::)](https://gitlab.com/gitlab-com/gl-security/security-operations/leadership/-/wikis/OffSec-Recommendations-Dashboard) | Threat Intel | Phase 1 | @madlake | TBD |

| 11 | Signals Engineering (~SET::Signals-Improvement, SET::Detection-New, SET::Signal-Gap) | Signals Engineering | TBD | TBD |TBD |

| 12 | [GitLab vulnerabilities](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=bug%3A%3Avulnerability&first_page_size=100) | AppSec/Multiple | TBD |  TBD | TBD |

| 13 | Data Security Recommendations (~DataSec::consult) | DataSec | TBD |  TBD | TBD |

| Label Category | Options | Usage |

|----------------|---------|-------|

| **Workflow Status** | `USRM Workflow::Finding Identified`, `USRM Workflow::Remediation Plan`, `USRM Workflow::Monitoring`, `USRM Workflow::Closed` | Process tracking |

| **Department**|`Department:[department-name]`| To identify department that owns the risk |

| **Priority** | `priority::1`, `priority::2`, `priority::3`, `priority::4` | Aligns with GitLab standard priority framework |

| **Severity** | `severity::1`, `severity::2`, `severity::3`, `severity::4` | Aligns with GitLab standard severity framework |

| **Department**|`Department:[department-name]`| To identify department that owns the risk for Corporate findings |

| **Group**|`group:[group-name]`| To identify product that owns the risk for Product findings |

| **Priority** | `priority::1`, `priority::2`, `priority::3`, `priority::4` | Aligns with GitLab standard priority framework. Use either priority/severity labels OR risk rating labels, not both |

| **Severity** | `severity::1`, `severity::2`, `severity::3`, `severity::4` | Aligns with GitLab standard severity framework. Use either priority/severity labels OR risk rating labels, not both |

| **Risk Rating** | `RiskRating::Critical`, `RiskRating::High`,`RiskRating::Moderate`,`RiskRating::Low`| Alternative to severity and priority to rate risks|

| **Risk Treatment** | `risk-treatment::remediate`, `risk-treatment::accept` | Indicates whether risk will be remediated or formally accepted |

| **STORM Risk** | `STORM RISK:#` | To enable risk mapping reporting |

| **Finding Coordinator** | `FindingCoordinator::@team member` | To identify the coordinator responsible for monitoring the finding through the USRM process |

### Risk Rating

Many teams (example [SIRT](/handbook/security/security-operations/sirt/severity-matrix/)) have existing risk assessment methodologies. For those that don't, please use the standardized GitLab [priority](https://docs.gitlab.com/development/labels/#priority-labels) and [severity](https://docs.gitlab.com/development/labels/#severity-labels) framework, adapted for security division requirements:

Many teams (example [SIRT](/handbook/security/security-operations/sirt/severity-matrix/)) have existing risk assessment methodologies. For those that don't, please use the standardized GitLab [priority](https://docs.gitlab.com/development/labels/#priority-labels) and [severity](https://docs.gitlab.com/development/labels/#severity-labels) framework, adapted for security division requirements below:

<details><summary>Priority and Severity Framework</summary>

#### Priority Rating (Business Impact and Urgency)

| Priority | Label | Criteria | Target Resolution | Notification | Equivalent Mappings |

|----------|-------|----------|-------------------|--------------|-------------------|

| **1 (Critical)** | `priority::1` | Urgent security threat requiring immediate action regardless of team capacity | 30 days maximum | Immediate escalation to Security leadership | StORM Critical (26-30), Vulnerability Critical (CVSS 9.0-10.0), Observations Critical (16) |

| **2 (High)** | `priority::2` | High impact security issue that will be addressed soon with dedicated capacity | 60-90 days | Security management notification within 24 hours | StORM High (21-25), Vulnerability High (CVSS 7.0-8.9), Observations (12-15) |

| **3 (Medium)** | `priority::3` | Important security improvements that may compete with other priorities | 90-120 days | Standard team lead notification | StORM Medium (11-20), Vulnerability Medium (CVSS 4.0-6.9), Observations (4-11) |

| **4 (Low)** | `priority::4` | Security enhancements with no designated timeline | No specific timeline | Standard backlog management | StORM Low (1-10), Vulnerability Low (CVSS 0.1-3.9), Observations (1-3) |

| **1 (Critical)** | `priority::1` | Urgent security threat requiring immediate action regardless of team capacity | 30 days maximum | Immediate escalation to Security leadership | StORM Critical (26-30), Vulnerability Critical (CVSS 9.0-10.0) |

| **2 (High)** | `priority::2` | High impact security issue that will be addressed soon with dedicated capacity | 60-90 days | Security management notification within 24 hours | StORM High (21-25), Vulnerability High (CVSS 7.0-8.9) |

| **3 (Medium)** | `priority::3` | Important security improvements that may compete with other priorities | 90-120 days | Standard team lead notification | StORM Medium (11-20), Vulnerability Medium (CVSS 4.0-6.9) |

| **4 (Low)** | `priority::4` | Security enhancements with no designated timeline | No specific timeline | Standard backlog management | StORM Low (1-10), Vulnerability Low (CVSS 0.1-3.9) |

#### Severity Rating (Technical Impact and Complexity)

| Severity | Label | Definition | Examples | Remediation SLO |

|----------|-------|------------|----------|-----------------|

| **1 (Blocker)** | `severity::1` | Security issue that completely blocks normal operations or causes data loss | System compromise with no workaround, active data breach, critical control failure | Immediate mitigation required |

| **2 (Critical)** | `severity::2` | Security issue with significant impact but complex workaround available | Critical vulnerabilities with limited exploit scenarios, major compliance gaps | 30 days for Critical vulnerabilities, 90 days for observations |

| **3 (Major)** | `severity::3` | Security issue with moderate impact and reasonable workaround | Medium vulnerabilities, process improvements, minor compliance issues | 90 days for vulnerabilities, 12 months for observations |

| **4 (Minor)** | `severity::4` | Security enhancement or minor issue with minimal impact | Best practice improvements, documentation updates, low-priority recommendations | 180 days for vulnerabilities, 18 months for observations |

| **2 (Critical)** | `severity::2` | Security issue with significant impact but complex workaround available | Critical vulnerabilities with limited exploit scenarios, major compliance gaps | 30 days for Critical vulnerabilities |

| **3 (Major)** | `severity::3` | Security issue with moderate impact and reasonable workaround | Medium vulnerabilities, process improvements, minor compliance issues | 90 days for vulnerabilities |

| **4 (Minor)** | `severity::4` | Security enhancement or minor issue with minimal impact | Best practice improvements, documentation updates, low-priority recommendations | 180 days for vulnerabilities |

#### Risk Assessment Guidelines

- **Exploitability**: Ease of exploitation or occurrence

- **Compensating Controls**: Existing mitigations that reduce severity

</details>

### Recommendations

Recommendations reflect how the finding will be addressed. ISO 31000 recommends applying one or more of the following approaches to treating risks: