Security at Estaio

Real estate runs on trust. Agents trust us with the data they use to serve their clients, and clients trust the share pages their agent sends them. Security at Estaio isn't a checklist — it's a continuous practice that shapes how we design products, write code, run infrastructure, and hire people.

This document describes the controls we have in place today. It is intentionally specific where helpful and intentionally generic about implementation details whose disclosure would weaken the very protections we're describing. For a deeper look — including a current sub-processor list, a penetration-test summary, or a copy of our Data Processing Addendum — contact security@estaio.com.

We operate under a defense-in-depth model: multiple overlapping controls so that the failure of any single layer does not result in unauthorized access to customer data.

In transit

All connections between your browser or device and the Service are encrypted using TLS 1.2 or higher with modern cipher suites. We disable known-weak protocols, enforce HSTS, and renew our certificates automatically.

At rest

Customer data stored in our primary databases and object stores is encrypted at rest using industry-standard symmetric encryption (AES-256 or equivalent). Encryption keys are managed by a managed key-management service and are rotated on a regular schedule. Production keys are accessible only to a small set of automated services and are not held by any individual.

Backups

Backups are encrypted using the same standards as primary storage and are stored in a separate failure domain. Backup encryption keys are distinct from primary-database keys to prevent a single compromise from affecting both.

Secrets

API keys, credentials, and other secrets are stored in a centralized secret manager with strict access controls. Secrets are not committed to source-code repositories; automated scanning blocks accidental commits and rotates credentials when a leak is suspected.

User authentication

We support email + password authentication with strong password requirements, brute-force throttling, and account-lockout protection. Passwords are stored as salted hashes using a modern adaptive hashing algorithm; we never see or store plaintext passwords.

Multi-factor authentication is offered to every Account and is required for accounts with elevated privileges (such as Brokerage Administrators). Where supported, you can use authenticator apps, hardware security keys, or platform biometrics.

Single sign-on (SSO)

Brokerages on eligible plans can enable SSO via SAML 2.0 or OIDC for centralized identity management, automatic deprovisioning, and enforcement of corporate password and MFA policies.

Session management

Sessions expire after a defined period of inactivity. You can view and revoke active sessions from your Account settings, and we revoke sessions automatically following a password change, MFA reset, or detected security event.

Internal access

Employee access to production systems is granted on a least-privilege, just-in-time basis. Privileged actions are logged, peer-reviewed where applicable, and reviewed periodically. We do not access customer data except as necessary to operate, secure, support, or improve the Service, and where required, we obtain customer authorization or use de-identified data.

Hosting

The Service is hosted by leading cloud infrastructure providers operating from facilities certified under recognized industry standards (such as SOC 2, ISO 27001, ISO 27017/27018, and PCI DSS where applicable). The physical security of those facilities — including 24/7 staffing, biometric access, video surveillance, and environmental controls — is the responsibility of the underlying provider and is regularly audited.

Network architecture

Production workloads run in isolated virtual networks with strict ingress and egress rules. Resources that do not need public exposure are not exposed to the public internet. Internal traffic is encrypted, and identity-based service authentication restricts which services can talk to which.

DDoS protection and WAF

Public endpoints are protected by an upstream content delivery network and DDoS mitigation. A web application firewall is enabled with rule sets that block well-known web attacks (such as SQL injection and cross-site scripting attempts) and rate-limit abusive traffic.

Hardened images and patching

Operating-system images, container base images, and runtime dependencies are continuously scanned for vulnerabilities and rebuilt regularly. Critical patches are deployed under our documented vulnerability-management timelines.

Secure development lifecycle

Security is integrated into our development lifecycle from design through deployment. Changes to the Service follow a documented engineering process that includes design review for sensitive areas, peer code review for every production change, and automated testing.

Automated scanning

We run automated security checks on every change before it can be deployed, including:

• Static analysis (SAST) for common application security flaws;
• Software composition analysis (SCA) to detect vulnerable dependencies and license issues;
• Secret scanning to block accidental credential commits;
• Container image scanning to detect known vulnerabilities in base layers; and
• Dynamic analysis (DAST) on staging environments for runtime vulnerabilities.

Tenant isolation

The Service is multi-tenant. Tenant boundaries are enforced at the data layer through row-level isolation, application policies, and service-level access controls. Internal audits and automated tests verify that no request issued in one tenant's context can return data belonging to another tenant.

Penetration testing

We engage independent third parties to perform application and network penetration tests on a periodic basis (at minimum annually) and after significant architectural changes. High-severity findings are tracked to remediation and verified in a follow-up test or attestation. A summary of the most recent test is available under NDA on request.

We maintain a documented vulnerability-management program with internal service-level objectives based on severity:

• Critical vulnerabilities — remediated or mitigated as soon as possible, typically within hours of confirmed validation;
• High — within 7 days;
• Medium — within 30 days;
• Low / informational — addressed during routine maintenance.

Severity is determined using the Common Vulnerability Scoring System (CVSS) and adjusted for our environment. Where the underlying issue lies with an upstream dependency that has not yet released a fix, we apply compensating controls until a patched version is available.

We centrally collect security-relevant events from our infrastructure, applications, and identity provider. Logs are stored in tamper-evident storage with retention tuned to legal, forensic, and operational needs.

Automated detections raise alerts for known abuse patterns, credential-stuffing attempts, unusual privileged actions, anomalous access to customer data, and other indicators of compromise. Critical alerts page on-call engineers around the clock.

We maintain a documented incident-response plan covering detection, triage, containment, eradication, recovery, and post-incident review. The plan is tested regularly through tabletop exercises and is updated based on lessons learned.

Customer notification

If we determine that a security incident has resulted in the unauthorized acquisition, use, or disclosure of personal information about you or your Clients, we will notify affected customers as required by applicable law and within the contractual timeframes set out in our Data Processing Addendum. Where notification is required, we will provide information about what happened, what data was affected, what we are doing in response, and what affected individuals can do.

Forensics and root cause

For significant incidents we perform a structured root-cause analysis and produce an internal report. Where appropriate, we share a public or customer-facing summary describing the impact and the corrective actions taken.

Production data is backed up on a regular schedule. Backups are encrypted, integrity-checked, stored in a separate failure domain from the primary, and tested through periodic restore drills. We maintain documented Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for the Service, which are reviewed at least annually.

Our disaster-recovery plan covers a range of failure scenarios — including provider outages, regional unavailability, and data corruption — and is exercised at least once per year.

Customer data is logically segregated at the application layer. Each request is bound to an authenticated tenant identity, and our data-access libraries refuse to issue queries without a tenant scope. Internal tests run continuously to detect any regressions in tenant isolation.

Customer data is primarily stored in the United States. Certain operational metadata (such as observability traces or aggregated metrics) may be processed in other jurisdictions by our service providers under contracts that include the appropriate transfer safeguards.

We use a small set of carefully selected sub-processors to deliver the Service. Each sub-processor is reviewed for security and privacy posture before it is engaged and at regular intervals afterward, and each is bound by a written agreement that includes confidentiality and data-protection obligations.

Categories of sub-processors include cloud infrastructure hosting, transactional email delivery, error and performance monitoring, payment processing, customer-support tooling, and AI model providers. A current, named list of sub-processors — along with notice of material changes — is available to customers under NDA via security@estaio.com.

We require sub-processors to implement security controls that are at least as protective as those described in this document, and we exit relationships with sub-processors that do not maintain those standards.

Our personnel are the last line of defense for everything described above. We maintain the following controls for employees and long-term contractors:

• Background checks on relevant personnel prior to access to production systems, where permitted by local law;
• Security training at onboarding and annually thereafter, with role-specific training for engineers, support, and people-managers;
• Confidentiality agreements binding every employee and contractor;
• Acceptable-use, device, and remote-work policies covering encryption, password managers, screen locks, and approved software;
• Principle of least privilege for all internal access, with quarterly access reviews;
• Off-boarding processes that revoke access on the same business day as a separation event.

Devices used by personnel to access production systems are managed and hardened. Controls include full-disk encryption, screen-lock enforcement, automatic patching, endpoint detection and response (EDR), and centralized device inventory. Lost or stolen devices are remotely wiped of any managed data.

AI features in the Service rely on third-party AI service providers operating under written agreements. Those agreements require providers to (a) restrict use of customer inputs and outputs to delivering the requested operation, (b) prohibit use of customer data to train general models for the benefit of third parties, (c) implement commercially reasonable security controls, and (d) limit retention to what is needed to deliver the feature.

We do not transmit Listing Data or Client information to AI providers beyond what is necessary to deliver the specific feature you invoked. Where feasible, we apply minimization, redaction, or summarization techniques before routing data to an AI provider.

We design the Service to align with widely recognized security and privacy standards. Where our customers operate in regulated environments, we provide the documentation needed to help them meet their own compliance obligations.

Current compliance status, third-party attestations, and any relevant audit reports are made available to customers under NDA on request to security@estaio.com. We pursue formal certifications on a roadmap appropriate to the size and maturity of the Service.

Cloud security is a shared responsibility. We are responsible for the security of the Service. You are responsible for how you use it. To help us help you, we ask that you:

• Use a strong, unique password and enable multi-factor authentication;
• Keep your device, browser, and operating system up to date;
• Use the Service only on devices that you trust and that comply with your brokerage's security policies;
• Treat share-page links and Client invitation tokens as sensitive — do not post them in public channels;
• Use SSO for centrally managed brokerages where available;
• Revoke departing team members' access promptly;
• Report suspicious activity or suspected compromise to security@estaio.com as soon as you become aware of it; and
• Comply with all applicable laws, MLS rules, and brokerage policies in how you use the Service and the data within it.

We welcome reports from security researchers. If you believe you have found a security vulnerability in the Service, please report it to security@estaio.com with as much detail as possible, including reproduction steps, impacted endpoints, and your contact information.

Safe-harbor commitment

We commit not to pursue legal action against researchers who:

• Make a good-faith effort to comply with this policy;
• Limit testing to accounts they own or have explicit permission to test;
• Do not access, modify, or destroy data belonging to other users;
• Do not perform denial-of-service or social-engineering attacks against Estaio personnel or customers; and
• Give us a reasonable opportunity to investigate and remedy the issue before publicly disclosing it.

We will acknowledge receipt of your report within a small number of business days, keep you informed about our investigation, and credit researchers (where you wish to be credited) for valid reports.

We do not currently operate a public bug bounty program. We may, at our discretion, recognize valid, novel reports with a swag, a public acknowledgment, or — for material issues — a financial reward. As the program matures we may launch a formal bounty with published scope and reward levels.

Security is a moving target. We will update this document as our controls evolve. Material changes will be reflected in the “Last updated” date at the top of this page. For substantive changes that affect customers (for example, changes to sub-processors that meaningfully alter the geography of data processing), we will notify customers as required by their contract.

For general security inquiries, customer security documentation requests, or to report a vulnerability, email security@estaio.com.

For privacy-specific questions, see our Privacy Policy and contact privacy@estaio.com.