Ask security questions while buying, not after a problem
Most security problems in business software are not clever attacks. They are a former employee whose login still works, a shared admin password written on a sticky note, a backup nobody ever tried to restore, or a cashier who can quietly delete a bill. Each of these can be prevented by decisions made while the software is being designed. This checklist is for owners and managers buying custom software who want to ask the right questions without being security experts.
It covers the software you commission and the data inside it. Keeping a website's content management system and plugins updated is a different job, explained in our guide to website security and backups.
Roles and permissions: decide who can see and change what
Every user should see only what their job needs. In a hospital, the billing clerk does not need clinical notes; in a shop, the cashier does not need the purchase price; in a multi-branch business, branch staff usually see only their own branch. The software should let you create roles, give each role its permissions, and then assign people to roles, so a new joiner gets the right access in one step.
Pay special attention to destructive actions. Deleting a bill, editing an approved entry, changing a rate or reversing a payment should be limited to a few roles, and ideally should require a reason to be typed in. Ask the developer to show you, on a test system, what a junior user sees when trying an action they are not allowed to do.
Logins: passwords, OTP and shared accounts
- One person, one login: shared logins make it impossible to know who did what. Every user should have their own account, including part-time and branch staff.
- Password rules: the software should refuse very short or common passwords and store passwords in a protected (hashed) form, never as plain text.
- OTP for sensitive access: a one-time password by SMS, or an authenticator app, adds a second check for administrators and remote logins. Ask whether it is available and for which roles.
- Leavers: when someone leaves, their account should be deactivated the same day. Deactivating rather than deleting keeps their past entries traceable.
- Repeated failures: several wrong passwords in a row should pause or lock the account, so passwords cannot be guessed endlessly.
Also ask how a user who forgets a password resets it, and who can reset an administrator's password. A reset process that anyone can trigger with a single phone call is a weak point.
Audit logs: a record of who changed what, and when
An audit log records important actions: who created, edited or deleted a record, when, and what the value was before and after. When a bill total changes after the day is closed, or a concession appears that nobody remembers approving, the audit log is how you find out what happened.
Agree with the developer which actions will be logged. At minimum, include logins, changes to money, rates and stock, deletions, and changes to user permissions. The log should be readable by the owner or a chosen manager, and no ordinary user, including administrators, should be able to edit or erase it.
Backups that have been restored at least once
A backup is a copy of your data that can rebuild the system if the original is lost, corrupted or locked by ransomware. A backup that has never been restored is a hope rather than a protection, because you do not know whether it is complete or usable.
| Question | What to agree |
|---|---|
| How often does it run? | A frequency that matches how much work you could afford to re-enter; busy billing data usually needs at least a daily copy |
| Where is it stored? | Somewhere separate from the main server, so one failure cannot destroy both |
| How long is it kept? | Several older copies, not just the latest, in case a problem is noticed late |
| Who checks that it ran? | A named person who receives or checks a confirmation |
| When is a restore tested? | On a schedule you agree, by restoring to a test system and checking totals |
| Can we hold a copy ourselves? | Yes, in a format you can store independently |
Hosting, SSL and keeping the software updated
Where the software runs matters as much as how it is written. If it is hosted on a cloud server, ask who manages the server, who applies operating system and security updates, and whether a firewall limits access to only the services that need to be open. If it runs on a computer in your office, ask how that machine is protected and backed up, and what happens if it fails.
Any software used over the internet should use HTTPS, shown by the padlock in the browser, so that data between the user and the server is encrypted. HTTPS is necessary but not enough on its own: it protects data in transit, not a weak password or an over-generous permission. The frameworks and libraries the software is built on also receive security fixes over time, so ask whether applying them is part of the maintenance agreement.
Your data: export, ownership and personal data law
You should be able to take a complete copy of your data out of the system in a usable format, such as spreadsheets or a database backup, whenever you need it. Try this early, while the developer is engaged, rather than at the moment you want to move.
If your software holds personal data about customers, patients, students or employees, India's Digital Personal Data Protection Act, 2023 is relevant. It deals with how organisations collect, use and protect digital personal data. You do not need to become a lawyer, but it is sensible to collect only the personal data you actually use, limit who can see it, and know how you would respond if someone asks what you hold about them. Read the official material on the Ministry of Electronics and Information Technology website, and take advice from a legal professional on what applies to your organisation. This article is not legal advice.
Who holds the keys: admin access and credentials
Somebody must hold the highest level of access to the software, the server, the database, the domain and any SMS, WhatsApp or payment gateway accounts. That should be your organisation, not only the developer. Keep a securely stored list of these credentials with a senior person, and change them when staff who knew them leave.
The developer will need access to maintain the system. Give it through named accounts that can be removed, rather than through the owner's own login, and ask that their activity is recorded in the audit log like anyone else's.
A checklist to attach to your contract, and how MATROP builds
- Roles and permissions are defined per job, with branch-level restrictions where needed.
- Each user has an individual login, and leavers are deactivated the same day.
- OTP or another second check is available for administrators.
- Audit logs record logins, money and stock changes, deletions and permission changes, and cannot be edited.
- Backups run automatically, are stored separately and are test-restored on an agreed schedule.
- The system uses HTTPS, and server and framework updates are covered by maintenance.
- A full data export is available in a usable format.
- All master credentials are held by the organisation.
At MATROP PRIVATE LIMITED, security is part of how we build custom software: secure coding, role-based access, audit logs and backups, with deployment that includes backup and monitoring. If your sector or customers require a formal, certified security audit, engage an independent auditor; that is a separate job from development, whoever builds the software. Hospitals can see the same ideas applied to patient records in our guide on patient data security in hospital software, and you can contact us to discuss how these points would apply to your own system.
Questions people ask
Is HTTPS enough to keep our business software secure?
No. HTTPS protects data travelling between the browser and the server, but it does nothing about weak passwords, shared logins, excessive permissions or missing backups.
What should a backup restore test actually check?
That the restored copy opens, that record counts and totals (such as the last day's bills or closing stock) match the live system, and that attachments are present. Write down the date and result so you have a record of each test.
Should our software developer have permanent admin access?
They need access to maintain the system, but through a named account that you can switch off and that appears in the audit log. Master credentials should stay with your organisation.
Does the DPDP Act apply to a small business's software?
The Act deals with digital personal data, which most business software holds. How its obligations apply to your organisation is a legal question, so read the official material on the MeitY website and consult a legal professional.
