This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
The Observation Management Program at GitLab is used to identify, track, remediate and provide a risk ratings of identified findings, exceptions or deficiencies for any Tier 3 information system risks that are identified as an output of compliance operations or other mechanisms by team members, such as self-identification of a system specific risk.
This procedure details the remediation process of observations.
Tier 3 risks identified at the information system or business process levels
|Security Compliance Team||Responsible for executing Security control tests to determine test of design and test of operating effectiveness of Security and IT general controls.|
|Internal Audit||Responsible for executing Internal Audit control tests to determine test of design and test of operating effectiveness of all internal controls as required by audit plan.|
|Security Risk Team||Responsible for executing Third Party Risk Management (TPRM) risk and security assessments to determine risk associated with third party applications and services.|
|Field Security Team||Responsible for executing Customer Assurance Activities(CAA) responsible for providing customer assurance with GitLab's security practices and operating procedures.|
|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.|
|Remediation Owner||Validates observation, confirms assignee, stop date (due date), finalizes remediation plan and conducts remediation activity based on defined remediation SLA's.|
|Observation Program DRI||Responsible for regular reviews of program health and stakeholder report delivery.|
|Managers to Executive Leadership||Responsible for escalation as necessary and resource allocation for remediation activity.|
|Security Assurance Management (Code Owners)||Responsible for approving significant changes and exceptions to this procedure.|
It is the responsibility of the Observation Manager to track the milestones, work progress and validation of the remediation activity.
See STEP 3 in the applicable runbook below for the
Observation Remediation Workflow based on observation type:
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 the @sec-compliance-team. The Observation Manager will then validate the remediation activity for completeness, re-test the observation (as applicable) and close the observation issue.
It is the responsibility of the Observation Manager to determine if a open observation is not valid or no longer applicable. This could be applicable for a variety of reasons including:
If an observation is confirmed Ignored or Invalid, the associated risk rating of that observation can be changed. See the Observation Risk Rating Adjustment runbook for further details.
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 observation Epics can be found here.
The Remediation Owner is responsible for tagging the Observation Manager in the observation issue to validate the remediation activity for completeness, re-test the observation (as applicable) and close the observation issue. If there is no Observation Manager assigned, tag the @sec-compliance-team for Observation Manager assignment.
In cases where Internal Stakeholders (not the Remediation Owner) provide remediation documentation to support closure of the observation. Please tag the Observation Manager in the observation issue. This will trigger the validation of the remediation activity for completeness, re-test as appropriate and closure by the Observation Manager.
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||Remediation Goal|
|High||6 months, or as otherwise defined by the agreed upon remediation plan||4 weeks|
|Moderate||6-12 months, or as otherwise defined by the agreed upon remediation plan||6 weeks|
|Low||> 12 months, or as otherwise defined by the agreed upon remediation plan||8 weeks|
A more detailed SLA and Remediation Goal process can be found in this runbook (access is available only to internal GitLab team members)
Throughout the course of testing or general monitoring of the GitLab ecosystem, Opportunities for Improvement (OFI) may be identified and documented so that the overall control environment and GitLab's processes can be improved.
To capture an OFI, create an issue in the Observation Management project and add the RiskRating::OFI label.
OFI's do not have defined remediation SLA's as they are process improvements or suggestions only. The Remediation Goal to communicate the OFI to the appropriate stakeholder is 10 weeks.
Exceptions will be created for observations that breach a mutually agreed upon remediation date, breach in SLA or if the Remediation Owner confirms the observation will not be remediated.
Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.
If you have any questions or feedback about the security compliance observation management process please contact the GitLab Security Compliance Team