Security policy

This is what we actually do, written plainly enough that you can hold us to it. It is the detail behind the security safeguards condition in POPIA and behind the security clause in our terms.

Access

• Multi-factor authentication on every account we hold, without exception, including our own.
• Least privilege. Access is granted for a named person and a named reason, and it is removed when either one ends.
• Credentials live in a password manager. They are never sent in email or in a chat message, and a credential that has been sent that way by somebody else is treated as compromised and rotated.
• Client administrative access is issued per person rather than as one shared login, so an account can be withdrawn when somebody leaves without disrupting anybody else.
• Access to production is reviewed when a project ends and at least twice a year for anything we manage on an ongoing basis.

The infrastructure

• TLS on everything, with certificates renewed automatically and HTTP redirected rather than served.
• Encryption at rest for databases, object storage and backups, provided by the platforms named below.
• Patching on a schedule for what we manage, and inside 24 hours for a vulnerability that is being actively exploited.
• Nightly backups kept for thirty days, held separately from the systems they back up, and restored on a test schedule.
• Logging and error monitoring, so that we hear about a failure before a customer reports it.

How we build

• Secrets are never committed to a repository. They live in the platform's environment configuration, and a leaked secret is rotated before anything else is done.
• Dependencies are watched for known vulnerabilities and updated deliberately rather than all at once.
• Changes reach production through version control, so every change is attributable and every deployment can be reversed.
• Test and staging environments never hold real personal information where sample data will do.

Who else touches your data

We use operators, and POPIA makes us responsible for them. Each one is bound by written data processing terms, is used only for the purpose named here, and is chosen partly on where it stores data.

• Vercel, Amazon Web Services and Microsoft Azure: application hosting and infrastructure.
• Supabase: databases, authentication and file storage for applications we build.
• Cloudflare: DNS, content delivery and traffic filtering.
• Microsoft 365 and Google Workspace: mail, files and collaboration, for us and for the clients we manage.
• Resend: transactional and newsletter email.
• Sentry: error monitoring for applications we support.
• Stripe: payments, for products that take them. Card data goes to Stripe and never to us.

When there is an incident

We contain it first, then establish what actually happened, then tell everybody who needs to know. Where personal information has or may have been accessed by somebody who should not have it, we notify the Information Regulator and every affected person as soon as reasonably possible after establishing the facts, as section 22 of POPIA requires. Affected clients hear from us directly, in writing, with what happened, what it means for them and what to do. Anything material gets a written post-mortem.

Reporting a vulnerability

If you have found a weakness in this site, in something we built, or in something we host, write to info@bonangtech.com with the words security report in the subject line. Tell us what you found and how to reproduce it. We acknowledge within one business day, keep you updated while we fix it, and credit you when it is done if you want to be named.

We will not pursue anybody who reports a genuine finding in good faith, provided you stayed within the scope: no accessing or altering data that is not yours, no denial of service, no social engineering of our people or our clients, no automated scanning heavy enough to affect a live service, and no public disclosure before we have had a reasonable period to fix it. We do not run a paid bounty programme. We do answer every report from a person.