Is It Safe to Connect an AI Leasing Tool to Your PMS? 9 Data-Security Questions to Ask

It can be — but "safe" isn't a yes/no. Connecting an AI leasing tool hands it the most sensitive data your business holds: applicant SSNs, bank details, government IDs, income. Safe means the vendor can answer nine specific questions — about model-training, encryption, internal access, and audits — with the right answers. Here they are.

A property manager in our discovery calls described watching a prospect stop cold during a self-showing flow: "I'm not comfortable entering in my social security number... I didn't know that you had to do that." The kicker: the PM hadn't realized their previous vendor had quietly added the SSN-collection requirement to the flow. They found out when applicants started dropping off.

That story points to something underappreciated about AI leasing security: the question isn't only "is the vendor secure?" It's "what is my vendor quietly making my applicants hand over, and did I even know?" Data security is also a trust and conversion problem. Applicants abandon when they're surprised by data demands — so handling sensitive information well is both a compliance obligation and a way to protect your pipeline.

A leasing pipeline concentrates SSNs, bank details, government IDs, and income documentation in one place — a complete identity-theft toolkit. That makes tenant and applicant databases an outsized breach target. The average cost of a data breach hit a record $4.88 million in 2024 (IBM Cost of a Data Breach Report 2024). That figure isn't meant to frighten — it's meant to calibrate. This is not a low-stakes question.

So "is it secure?" is too vague to act on. Below are nine questions that turn a fuzzy worry into a vendor scorecard, organized across four pillars: (1) model training and data use, (2) encryption, (3) access controls, (4) audits and pen testing.

Does it train its AI models on my tenant or applicant data?

This is the question most property managers forget to ask — and the one with the most potential for surprise. A no-training stance is not automatic. Reputable enterprise AI providers — including the commercial APIs used by AI tools — default to no-training: data sent through commercial API agreements is not used to improve or train models unless you explicitly opt in. OpenAI's commercial API policy (effective March 1, 2023), Anthropic's commercial terms, and Microsoft Azure's Data Processing Agreement all establish this protection by default.

But the landscape is uneven. A major CRM has offered settings that allow customer data to train its "global predictive AI models," with that option on by default. A major developer-tools suite recently announced a policy to use in-app content for AI training by default on many plan tiers. These aren't obscure vendors — they're products millions of businesses use daily, and many customers didn't realize what they'd agreed to.

The implication for property managers: a leasing tool that touches applicant SSNs, bank details, and ID documents must contractually exclude that data from any model training. "We don't do that" isn't enough. Make them state it in writing — in the service agreement, not buried in a settings toggle.

And ask a follow-on: who are the vendor's underlying AI providers, and what do their commercial terms say? A well-designed AI leasing product builds on enterprise APIs that already carry no-training protections. A vendor who can't name their providers — or who isn't sure what their providers' terms say about training — is telling you something about how carefully they've thought through this.

What a passing answer sounds like: "We do not train any AI models on your or your applicants' data — it's contractually excluded, and our AI providers' commercial terms enforce no-training protections too."

Is my data encrypted in transit and at rest?

This is table stakes. Any vendor that can't answer this in one sentence is a red flag. The standard is TLS in transit (data moving between your browser, your PMS, and the tool) and AES-256 at rest (data sitting in their database). These aren't advanced measures — they're the floor. If a vendor hesitates, hedges, or gives you a vague "we take security seriously," move on.

One nuance worth understanding: some vendors encrypt data in transit but apply weaker protections at rest, or use encryption inconsistently across different data types. Ask whether encryption applies to all data — including backups, logs, and the specific high-sensitivity fields like SSN and bank account numbers — not just to primary application data.

What a passing answer sounds like: "All data is encrypted in transit with TLS and at rest with AES-256 — standard, no exceptions, across all data types including backups."

Who on the vendor's side can actually see my tenant data?

The threat isn't only outside attackers — it's who inside the vendor can open a record. This is the most-overlooked risk in vendor security evaluations. Ask specifically about role-based access controls (RBAC), least-privilege access (employees get the minimum access necessary to do their job, not blanket access to all customer data), and employee-access logging (every record view is recorded with a timestamp and identity).

A vendor with no internal-access controls is essentially trusting every employee — current and future — with your applicants' financial and identity data. That trust should be contractual and audited, not assumed.

What a passing answer sounds like: "Access is role-based and least-privilege; almost no one can see raw applicant data, and every access event is logged and reviewable."

Where is my data hosted, and is it isolated from other customers?

Two distinct questions worth separating. First, hosting region: where your data physically lives matters — particularly for Canadian property managers operating under stricter provincial privacy laws that govern where personal data can be stored and processed. Ask any vendor whether they offer Canadian data residency or whether all data flows through US-based infrastructure. Second, tenant isolation: confirm that your applicant data is logically partitioned so one customer's records can never be accessed through another's account.

These aren't hypothetical concerns. Multi-tenant systems with poor isolation have produced real cross-customer data exposures. The question is simple; the passing answer is short.

What a passing answer sounds like: "Hosted on a major cloud provider, with logical isolation per customer; Canadian data can be region-restricted on request."

What happens to applicant SSNs, bank details, and ID documents specifically?

General "we're secure" language isn't enough for the highest-value data your leasing process touches. Ask specifically about three things: retention (how long is SSN and bank data kept after a tenancy decision?), masking (is the SSN displayed and stored in masked form — e.g., ***-**-1234 — rather than plain text?), and deletion on request (can an applicant's data be purged if they ask?).

This matters beyond compliance. It's the same hesitation that makes applicants abandon self-showing flows when they're unexpectedly asked for a social security number. How a vendor handles this data isn't just a security question — it's a direct factor in whether applicants trust your process enough to complete it.

What a passing answer sounds like: "SSNs and bank details are masked in our system, retained only as long as legally required, and permanently deleted on request."

How does the tool's data flow when it syncs with my PMS?

Know exactly what the sync reads — and how your PMS credentials are stored. When an AI leasing tool syncs your properties, it's pulling your listings and availability data into the leasing flow. The right questions: What's the read scope of the sync? Are your PMS credentials stored encrypted, or in plain text? Is the sync connection audited?

Credentials to your PMS are high-value targets — they're the keys to your property management data. A vendor who stores them in plain text, or can't explain how they're protected, introduces a risk that goes well beyond the leasing tool itself.

What a passing answer sounds like: "We sync your property and listing data in, over an encrypted connection, with PMS credentials stored encrypted — the connection is read-scoped and audited."

Has it passed an independent SOC 2 Type II audit?

SOC 2 Type II is the gold standard for SaaS security verification — and the distinction between Type I and Type II matters. Both are built on the AICPA Trust Services Criteria (covering security, availability, processing integrity, confidentiality, and privacy). But Type I only confirms that controls were designed well at a single point in time. Type II confirms they actually operated effectively over a 6–12 month period — a fundamentally harder bar to clear, and the one that gives you meaningful assurance.

A vendor with only Type I has passed a design review. A vendor with Type II has been watched. Ask for Type II, and ask whether they can share the report under NDA. Vendors who've earned it will say yes.

What a passing answer sounds like: "We hold a SOC 2 Type II report and can share it under NDA."

Does it run regular penetration testing?

Documentation and audits confirm what was built. Penetration testing confirms it holds up under active attack. A pen test means an external security team is actively trying to break into the vendor's systems — finding vulnerabilities before a real attacker does. Ask how often they run them (at least annually is the minimum), and whether they'll share a summary of findings and their remediation timeline.

A vendor who runs pen tests and remediates findings on a tracked schedule is treating security as an operational practice. One who can't answer the question is treating it as a marketing checkbox.

What a passing answer sounds like: "We run third-party penetration tests at least annually and remediate all findings on a documented and tracked timeline."

Will it sign a Data Processing Agreement — and how does it handle breach notification and sub-processors?

Everything above is talk until it's in a contract. A Data Processing Agreement (DPA) is the legal instrument that binds a vendor as your data processor and makes their commitments enforceable. Three things to confirm in any DPA: (1) the vendor will actually sign one — not all will, which is itself a red flag; (2) a breach-notification commitment with a defined window (GDPR requires 72 hours; CASL applies differently — know what your applicable law requires and hold vendors to it); (3) a disclosed sub-processor list — the third parties the vendor shares your data with — and a commitment to notify you when it changes.

Sub-processors matter because your data doesn't stay only with the vendor you contracted. It flows to their cloud provider, their analytics tools, their support platforms. A DPA that names sub-processors gives you visibility into that chain. If a vendor adds a new sub-processor without notice, your applicants' data is moving somewhere you didn't agree to — and that's both a compliance and a trust problem.

For Canadian property managers, a DPA is especially important: it should address applicable provincial privacy laws (PIPEDA / provincial equivalents) and specify breach-notification obligations that meet Canadian standards. Don't accept a US-only DPA template if you operate in Canada.

What a passing answer sounds like: "Yes, we'll sign a DPA. We notify you of any breach within a defined window (e.g. 72 hours), maintain a current sub-processor list, and notify you before adding new sub-processors — and our DPA covers applicable Canadian privacy requirements."

The 9-question vendor-security scorecard

Print this and bring it to any vendor call. A vendor worth trusting answers every row without flinching.

Frequently Asked Questions

Is it safe to connect an AI leasing tool to my PMS?

Yes, if the vendor can pass the nine questions above. "Safe" is something you verify through their answers, not something you assume from their marketing.

Does AI leasing software train on my tenant data?

Reputable vendors don't, but a no-training stance isn't automatic — make the vendor state it in writing and confirm their AI providers' commercial terms enforce it too.

What is SOC 2 Type II and why does it matter?

An independent audit confirming a vendor's security controls operated effectively over 6–12 months — stronger than a self-assessment or a point-in-time Type I snapshot, and the standard you should ask for.

How should applicant SSNs and bank details be protected?

Encrypted in transit and at rest, displayed and stored in masked form, retained only as long as legally required, and permanently deletable on request.

What's the difference between encryption in transit and at rest?

In transit protects data while it moves between systems (TLS); at rest protects it while it's stored in the vendor's database (AES-256). Both are required — not either/or.

What is a Data Processing Agreement (DPA)?

The contract that makes a vendor's data-handling commitments legally enforceable, names their sub-processors, and specifies breach-notification timelines — the document that turns verbal promises into obligations.

Does a leasing tool's PMS sync expose my data?

A well-built sync pulls your property and listing data over an encrypted connection, with PMS credentials stored encrypted and a scoped read-only connection — ask specifically about each of these.

Is data security different for Canadian property managers?

It can be — Canadian privacy law is stricter on where personal data is stored and processed, so ask specifically about data residency and whether the vendor offers Canadian-region hosting.

The vendors worth trusting are the ones who answer all nine without flinching — and who treat your applicants' data as the trust asset it is. Want to see how LetHub answers all nine? Book a demo.