Security

Niimbu holds the record of what a business sold, what it is owed, what it paid and who it paid it to. That record is worth protecting for its own sake, and it is also the thing an attacker would most want to change rather than merely read.

So the design assumption is that any single control will eventually fail, and the job is to make sure no single failure is enough. Credentials alone should not be enough to move money. Access to one system should not grant access to the next. An action taken should leave a record that the person who took it cannot quietly edit.

This page describes the controls we operate. It does not claim a certification we have not earned. Where we complete a formal audit we will name it here, with its scope and its date, and you will be able to ask for the report.

Traffic between your browser and Niimbu is encrypted with TLS, and the site is served over HTTPS only. Requests arriving over plain HTTP are redirected rather than answered.

Data at rest is encrypted on the storage that holds it, including databases, backups and file uploads. Passwords are never stored in a form that can be reversed: they are hashed with a slow, salted algorithm designed for the purpose, which means that even we cannot read yours.

Secrets such as API keys and partner credentials are held in a managed secret store, not in source code and not in configuration files that travel with the application.

Most losses at a small business are not sophisticated attacks. They are a shared login, a staff member who kept access after leaving, or one person holding a permission nobody meant to give them. Niimbu is built to make the correct arrangement the easy one.

• Every member of staff gets their own login, so the audit trail names a person rather than a device
• Roles limit what each person can see and do, down to individual areas of the product
• Approval rules mean a payout above a threshold needs a second person, set in advance rather than argued about in the moment
• Spending limits on expense cards are set before the card is used, not reconciled afterwards
• Two factor authentication is available on every account and we strongly recommend it for anyone who can move money
• Sessions expire, and you can end a session on a device you no longer have

Actions that change money, permissions or records are written to a log that shows who did what and when.

Our own staff get the least access their job requires and no more. Access to production systems is limited to a small group, requires multi factor authentication, and is logged.

A support agent helping you with a question does not need to see everything in your account, and does not. Where a support action requires elevated access, it is time limited and recorded.

Access is reviewed periodically and removed when somebody changes role or leaves. Staff are subject to background checks appropriate to their role and to confidentiality obligations in their contracts.

Card payments are processed by our licensed payment partners. Niimbu does not store full card numbers or card verification values on its own systems. Where a card is shown in the product it is shown as the last few digits, which is enough to recognise it and not enough to use it.

Funds are held with licensed financial institutions rather than by Niimbu. That separation is a regulatory requirement and it is also a security property: a compromise of the software is not a compromise of the account that holds the money.

Payout instructions are checked against the approval rules you configured before they are sent, and high value or unusual instructions are subject to additional review.

Niimbu runs on established cloud infrastructure with providers that operate physically secured data centres. We do not run servers in an office.

• Environments are separated, and production data is not copied into development or testing
• Databases are backed up on a schedule, backups are encrypted, and restores are tested rather than assumed
• Systems are monitored for availability and for unusual behaviour, with alerts that reach a person
• Patches for the platforms and libraries we depend on are applied on a regular cycle, and urgently when a serious vulnerability is published

Changes to the product go through code review before they are merged, and through automated checks that run on every change. Dependencies are scanned for known vulnerabilities, and we treat a vulnerable dependency as a defect rather than as background noise.

Features that touch money, permissions or personal data get more scrutiny than features that do not, because the cost of getting them wrong is not symmetrical.

Transactions are monitored for patterns associated with fraud and with money laundering. Some of that monitoring is required of us and of our licensed partners, and some of it exists because a business that has been defrauded rarely gets the money back.

Where something looks wrong we may hold a transaction and ask you about it. We would rather ask an unnecessary question than let one payment through that should have been stopped.

We have an incident process, and it starts with containing the problem rather than explaining it. Once the immediate risk is handled we investigate root cause, fix it, and record what we changed so the same thing does not recur.

Where an incident affects your data, we will tell you. Where it is a personal data breach likely to affect people's rights, we notify the Nigeria Data Protection Commission and the people affected within the period the law requires. We would rather deliver an uncomfortable notification early than a comfortable one late.

The strongest controls we can build still sit behind your credentials. Five things do most of the work:

• Turn on two factor authentication, especially for anyone who can approve a payout
• Give every member of staff their own login and their own role, and never share one
• Remove access on the day somebody leaves
• Confirm account details out of band before you approve a payment to a new recipient, particularly if the details arrived by email
• Treat any message asking you to move money urgently as suspicious, including one that appears to come from us

We will never ask you for your password, for a one time code, or for your card details. If somebody claiming to be from Niimbu asks for any of them, they are not from Niimbu. End the conversation and tell us.

If you have found a security issue in Niimbu, we want to hear about it. Write to [email protected] with "Security" in the subject line, describe what you found and how to reproduce it, and give us a way to reach you.

We will acknowledge your report, investigate, keep you updated on what we find, and credit you if you would like us to. We will not pursue legal action against anyone who reports an issue in good faith, gives us reasonable time to fix it before disclosing it publicly, and does not access, alter or delete data belonging to anyone else while researching.

Please do not run automated scans or load tests against the live service. Tell us what you intend to test and we will find a way to let you do it safely.

If your organisation needs to assess us before you can sign, ask. We answer security questionnaires, we will confirm specific controls in writing, and we can talk to your security team directly.

Write to [email protected] and say what you need and by when.