A 10-Point Security Checklist for Business Software

When a small company buys or builds business software, security usually comes up late, as a line near the end of the proposal: "industry-standard security." That phrase doesn't mean much. What matters is a handful of specific practices, most of which cost little if they're planned from the start and a lot if they're added after something goes wrong.

You don't need to be technical to ask the right questions. Here are ten checks you can run on any system, whether you're building it, buying it or inheriting it.

A quick note: this is a practical checklist, not a certification or a guarantee. Products that handle payments, health records or other regulated data have additional legal requirements, and you should take professional advice on those.

1. Who can log in, and how?

Every person should have their own account. Shared logins make it impossible to know who did what, and they linger long after someone leaves. Ask whether passwords are stored safely (hashed, never in plain text), whether there are limits on repeated failed attempts, and whether two-step verification is available for administrators at least.

2. Does each person see only what they should?

Role-based access means a sales rep can't open payroll and a customer can't see another customer's invoices. This is the failure that quietly causes the most embarrassment: user A changes a number in a web address and sees user B's data. Ask the team to demonstrate that it can't happen, not just to say so.

3. Is data encrypted in transit and at rest?

"In transit" means the padlock in the browser (HTTPS), which should be on every page, not just the login. "At rest" means stored data, especially backups and uploaded files, is protected so a stolen disk or a leaked backup file isn't readable. Ask where sensitive fields such as ID numbers or bank details are stored and how.

4. Are backups real, and have they been tested?

A backup you've never restored is a hope, not a backup. Ask how often data is copied, where the copies live (not on the same server), how long they're kept, and when someone last restored one successfully. Ask the same about the code and configuration, not only the database.

5. How are updates and patches handled?

Most real-world breaches use known flaws in out-of-date software. Someone needs to own keeping the operating system, frameworks and libraries up to date, on a schedule. If the answer is "when something breaks", that's a risk. This is a central part of ongoing software maintenance.

6. What happens to secrets like passwords and API keys?

Keys for payment gateways, email services and databases should live in protected configuration, not inside the code or in a shared chat. If a developer leaves, can you change every key without a crisis? Which brings us to ownership, covered in who owns your software.

7. Is there a record of important actions?

An audit log records who changed what and when: who edited a price, exported customer data, or deleted an order. You'll want it the first time something looks wrong. It also deters casual misuse.

8. How are third-party services and integrations controlled?

Each connected service, whether payments, messaging or an accounting tool, is another door. Give each connection only the permissions it needs, and keep a list of what's connected. When you add integrations, review them the way you would a new supplier. Our note on connecting CRM, accounting and order systems covers some of the design choices.

9. Is personal data collected on purpose?

Only keep what you need. The less personal data you hold, the less there is to protect, lose or explain. Check that privacy and consent notices match what the product really does, and that you know how to delete a person's data if asked. India's data protection law and similar laws elsewhere create duties here, so ask an adviser what applies to you.

10. What is the plan if something goes wrong?

Before there's an incident, decide who is told, who can switch the system off, how customers will be informed and who talks to whom. A one-page plan written on a calm day is far better than improvising during a bad one. Include a phone number that someone answers.

How to use this list

Print it. Take it to your next call with a vendor or your own developers and ask about each item. You're not trying to catch anyone out; you're looking for specific answers. "We hash passwords with bcrypt and require two-step verification for admins" is a specific answer. "We take security very seriously" is not.

It also helps to include a few of these as written requirements in your project brief. If you're still shaping that, preparing software requirements is a good place to start, and our security page describes how we handle these things on our own work. If you'd like a second opinion on an existing system, get in touch.