3 tips to improve your security risk management program

Higher agent accuracy, lower token cost
Learn how to harden your software factory and let AI agents earn autonomy, without trading away security.
Stay updated with our latest features and improvements.
Published on: May 28, 2024
Establishing a security risk management program is more than just checking the compliance box. Here are a few ways to help better protect information and support strategic decision-making.
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.
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):
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).
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:
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?"
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 securityrisk@gitlab.com.
If you’d like to learn more about how we manage security risk, please check out the StORM program in the GitLab Handbook.
No credit card required.
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Start building faster today
See what your team can do with the intelligent orchestration platform for DevSecOps.
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license