In the first part of this series, I argued that after 22 years, it's time to replace Cybersecurity Awareness Month with Cybersecurity Readiness Month. Awareness made sense in 2004, but today everybody knows cyberattacks happen. Knowing hasn't made us particularly good at preventing them or dealing with the aftermath.
In Part Two, we looked at personal readiness: protecting important accounts, limiting what attackers can reach, testing backups, and preparing for failure. Now let's apply those principles to organizations, where the consequences are bigger and the systems more complicated. Most companies have security policies, scanners, incident response plans, and enough dashboards to qualify as a small television studio. What they don't always know is whether any of it will work when something goes wrong.
Compliance Isn't Readiness
Organizations love checklists. Security policy? Check. Annual training? Check. Vulnerability scanning? Check. Incident response plan? Check. Unfortunately, attackers don't care how many boxes you've checked.
Compliance frameworks serve a purpose, but meeting requirements isn't the same as being prepared. Having an incident response plan doesn't mean your team can execute it, and running vulnerability scanners doesn't mean you're fixing what matters. The real question is whether your controls actually work. If all you can demonstrate is that somebody purchased them, you've confused procurement with security.
Stop Treating Every Vulnerability Like the Apocalypse
Security teams are drowning in findings from scanners, cloud security tools, and penetration tests. Everything gets ranked by severity, tickets get assigned, and developers struggle to keep up. But a critical vulnerability doesn't automatically mean an attacker can exploit it in your environment.
Context matters. Is the vulnerable code used? Can an attacker reach it? What privileges would exploitation provide? A critical vulnerability in unreachable code may deserve less attention than a medium-severity issue on an internet-facing authentication endpoint.
Readiness means prioritizing actual risk. Identify exposed applications, use reachability analysis to find vulnerable functionality your code invokes, and consider active exploitation and business impact. Semgrep has been explaining how reachability analysis cuts through dependency alert noise since 2022. Your security team doesn't need another dashboard displaying 40,000 findings. It needs to know which four could ruin everyone's weekend.
Your Developers Are Part of the Security Team
Application security used to follow a predictable schedule. Developers wrote code, security scanned it, somebody filed tickets, and everyone argued about false positives until the release deadline settled the argument.
That model was struggling before AI started generating code faster than traditional security reviews could keep up. The answer isn't banning AI or making developers wait three weeks for approval. That's how you convince everyone security is the department of no. Instead, integrate security scanning into pull requests so developers get useful feedback while the code is fresh. Prioritize actionable findings and gradually introduce blocking policies for issues you're confident represent real risk. Semgrep has a walkthrough of how to prevent vulnerable code from merging without blocking developers. The goal isn't turning developers into security specialists. It's making secure development the easiest option.
And stop measuring success by alert volume. If nine out of ten warnings are irrelevant, developers will eventually ignore the tenth. A security tool nobody trusts is no better than one nobody uses.
Know What You're Actually Running
Modern applications are assembled from open-source packages, libraries, APIs, containers, and cloud services. Do you know what's running in your environment?
Supply chain attacks demonstrate that attackers don't always need to compromise your developers. Sometimes they only need to compromise something your developers trust. A malicious package can steal credentials during installation, while a legitimate library might contain a vulnerability that's only dangerous when specific functionality is used. Those are different problems requiring different responses.
Start by maintaining an inventory of dependencies, monitoring for malicious updates, and identifying which repositories are affected when something becomes compromised. Semgrep's research on malware detection and response automation shows how organizations can identify affected repositories, alert teams, and automate parts of the response. You don't have to eliminate every dependency, but you should know which ones can hurt you and what you'll do about them.
Practice Before Somebody Else Makes You
Every organization claims to have an incident response plan. Some even know where to find it. But when was the last time anyone tested it? As Mike Tyson famously said, “Everyone has a plan until they get punched in the mouth.”
Pick a realistic scenario, such as compromised credentials or a malicious dependency, and have the people responsible for responding work through it. Include engineering, security, IT, legal, communications, and leadership. Who owns the affected systems? Can credentials be revoked quickly? Can you identify compromised repositories, isolate systems, and restore services?
Record how long each step takes, where people get stuck, and which decisions require approval. Then fix those problems and run the exercise again. A tabletop exercise where everyone congratulates themselves probably wasn't difficult enough. The goal isn't proving everyone knows the plan. It's discovering where the plan falls apart.
Measure What Actually Matters
Organizations love measuring activity. Vulnerabilities found, alerts generated, employees trained. Those numbers look good on dashboards but don't necessarily mean you're safer.
Better measurements are harder. How quickly can you fix an exploitable vulnerability? How much unnecessary work are you creating for developers? Can you detect compromised credentials, contain an incident, and restore critical systems within acceptable timeframes?
Readiness isn't about proving you've done a lot of security work. It's demonstrating that the work makes a difference.
The 2:00 A.M. Test
Here's the organizational version of the readiness test from Part Two.
It's 2:00 a.m. An attacker has compromised a developer's credentials, accessed production, and started moving through your infrastructure. Your security team receives an alert.
Can they determine whether it's real, identify what the attacker can reach, and contain the compromise without taking the business offline? Do they know who has authority to make those decisions? More importantly, have they demonstrated they can do these things, or does everyone just assume somebody else knows how?
If your answers are policies, vendor contracts, and screenshots of dashboards, you might have a security program. Whether you have a ready organization is another matter.
That's why I keep arguing for Cybersecurity Readiness Month. We've spent decades teaching people cyberattacks are possible and billions buying tools to identify potential problems. It's time to find out whether we can handle them.
In the final installment, we'll tackle the part everyone hopes to avoid: what happens after an attack succeeds. Prevention eventually fails, and when it does, the difference between an incident and a catastrophe is what you're prepared to do next.
