When a growing company has a security incident, the cause is rarely sophisticated. It’s an old admin account nobody turned off. A database left open to the internet during testing. A password reused from a personal account that leaked years ago.
The good news is that the fixes are mostly cheap. The hard part is doing them consistently while everyone is busy shipping. Here are the seven we see skipped most often.
1. Multi-factor authentication everywhere
Not just on email. On your cloud console, your code repository, your domain registrar, your payment provider and your password manager. If someone takes over your domain registrar account, they can take over your email and website in an afternoon.
Use an authenticator app or hardware key where you can. Text-message codes are better than nothing, but they’re the weakest option.
2. Removing access when people leave
Make a short offboarding checklist and actually use it. Cloud accounts, code hosting, shared drives, chat, CRM, any vendor portals. Former contractors are the usual gap, because there’s no formal last day.
Once a quarter, review who has access to what. You’ll almost always find someone who shouldn’t be there.
3. Keeping secrets out of code
API keys, database passwords and tokens end up in code repositories all the time, often in an old commit that everyone forgot about. Turn on secret scanning in your repository host, move secrets into a proper secrets manager, and rotate anything that has ever been committed.
4. Knowing what’s exposed to the internet
Every few months, list everything in your cloud accounts that can be reached from the internet: load balancers, storage buckets, databases, test servers. Most teams are surprised by at least one item. Test environments are the usual culprit because they’re set up quickly and forgotten.
5. Backups you’ve actually restored
A backup you’ve never restored is a hope, not a plan. Pick a date, restore your main database into a separate environment, and time how long it takes. Do it again every quarter. Keep at least one copy that can’t be deleted by the same account that runs production, so ransomware or a compromised account can’t wipe both.
6. Updating dependencies on a schedule
Most modern software is built on open-source libraries, and those libraries get security fixes all the time. Turn on automated dependency updates, and set aside a little time each sprint to merge them. Falling a year behind turns a small update into a risky project.
7. Logging that would help you after the fact
If something did go wrong, could you tell who logged in, what they changed and when? Turn on audit logging in your cloud provider and identity system, send logs somewhere that can’t be edited by the people being logged, and keep them for at least a year.
Where to start
If you only have one afternoon, do the first two: multi-factor authentication on every important account, and an access review. Together they close the doors most attackers walk through.
Then work down the list a step at a time. None of this needs a large security team. It needs someone who owns it and a recurring date in the calendar.
If customers or partners are starting to ask for security questionnaires or SOC 2, these habits are also the foundation you’ll build on. Our SOC 2 readiness starter guide covers what comes next.
Want a quick security review?
We'll check your cloud accounts, code pipeline and access setup, and tell you what to fix first.