<!--Please answer the below questions to the best of your ability.--> #### What's this issue all about? (Background and context) Both external teams in internal counterparts have requested the ability to define a reason when dismissing a vulnerability. This is a pivotal component in vulnerability management since security teams refer back to these reasons for compliance audits and even when triaging similar vulnerabilities. #### What hypotheses and/or assumptions do you have? We believe these are the appropriate values that will encompass >90% of all uses cases when users decide not to address a detected vulnerability. * Accept risk * False positive * Mitigating control * Out of scope #### What questions are you trying to answer? 1. Are these the correct values users would expect? 2. Do these values account for >90 of the cases users would normally encounter? #### What research methodology do you intend to use? Internal interviews with the security team. Considering a larger survey. #### What persona, persona segment, or customer type experiences the problem most acutely? gitlab~9335226 #### What business decisions will be made based on this information? #### What, if any, relevant prior research already exists? N/A #### Who will be leading the research? @andyvolpe #### What timescales do you have in mind for the research? 1 Milstone - %"13.5" #### Relevant links (problem validation issue, design issue, script, prototype, notes, etc.) <!-- #### TODO Checklist Consider adding a checklist in order to keep track of what stage the research is up to. Some possible checklist templates are here: https://about.gitlab.com/handbook/engineering/ux/ux-research-training/templates-resources-for-research-studies/#checklists -->