Security
How we protect the client information your firm shares with us — including what we do not yet have.
Brokerages are accountable for the client information they share with third parties. This page sets out how we protect it, so your compliance function can assess us without a call.
Everything below describes controls that are in place today. Where we do not have something, we say so.
Where your data lives
All customer data, uploaded documents and generated outputs are stored on Amazon Web Services infrastructure in the af-south-1 (Cape Town) region, within the Republic of South Africa.
Certain processing occurs outside South Africa through approved sub-processors. This includes AI inference, OCR, progress streaming and screening services. Storage stays domestic; the processing needed to produce an output goes offshore, and the output is returned to South African storage.
Cross-border processing is managed under section 72 of POPIA and the applicable commercial agreements and data processing agreements.
We do not claim that offshore providers retain nothing. Some retain limited information for a bounded period for abuse monitoring or operational purposes; the position for each is set out in our sub-processor list.
We would rather state this plainly than describe ourselves as fully data-resident. For completeness: we have investigated in-country inference and it is not currently available to us. AWS Bedrock is present in the Cape Town region, but that region supports no on-demand throughput for the models we use — the only inference profile that resolves is a global one, which routes to AWS's international infrastructure. So no provider offers us genuine in-country inference today. If it becomes available, we will move.
The full list of providers, and what each one receives, is available on request from admin@brokerai.co.za.
Your documents are not used to train models
We hold commercial API licences with our AI providers. Under those licences and the accompanying data processing agreements, content submitted through the API is not used to train or improve the providers' models. We do not use customer content or generated output to train any model of our own.
This is a contractual position we can evidence, not only a statement of intent, and it is a term of our Terms of Service at clause 8.3(e). We will provide the relevant provider terms on request.
Encryption
- In transit: TLS 1.2 or higher on all connections
- At rest: AWS KMS encryption on every store that holds customer content. Uploaded documents, generated outputs, document templates and inbound email are encrypted with a customer-managed KMS key in our own account, with automatic key rotation enabled. Our databases are encrypted with AWS-managed KMS keys, and the vector database used for document search is encrypted at rest.
- Credentials: authentication is handled by AWS Cognito; we never see or store passwords in readable form.
Access control
Access to customer information is restricted to authorised personnel on a least-privilege basis for defined support, billing, security and incident-response purposes. Access to production information is logged and subject to confidentiality obligations.
- Role-based access, on a least-privilege basis
- All access to production data is logged, and account-level activity is recorded in AWS CloudTrail
- Access is revoked on the same day a person leaves
- Personnel are bound by written confidentiality obligations
- Multi-factor authentication is available on all accounts and is enforced where an organisation requires it (see below). We are in the process of mandating it on every administrative account, and will update this page when that is complete rather than claim it before it is true.
What we offer your firm. Multi-factor authentication is available to every user, and an administrator can require it for your whole organisation — once set, a user in your organisation cannot reach the service without enrolling. We do not currently offer SAML or OIDC single sign-on, and we do not currently offer IP allowlisting. If either is a requirement for your firm, tell us.
Tenant separation
Customer data is separated by logical separation with tenant-scoped queries. Every stored record carries a tenant identifier, queries are parameterised on it, and authorisation is enforced in the application layer before any record is returned.
To be precise, because the question deserves a precise answer: this is not separate databases, separate schemas, or a separate bucket per customer. It is shared infrastructure with a tenant identifier on every row and enforcement in the query and authorisation layer.
The detailed control design is available in our enterprise security pack, provided under NDA — email admin@brokerai.co.za.
Monitoring, backup and recovery
- Continuous backups of our operational databases, with point-in-time recovery to any second in a 35-day window
- The vector database is backed up daily and retained for 7 days
- Backups are encrypted at rest
- Application and infrastructure monitoring and alerting through AWS CloudWatch
- We do not currently publish a formal recovery point or recovery time objective. We are not going to state numbers we do not test. Our recovery position is the 35-day continuous backup window above, and our deployment process supports an immediate rollback to the previously running version.
Development practices
- Infrastructure defined and deployed as code
- Every change is peer-reviewed and must pass automated linting, type checking and the full test suite before it can be merged
- Automated dependency, secret and static application security testing runs against every change
- Development and staging environments contain no production customer data. There is no process that copies, seeds or restores production data into a lower environment. Staging runs on entirely separate storage, databases and identity pools.
Penetration testing. We do not currently hold a penetration test attestation for this application. A re-attestation naming Broker AI (Pty) Ltd against broker-ai.org is planned, and this section will be updated when it exists.
Incident response and breach notification
We maintain an incident response procedure covering detection, containment, assessment and notification.
Where there are reasonable grounds to believe customer content has been accessed or acquired by an unauthorised person, we will notify the affected customer immediately, as section 21(3) of POPIA requires of an operator, with enough detail for you to meet your own notification obligations to the Information Regulator and to your clients under section 22.
We will not delay notification to complete an investigation.
Report a suspected vulnerability or incident to admin@brokerai.co.za. We aim to acknowledge within one business day.
Our role under POPIA
For your clients' information contained in documents you upload, you are the responsible party and we are your operator. We process it only on your instruction, for the purpose of producing the output you requested.
The written operator agreement required by section 21(2) of POPIA is built into our Terms of Service at clause 8. A standalone Data Processing Agreement is available from admin@brokerai.co.za if your compliance function requires one.
Sub-processors
Our current sub-processor list is available on request from admin@brokerai.co.za. We give at least 30 days' notice before adding or replacing one, and you may cancel without penalty if you reasonably object on data protection grounds.
Data retention, export and deletion
- Uploaded source documents are deleted automatically five days after upload. This is enforced by a storage lifecycle rule, not by application code, so it runs whether or not anything else does.
- Generated outputs are retained until you delete them. We do not currently expire them on a schedule, because brokers rely on being able to return to a document they produced months ago. You can delete any output from within the application at any time, and we will delete on request.
- Records of the jobs you have run, including the information extracted from your documents, are retained for 400 days and then deleted automatically.
- Main application logs are retained for 14 days. Other security and access logs are retained for between 1 and 90 days, depending on the system.
- After termination we keep your data available for export for 30 days, then delete it.
- Deleted data clears our backups within 35 days, which is the length of our continuous backup window.
- Billing, tax and company records are retained for the applicable statutory period.
- We confirm deletion in writing on request.
Export. You can download any document you have generated, at any time, from within the application. We do not currently provide a single self-service "export everything" function; if you need a complete extract of your organisation's data — for a migration, an audit or a regulatory request — email admin@brokerai.co.za and we will produce it. We are building the self-service version.
Deletion requests. A request to delete an account is actioned by our team rather than by an automated process. Tell us at admin@brokerai.co.za and we will remove the account and its data, and confirm in writing.
We know brokerages must retain advice records for five years under section 3(2) of the FAIS General Code. Broker AI is not a system of record for that purpose — export and keep your own copies.
Certifications
We do not currently hold ISO 27001 or SOC 2 certification. Our infrastructure provider, AWS, maintains ISO 27001, SOC 1, SOC 2 and SOC 3 certification for the underlying platform, which does not extend to our application.
Contact
Security and general: admin@brokerai.co.za · 082 554 2605
Information Officer: Dean Geldenhuys (registered with the Information Regulator, reg. no. 2026-065219)