Why Desishub · Pillar 01 of 03
Security is our first decision, not our last
When thousands of people trust your system with their money, security is not a feature you add at the end
We build systems that hold loan books, patient records, school fees and till takings. This page sets out exactly how we protect them — at the network, in the application, in the database, and in how we work. It also says plainly what we do not have.
Facts on this page last verified 6 November 2026
- Written scope before you pay
- A working demo every Friday
- You own the code
What you get as a client
Security is only credible if it arrives as something you can check. On every enterprise project you get:
- A written security checklist for your system — the authentication model, the isolation boundary, what is encrypted, who has access — agreed before we start building.
- Audit logs of the actions that matter: who changed a loan, who voided a sale, who exported data, and when.
- A backup schedule in writing, with the date of the last tested restore.
- A penetration test before launch, and the report, including the findings we had to fix.
- Ownership of your source code, your database and your deployment account. If you ever want to leave, you can, and nothing is held hostage.
- A named engineer accountable for the security of your system, reachable directly.
Three systems where this was the hard part
FundPier runs multiple savings and credit co-operatives on a single deployment. Each one sees only its own members, loans and repayments, because the isolation is enforced where queries are built rather than where screens are drawn.
Intellixio was built to the same standard for a different industry and has run with no crosstalk between accounts since launch.
Shoppleet keeps selling when the internet drops, which means it holds real sales data on a machine sitting in a shop. That local store is encrypted, the sync queue is signed, and a stolen till cannot be used to rewrite history on the server.
The tooling, so you can check it
Sentinel and Scout are not internal names for a process. They are published, and you or your own security people can read them before trusting them: Sentinel, our web application firewall and request-filtering layer, and Scout, our application security scanner. The framework our backends are built on is open too — Grit — which means the authentication, tenant-scoping and migration machinery described above is inspectable rather than asserted.
Reporting a vulnerability
If you have found a security issue in anything we run, we want to hear from you before anyone else does. Write to security@desishub.com. Our policy is published at /.well-known/security.txt. We acknowledge reports within 24 hours, keep you updated while we fix the issue, and credit you if you would like us to.
What we do not claim
We hold no ISO 27001 or SOC 2 certification and we will not borrow the language of either. We are not a dedicated security firm; we are a software team that treats security as part of building rather than as an audit bolted on at the end. If your procurement process requires a certified vendor, tell us on the first call and we will say honestly whether you should shortlist us.
If you want this in a form you can hand to a board or a regulator, ask and we will send a one-page summary of the practices above, written for the specific system you are considering.
Related: security audits and penetration testing as a standalone service, and the performance and design pillars.
Why teams pick us
How we secure the stack
- 01
Tenant isolation in the database
Every tenant-scoped query is filtered in the data layer rather than the interface, so a missing filter in a new feature fails closed instead of leaking. This is the model behind FundPier's multi-SACCO deployment.
- 02
Authentication designed for the threat
Server-side sessions, OTP or multi-factor wherever money moves, role-based access down to the individual action, and per-resource policies rather than one global admin flag.
- 03
Encryption in transit and at rest
TLS everywhere, enforced and redirected. Database volumes and backups encrypted at rest. Secrets held in the deployment environment, never committed to the repository.
- 04
A firewall and a scanner we wrote
Sentinel, our web application firewall, and Scout, our application security scanner, are open source and run against our own client systems. We read our own findings before anyone else does.
- 05
Backups with tested restores
Scheduled backups held off the primary host, with restores actually performed and the date recorded. An untested backup is a guess, not a plan.
- 06
Senior review on every change
No code reaches a client's production system without a second engineer reading it. Dependencies are scanned, and a penetration test runs before an enterprise launch.
FAQ
Frequently asked questions.
01Where is our data hosted, and can we keep it in Uganda?
Most client systems run on our own VPS infrastructure or on AWS, fronted by Cloudflare. If your regulator or board requires data to stay in a particular jurisdiction, or on hardware you own, we can deploy to a server you control, including on-premise. Decide this before we build, because it changes the architecture.
02How do you stop one tenant seeing another tenant data?
Isolation is enforced at the database level, not in the interface. Every tenant-scoped table carries a tenant key, every query is filtered by the authenticated session, and the filter lives in the data layer where application code cannot bypass it by mistake. FundPier runs several savings and credit co-operatives on one deployment this way, and Intellixio was built to the same model.
03Who on your team can see our production data?
Only the engineers assigned to your project, and only through audited access. We do not copy production data into development environments. When we need realistic data for testing we generate it, or anonymise an export.
04Do you run penetration tests?
Yes, before an enterprise launch and on request afterwards. We publish Sentinel, a web application firewall, and Scout, an application security scanner, as open source, so the engineers testing your system are the ones who wrote the tooling. You get the findings ranked by what an attacker could actually reach, with the fix for each one.
05What happens if there is a breach?
We tell you in writing, with what we know and what we do not yet know. Then we contain it, patch, rotate credentials, and write up the timeline and the change that prevents a repeat. You can reach us about a security issue at security@desishub.com, which is also published at /.well-known/security.txt.
06Are you ISO 27001 or SOC 2 certified?
No, and we will not imply otherwise. Neither certification is held by Desishub today. What we can give you is the practice-by-practice detail on this page, a security checklist specific to your project, and a named engineer accountable for it. If your procurement process requires a certified vendor, say so early and we will tell you honestly whether to shortlist us.
07How are backups handled, and have you tested a restore?
Databases are backed up on a schedule set per project, nightly as standard and more often for payment systems, with copies held off the primary host. A backup nobody has restored is not a backup, so restores are performed and the test date recorded.
Ready to grow your business in Uganda?
Desishub Technologies is the partner you need for world-class web design and custom software development.