Risk management is typically viewed as a check-the-box compliance activity. It can also be seen as a blocker. Effective risk management programs provide their company’s decision-makers with relevant, reliable, and usable information to support the achievement of objectives and mitigation of risks. GitLab’s Security Operational Risk Management (StORM) program identifies, monitors, and supports the remediation of security risks. Risk information from the StORM program informs our Security division’s strategy and helps to maintain the confidentiality, integrity, and availability (CIA) of customer and GitLab data. We’ve made some changes over the past year to our risk management practices to better support strategic decision-making and we’d like to share some of these changes in the spirit of collaboration and transparency.
Aggregate and self-serve risk information
Risk information measures and contextualizes risks. For example, if we have a risk related to identity management, helpful risk information might be the number of open compliance observations related to identity management (for example, lack of multi-factor authentication for # applications). A more qualitative example for the same risk could be the latest developments related to the rollout of a single sign-on (SSO) platform.
The efficiency of self-serving risk information will depend on the level of access you have to company information. Aggregating risk information at GitLab involves searching the following sources (among others):
- GitLab - GitLab objects (i.e., epics, issues, and merge requests) related to our risk
- Google Drive - documents, spreadsheets, and presentations
- Shared calendars - meetings, agendas, and recordings
- Slack - recent announcements and discussions
- The GitLab Handbook - policies, key contacts, operational guides, and roadmaps
By finding risk information ourselves, we get familiar with the risks, identify key team members, reduce the risk of bias, and save risk owners time. When pulling information from other teams/departments/functions that report on risks (for example, Internal Audit), highlight that overlap to show a more comprehensive view of your risks. In your search for risk information, try to find out if customers are interested in this risk and what competitors are doing about it? Linking disparate information in an easily consumable way also helps folks get up to speed quickly (very helpful for new team members).
Identify metrics to contextualize risks
Risks can be ambiguous. Having metrics to help put them into context and measure progress toward a goal is key to making better decisions. How are these risks affecting the achievement of objectives, what does success look like? Identify the end goal and how that can be measured. Even if the information for the metric isn’t readily available, it’s a helpful guide until you can establish the metric or activity that generates the metric. High-level metrics are also helpful to understand the breadth and complexity of your company such as number of:
- team members
- temporary service providers (i.e., contractors)
- applications in your tech stack
- production servers
- active vendors
- countries in which your company operates
When documenting or presenting this information (ex., a quarterly risk report), it’s helpful to link out to the source of these metrics so that they can be viewed by readers. Ask decision-makers for feedback on these metrics, asking, "Is what we have helpful or is there anything else you'd like to see?"
Open up access to risk information for greater awareness and engagement
Access to risk-related information, audit findings, and other compliance output is usually restricted to specific teams or select team members. Does it have to be? We’ve found that opening up access and hosting it on a familiar platform (GitLab for us) has increased engagement and awareness.
Risks and objectives are always changing. Differing perspectives gained from greater transparency can help refine risks and create an environment for new ideas. Risks should be considered always in draft and contributions from risk owners and other contributors should be encouraged.
Have you tried any of the above suggestions? If so, how did it go? Or do you have ideas about how we can better support security-related decision-making? We’d love to hear from you. Please share feedback in our forum or email us directly at [email protected].
If you’d like to learn more about how we manage security risk, please check out the StORM program in the GitLab Handbook.
