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.
- 374 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. Someone whose role is not required to use two-factor sign-in, and who has not enrolled it, is asked for their password instead. 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.
- 70 approval doors refuse the person who made the record. Payments run a tiered approval ladder. Stock adjustments need two signatures. On the doors in our separation-of-duties register — payment approvals, supplier payment proposals, three-way-match releases, manual journals, credit limits, commission runs, rewards, pay appeals, leave, sales-return applications, credit refunds, redemptions and more — the system refuses the person who made, requested or benefits from the record. Not every door carries this rule yet, and we do not say it does. On most of them the Managing Director can complete the step when nobody else is eligible, and every such step is recorded; the Managing Director can also invoke a time-limited Emergency Override on a payment request, which 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.
Our money and stock ledgers are frozen in the database itself, from one list that the build checks against the database. Journal lines, stock movements, the customer wallet, VAT entries, bank statement lines and the other ledgers nothing has a reason to edit can be neither changed nor deleted. The rest — payments and their allocations, supplier payments, cashback, withholding tax, returns, counts and stock adjustments — can change only in the few columns their own life needs, such as a payment’s status, its bank matching, its notes and a one-time link to its void; never an amount, a customer or an identity. A commission line’s amounts freeze once its run is no longer open, and a posted journal entry’s header can change only to record its reversal. The database refuses to delete a row from any of them, whichever login asks; a mistake is corrected with a new entry. The audit log, the record of who did what, is protected 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 (National Identification Number, NIN; Bank Verification Number, 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 most of what is sent to an AI. Phone numbers, emails, addresses, account numbers and national identifiers are removed from text before a line is written to a log or a text prompt is sent to an AI provider. Some inputs go as they are because the task needs them: document images, voice recordings, dictated orders, bank-statement narrations and the Managing Director’s dictation, sent to the providers named in our Privacy Policy. A build check fails when a file turns the scrub off without a written reason, and a test compares the list of those files with the code.
- You can ask for your data, and you can ask us to delete it. Access, correction, portability and erasure requests are made by email to the address in our Privacy Policy and are recorded in a data-request register that tracks the 30-day deadline and warns our Data Protection Officer and the Managing Director when one is overdue. There is no online request form yet. Your rights under the Nigeria Data Protection Act 2023 are set out in the same 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. Last successful restore: 19 October 2026. An untested backup is a hope, not a control.
- The application’s database account cannot drop a table, truncate one or change the schema. Those are separate, deliberate acts under a separate login. It can delete rows only from a short, named list of working tables — drafts being rebuilt, caches, sessions and the like — never from a ledger, and every table added from now on starts out undeletable.
- 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 (SOC 2 is an independent audit standard for service providers), 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.
The rules for using our website and services are in our Terms of Service.