Secure Business Software: What "Bank-Level Security" Should Mean

Almost every software vendor in Pakistan will tell you their system has bank-level security. Very few will say what the phrase means, because in a great many cases it means an HTTPS certificate and a login screen. Secure business software is not a claim — it is a short list of mechanisms, and every one of them can be demonstrated in a live session by a vendor who has actually implemented it. This piece names the five that matter, says plainly what each one prevents, and gives you the questions that separate a vendor with an architecture from a vendor with a slogan.

What the phrase is usually doing

“Bank-level security” borrows trust you already extend to your bank and attaches it to a system you have not inspected. It is not a standard. No certification body issues it, nobody audits it, and there is no penalty for using it loosely. A vendor can say it about a system in which every logged-in user’s session can read every table in the database, and no rule has been broken — because the phrase has no content of its own.

That does not make it worthless. It makes it the opening of a conversation rather than the end of one. The right reply is not “prove you are as secure as a bank” — the bank comparison is a distraction — but “name the mechanisms, and show me each one working”. A vendor who has built security into the architecture will enjoy that conversation. A vendor who has not will steer you back towards features.

We make the same claim on our own security page, so it is only fair that we spell out what we mean by it.

The five mechanisms behind secure business software

1. Row-level security

This is the one that separates real systems from painted ones. Row-level security means the database itself decides which records exist for a given user. A teacher’s query cannot return another teacher’s class. A branch manager’s query cannot return another branch’s ledger. The restriction lives with the data, not with the screen showing the data.

The alternative — and it is depressingly common — is a system where the query returns everything and the interface hides what the user should not see. That works right up until someone changes a filter in a report, guesses a record number in the address bar, or exports to Excel. The distinction matters enough that we gave it its own article.

2. Column-level security

Rows are not the whole problem. Two people can legitimately need the same record and have no business seeing the same fields of it. An HR assistant maintaining an employee’s contact details and leave balance does not need the salary column. A production supervisor checking an order’s specification does not need its margin.

Column-level security restricts fields independently of the records that hold them, so the same employee record opens differently for different roles. Without it, every sensitive field forces a crude choice: give someone the whole record or give them nothing, which in practice means giving too many people too much.

3. Encryption in transit and at rest

Data is encrypted travelling between the user’s browser and the system, and encrypted where it is stored. An intercepted connection on a shared office network yields nothing readable; a copied disk or a stolen backup file yields nothing readable either.

Notice what encryption does not do. It protects data from someone outside the system. It has nothing to say about a logged-in user reading records that are not theirs — and in business software that is the more likely incident by a wide margin. Vendors who talk about encryption and stop are answering the easier question.

4. Role-based access control

Every role gets exactly its own slice of the system and nothing more. This is the design that gives our school management system nine portals rather than one screen with permissions bolted on: a parent sees their own child, a teacher sees their own classes, finance sees money, only the super admin sees the whole. The same architecture governs a multi-unit ERP, where a unit’s staff work in their unit and the group’s directors see across all of them.

Roles are easy to get wrong — they tend to get drawn from the org chart instead of from the work, which produces roles nobody fits. That failure and how to avoid it is the subject of our guide to role design.

5. Automated, scheduled backups

Backups belong in a security list because most data loss in Pakistani businesses is not theft. It is a bad import, a mistaken deletion, a failed disk, a power event at exactly the wrong moment. Automated backups on a schedule turn each of those from a catastrophe into a restore.

The claim to interrogate here is not whether backups exist but whether anyone has ever restored from one. An untested backup is a hope with a filename, which is why backups and disaster recovery deserve their own conversation with any vendor.

The sixth mechanism nobody advertises: the audit trail

The five above decide who can reach what. One more decides whether you can ever find out what actually happened: a log of who did what, and when, with the value before the change as well as after it.

The difference between a decorative log and a real one is worth thirty seconds of any demo. A real one records the before value — an entry that says a price was edited settles nothing, while the old figure beside the new one settles it completely. A real one cannot be quietly amended by the privileged users it watches, because a log the administrator can edit documents only the honest. And a real one is readable by the owner from the interface, because a trail that needs a developer to interpret will be consulted approximately never. Most disputes inside a business are not about whether something was permitted; they are about what was done — and the audit trail is the only witness in the room without an interest in the answer.

The questions to put to a vendor who uses the phrase

Take these into the meeting. They are answerable in minutes by anyone who built what they claim.

1. Is access enforced in the database or in the interface? Ask them to say which, in those words, and to show you where.
2. Log in as my most restricted user, then try to reach data that user should not have — by editing a report filter, by changing a record identifier in the address bar, and by exporting a list. All three should fail identically.
3. Can two roles open the same record and see different fields? Show me.
4. Is data encrypted in transit and at rest? Both halves, not one.
5. How often do backups run, how long are they kept, where do the copies live, and when did you last restore one? The fourth part of that question is the real one.
6. Who can see the audit trail, and can anyone edit it? A log that privileged users can quietly amend is decoration.
7. When my accountant resigns on Tuesday, what happens to their access on Wednesday, and who does it?

If a vendor answers all seven without reaching for a brochure, the phrase they used at the start of the meeting was probably earned.

What security architecture cannot do for you

Being honest about the limits is part of the case. No mechanism on this list protects a business where three people share one login, where the departed manager’s account still works six months later, or where the owner’s password is the company name and the year it was founded. A well-designed system narrows the blast radius of those habits — a shared login still cannot read another branch’s ledger — but it cannot abolish them.

Nor does architecture substitute for judgement about where data lives. The trade-offs between a cloud deployment and a server in your own building are real ones — connectivity, power, backup discipline, and who is responsible at eleven at night — and they deserve to be weighed rather than assumed. We build both, which is precisely why we can afford to be even-handed about it.

Security in business software is unglamorous and entirely checkable. If you are evaluating a system now — ours or anyone’s — take the seven questions above into your next demo, and tell us what the answers were if you would like a second opinion on them.