Information Security Policy

1. Purpose & Scope

1.1 Purpose

This policy establishes the information security requirements for Mates With Property Pty Ltd (ACN 678 025 155 | ABN 64 678 025 155), trading as PropBoss ("PropBoss", "we", "us", or "our"). It defines the controls we apply to protect the confidentiality, integrity, and availability of all information assets, with specific attention to Consumer Data Right (CDR) data handled under our CDR representative arrangement with Fiskil Pty Ltd.

1.2 Scope

This policy applies to:

• All personnel — employees, contractors, and any third parties with access to PropBoss systems or data.
• All systems that store, process, transmit, log, or support CDR data, including:
  • Production application (hosted on Vercel)
  • Database and authentication services (Supabase / PostgreSQL)
  • Source code repository (GitHub)
  • CI/CD pipeline (Vercel)
  • Email processing (SendGrid / Twilio)
  • Bank feed integration (Fiskil)
  • AI processing services (Anthropic)
  • Monitoring, logging, and support tooling where CDR data could appear
• All devices used to access the above systems, including company-owned and personally-owned (BYOD) devices.

1.3 Governance & Review

• This policy is reviewed at least annually (or sooner if there is a material change to systems, regulations, or threat landscape).
• The Director is responsible for policy approval and ensuring compliance.
• All personnel must acknowledge this policy upon onboarding and after each revision.

2. Access Control

2.1 Principles

• Least privilege: access is granted only to the minimum set of systems and data required for a person's role.
• Need-to-know: CDR data access is restricted to personnel who require it for operational purposes.
• No shared accounts: each person has a unique identity. Service accounts (API keys) are stored in environment variables on the hosting platform, never in source code.

2.2 Multi-Factor Authentication (MFA)

MFA is required for all accounts that can access:

2.3 Credential Management

• Accounts are deactivated immediately upon role change or departure.
• API keys and secrets are rotated when personnel with access depart, or at least annually.
• Production secrets are stored exclusively in the hosting platform's environment variable system (Vercel) — never committed to source code.

3. Asset & Endpoint Security

3.1 BYOD Policy

PropBoss permits the use of personally-owned devices (BYOD) under the following mandatory controls:

3.2 Non-Compliant Devices

Devices that do not meet the above requirements must not be used to access production environments, the database dashboard, or any system containing CDR data. Production database credentials are only accessible via the hosting platform — they cannot be extracted to local devices.

4. Vulnerability & Patch Management

4.1 Application & Dependencies

• Third-party dependency vulnerabilities are monitored via automated scanning (GitHub Dependabot).
• Critical security vulnerabilities in the application or its dependencies are fixed as soon as possible upon identification.
• Code changes are reviewed before deployment. Security-sensitive changes require explicit review.

4.2 Infrastructure

• Supabase and Vercel manage infrastructure-level patching as part of their managed service offerings.
• We monitor their status pages and security advisories for issues that may affect our service.
• Operating system updates on developer devices are applied promptly.

4.3 Exception Handling

Any exception to remediation (e.g., a vulnerability that cannot be immediately addressed) must be documented with: justification for the delay, compensating controls in place, approval by the Director, and a target remediation date.

5. Security Incident Identification, Logging & Response

5.1 What Is a Security Incident

A security incident is any event that compromises or may compromise the confidentiality, integrity, or availability of PropBoss systems or data. Examples include:

• Unauthorised access to the database or admin dashboard
• CDR data exposed to unauthorised parties
• Compromise of API keys, service role keys, or webhook secrets
• Repeated failed authentication attempts suggesting brute-force attack
• Webhook signature verification failures (potential tampering)
• Loss or theft of a device with access to production systems
• Malware infection on a device with production access

5.2 Identification & Logging

Incidents may be identified through the following sources:

Each incident record captures at minimum: date and time of detection, impacted area or system, how the incident was detected, description of the event, and severity assessment. Logs are reviewed regularly to identify potential patterns or emerging threats.

5.3 Incident Response Process

1. Triage (within 1 hour): Assess severity and scope. Determine if CDR data is affected. Contain the incident (e.g., revoke compromised credentials, disable affected accounts).
2. Investigation (within 24 hours): Identify root cause. Determine extent of data affected. Preserve evidence (logs, screenshots).
3. Remediation: Apply fixes to prevent recurrence. Rotate any compromised credentials. Restore affected systems.
4. Notification:
   • Fiskil: notified within 24 hours of confirming any CDR-related incident or potential threat to CDR data.
   • Affected users: notified as required by the Privacy Act 1988 and the Notifiable Data Breaches scheme.
   • OAIC: notified as required under the CDR framework and NDB scheme for eligible data breaches.
5. Post-incident review: Document lessons learned. Update controls and this policy if needed. Brief all relevant personnel.

6. Data Protection

6.1 Encryption in Transit

• All communications between PropBoss systems and external services use TLS 1.2 or higher.
• Vercel enforces HTTPS on all endpoints with HSTS enabled.
• Supabase enforces TLS for all database connections and API calls.
• Fiskil API communications use TLS 1.2+.

6.2 Encryption at Rest

Bank account numbers displayed in the application are masked (e.g., ••••1234) — full values are only decrypted when operationally required. Encryption keys are managed via Supabase Vault, a secure isolated key management system.

6.3 Data Retention & Secure Deletion

• CDR data is not retained longer than necessary for the purpose for which it was collected (providing bank feed functionality to the property owner).
• When a user revokes CDR consent (via the application or via their bank), all associated bank transactions are immediately deleted via cascade deletion. The bank connection is marked as disconnected and an audit log entry is recorded.
• When a user closes their PropBoss account, all associated CDR data is securely deleted.
• Deletion is verified through audit log review.

6.4 Data Minimisation

• PropBoss requests only the transactions CDR data scope — the minimum required to provide the bank feed feature.
• CDR data is used solely for the purpose consented to by the user (matching bank transactions to properties and generating financial reports).
• CDR data is not used for marketing, profiling, or any secondary purpose.

7. Third-Party & Supplier Security

7.1 Vendor Assessment

Before engaging any third-party vendor that may host, process, or have access to CDR data (or logs containing CDR data), PropBoss assesses their security posture, data handling practices, and incident response commitments.

7.2 Current Vendors

7.3 Contractual Requirements

• Vendors that host or access CDR data are required to maintain appropriate security controls as part of their service agreements.
• Vendor security posture is reviewed annually as part of the policy review cycle.
• New vendors or changes to existing vendor data handling trigger an ad-hoc security assessment.

8. Compliance

All personnel are responsible for complying with this policy. Non-compliance may result in disciplinary action, including termination of access and/or engagement. Questions or concerns about this policy should be directed to the Director.

9. Document History

10. Contact

If you have any questions about this Information Security Policy, please contact us: