A growing Indian company rarely has a security team. It has an owner, an accountant, and a software vendor who says "don't worry, it's secure." This article is the list of things that phrase should actually mean, written so a business owner can check them without being an engineer. Most of it is not expensive. Most of it is skipped.
Why this matters more than it used to
Two things changed. First, business data now lives outside the office: on cloud servers, on staff phones, in WhatsApp groups. A lost phone or a shared password is a real breach, not a hypothetical. Second, the Digital Personal Data Protection Act, 2023 made every Indian business that collects personal data legally responsible for protecting it. If your ERP, LMS, clinic system or app stores customer names, phone numbers, Aadhaar details, health records or student information, that is you.
Authentication: who can log in
- Individual logins for every user. No shared "counter" login. When five people use one password, you cannot tell who did what, and you cannot remove one person's access when they leave.
- Two-factor authentication for anyone who can see money or personal data. An OTP on the phone, or an authenticator app, in addition to the password. It should be available on every system and mandatory for owners, accounts and admins.
- Password rules that are sensible, not theatrical. A minimum length of 12 characters and a check against known leaked passwords do more than forcing a change every 30 days, which just produces passwords written on sticky notes.
- Sessions that expire. A staff member's browser on a shared PC should not stay logged in for weeks.
- A leaver process. The day someone resigns, their access goes. Ask your vendor how you disable a user, and try it.
Access control: who can see and do what
The principle is that each person sees only what their job needs. A salesperson sees their own customers, not everyone's margins. A godown worker records stock movements but cannot edit prices. A teacher sees their own classes, not the fee ledger.
Ask the vendor to show you the roles in the system and what each one can do. If the answer is "admin and user", that is not access control. Ask specifically about exporting data: who can download the full customer list to Excel, and is it logged?
Audit logs: what happened and who did it
Every change to money, stock, prices, grades or patient records should be recorded with who, when and what changed. This is not for catching thieves, though it does that. It is for answering "why does this invoice show a different amount" three months later without a shouting match. Ask to see the audit log on the demo, and ask whether it can be edited or deleted. It should not be.
Backups: the practice that saves companies
Ransomware, a failed disk, a deleted database by mistake, a vendor going out of business. Backups are the answer to all of them, and they are the item most often found to be missing when it is too late.
| Question | Acceptable answer |
|---|---|
| How often is the data backed up? | At least daily; hourly or continuous for billing and transactions |
| Where are backups stored? | On a different server or cloud account from the live system, in India |
| Are backups encrypted? | Yes, with keys not stored alongside the backup |
| When was a restore last tested? | Within the last three months, with a written result |
| Can we get a copy of our own data? | Yes, in a standard format, on request, without a fee |
| How long are backups kept? | Daily for at least 30 days; monthly for at least a year |
A backup that has never been restored is a hope, not a backup. Ask the vendor to restore last week's backup to a test environment in front of you once a year.
Data in transit and at rest
Every screen and every app should talk to the server over HTTPS, with a valid certificate. That is basic and free. Data at rest, on the database disk and in backups, should be encrypted. Personal identifiers such as Aadhaar numbers, if you must store them at all, should be encrypted or masked separately, and shown only partially on screen.
Also ask where the server physically is. For most Indian businesses, hosting in an Indian region of a cloud provider is the simplest answer to both latency and compliance questions.
The DPDP Act, 2023 in plain terms
The Act treats any business deciding why and how personal data is collected as a "data fiduciary" with duties. The rules that operationalise it have been notified with phased timelines, so the obligations are no longer theoretical. As a business owner, the practical duties are these.
- Collect only what you need, for a stated purpose. A coaching class does not need a student's blood group. A delivery app does not need the customer's date of birth.
- Get consent that is clear and can be withdrawn. A pre-ticked box is not consent.
- Keep it secure. The Act expects reasonable security safeguards, and penalties for failing to provide them can run up to ₹250 crore per instance under the Act's schedule. That figure is for serious failures, but it tells you how seriously the law takes it.
- Delete it when the purpose is over. Old customer data is a liability, not an asset.
- Report breaches. To the Data Protection Board and to the affected people. That means you need to be able to detect a breach, which brings us back to logs.
- Handle requests. People can ask what data you hold and ask for it to be corrected or erased. Your software should make that possible without a developer.
If your vendor has not heard of the Act, that is a concern. If they say it does not apply to you because you are small, they are wrong: it applies to any business processing digital personal data in India, with limited exemptions.
Secure development practices to ask about
You do not need to understand these, but you can ask whether the vendor does them and expect a straight answer.
- Are dependencies and frameworks kept updated, and is there a schedule for it?
- Is user input validated on the server, not only in the browser? (This is what stops the classic injection attacks.)
- Are secrets such as database passwords and API keys kept out of the source code?
- Is there a staging environment, so changes are tested before they reach your live data?
- Has the application ever had an external security review or penetration test? For a system holding health, financial or student data, it should.
- What happens when a vulnerability is found in something they use? Who patches it, and how fast?
Things that go wrong in practice
- The owner's own account has a weak password and no second factor, because rules are for staff.
- The WhatsApp group where staff share screenshots of customer details.
- Excel exports of the full customer list sitting in ten personal Google Drives.
- An ex-employee whose login still works a year later.
- An app that stores the API key inside the Android package where anyone can read it.
- Backups on the same server as the database, so the ransomware encrypts both.
None of these need expensive tools. They need a checklist and someone responsible for going through it every quarter.
What to put in the contract
Before signing with any vendor, write in: who owns the data and the source code; where the data is hosted; the backup schedule and restore commitment; a duty to notify you of a breach within a fixed number of hours; the process for removing users; and what happens to your data if the contract ends. A vendor who resists these clauses is telling you something. Our guide to choosing a software development company covers the wider contract questions, and if you are weighing a custom system against a product, the same security questions apply to both.
Where SailRight fits
Every system we build, from custom business software to our RightSutra suite, ships with individual logins, role-based access, audit logs, encrypted backups and Indian hosting as the default, not as extras. If you want us to review the security of a system you already run, or to build one properly from the start, get in touch.
- Security
- DPDP Act
- Backups
- Access control
- Vendor checklist
- Data protection
