Security Policy

1. Purpose and scope

This Security Policy describes how Alada approaches the security of personal information and other data handled by our Service.

Alada is operated by Emmanuel Phiri (ABN 81 224 437 424), based in Perth, Australia.

This Policy is high-level and is intended to:

• Provide transparency to users and partners
• Summarise our security controls and processes
• Complement our Privacy Policy and Terms of Service.

We draw on OAIC guidance under the Privacy Act 1988 (Cth) and industry best practices (including ISO 27001-style controls and modern cloud-security patterns).

2. Security governance

Security responsibilities are assigned within the team.

We maintain internal procedures for access control, incident response, and secure development and deployment.

We incorporate security and privacy considerations into product design and feature planning ("security and privacy by design").

3. Access control and authentication

Access to production systems (e.g. Supabase database, Vercel projects, Twilio/Stripe dashboards) is limited to authorised personnel with a legitimate business need.

We apply the principle of least privilege, restricting access to only what is necessary for each role.

Administrator and cloud accounts use strong passwords and multi-factor authentication (MFA) where available.

Access rights are reviewed periodically and revoked promptly when no longer needed (for example, when team members change role or depart).

4. Data encryption and storage

In transit – All connections to the Alada web app are made over HTTPS/TLS, encrypting data between your device and our servers.

At rest – Data stored in our databases and cloud storage (e.g. Supabase/Postgres, Vercel) is encrypted at rest using our providers' built-in encryption features.

Access to encryption keys is managed via these providers' secure mechanisms, and keys are not stored in source code.

We follow OAIC guidance to take reasonable steps to protect personal information from unauthorised access, modification or disclosure.

5. Secure development and change management

Code changes are managed via modern version-control workflows (e.g. Git) and are reviewed before deployment.

We monitor third-party dependencies for known vulnerabilities and update them regularly.

Secrets such as API keys and database credentials are stored in environment variables or secure secret-management tools and are not committed to source control.

We maintain separate development and production environments and avoid using real personal data in non-production environments where practicable.

6. Logging, monitoring and detection

We keep logs of important events such as authentication attempts, significant errors and administrative actions.

Logs are stored securely and access is restricted to authorised personnel.

We use monitoring tools provided by our hosting and database providers, and third-party analytics/logging where appropriate, to help detect unusual activity or performance issues.

Alerts are configured for critical events where feasible.

7. Third-party providers and vendor security

We rely on reputable third-party providers, including:

• Supabase – hosting our database and authentication
• Vercel – hosting and deploying the application
• Twilio (or similar) – sending SMS
• Stripe – processing payments
• OpenAI – powering AI-assisted features
• Analytics tools such as PostHog and Google Analytics.

Before using providers that process personal information, we consider:

• Their reputation, security documentation and certifications where available (e.g. ISO 27001, SOC reports)
• Their data-handling and privacy policies
• Where their systems are hosted and how data is transferred and stored.

We enter into appropriate agreements with key providers and maintain an internal register of major sub-processors.

With OpenAI and similar AI providers, we use their API offerings and rely on their published commitments that API inputs and outputs are not used to train models by default, unless a customer explicitly opts in. We do not opt in to such training for Alada data.

8. Backup and disaster recovery

Databases are backed up regularly using Supabase's or our database provider's backup services.

We retain backups for a defined period to support restoration in case of system failure or data loss.

We maintain documented restore procedures, and we periodically review them to ensure they remain appropriate as the architecture evolves.

9. Incident response and data-breach handling

We maintain internal processes to respond to security incidents and potential data breaches.

If we become aware of an incident involving unauthorised access, loss or disclosure of personal information, we will:

• Investigate and contain – identify scope, contain the issue, and prevent further unauthorised access where possible.
• Assess impact – evaluate the likelihood and severity of harm, and whether the incident meets the threshold of an "eligible data breach" under the Notifiable Data Breaches (NDB) scheme, where that scheme applies to us.
• Notify – where required, notify affected individuals and relevant regulators and provide guidance on steps users can take to protect themselves.
• Learn and improve – review the root cause and update our systems, processes or training to reduce the chance of recurrence.

Security concerns or suspected vulnerabilities can be reported to: security@alada.app

10. Device and account security (shared responsibility)

While we take steps to secure our systems, you also play a role in protecting your account:

• Use strong, unique passwords and keep them confidential.
• Protect access to your email and SMS, as these may be used for login or recovery.
• Use up-to-date operating systems and browsers.
• Log out or lock your device when not in use, especially on shared devices.
• Contact us promptly if you suspect unauthorised access to your account.

11. Data minimisation and retention

We aim to collect only the personal information reasonably necessary for the Service.

We regularly review the types of data we store and the periods for which we store them, taking into account legal obligations and product needs.

When you delete your account, we either delete or de-identify your data from active systems after our 30-day soft-deletion window, subject to limited retention in backups, logs and billing records as described in the Privacy Policy.

12. Continuous improvement

Security threats, technologies and legal requirements change over time. We are committed to ongoing improvement, including:

• Reviewing our security controls and processes periodically
• Responding to significant new vulnerabilities or threats as they arise
• Updating this Security Policy when our practices or legal obligations materially change.

We will post the updated Policy on our website and update the "Last updated" date when changes are made.

13. Contact

Security-specific enquiries or vulnerability reports:

Security: security@alada.app

Privacy and general enquiries:

Privacy: privacy@alada.app

Support: support@alada.app