Large breaches make headlines for their scale, but the lessons are usually small and repeatable. Again and again, the root cause is not an exotic exploit. It is a misconfiguration, a reused credential or a process that relied on everyone remembering to do the right thing. Four takeaways apply to almost any organisation.
1. Human error is a design problem
Blaming an individual rarely prevents the next incident. If one mistake can expose a large amount of data, the system allowed it. Build guardrails: default-deny permissions, approval steps for risky changes, and automated checks that catch a misconfiguration before it reaches production.
2. Know where your data lives
You cannot protect what you have not inventoried. Many organisations discover sensitive data in places they did not expect: old exports, test databases, shared drives and third-party tools. Keep a current map of what data you hold, where it sits and who can reach it, and remove what you no longer need.
3. Apply least privilege everywhere
Broad access turns a small compromise into a large one. Give people and services only the access their role needs, review it on a schedule, and remove it promptly when someone changes team or leaves. Strong multi-factor authentication on every account that matters is the cheapest control with the biggest effect.
4. Detect early and rehearse the response
Damage grows with the time between compromise and discovery. Centralised logging, alerting on unusual access patterns and clear ownership of on-call response shorten that window. Just as important, practise the plan: who decides, who communicates, and who talks to customers and regulators.
Where to start
- Inventory your most sensitive data and the systems that touch it.
- Enforce multi-factor authentication and remove standing access you cannot justify.
- Add automated configuration checks to your delivery pipeline.
- Run a tabletop exercise for a breach scenario and fix the gaps it reveals.
None of this requires a new product purchase. It requires ownership, discipline and a regular review, which is exactly what a technology governance practice is for.
