Data Security and AI: What Property Managers Need to Know

Your Agency Holds Some of the Most Sensitive Personal Data in Any Industry. Here’s How to Evaluate Whether an AI Tool Will Protect It — and What Questions You Should Be Asking Before You Sign Anything.

Property management agencies are custodians of an extraordinary volume of personal information.

Think about what sits in your property management platform right now: tenant names, phone numbers, email addresses, residential addresses (current and previous), dates of birth, driver’s licence numbers, bank account details, employment information, rental payment histories, references from previous landlords, emergency contacts, and — increasingly — photos and videos of tenants’ homes taken during inspections.

For owners, you hold financial information, tax file numbers (or equivalent), bank details for disbursements, mortgage information, insurance policy details, and correspondence that may contain commercially sensitive information about their investment strategy.

This isn’t generic consumer data. This is deeply personal, financially sensitive information that, if exposed, could enable identity theft, financial fraud, or serious invasions of privacy.

When you introduce an AI tool into your operations — one that reads, processes, and responds using this data — you are extending the chain of data custody. You’re adding another system, another vendor, and another set of access points to information that your tenants and landlords entrusted to your agency.

This doesn’t mean AI is inherently risky. It means you need to evaluate AI vendors with the same rigour you’d apply to choosing a trust accounting platform or a document storage provider — arguably more, because an AI agent actively processes data rather than passively storing it.

This article will equip you with the knowledge to do exactly that.

The Data Your AI Agent Will Touch

Before we discuss security frameworks and compliance requirements, let’s be explicit about the categories of data an AI agent will interact with in a property management context:

Data the AI Processes Actively

These are data types the AI reads, interprets, and uses to make decisions or generate responses:

Data the AI Stores (Temporarily or Persistently)

Depending on the vendor’s architecture, the AI may:

• Temporarily store conversation transcripts in memory while processing a request (cleared after the interaction)
• Persistently store interaction logs, decision records, and performance data for audit, training, and improvement purposes
• Cache frequently accessed reference data (like property details or preferred trades lists) to improve response speed

The distinction between temporary and persistent storage matters significantly for security and privacy compliance. You need to know which model your AI vendor uses.

Data the AI Should Never Store

Certain categories of data should pass through the AI transiently (used to answer a query, then discarded) but never be persistently stored in the AI vendor’s systems:

• Bank account numbers and BSB codes
• Tax file numbers (TFNs) or Singapore NRIC/FIN numbers
• Driver’s licence or passport numbers
• Credit card details
• Passwords or security PINs

If an AI vendor needs to reference this type of data (for example, confirming a tenant’s identity), it should query the source system (e.g., PropertyMe) in real time, use the result for the immediate interaction, and not retain a copy.

The Regulatory Landscape: Australia and Singapore

Australia

Property management agencies in Australia operate under several overlapping data protection obligations:

The Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs)

The Privacy Act applies to organisations with an annual turnover of more than A$3 million, as well as certain smaller organisations that handle health information or provide services to the Commonwealth. However, many industry bodies and state regulations effectively extend privacy obligations to all property management agencies regardless of size.

Key principles relevant to AI adoption:

• APP 1 (Open and Transparent Management): Your agency must have a clear privacy policy that describes how personal information is managed — including by third-party technology providers like AI vendors.
• APP 6 (Use or Disclosure): Personal information can only be used for the purpose for which it was collected, or a directly related purpose the individual would reasonably expect. If you collected a tenant’s phone number for tenancy management purposes, using it within an AI system that handles tenancy-related communications is likely within scope. Using it for unrelated marketing would not be.
• APP 8 (Cross-Border Disclosure): If the AI vendor processes or stores data outside Australia, you must take reasonable steps to ensure the overseas recipient handles the data consistently with the APPs. This is particularly relevant if the AI vendor’s servers or subprocessors are located in the US, EU, or Asia.
• APP 11 (Security): You must take reasonable steps to protect personal information from misuse, interference, loss, unauthorised access, modification, or disclosure. Introducing an AI vendor into your data ecosystem means you need to assess whether that vendor meets the standard of “reasonable steps.”

State and Territory Tenancy Legislation

Various state acts — such as the Residential Tenancies Act 1997 (VIC), the Residential Tenancies Act 2010 (NSW), and the Residential Tenancies and Rooming Accommodation Act 2008 (QLD) — contain provisions about the collection, use, and storage of tenant information. These vary by jurisdiction and should be reviewed with your legal advisor in the context of AI adoption.

The Notifiable Data Breaches (NDB) Scheme

Since February 2018, organisations covered by the Privacy Act must notify the Office of the Australian Information Commissioner (OAIC) and affected individuals when a data breach is likely to result in serious harm. This means that if your AI vendor suffers a data breach involving your tenants’ or owners’ data, you may have a legal obligation to notify — even if the breach occurred in the vendor’s system, not yours.

This is why your contract with any AI vendor must include clear data breach notification provisions with specific timeframes.

Upcoming Reforms

The Australian Government’s response to the Privacy Act Review (2023) signals significant upcoming changes, including:

• Expanded individual rights (right to erasure, right to object to automated decision-making)
• Broader coverage (potentially removing the A$3 million turnover threshold)
• Increased enforcement powers and penalties
• A positive duty to implement technical and organisational security measures

These changes are not yet enacted, but agencies adopting AI tools now should select vendors whose practices would comply with the anticipated stricter regime. Choosing a vendor that barely meets current requirements may create problems when the law tightens.

Singapore

For agencies operating in Singapore, the primary framework is:

The Personal Data Protection Act 2012 (PDPA)

Singapore’s PDPA shares many principles with Australian privacy law but has some important differences:

• Consent: The PDPA requires consent for the collection, use, and disclosure of personal data. The consent must be informed — individuals need to know that their data may be processed by an AI system.
• Purpose Limitation: Data can only be used for purposes the individual has been informed about and consented to.
• Data Protection Provisions: Organisations must protect personal data with reasonable security arrangements.
• Do Not Call (DNC) Registry: If the AI agent makes outbound calls or sends messages, it must comply with Singapore’s DNC provisions. This is relevant for AI-initiated communications to tenants or owners.
• Data Breach Notification: Since February 2021, organisations must notify the Personal Data Protection Commission (PDPC) and affected individuals of significant data breaches within three calendar days of assessment.
• Cross-Border Transfer: Personal data can be transferred out of Singapore only if the receiving country provides a comparable standard of protection, or if the transfer is covered by contractual obligations.

The PDPA’s Accountability Obligation is particularly relevant: organisations must be able to demonstrate that they have policies and practices to meet their PDPA obligations. This means documenting your AI vendor assessment, the data that flows to the vendor, and the security measures in place — not just trusting the vendor verbally.

Implications for Agencies Operating in Both Markets

If your agency operates in both Australia and Singapore (or serves landlords who own properties in both jurisdictions), you need to comply with the stricter of the two requirements for any given data type. In practice, this means:

• Explicit consent mechanisms for Singaporean data subjects (which may go beyond what Australian law currently requires)
• Data breach notification within 3 days (aligning with Singapore’s tighter timeline)
• Clear documentation of data flows, storage locations, and security measures
• Contracts with AI vendors that address both regulatory frameworks

The Security Evaluation Framework: 10 Areas to Assess

When evaluating an AI vendor’s security posture, use the following framework. Each area includes questions to ask and acceptable answers to expect.

1. Data Encryption

What to ask:

• “Is data encrypted in transit and at rest?”
• “What encryption standards do you use?”
• “Who manages the encryption keys?”

Acceptable answers:

• TLS 1.2 or 1.3 for data in transit (the same standard used by banking and government websites)
• AES-256 encryption for data at rest (the gold standard for stored data)
• Encryption keys managed through a reputable key management service (e.g., AWS KMS, Google Cloud KMS, Azure Key Vault) — not stored in the application code or on individual servers

Red flag: “We use encryption” without being able to specify the standard or key management approach.

2. Data Residency and Storage Location

What to ask:

• “Where is our data physically stored?”
• “Which cloud provider do you use?”
• “Can we specify that data remains within Australia (or Singapore)?”

Acceptable answers:

• Major cloud providers (AWS, Google Cloud, Microsoft Azure) with data centre locations in Sydney, Melbourne, or Singapore
• Ability to specify data residency region (especially important for Singapore PDPA compliance)
• Clear documentation of all locations where data is stored or processed, including backup and disaster recovery locations

Red flag: Vague answers like “the cloud” without specifying the provider or region. Or data stored in jurisdictions with weaker privacy protections without your knowledge or consent.

3. Access Controls

What to ask:

• “Who at your company can access our data?”
• “How is access controlled and monitored?”
• “What is your process for granting and revoking access?”

Acceptable answers:

• Role-based access control (RBAC): only specific employees with a legitimate need can access customer data
• Multi-factor authentication (MFA) required for all staff accessing customer environments
• Access is logged and auditable — you can request records of who accessed your data and when
• Access is reviewed regularly (quarterly at minimum) and revoked immediately when staff leave the vendor company
• Production data access limited to a small number of senior engineers, with additional approval required

Red flag: “Our whole team can access the system” or inability to describe access control procedures.

4. Data Retention and Deletion

What to ask:

• “How long do you retain our data?”
• “What happens to our data if we cancel our subscription?”
• “Can we request deletion of specific data?”

Acceptable answers:

• Clear data retention policy with defined timeframes (e.g., conversation transcripts retained for 12 months, then automatically purged; or configurable to your agency’s policy)
• Upon contract termination: all customer data deleted within a specified timeframe (30–90 days is standard), with a certificate of destruction provided upon request
• Ability to request deletion of specific records (supporting tenants’ or owners’ potential right-to-erasure requests)
• Backup data is also deleted within a defined timeframe after primary data deletion

Red flag: “We keep everything indefinitely” or no clear deletion process. Also: “We retain data to improve our AI model” without explicit consent — this is a significant privacy issue (see Section 6 below).

5. Incident Response and Breach Notification

What to ask:

• “What is your incident response process?”
• “How quickly will you notify us of a data breach?”
• “Have you ever experienced a data breach?”

Acceptable answers:

• Documented incident response plan that includes: detection, containment, assessment, notification, and remediation steps
• Contractual commitment to notify your agency of any confirmed or suspected breach within 24–48 hours (allowing you to meet your own regulatory notification obligations)
• Willingness to discuss previous incidents (if any) and how they were handled. A vendor that has experienced an incident and handled it well may actually be more mature than one that claims to have never had any issues.
• Regular incident response drills and testing

Red flag: No documented incident response process. Contractual notification timeframes longer than 72 hours (which would make it impossible for you to meet Singapore’s 3-day requirement). Refusal to discuss incident history.

6. AI Model Training and Data Usage

This is an area unique to AI vendors and critically important. It deserves special attention.

What to ask:

• “Is our data used to train your AI model?”
• “Are our tenants’ conversations used to improve the AI’s responses for other clients?”
• “How is our data isolated from other customers’ data?”

Why this matters:

Large language models (LLMs) and other AI models improve through training on data. If your AI vendor uses your agency’s tenant conversations, maintenance requests, and property data to train a shared AI model, several problems arise:

1. Privacy violation: Tenant and owner data is being used for a purpose (AI training) that they didn’t consent to and probably wouldn’t expect.
2. Data leakage risk: Information from your agency’s data could theoretically influence the AI’s responses to other agencies’ queries. While modern AI architectures have safeguards against this, it’s a legitimate concern.
3. Competitive sensitivity: If the AI learns about your agency’s processes, client base, and operational patterns, and these learnings benefit competitors using the same AI vendor, you’ve effectively shared competitive intelligence.

Acceptable answers:

• “Your data is used solely to deliver services to your agency. It is not used to train our shared/base AI model.”
• “Each customer’s data is logically isolated. Our AI operates on your data within your environment — it doesn’t cross-pollinate with other customers’ data.”
• “If we wish to use anonymised, aggregated data for model improvement, we will seek explicit consent and explain exactly what data is involved.”
• Data isolation architecture is documented and available for review

Red flag: “Your data helps improve our AI for all customers” without explicit consent mechanisms. Or inability to clearly explain how customer data is isolated.

7. Subprocessors and Third-Party Services

AI vendors rarely operate in complete isolation. They typically use subprocessors — third-party services that handle specific functions. Common examples include:

• Cloud hosting providers (AWS, Google Cloud, Azure)
• LLM providers (OpenAI, Anthropic, Google, or self-hosted open-source models)
• Communication APIs (Twilio for phone/SMS, SendGrid for email)
• Monitoring and logging services
• Payment processors

What to ask:

• “What subprocessors do you use?”
• “Is our data shared with any third parties?”
• “Does data pass through any external LLM APIs (e.g., OpenAI)?”

Why the LLM question matters:

If your AI vendor sends tenant conversation data to an external LLM provider (e.g., sends a tenant’s maintenance request to OpenAI’s API for processing), you need to understand:

• What data is sent to the LLM provider?
• Where does the LLM provider process this data?
• Does the LLM provider retain the data? For how long?
• Does the LLM provider use the data for their own model training?

Major LLM providers have evolved their data practices significantly. For example, OpenAI’s API terms (as of 2024) state that data submitted via the API is not used to train their models. However, the specifics vary by provider and by the specific API plan or agreement in use. Your AI vendor should be able to provide clear documentation on this.

Acceptable answers:

• Complete list of subprocessors, with the purpose of each and the data they access
• Data Processing Agreements (DPAs) in place with all subprocessors
• Clear explanation of what data is sent to external LLM providers, if any
• Confirmation that subprocessors are bound by equivalent security and privacy obligations
• Notification process when subprocessors change

Red flag: “We can’t disclose our subprocessors” (this makes it impossible for you to assess your data supply chain). Or: discovery that data is being processed by LLM providers in jurisdictions you weren’t informed about.

8. Compliance Certifications and Audits

What to ask:

• “Do you hold any security certifications?”
• “Are you audited by independent third parties?”
• “Can we review your most recent audit report?”

What to look for:

Reality check: Many early-stage AI vendors (including startups) may not yet have SOC 2 or ISO 27001 certification. These certifications are expensive and time-consuming to obtain. The absence of certification isn’t automatically disqualifying — but if the vendor doesn’t have them, you should expect:

• A clear roadmap and timeline for obtaining certification
• Willingness to complete a detailed security questionnaire
• Willingness to allow a third-party security assessment
• Documented security policies and procedures that you can review

Red flag: No certifications, no roadmap to obtain them, and unwillingness to provide detailed security documentation.

9. Vulnerability Management and Testing

What to ask:

• “Do you conduct regular penetration testing?”
• “How do you handle security vulnerabilities in your software?”
• “Do you have a bug bounty or responsible disclosure programme?”

Acceptable answers:

• Annual (minimum) penetration testing by an independent security firm, with results available for review (or at least a summary of findings and remediations)
• Automated vulnerability scanning of code and infrastructure on an ongoing basis
• Defined process for patching critical vulnerabilities (e.g., critical vulnerabilities patched within 24–48 hours, high-severity within 7 days)
• Responsible disclosure or bug bounty programme (indicates a mature security culture)

Red flag: No penetration testing, or testing performed only by internal staff.

10. Business Continuity and Disaster Recovery

What to ask:

• “What is your uptime commitment?”
• “What happens if your system goes down — do our phones go unanswered?”
• “How is data backed up, and how quickly can you recover from a disaster?”

Acceptable answers:

• Uptime commitment of 99.9% or higher (often documented in a Service Level Agreement / SLA)
• Failover architecture: if the primary system fails, a backup system takes over with minimal or no interruption
• Clear fallback procedure for communication handling during outages (e.g., calls redirect to voicemail, or to a backup human answering service)
• Regular backup schedule (daily minimum), with backups stored in a separate physical location from primary data
• Tested recovery procedures: not just “we have backups” but “we have tested restoring from backups and can recover within [X] hours”
• Disaster recovery testing at least annually

Red flag: No SLA, no documented disaster recovery plan, or inability to explain what happens to incoming calls/messages during an outage.

The Contract: What to Include

Your commercial agreement with an AI vendor should include specific data security and privacy provisions. Don’t rely solely on the vendor’s standard terms of service — negotiate the following:

Data Processing Agreement (DPA)

A DPA is a contractual document that defines:

• What data the vendor processes on your behalf
• The purposes for which data is processed
• The vendor’s obligations regarding data security, confidentiality, and privacy
• Subprocessor disclosure and approval
• Data breach notification timeframes and procedures
• Data retention and deletion obligations
• Audit rights (your right to audit or inspect the vendor’s data handling practices)

In many jurisdictions, a DPA is not just good practice — it’s a legal requirement for any third party processing personal data on your behalf.

Security Schedule

A security schedule or appendix that documents:

• Encryption standards
• Access control procedures
• Data residency commitments
• Vulnerability management practices
• Incident response procedures and notification timeframes
• Compliance certifications held or in progress

Liability and Indemnification

Clear provisions regarding:

• Who is liable if a data breach occurs due to the vendor’s negligence
• Indemnification for regulatory fines or penalties resulting from the vendor’s failure to meet their data protection obligations
• Insurance requirements (the vendor should hold cyber liability insurance)

Exit Provisions

Clear terms for what happens when the relationship ends:

• Data export: you can retrieve your data in a usable format
• Data deletion: the vendor deletes all your data within a specified timeframe and provides written confirmation
• Transition period: reasonable time to migrate to an alternative solution without loss of service

What AI Vendors Should Be Doing (But Many Aren’t)

Beyond meeting your requirements, there are practices that distinguish a genuinely security-conscious AI vendor from one that treats security as a compliance checkbox:

Privacy by Design

The vendor’s product should be built with privacy and security as foundational principles, not added as afterthoughts. Evidence of privacy by design includes:

• Data minimisation: the AI collects and processes only the data it needs, not everything it can access
• Default privacy settings: the system defaults to the most privacy-protective configuration
• Anonymisation and pseudonymisation where possible (e.g., using property IDs rather than addresses in internal logs)
• Regular privacy impact assessments for new features

Transparency Reporting

Some mature vendors publish transparency reports documenting:

• The number of data access requests received (from law enforcement or government agencies)
• Security incidents (anonymised)
• System uptime performance
• Data processing volumes

While this level of transparency is more common in large enterprises, it’s a positive signal from a vendor of any size.

Human-in-the-Loop for Sensitive Decisions

As discussed in our previous article on maintenance triage, a well-designed AI system knows when to defer to humans. From a data security perspective, this is also important:

• The AI should not make decisions about disclosing sensitive data without appropriate verification
• Identity verification protocols should be robust (e.g., before sharing financial information with a caller claiming to be a landlord)
• The AI should log all decisions involving sensitive data access for human review

Regular Security Training for Vendor Staff

The vendor’s own employees are a potential vulnerability. Ask whether the vendor provides:

• Regular security awareness training for all staff
• Specific training for engineers on secure coding practices
• Background checks for employees who access customer data
• Clear policies on acceptable data handling (e.g., no customer data on personal devices or in personal cloud storage)

A Practical Security Assessment Checklist

To make this actionable, here’s a checklist you can use when evaluating AI vendors:

Non-Negotiable Requirements

• Data encrypted in transit (TLS 1.2+) and at rest (AES-256)
• Clear data residency — you know exactly where your data is stored
• Your data is NOT used to train shared AI models without explicit consent
• Data Processing Agreement available and includes breach notification, deletion rights, and audit provisions
• Subprocessor list provided with data flow documentation
• Data breach notification within 48 hours (contractually committed)
• Data deletion upon contract termination with written confirmation
• Trust accounting data access is read-only (AI cannot initiate financial transactions)
• Identity verification protocols before disclosing sensitive information

Strongly Recommended

• SOC 2 Type II certification (or ISO 27001), or a documented roadmap to certification within 12 months
• Annual third-party penetration testing
• Role-based access control with multi-factor authentication for vendor staff
• Documented incident response plan
• Business continuity / disaster recovery plan with tested recovery procedures
• Cyber liability insurance held by the vendor
• Ability to specify data residency region (Australia and/or Singapore)

Good-to-Have

• ISO 27701 (privacy management) certification
• Bug bounty or responsible disclosure programme
• Transparency reporting
• Regular data protection impact assessments

Vendor staff background checks and security training documentation available

How to Talk to Your Tenants and Landlords About AI and Data

Introducing AI into your operations will prompt questions from tenants and landlords about how their data is being used. This is healthy and should be addressed proactively rather than reactively.

Update Your Privacy Policy

Your agency’s privacy policy should be updated to reflect the use of AI tools. Specifically:

• Disclose that an AI system may handle communications (phone, text, email)
• Explain what data the AI accesses and for what purpose
• Identify the AI vendor as a third-party data processor
• Explain that all AI interactions are logged and available for review
• Describe how tenants/landlords can opt out of AI-handled communications if they prefer to speak with a human (where operationally feasible)
• Note any cross-border data processing (if applicable)

Notify Tenants and Owners

When you first introduce AI to your operations, consider sending a brief, plain-language notification:

“We’re introducing a new AI-powered assistant to help handle maintenance requests, general enquiries, and after-hours communications. This technology helps us respond faster and more consistently. The AI agent has access to your tenancy/property information within our management system to provide personalised, accurate service. All conversations are recorded and available for review by our team. Your data is protected by enterprise-grade security and is never shared with unrelated third parties. If you ever prefer to speak with a human team member, just ask — the AI will transfer you immediately.”

This kind of transparency builds trust rather than eroding it. Most people’s concern about AI and data isn’t that it exists — it’s that it happens without their knowledge.

Handle Opt-Out Requests Graciously

Some tenants or landlords will want to opt out of AI-handled communications. This is their right, and it should be accommodated without friction. In practice, this might mean:

• Flagging the contact in your system so the AI routes their calls directly to a human
• Ensuring the AI identifies opt-out contacts at the start of an interaction and transfers immediately
• Not penalising opt-out contacts with longer wait times or inferior service

The percentage of people who opt out is typically very small (in most deployments, less than 5%), so this won’t significantly impact operational efficiency.

The Cost of Getting It Wrong

If the regulatory and ethical arguments for data security aren’t sufficient motivation, consider the commercial implications of a data incident:

Direct Costs

Indirect Costs

The total cost of a significant data breach for a mid-sized property management agency has been estimated at A$200,000–$1 million+ when direct and indirect costs are combined. For some agencies, this would be existential.

This is not an argument against AI adoption. It’s an argument for thoughtful, security-conscious AI adoption with a vendor that takes data protection as seriously as you do.

The Bottom Line

Data security is not a feature you evaluate once and forget. It’s an ongoing practice — a shared responsibility between your agency and your AI vendor.

The right AI vendor will:

• Be transparent about what data they access, how they process it, and where they store it
• Provide clear contractual commitments on security, privacy, and breach notification
• Hold (or be actively pursuing) independent security certifications
• Never use your data to train shared AI models without explicit, informed consent
• Support your compliance obligations under Australian and Singaporean law
• Welcome your questions, your audits, and your scrutiny — because they have nothing to hide

The wrong vendor will give vague answers, resist documentation, and treat your security concerns as obstacles to a sale rather than legitimate requirements of a responsible agency.

Your tenants and landlords trust you with their most personal information. When you extend that data to an AI system, you’re extending that trust. Choose a vendor that deserves it.

Zemly.ai processes all data within Australian-hosted infrastructure, does not use customer data for shared model training, and provides comprehensive Data Processing Agreements to every customer. Request our security documentation pack including our latest penetration test summary and data architecture overview.