Activity doesn't guarantee progress. Security teams keep falling into five habits that look productive, but leave our programs no stronger than before.
Some cybersecurity habits feel productive, but don’t actually make organizations more secure. Here are five that I see over and over.
1. Long security policies.
We write documents that satisfy auditors without considering the people who are supposed to follow them. The longer a policy gets, the less likely it is to be read and the less influence it has on behavior. People route around rules they haven’t read, don’t understand, or find unreasonable. Brevity is hard, but it’s the way to produce policies that people will actually use.
Write policies short enough that people will read and understand them.
2. Unrealistic security mandates.
Our documents often codify a target that the business can’t hit on any reasonable timeline. Examples include expecting patching within 24 hours, 100% SSO coverage, or full control over AI use. Knowing when to require urgency and when to pull back builds trust with the teams who have to do the work. Demanding across-the-board perfection burns that trust. Mandates earn cooperation when they reflect the right amount of insecurity rather than a perfect state.
Write mandates the business can actually meet.
3. Tool-chasing.
Many security professionals, myself included, are techies at heart. Not surprisingly, whenever we see a problem, our instinct is to solve it with a tool, whether homegrown or commercially procured. While technology is key to a cybersecurity program, its other tenets are people and process. Every tool we add without accounting for either is likely to fail or take us in the wrong direction.
Understand the people and process implications before pursuing the tooling.
4. Framework obsession.
We invoke “best practices” without asking whether they apply to our situation or whether they reduce risk. Frameworks such as the NIST Cybersecurity Framework, ISO 27001, and CIS Controls are useful starting points. Boards and auditors ask for them by name, which adds pressure to align rather than adapt. But too often we treat them as checklists without understanding how to create practices appropriate for our organization. A control that fits another organization may be the wrong investment for ours.
Choose controls that fit your organization’s threat model, business goals, budget, and team.
5. Metrics masquerading as outcomes.
Reporting metrics comes with the job, but just because we can track something doesn’t mean we should. Mean time to patch, blocks recorded, and training completions trend up without telling anyone whether the organization is safer. We end up reporting numbers stakeholders don’t care about or measuring work that doesn’t improve security. Better measures describe how much the attack surface has shrunk, which exposures we closed, and how well we understand the environment we defend. They point the way out of the vulnerability management hamster wheel toward the defender’s advantage.
Report in terms that business leaders can act on.
Recognize the patterns.
Each of these habits is hard to spot in our own programs because it looks like good practice. Reflecting on our practices, whether during an annual review or quarterly checkpoint, gives us the chance to adjust course before small habits harden into big problems.
