Legal

Data Protection, Compliance & Security Policy

Last updated: 16 October 2026

This policy describes how Nimbl Mail protects your information, and the information of the people you send to, when you use our platform. It covers the law we work within, how our infrastructure and application are secured, who inside our business can see client data, and what we do if something goes wrong.

Section 1: Introduction and overview

Nimbl Mail is a bulk email platform operated by Nimbl, based in South Africa. We take the stewardship of your data seriously: it is the foundation of the service we provide, and protecting it is a responsibility we build into the product rather than bolt on afterwards. This policy explains, in plain terms, how we do that. For our full privacy notice, see our Privacy Policy.

1.1 Our two roles under POPIA

Under the Protection of Personal Information Act (POPIA), we act in two distinct roles depending on the data:

  • Responsible party for the personal information of our account holders: the people and businesses who sign up to use Nimbl Mail. This includes names, email addresses, company details, and billing information. We decide how that data is used.
  • Operator(processor) for the subscriber and recipient data our clients upload and send to. We process that data strictly on our clients' instructions and for the sole purpose of providing the service. If you received an email sent through Nimbl Mail and want your data changed or removed, please contact the sender, who is the responsible party for their own lists.

1.2 Compliance

We operate in line with the South African data-protection framework, including:

  • The Protection of Personal Information Act, 4 of 2013 (POPIA);
  • The Electronic Communications and Transactions Act, 25 of 2002 (ECTA);
  • The Consumer Protection Act, 68 of 2008 (CPA).

1.3 Privacy principles

When we collect, store, use, and delete personal information, and when we respond to requests about it, we hold to the following principles:

  • Choice and consent: we require our clients to only send to people who have agreed to hear from them, and we do not use recipient data for our own marketing.
  • Transparency: we tell you what we do with your data and keep this policy up to date.
  • Accountability and security: we take reasonable technical and organisational measures to keep data safe from loss, damage, or unauthorised access.
  • Access: we give you access to the personal information we hold about you on request, unless the law prevents it.

1.4 Information and access requests

If you are an account holder: you can view, correct, update, or delete most of your information directly in the platform at any time. For anything you cannot change yourself, email our Information Officer at privacy@nimbl.one.

If you are a data subject(for example, you are on a list that one of our clients sends to) and you want access to, or deletion of, your data, the responsible party is the client who holds that list. Please contact them directly. Where we are asked to assist, we will handle the request in line with POPIA and our clients' instructions.

1.5 Breach notification

In the unlikely event that personal information under our control is accessed or acquired by an unauthorised person, we will notify the Information Regulator of South Africa and the affected parties as soon as reasonably possible after establishing the extent of the breach, as required by section 22 of POPIA. Our internal response process is described in Section 3.6.

1.6 Information Officer and contact

Our Information Officer is responsible for POPIA compliance and for handling data requests and complaints. You can reach them at privacy@nimbl.one.

1.7 Changes to this policy

If we make material changes, we will post the updated version here and, where appropriate, let you know. Your continued use of the service after an update means you accept the revised policy.

Section 2: Platform and infrastructure security

2.1 Architecture

Nimbl Mail runs as a set of isolated services rather than a single monolith, which limits the blast radius of any one failure:

  • A Laravel application serves the API and business logic.
  • A Next.js front end serves the dashboard and this public site.
  • PostgreSQL stores application data; Redis backs queues and caching.
  • Horizon workers process background jobs (sending, imports, reporting) off the request path.
  • A self-hosted Postal mail transfer agent handles the actual delivery of email.
  • Nginx terminates and routes traffic in front of the application.

2.2 Hosting and data location

The platform is deployed on managed container infrastructure, with Cloudflare in front of it for TLS, DNS, and protection against common network-level attacks and abusive traffic. Some of our infrastructure and service providers may process data outside South Africa. Where that happens, we take reasonable steps to ensure a comparable level of protection, as required by POPIA.

2.3 Data storage and tenant isolation

Nimbl Mail is multi-tenant: many clients share the same securely managed infrastructure, but each client's data is logically separated. Every record is scoped to the tenant that owns it, and the application enforces that a signed-in user can only ever reach their own tenant's contacts, campaigns, and reports. Administrative accounts are kept completely separate from tenant accounts.

2.4 Encryption

  • In transit: all traffic to the dashboard, the API, and this website is served over HTTPS/TLS. Connections between our services, and the submission of mail to the delivery infrastructure, use encrypted channels.
  • Sensitive credentials at rest: secrets such as API keys and DKIM signing keys are stored encrypted, not in plain text.
  • Passwords: account passwords are stored only as salted one-way hashes, so we cannot read or recover them, only reset them.

2.5 Application security

The platform is built to withstand the attacks common to web applications:

  • SQL injection: database access goes through a parameterised query layer (Eloquent/PDO); we do not build queries by string concatenation of user input.
  • Cross-site scripting (XSS): input is validated and output is escaped by default in the front end.
  • Cross-site request forgery (CSRF): state-changing requests are protected by framework CSRF safeguards.
  • Abuse and brute force: authentication and the API are rate-limited, and repeated failed logins are throttled.

2.6 Authentication and access control

  • Users sign in with a password, and administrators are protected by two-factor authentication.
  • Access within an account is managed by the account's own administrators, who decide what each user can see and do.
  • Our own administrative tooling is separate from client accounts and limited to authorised staff.
  • API access is authenticated with per-account keys, which can be revoked at any time.

2.7 Backups

We take regular backups of the application database so that data can be restored after a failure, and we store them securely.

2.8 Monitoring and logging

  • Privileged and sensitive actions are recorded in an audit log.
  • Application errors are captured by monitoring so we can detect and investigate problems quickly.
  • Verbose error details are logged privately and are never shown to end users.

2.9 Email security and deliverability

Because we run our own delivery infrastructure, sending is tightly controlled. We authenticate mail with SPF, DKIM, and DMARC; Nimbl Mail generates and manages DKIM signing keys and provisions them to the delivery layer so that your mail is cryptographically signed. We monitor bounces and complaints, apply sending limits and warm-up controls, and act on abuse to protect the deliverability and reputation of every sender on the platform.

2.10 Disaster recovery

Our services are containerised and reproducible, so the platform can be rebuilt and restored from infrastructure definitions and backups if a server or component is lost.

2.11 Vulnerability management and testing

We keep our frameworks and dependencies up to date and apply security patches promptly, and we review changes with security in mind before they ship.

Section 3: Operational and internal controls

3.1 Who can access client data

Access to client data from within our business is limited to authorised personnel who need it to operate the service or to provide support, and only to the extent required to do so. We work on the principle of least privilege: people get the minimum access necessary for their role, and nothing more.

3.2 Personnel and contractors

Everyone who works on Nimbl Mail, including any contractors or service providers, is bound by confidentiality obligations covering client data and is required to handle it only in line with this policy and our clients' instructions. We are a small team: access to production systems and client data is limited to the people who operate the service, and it is removed promptly when someone no longer needs it.

3.3 Device and remote-access security

Administrative access to production systems is performed over encrypted connections, protected by strong authentication. Devices used to access client data are kept up to date and secured, and credentials are never shared.

3.4 Sub-processors

We use a small number of trusted service providers to run Nimbl Mail. We share personal information with them only as needed to provide the service, under appropriate safeguards, and we do not sell your data. These currently include:

  • Our container hosting provider, where the application and database run.
  • Cloudflare, for DNS, TLS, and network protection.
  • Payfast, to process subscription payments. Card details are handled by the payment provider and are not stored by us.
  • Our error-monitoring and, where used, email-validation providers.

3.5 Data retention and deletion

We keep account and billing data for as long as your account is active and as required for legal, tax, and accounting purposes. You can delete subscribers, campaigns, and content at any time. When you close your account, we delete or anonymise personal information within a reasonable period, unless we are required to keep it by law.

3.6 Breach response plan

If we become aware of a potential data breach, we follow a defined plan with five steps:

  • Identification and classification: we confirm whether a breach has occurred and assess what data and whose data is involved.
  • Containment and recovery: we stop the breach, limit its impact, and restore affected systems and data from backups where needed.
  • Risk assessment: we assess the likely consequences for the people whose data is affected, and how serious they are.
  • Notification: where required, we notify the Information Regulator and the affected parties as soon as reasonably possible, in line with section 22 of POPIA.
  • Evaluation and response: after the incident we review what happened and what we changed, to reduce the chance of it happening again.