Every business owner commissioning software should ask for six basics: secure logins with multi-factor authentication for admins, encryption in transit and at rest, regular security updates, tested backups, tightly controlled access, and security testing before launch. You do not need to understand the code to demand these. You need to ask the right questions and expect specific answers.
Security failures in small-business software rarely come from Hollywood-style hackers. They come from ordinary gaps: an admin account with a reused password, a library nobody updated, a backup that was never tested. This checklist targets those.
The 12-point security checklist
Print this, take it to your next meeting with a developer or agency, and listen for concrete answers. "Don't worry, it's secure" is not one.
| # | Ask this | A good answer sounds like |
|---|---|---|
| 1 | How are passwords stored? | "Hashed with a modern algorithm such as bcrypt or Argon2, never in plain text." |
| 2 | Is multi-factor authentication available? | "Yes, and it's mandatory for admin accounts." |
| 3 | What stops someone guessing passwords? | "Login attempts are rate-limited and suspicious activity is logged." |
| 4 | Who can see what? | "Roles with least privilege; staff only see the data their job needs." |
| 5 | Is all traffic encrypted? | "HTTPS everywhere, with automatic certificate renewal." |
| 6 | Is stored data encrypted? | "The database and backups are encrypted at rest." |
| 7 | Where are passwords and API keys kept? | "In a secrets manager or encrypted environment settings, never in the code repository." |
| 8 | How do you guard against common attacks? | "We follow the OWASP Top 10, validate inputs and use parameterised database queries." |
| 9 | How are updates handled? | "Dependencies are scanned and patched on a schedule, with urgent patches applied quickly." |
| 10 | What gets logged and who is alerted? | "Logins, admin actions and errors are logged; alerts go to a named person." |
| 11 | How do backups work? | "Automated, stored off-server, and we test a restore regularly." |
| 12 | What testing happens before launch? | "Code review, automated tests, and an independent security test for sensitive systems." |
The sections below explain why each group matters, in plain English.
Who can get into the system, and how?
Most real-world breaches start with a login, so authentication deserves the most attention. Authentication simply means proving who you are.
- Hash passwords properly. A hash is a one-way scramble; even the developer cannot read the original password. If anyone can email you your password, it is stored wrongly.
- Require multi-factor authentication (MFA) for admins. A code from an authenticator app stops most stolen-password attacks.
- Rate-limit logins. The system should slow down or block repeated failed attempts from the same source.
- Expire sessions. Logged-in sessions should time out, especially on shared office computers.
- Use roles, not shared logins. Everyone gets their own account with only the permissions they need. Our explainer on role-based access and permissions covers how to design these.
How is data protected in transit and at rest?
Data needs protecting in two states: moving across the internet ("in transit") and sitting in your database or backups ("at rest").
HTTPS handles the first. It should be on every page and every API call, not just the login screen. For the second, the database, file storage and backups should be encrypted, so a stolen disk or leaked backup file is useless on its own.
Then there are secrets: database passwords, payment-gateway keys, email-service keys. A secret committed to a code repository should be treated as leaked, because repositories get shared, copied and cloned. Ask where secrets live and how they would be rotated if a staff member left.
How is the code itself kept safe?
Good developers write code that assumes every input could be hostile. The OWASP Top 10, a widely used list of the most common web application security risks published by the Open Worldwide Application Security Project, is the standard reference. Ask whether the team works to it.
In practice, that means:
- Validating every input, from form fields to file uploads.
- Using parameterised queries so that text typed into a form can never be run as a database command (an attack called SQL injection).
- Setting a Content Security Policy (CSP), a browser instruction that limits which scripts may run on your pages.
- Reviewing code before it is merged, ideally by a second developer.
- Scanning third-party libraries for known vulnerabilities, because most modern apps are built largely from open-source packages.
What does a real security fix look like?
Here are two from our own website. During a review of grww.tech, we found that the login rate limit could be bypassed. The code identified visitors by an IP-address header that a client can set themselves, so an attacker could pretend to be a new visitor on every attempt and keep guessing. We changed it to trust only the address supplied by our own server infrastructure.
We also removed unsafe-eval from the site's Content Security Policy. That setting allows the browser to run code built from text strings at runtime, which widens the door for script-injection attacks. Removing it meant adjusting how some code loaded, but tightened the policy without changing what visitors see.
Neither issue would show up in a demo. Both were found by deliberately reviewing security settings, which is why you should ask for that review rather than assume it happens.
What happens when something goes wrong?
Assume an incident will happen one day and judge the software by how quickly you would notice and recover.
- Logging: record logins, failed logins, permission changes and data exports, with timestamps.
- Alerts: someone specific should be notified about unusual activity, errors and downtime.
- Backups: automated, stored off the main server, with restores tested. An untested backup is a hope, not a plan.
- An incident plan: a one-page document saying who to call, how to lock accounts, how to restore, and who tells customers.
Privacy laws add obligations here. India's DPDP Act 2023 and Australia's Privacy Act 1988 both include duties around personal data breaches. Our guide to data privacy for custom software under the DPDP Act and Privacy Act explains what that means for your system.
Who holds the keys after launch?
Ownership of accounts is a security issue, not just an admin one. Hosting, domain, code repository, email-sending service and payment gateway accounts should be in your company's name, with developers added as users you can remove.
Two habits close many gaps:
- Offboard properly. When a staff member or contractor leaves, remove their access the same day, and rotate any shared secrets they knew.
- Review access quarterly. List who can log in to what. You will usually find at least one account nobody remembers creating.
How do you know the security actually works?
You test it. Automated tests confirm that, say, a sales user cannot open the admin settings page. Code review catches risky patterns. For software that handles payments, health information, identity documents or large volumes of personal data, an independent penetration test (an outside specialist trying to break in, with permission) is worth commissioning before launch and after major changes.
Security testing sits within wider quality assurance; our explainer on why skipping QA testing costs more later covers the full picture. For where security fits in the overall build, see our complete guide to custom software development.
Frequently asked questions
Does security make software much more expensive?
Built in from the start, the basics add modest effort: they are part of doing the job properly. Bolting them on after launch, or after an incident, costs far more. Independent penetration tests are a separate line item priced by scope.
Is off-the-shelf software more secure than custom software?
Not necessarily. Popular platforms have dedicated security teams, but they are also bigger targets, and plugins added to them are a common weak point. Well-built custom software with the basics above can be very secure.
Do I need a penetration test for a small internal tool?
Often not. For a low-risk internal tool, code review, sensible access controls and good updates are usually enough. Commission a test when the software holds sensitive personal data, takes payments or is exposed to the public at scale.
What should I do if I suspect a breach?
Lock affected accounts, preserve logs, and contact your developer immediately. Then take legal advice on your notification duties under the privacy laws that apply to you, as these can have tight timelines.
Make security part of the brief
The cheapest time to get security right is before the first line of code. Talk to us about your project and we'll write these basics into a fixed-price scope from day one; our software services also cover security reviews of existing systems.