Security

Insurance brokers entrust Mica with sensitive information — client identities, conversations, financial details. We treat that trust as the foundation of the product, not an after-thought. This page describes the technical and organisational controls we apply to protect broker data and meet our obligations under POPIA s19 and equivalent frameworks.

We deliberately describe controls rather than configurations, and categories of technology rather than specific vendors or endpoints. Sharing operational detail at that level helps adversaries more than it helps prospective customers. For our current sub-processors and the systems they operate, see meetmica.com/subprocessors.

1. Our approach

Mica is built on a set of operating principles that determine how the service is designed, run and changed:

• Least privilege — no person or system has more access than the role requires.
• Defence in depth — no single control protects sensitive data; multiple independent layers do.
• Secure by default — production-grade settings are the starting point, not the destination.
• Auditable by design — every meaningful action is logged in a way that can be reviewed after the fact.
• Honest about boundaries — we describe what we have done, not what we aspire to. Open items are listed in section 15.

2. Compliance & alignment

Mica is operated to meet the following frameworks and obligations:

We are not currently certified to SOC 2, ISO 27001 or equivalent. REVIEW: roadmap target A formal external audit programme is planned — see section 15.

3. Encryption

3.1 In transit

All connections between client devices and the Service are encrypted using TLS 1.2 or higher, with cipher suites that provide forward secrecy. Connections to integrated third-party services (mail providers, messaging providers, AI providers) are likewise encrypted end-to-end with the provider.

3.2 At rest

Customer Data is encrypted at rest using industry-standard symmetric encryption (AES-256 or equivalent). Database backups, file storage and message queues are encrypted using keys managed by our cloud provider's key-management service. Keys are rotated on the provider's standard schedule, and are never exposed to application code.

3.3 Application-level secrets

API keys, OAuth refresh tokens and other credentials supplied by you or required to operate the Service are stored encrypted and accessed only at the moment they are needed. Access to the secret store is restricted to a small set of production roles and is fully logged.

4. Access & authentication

4.1 User authentication

You can sign in to Mica with email + password or with single sign-on through Google or Microsoft. Passwords are stored only as salted, slow-hash digests; we cannot recover a plaintext password. Multi-factor authentication is supported on user accounts and recommended for all administrators.

4.2 Staff access to production

Access to production systems is restricted to a named set of engineers under a least-privilege model, gated by multi-factor authentication and SSO with our identity provider. Sensitive operations require explicit approval and are logged.

4.3 Joiners, movers, leavers

When a team member's role changes, their access is reviewed and updated. When a team member leaves, their access is revoked the same business day across all production systems and connected services.

4.4 Separation of environments

Production, staging and development environments are logically separated, with distinct credentials and network boundaries. Customer Data is not used in staging or development.

5. Infrastructure & network

Mica runs on leading cloud platforms with documented security and compliance posture. Production infrastructure is hosted in regions that provide protections consistent with POPIA and GDPR requirements. Architecture-level detail (regions, account boundaries, security-group topology) is shared under NDA with enterprise customers on request.

Network controls in production include:

• Private networking for service-to-service communication, with public exposure limited to a small set of hardened endpoints;
• Web application firewall (WAF) and DDoS mitigation at the edge;
• Rate limiting and abuse detection on authentication and high-cost endpoints;
• Restricted egress for production workloads.

6. Application security

6.1 Secure development

Engineering work follows a peer-review process. Every change to production is reviewed by at least one other engineer and goes through automated checks (linting, type-checking, secret scanning, unit tests) before merge.

6.2 Dependency & supply-chain management

We use automated tooling to monitor third-party dependencies for known vulnerabilities. Critical advisories are triaged on disclosure and remediated according to severity. Build artefacts are produced from controlled CI environments, and deployment is restricted to authorised pipelines.

6.3 Authorisation model

The Service enforces row-level access controls in the database such that a user can only read or modify records they are entitled to. These rules are tested at multiple layers (database, API, client) so a defect in one layer does not expose data.

7. Monitoring, logging & detection

We capture security-relevant events across the application, infrastructure and integrations, including authentication events, configuration changes, privileged actions and unusual traffic patterns. Logs are forwarded to a central system with retention sufficient to support investigation and regulatory enquiries.

Alerts are routed to on-call engineers with documented response runbooks. Indicators of compromise — unexpected privileged actions, mass data exports, repeated failed authentications, abnormal API patterns — trigger automated and human review.

8. Incident response

We maintain a documented incident-response process covering detection, triage, containment, eradication, recovery and lessons learned. Key obligations:

• POPIA s22 — where personal information has been accessed or acquired by an unauthorised person, we notify the Information Regulator and affected data subjects as soon as reasonably possible.
• GDPR Art. 33 — where applicable, we notify the relevant supervisory authority within 72 hours of becoming aware of a qualifying breach.
• Customer notification — we notify affected customers of incidents affecting their data without undue delay, with enough detail for them to meet their own regulatory obligations.

Post-incident reviews are conducted blamelessly and result in concrete control changes.

9. Business continuity & backups

Customer Data is backed up on a rolling schedule, with backups encrypted and stored separately from primary databases. Backups are tested for restorability on a regular cadence.

These targets describe our current commitments and may improve as the Service matures. Custom RPO/RTO commitments for enterprise plans are available on request.

10. Sub-processors

The Service relies on a small number of carefully selected sub-processors for hosting, communications and AI inference. Each is bound by contract to apply security measures consistent with these commitments, and is reviewed on engagement and periodically thereafter.

The current list, including the category of data each processes and their location, is published at meetmica.com/subprocessors. We notify customers of material changes to the list in line with our Data Processing Agreement.

11. Personnel security

• Background checks — where lawful, background checks are performed before granting access to production.
• Confidentiality obligations — every team member and contractor signs a confidentiality agreement before being granted access to Customer Data.
• Security training — staff complete security and privacy training on joining and at least annually thereafter, with additional training for engineering and customer-facing roles.
• Device security — staff devices used to access production are enrolled in centralised management with disk encryption, automatic lock, screen-saver lock and current OS patching enforced.
• Phishing & social-engineering — staff are trained to recognise and report attempts; a clear escalation path exists.

12. Vulnerability management

We monitor public vulnerability feeds and our own systems for weaknesses, and remediate based on severity, exploitability and exposure. Critical issues are addressed on an emergency cadence; lower-severity issues follow our standard release process.

External penetration testing is performed periodically by an independent specialist firm. REVIEW: pen-test cadence Findings are tracked to closure and verified on retest. A coordinated disclosure programme is available — see section 14.

13. Shared responsibility

Security of the platform is a shared responsibility. MeetMica is responsible for the security of the Service. You are responsible for security in your use of the Service, including:

• Choosing strong passwords and enabling multi-factor authentication on your Account and on connected providers (Google, Microsoft, WhatsApp);
• Keeping your devices secure and patched;
• Granting access only to people who need it, and removing access promptly when roles change;
• Reviewing audit logs and exports periodically;
• Ensuring your use of Mica complies with your regulatory obligations (FAIS, FSCA conduct standards, POPIA);
• Notifying us promptly of any suspected unauthorised access.

14. Reporting a security concern

If you believe you have found a vulnerability in Mica or a security issue affecting your Account, we want to hear from you.

We commit to:

• Acknowledge your report promptly;
• Investigate in good faith and keep you informed of progress;
• Not pursue legal action against researchers acting in good faith within the scope of our disclosure policy;
• Credit researchers on request, where the issue is confirmed and resolved.

Please give us a reasonable period to remediate before any public disclosure. Avoid testing against accounts you do not own, do not modify or exfiltrate data beyond the minimum needed to demonstrate the issue, and do not run automated scans against production without prior agreement.

15. Looking ahead

We are honest about where we are. Open items on our security roadmap include:

• SOC 2 Type II readiness assessment REVIEW: target date
• ISO 27001 alignment review REVIEW: target date
• Public bug-bounty programme REVIEW: target date
• Customer-facing audit log export

This page will be updated as items land. Enterprise customers can request a current security posture summary under NDA at any time.

16. Contact

MeetMica is a product of Takat (Pty) Ltd, Reg. 2015/294016/07.