Observations in the context of security compliance refers to any Tier 3 operational risks which are more granular than Tier 2 operational risks. These observations are risks identified at the Information System level. The volume and granularity of these Tier 3 risks make it inappropriate to track via the GitLab Risk Register and so this observation management process will guide team-members on how to track these Tier 3 risks.
The following phases walk through the lifecycle of operational risk observations.
Observations can be identified in the following ways:
Each observation has a GitLab issue associated with it in the Observation Management project. The GitLab security compliance team will create all observation issues to ensure uniformity in the process. If you have a Tier 3 operational risk that you have identified, please reach out to the GitLab security compliance team and we can help get this observation record created.
If a template does not exist for the related source of the identified observation, please create an MR for the proposed new observation issue template and share with the Security Compliance team.
Tier 3 operational risk ratings are based off the STORM risk rating methodology.
"Likelihood" refers to the likelihood that the observation will impact the results of an internal or external audit:
|Qualitative Score||Risk Level||Scoring Guidelines|
|5 to 6||HIGH||6 = This observation will certainly change internal or external audit results 5 = This observation will almost certainly change internal or external audit results|
|3 to 4||MODERATE||4 = This observation will likely change internal or external audit results 3 = This observation could change internal or external audit results|
|1 to 2||LOW||2 = This observation is unlikely to change internal or external audit results 1 = This observation won't change internal or external audit results|
"Impact" refers to the impact this observation would have on the results of an internal or external audit if such an impact were to occur:
|Impact Score||SOC Audit Impact Guidelines|
|Very Low (1)||This observation will not result in an audit exception or a qualified report|
|Low (2)||This observation could result in a low-risk audit exception|
|Moderate (3)||This observation on its own will result in a low-risk audit exception|
|High (4)||This observation on its own will result in either a moderate-risk audit exception or could result in a qualified report|
|Very High (5)||This observation on its own will result in either a high-risk audit exception or will result in a qualified report|
Inherent risk of the observation is calculated by multiplying the qualitative score of the likelihood by the qualitative score of the impact and using that product in the STORM risk level table.
Current observations can be tracked in a number of different ways:
If multiple observation issues relate to the same root cause or are blocked by the same component of work, these issues will be connected together into an Epic in order to more clearly see how multiple observations issues are connected. A list of these Epics can be found here.
Once observations are identified and recorded by the security compliance team, that observation will first be validated by the observation owner. Once validated, it will be up to the observation owner to identify the milestones/phases of work involved in the remediation, tracking progress towards remediation, and completing remediation. Once remediation has been completed, the observation owner will notify the security compliance team who will validate that remediation has been completed and re-test the observation as appropriate before closing the observation issue.
Observation remediation SLA's are determined by the risk rating of the individual observation. The following table shows the SLA for each risk rating:
|Risk Rating||Remeditation SLA|
If you have any questions or feedback about the security compliance observation management process please contact the GitLab security compliance team.