Security in business software is usually discussed as a list of technologies — encryption, firewalls, certifications — which is both true and mostly unhelpful to someone deciding whether to trust a system with their operation.
The questions that actually determine your exposure are simpler and rarely asked directly: who can see what, where does the data physically live, what happens if the vendor disappears, and can you leave with everything.
This article is about those questions, and about what we consider non-negotiable in what we build.
Access control is the control that matters most
For most businesses, the realistic risk is not a sophisticated external attack. It is that everyone in the system can see everything, and something eventually goes wrong internally — a departing employee exports a customer list, a junior sees payroll, a contractor retains access for a year after the engagement ended.
Role-based access is the answer, and it is frequently configured once at go-live and never revisited.
Three practices that matter more than any technology choice:
Roles reflect actual jobs. Not three roles because the system offered three. A counter operator, an outlet manager, an accountant and an owner need genuinely different views.
Access is removed when people leave. This is the most common real-world failure. There should be a defined step in offboarding, and someone accountable for it.
Someone can answer who has access to what. If nobody can produce that list, the access model is theoretical.
Audit trails protect you, not just the data
An audit trail — who viewed or changed what, and when — is usually framed as a compliance requirement. Its practical value is different: it is how a dispute gets resolved.
When a figure is wrong, an audit trail turns an argument into a fact. When a customer alleges something, it establishes what actually happened. When an internal issue arises, it distinguishes error from intent — which matters enormously, because the alternative is suspicion distributed across people who did nothing wrong.
Systems without audit trails do not just fail audits. They make every disagreement unresolvable.
The questions to ask any vendor
Where does our data physically live? Which country, which provider. This has legal implications depending on your sector and jurisdiction, and it is a straightforward question with a straightforward answer.
Who at your company can access it? Every vendor's staff can technically reach customer data. The question is whether access is controlled, logged, and limited to people who need it for support.
What happens if you go out of business? For a small vendor this is a real risk. What are the arrangements — escrow, export, a defined process?
How do we get everything out? Not a report. Everything, in standard formats, on demand.
What are your backups, and have you tested restoring them? The second half is the important half. Untested backups fail at the moment they are needed, and many organisations discover this then.
Is anything sent to third parties? Analytics, AI providers, payment processors, communication services. Each is a place your data goes, and you should know the list.
Data ownership is the one that bites later
Of all of these, exportability is the one businesses regret ignoring.
A system whose data cannot leave in standard formats has a switching cost that rises every year. That cost is not abstract — it becomes a negotiating position against you at every renewal, and it eventually removes the option of changing your mind.
Our position: your data stays exportable in standard formats, always. A system you cannot leave is a system you are hostage to, and that is not a good basis for a commercial relationship. A vendor confident in their work does not need lock-in to retain clients.
Ask about export before signing, not at migration. Hesitation is itself the answer, and moving years of records covers what a good export actually needs to contain.
What we build to
Concretely, on the systems we deliver and on our own properties:
Encrypted in transit. HTTPS everywhere, with HSTS preloaded across subdomains.
Strict content security. A per-request nonce content-security-policy and hardened security headers on every response.
Least-privilege access. Role-based control, with data isolated per client — and in SYNTAX, per institution, so one college's data is unreachable from another's.
Responsible disclosure. A published security.txt and a disclosure policy, because researchers finding issues is a good outcome and needs a route.
Fail closed. Where authentication is unconfigured or unavailable, access is denied rather than defaulted open.
What we deliberately do not claim: we hold no ISO, SOC 2, CERT-In or HIPAA certification, and we do not describe ourselves as compliant with frameworks we have not been assessed against. A compliance claim is a legal assertion, not a marketing line, and vendors who blur that distinction are worth examining closely.
The parts that are your responsibility
Vendors cannot solve these, and they cause more incidents than technical vulnerabilities:
Shared logins. One account used by several people destroys the audit trail entirely — nothing can be attributed.
Access after departure. Discussed above, and worth repeating because it is the most common failure.
Devices. A system secured properly, accessed from a shared unlocked machine at a counter, is as exposed as the machine.
Data taken out. Exports to spreadsheets emailed around are outside every control the system has. This is the most common way business data actually escapes.
Frequently asked questions
Do we need certifications from our vendor?
Depends on your obligations. If your sector or your customers require it, then yes and verify it rather than accepting a claim. If not, certification is one signal among several and its absence is not disqualifying.
Is cloud less secure than on-premise?
Generally the opposite for small businesses, because reputable providers invest more in security than a small business can. The relevant questions are access control and data location, not the hosting model.
What if our vendor is acquired?
Ask what happens to data and terms on change of control. The practical protection is exportability — if you can leave cleanly, an acquisition is an inconvenience rather than a trap.
How often should we review access?
At least when people join or leave, and periodically otherwise. Most organisations that review find accounts belonging to people who left.
Should we worry about AI features and our data?
Ask specifically whether business data is sent to third-party model providers, whether it is retained, and whether it is used for training. Get it in writing. What "AI-powered" should mean covers the questions in more detail.
Where to start
Two things this week, neither requiring a vendor.
List everyone with access to your business systems and check whether all of them still work for you. Then ask your main vendor, in writing, how you would export everything if you decided to leave.
The first frequently surfaces accounts that should have been closed. The second tells you what kind of relationship you are actually in.
Our own disclosure policy is at /security. If you want a read on your current exposure, get in touch.