Almost nobody is breached by something nobody knew about. The incidents that reach a board usually start with known problems: a vulnerability in a dependency the company already ships, a credential sitting in a repository, or an account that belonged to somebody who left months ago.
A dependency is software your system relies on. A repository is where code or related project files are stored. Those details sound technical, but the business issue is simple. Known weaknesses stay dangerous when nobody closes them quickly enough, or when nobody knows who owns the affected system.
The time between disclosure and patching is the risk
When a vulnerability is disclosed publicly, exploit code often follows within days. The typical organisation patches critical issues in weeks. Everything in between is open season, and it requires no sophistication from the attacker at all.
The single most useful number to ask for is how long it takes you to patch a critical vulnerability. That number should be measured rather than estimated, because the exposure window is the period when the company is relying on hope.
Small faults become bigger failures when systems are unprepared
Most outages are a small fault meeting a system with no plan for it. A dependency slows, every client retries, and the traffic triples at the worst moment.
The same pattern applies to security. One compromised credential becomes lateral movement, meaning access spreading from one system to another, because nothing was segmented. Segmented access limits what one account or system can reach.
Ask these four questions this quarter
These are the four questions worth asking your engineering team:
- How long does it take us to patch a critical vulnerability, measured rather than estimated?
- Could we produce, today, a list of every system we run and who owns each one?
- If an account were compromised right now, what could it reach, and would we know?
- When did we last restore from a backup and time it?
If any answer is uncertain, that is the finding. The uncertainty is the vulnerability.
Annual testing leaves gaps between tests
A penetration test describes the software you had in February. Your code changes weekly. The durable protection is the checks that run on every change:
- secret scanning
- dependency scanning
- infrastructure policy
- access review on a schedule
Periodic testing then catches what automation cannot reason about. These checks matter because the system keeps changing after the test is finished.
None of this is exotic. The unglamorous work is what actually moves the risk.
