Security

Security that fits a school

Books-pro runs on the school's own machine, so most of the protection is structural: the data never leaves, access is per person, and every financial posting records who made it. Here is exactly what is built in — and what the school must still do.

Ask a security question See the role matrix

On-site by defaultNo central copy of school records on our side.
Per-person accessIndividual accounts, not one shared bursar login.
Traceable postingsEvery voucher records the user and the time.
RecoverableDaily backups plus JSON export you control.

Read this page as a factual description, not a certification. It lists the controls that exist in the product as shipped. It is not an audit report, and where something is not provided we say so.

1. The deployment model is the first control

Books-pro is installed on a computer the school controls — usually one office machine on the school network. The database is a single file on that machine. Staff use it through the desktop window or a browser on the local network. There is no vendor cloud account holding pupil records, because there is no vendor cloud.

That removes a whole class of risk: no third-party breach can expose records we never held. It also shifts responsibility. Physical access to that computer, the network it sits on, and the copies the school makes are all matters for the school.

2. Accounts, passwords and rights

Individual accounts. Each staff member is a user. The system records the user against postings rather than treating everyone as “the bursar”.
Screen-level rights. A user sees only the screens their role allows. Accounts, marks entry, receipts and settings can be granted separately.
Report-only roles. A director or board member can be given read and print access to reports without the ability to post, edit masters or change settings.
Password storage. Passwords are stored as salted scrypt hashes, not as readable text, so a copy of the user table does not reveal passwords.
Portal tokens. Parent and student portal access uses time-limited tokens; report cards cached in the Android app expire rather than staying valid indefinitely.

What is not built in: multi-factor authentication. If the school needs a second factor, put the server behind a network that already requires it and restrict who can reach the machine.

3. Financial controls

One posting path. Receipts, payments, journals and payroll post to the ledger once, through a voucher, rather than being typed twice.
Day book review. The day book lists every voucher for a date with debit and credit totals, so an unexplained entry is visible the same day.
Duplicate warnings. The software warns before a second identical posting, which is the common way money is over-receipted during a queue.
Version history. Records keep a history that can be restored, so an erroneous edit is reversible without restoring the whole database.
Matched payments, not guesses. Digital payments with a missing or duplicated learner code are held for review instead of being posted to the wrong account.

4. Provider credentials and card data

SchoolPay, Airtel Money and ObPay credentials are configured once by an administrator and stored encrypted on the school server. They are used server-side; they are not printed in the interface and are not placed in browser requests that staff can inspect.

Books-pro does not accept payment card numbers. Card details belong with the payment provider's own checkout. If a parent pays by card, the card data is handled by that provider, not by the school's system.

5. Network and remote access

On a local network the app is served over plain HTTP. That is fine on a private school LAN, and wrong on a network you do not trust — anyone who can listen on an open network could read traffic. Keep the server on a staff-only network segment and do not expose the LAN port directly to the internet.

Remote access is optional and must be enabled deliberately. When it is, the traffic is carried over HTTPS through a tunnel controlled by the school, and it reaches the same school-hosted system rather than a copy in a data centre. Turn it off when it is not needed.

6. Backups and recovery

Daily automatic backup with 30 days retained by default. The schedule is visible in Settings.
JSON export for a readable copy of the data you can keep elsewhere or hand to an auditor.
Restore from backup in the app, so recovery does not require our involvement.

Backups on the same machine do not survive theft, fire or a failed disk. The school should copy a backup off the server regularly — the backup check walks through it.

7. Licensing

Licence files are signed and bound to the named server host. The software verifies the signature offline, so licence checks do not send school data anywhere and do not require an internet connection. When a licence expires, licensed features lock, but the data is not deleted and export remains available.

8. The Android companion

The app is distributed as an installable package rather than through a public store listing. It contains no advertising and no analytics SDK. Report cards viewed offline are cached on the device with a time limit, and portal access uses issued tokens rather than a stored password. A lost phone should be handled by revoking that family's portal access at the school.

9. Logs

The host writes a log to %APPDATA%\Books-pro\logs\books-pro.log. It is there for diagnosing faults and should not contain passwords or provider keys. When sending a log for support, scan it first, or send only the relevant excerpt.

10. What we do not claim

To keep this page useful rather than promotional, the gaps are listed plainly:

No ISO 27001, SOC 2 or similar certification is held or implied.
No third-party penetration test report is published on this site.
The SQLite database is not encrypted at rest by default. Anyone with file-level access to the server's disk can read it; use Windows disk encryption and physical security.
LAN traffic is plain HTTP unless the school enables HTTPS or remote access.
There is no multi-factor login in the product itself.

11. What the school should do

Security responsibilities for the school
Area	Baseline action
Accounts	One account per person; disable leavers the same week; no shared logins.
Rights	Give the minimum screen rights for the role; keep a report-only login for the director.
Server	Lock the machine, use a screen lock, keep it on a staff network, run Windows updates.
Disk	Enable BitLocker or equivalent; keep the recovery key somewhere other than the server.
Backups	Confirm the daily job runs; copy a backup off the machine monthly; test a restore each term.
Providers	Store credentials only in the app; rotate them if a staff member with access leaves.
Remote access	Leave it off by default; turn it on only for a support session or a real need.
Phones	Revoke portal access for a family when a device is lost; keep tokens short.

12. Reporting a problem

If you believe you have found a security weakness, contact rbisiki@gmail.com with enough detail to reproduce it. Please do not test against a live school, do not access real learner or financial records, and do not publish the issue before we have had a reasonable chance to respond. We will confirm receipt and tell you what we have done.

13. Contact

Security and privacy questions: rbisiki@gmail.com. Telephone: +256 765 248 047 or +256 755 761 108. Location: Kampala, Uganda.