Many organizations say they value security. That’s not a surprise. With all the news of high-profile breaches and the scrutiny of security from the public eye, organizations seem to be prioritizing security in ways they haven’t in the past. What organization these days wouldn’t say security is important? However, not all organizations back up what they say by putting their words into action. They may “talk the talk,” but they don’t always “walk the walk.”
One of the most important contributors to “walking the walk” when prioritizing security is the culture of the organization. You can make technical, process and policy changes, but what will really enable those changes to stick is a culture that values security.
Here are seven signs indicating you have a culture that values security.
1. You invest in security.
You put your proverbial (and actual) money where your mouth is in the form of budget and staff. You can see the line items in the budget and the boxes on the org chart intended to maintain and improve the security of the organization. You might not have all the money and staff to do everything you want to do (who does?), but you should have enough to do meaningful work at a sustainable pace to achieve the most important security outcomes for the organization. And these days, the budget line items and org chart boxes related to security are likely bigger than they used to be.
2. You prioritize security over new functionality frequently.
At times, you put security concerns ahead of new functionality rather than simply being a “feature factory.” The “feature factory” churns out new features for users and does not prioritize other concerns, like improving security, upgrading components and generally paying down technical debt. In contrast, if working on security sometimes wins over building yet another feature, it shows that security carries value for the organization.
3. You “shift security left.”
Your product and engineering teams engage the security team early and often to discuss architecture, design and engineering choices and how to incorporate security into those choices. Shifting this engagement “left” in the schedule contrasts with what typically happens in many organizations: the product and engineering teams must get security to review what they’ve created just before deploying to production—on the “right” side of the schedule. Interactions with security are much more constructive and productive when they happen on the “left” and you make better decisions about security.
4. New security tooling comes with new training and time to implement it correctly.
When you decide to adopt new tooling to improve security, you enable those using it to be successful. So many tools sit on the shelf unused or, worse, actually hurt value delivery because the organization thought the work to adopt a new tool was done once they signed the contract to buy it. The people using the tool should know how to use it—they should have adequate training for your organization’s context and use cases. They should also have time to implement the tool correctly.
5. Sustainable security practices.
You conduct regular reviews of your environment, assess risks and practice good “security hygiene.” For example, you might have a policy specifying that open-source and other software must be no older than “latest version minus one.” You apply patches soon after they become available. You have good visibility into what systems, products and technologies are running in your environment. You conduct regular audits of the controls you have in place to determine whether they’re effective and operating as intended and take action when you discover a gap. You’re regular and consistent in the security fundamentals.
6. You “make the right way the easy way” when it comes to security.
You make it easy for those building and maintaining your systems to choose more secure methods, tools and technologies over less secure ones. Making it easy might involve creating hardened container images for developers to use “off the shelf” rather than creating their own, creating easily consumable services and components that already have security baked in and giving developers fast feedback on the security of their code through automated security tests.
You improve the developer experience by simplifying tasks, increasing productivity and reducing the cognitive load associated with secure engineering practices.
7. You behave with security in mind.
Actions speak louder than words. The true test of whether an organizational culture values security is the behavior of its employees. Is security a regular topic of conversation in meetings? Do employees advocate for security in how the organization operates? Do employees take actions (and avoid others) that appropriately mitigate risk to the organization? A good litmus test is how the organization increases security awareness generally (e.g., detecting phishing and the importance of multi-factor authentication) and how employees respond to it. Is the participation high? Are the complaints low? Another approach is to talk to your corporate IT group. They’ll likely give you a wealth of insight into how well (or not) the employees in your organization are behaving with security in mind. How many employees participate in security awareness education may not seem relevant to building and operating secure enterprise systems, but it is indicative of the cultural value that underpins them both.
Looking for these indicators will distinguish the organizations that truly value security and are taking real action to improve it from those who merely spout the rhetoric that security is important, but fail to back it up. If security is important to you, figure out which type of organization yours is. Culture matters and, especially in the long run, an organization with a culture that appreciates and reinforces the importance of security will achieve better security outcomes than ones that don’t.
First published on Forbes.com.