Vulnerability Management SLA Exception: Add Breached to Match SLO breached... (1053efdd) · Commits · GitLab.com / Content Sites / handbook

content/handbook/security/product-security/vulnerability-management/sla-exceptions.md

+2 −2

Original line number	Diff line number	Diff line
		@@ -26,11 +26,11 @@ For all FedRAMP findings, SLA exceptions are recorded using the [Deviation Reque

		SLA exceptions should not be requested when an SLA could not be met due to reasons which were within GitLab's control. This includes vulnerabilities requiring inter-group or inter-team collaboration, team members being unavailable due to planned or unplanned absence, or other work having a higher priority (such as feature or other bug-fix work).

		When SLAs can not be met in circumstances such as these, the SLA/SLO being missed and the related issues should be reviewed as part of regular group development retrospectives, similar to how bugs or features planned for a specific milestone being missed should be reviewed.
		When SLAs can not be met in circumstances such as these, the SLA/SLO being missed/breached and the related issues should be reviewed as part of regular group development retrospectives, similar to how bugs or features planned for a specific milestone being missed should be reviewed.

		Some common scenarios or suggestions for how to prevent these kind of situations include:

		- Reviewing vulnerability SLAs and time remaining as part of regular bug triage rotations to ensure SLAs are not near miss or already missed
		- Reviewing vulnerability SLAs and time remaining as part of regular bug triage rotations to ensure SLAs are not near miss or already breached
		- Vulnerability issues should be assigned and have an owner, and the owner should also ensure vulnerabilities are handed over during times of absence, planned or unplanned
		- Vulnerability issues should be handled as part of regular retrospectives and milestone planning work