Most pages like this one are a list of adjectives. This one is a list of controls that run, and it ends with the things we cannot claim. We would rather you trusted the second list than the first.
1. Money cannot move from an unattended screen
The likeliest way a distribution business loses money is not a hacker. It is a session left open on a laptop somebody walked away from.
- 229 money doors ask again. Every door money actually leaves through — paying a supplier, posting a journal entry, moving cash between bank accounts, refunding a customer, releasing an expense to the ledger, paying a rebate, approving a sales return or a cashback — as well as approving or voiding a payment, signing off a stock adjustment, finalizing a stock count, receiving a short stock transfer, writing off expired stock, closing or reopening an accounting period, resolving a customer dispute, approving payroll, raising a credit limit, changing someone’s role, granting a permission, and invoking the emergency override. Each re-asks for the operator’s authenticator code if their last proof of identity is more than ten minutes old. Being logged in is not enough.
- A code cannot be used twice. A privileged account cannot reach the cockpit or a money door without enrolling an authenticator, and a code that has been used once is consumed — it cannot be replayed.
- Nobody approves their own work. Payments run a tiered approval ladder. Stock adjustments need two signatures. The person who enters a number is not the person who releases it — with one named exception: the Managing Director can invoke a time-limited Emergency Override on a payment request, and every such override is logged and visible to the Financial Controller.
2. The books cannot be edited behind our backs
A ledger you can quietly change is not a record. It is a draft. Every posted journal entry carries a fingerprint, chained to the entry before it — alter an amount, a date or an account after posting and the fingerprint no longer matches, and every entry after it breaks too.
That fingerprint is signed with a secret kept in the server’s environment, which the application’s database account cannot read. So somebody who can edit a row still cannot forge a fingerprint that matches it.
The journals, the stock movements and the payment records are append-only in the database itself — the application cannot update or delete them at all; the database refuses. The audit log, the record of who did what, is protected the same way with one deliberate gap: the database refuses any change to an entry except placing it on legal hold, and refuses to delete an entry for 35 months, or for as long as it is on hold.
And a scheduled job walks the whole chain every day, re-computing every fingerprint. We do not take that job on trust. A proof script edits a real record in a real database, behind the application’s back, and checks that the alarm fires. A detector nobody has watched catch anything is decoration.
3. Your data
- Encrypted at rest, not merely access-controlled. National identity numbers (NIN, BVN), staff and supplier bank account numbers, two-factor secrets and Speak-Up reports are encrypted in the database, with a key held in the server’s environment and not in the database — a stolen copy of the data is not enough to read them.
- Everything else is access-controlled, and we say which is which. Payslips, HR records, next-of-kin and guarantor details are protected by role-based permissions and an append-only audit log rather than by encryption. We would rather tell you exactly which of your data is encrypted than imply that all of it is.
- Stripped from logs and from anything sent to an AI. Phone numbers, emails, addresses, account numbers and national identifiers are redacted before a line is written to a log or a prompt leaves the building. A build check enforces it, so it cannot quietly lapse.
- You can ask for your data, and you can ask us to delete it. Access, portability and erasure requests run through a defined path, not an inbox. Your rights under the Nigeria Data Protection Act 2023 are set out in our Privacy Policy.
4. If the worst happens
- The backup is restored on a schedule — not just taken on one. Every week a real backup is decrypted and rebuilt into a scratch database, and every table is counted against what was there when the snapshot was taken. An untested backup is a hope, not a control.
- The application’s database account cannot destroy the database. It cannot drop a table, empty one, or change the schema. Those are separate, deliberate acts.
- Browsers are told exactly what our pages may run. A Content Security Policy is enforced — not merely reported — on every signed-in page.
5. What we do not claim
This section is here because the rest of the page is only worth reading if it exists.
- We have not had an independent penetration test. One is planned. It has not happened. Until it does, nothing on this page has been checked by anyone outside COJUDE.
- We are not SOC 2 certified, and we are not pursuing it. COJUDE OS is internal software for one company. A certification aimed at software vendors would be a badge, not a control.
- We hold no card details. We never see a card number. Our customers pay by bank transfer, and our field sales staff never collect cash — counter takings at the depot are cash, counted against expected daily takings at close.
- Our tamper-evidence detects. It does not prevent. Somebody with complete control of the database server could still alter data. What they cannot do is alter it without leaving a mark we will find — the fingerprints are signed with a key the database does not hold. We think that distinction matters more than a stronger-sounding word would.