Information Security Policy

1. Purpose and scope

This policy exists to protect the information that law firms and their clients entrust to RealEstAi, and to tell customers plainly how we do it. It covers the RealEstAi platform: the web application at realestai.ca, its database, document storage, scheduled jobs and deployment pipeline; the cloud and source-control accounts that run it; and every person with access to any of these. A customer firm’s own devices, network, email and accounting systems remain the firm’s responsibility, as do the firm’s professional obligations to its clients and to the Law Society of Alberta.

2. Roles

3. Hosting

The platform runs in Microsoft Azure, Canada Central. The web application runs on Azure App Service, the database on Azure Database for PostgreSQL, and every uploaded or generated document sits in a private Azure Storage container that is never exposed to the public internet. Azure’s certifications cover Microsoft’s responsibilities: the data centres, the disk encryption and the managed database service. The controls in this policy are RealEstAi’s own, applied on top.

4. Access control

• Accounts are created by invitation. A firm administrator invites each team member and fixes their role and firm. Nobody can change their own role, firm or status, and no request from a browser can set them. Clients, realtors and brokers may register themselves, start in a pending state, belong to no firm and see nothing until a firm links them to a matter.
• Access follows firm membership. Every staff role in a firm (lawyer, firm administrator, articling student, conveyancer, trust administrator, assistant) works on all of that firm’s matters. Narrower checks apply to firm administration, to actions only a lawyer may take under Law Society rules (authorizing a release of trust funds, giving undertakings, signing the final report to the lender) and to trust-ledger entries.
• One check on every request. Access to a matter is decided by one shared check that confirms the signed-in user is active, that their firm is in good standing, and that they are the matter’s owner, staff of the firm that owns it, or a party the firm has linked to it. A file that is not yours answers “not found”, as if it did not exist. A deactivated user or a suspended firm is refused immediately wherever that check runs, and within five minutes everywhere else.
• External parties see only the document categories a firm has sent them, and can edit only where the firm allows it.
• Documents are served through the application, or through a download link limited to one document, read-only, valid for one hour.
• RealEstAi support access is read-only and recorded. Every access to a customer matter by RealEstAi personnel, including a refused attempt to change something, is written to the audit log. There is no “log in as the customer” feature. A firm can be given the record of support access to its matters on request.

5. Sign-in

• Passwords must be at least eight characters with upper case, lower case, a digit and a symbol, checked on the server wherever a password is set. They are stored only as a bcrypt hash.
• Lockout. Five wrong passwords lock the account for 30 minutes. Repeated failures from one network address are refused for a period, whichever account they target.
• Second factor. A six-digit single-use code is sent to the person’s email at sign-in. It is always required for administrator accounts. A firm administrator can require it for every member of the firm’s team with one setting (Admin, Team, Sign-in security); the change is audited. Codes expire after ten minutes, allow five attempts, are stored hashed and are limited to five per fifteen minutes.
• Sessions end after seven days without activity. “Remember me” extends this to 30 days for administrators and 365 days for other staff. Each user’s status, firm and role are re-checked against the database during a session. Session cookies are HttpOnly, Secure and SameSite.
• Password reset links are random, single-use, stored hashed and expire after one hour.
• Because the code and the reset link are delivered by email, firms should protect their own mailboxes with multi-factor sign-in.

6. Encryption

• In transit. The application is served over HTTPS only and sends a two-year HSTS header, so a browser that has visited once refuses plain HTTP afterwards. The connection to the database is encrypted. Calls to every provider are made over HTTPS.
• At rest, on disk. Azure Storage and Azure Database for PostgreSQL encrypt all data on disk with AES-256 and Microsoft-managed keys. Automatic database backups are encrypted the same way.
• At rest, inside the application. Before saving, the application encrypts with AES-256-GCM: clients’ government-ID numbers and dates of birth; a firm’s Alberta Land Titles and City of Calgary credentials; and the tokens for a lawyer’s connected mailbox, calendar or meeting account. Each stored value carries a key identifier so keys can be rotated without loss.
• Hashed, never stored in the clear: user passwords (bcrypt), one-time sign-in codes, password-reset tokens, and the network addresses recorded by analytics.
• Keys and secrets are held in the hosting platform’s protected application settings and in a separate deployment environment for production. They are never in source code; secret scanning runs on the repository and any alert is treated as a leak and rotated.

7. Logging and monitoring

• Audit log. Sign-ins (success, failure, lockout, second-factor result), user and role administration, the firm-wide sign-in setting, trust-ledger activity, funds release, document downloads, deletions, privacy-request reports and RealEstAi support access are recorded with who, what and when, and with the network address and device where the action carries them. Audit records are never edited or deleted by the application. A firm administrator can view their own firm’s records in the product.
• Trust ledger. Every change writes its audit record inside the same database transaction as the change. A ledger change without an audit record cannot happen through the application, and corrections are new entries rather than edits.
• Downloads are logged with the user, network address, device, document and matter.
• Monitoring. Request metrics and tracing across the platform, grouped error tracking, and uptime checks every five minutes.
• Detection. Six automated detectors run hourly: repeated failed sign-ins on one account, failed sign-ins across many accounts, spikes in refused requests, one account signing in from several addresses, sign-in from a new address, and unusually fast document activity. Critical alerts are emailed to a monitored mailbox.
• Log retention. Request metrics are kept 90 days and analytics events 180 days. Audit records are kept for the life of the record they describe and are not deleted.

8. Secure development and change management

• Every change is tested end to end on a local build against a local database before it is committed. A change to access control is tested with users from two different firms.
• Deployment is automated. Every commit builds and deploys to a non-production environment first; production is deployed only by a deliberate promotion. Production secrets are held in a separate, protected deployment environment, and every deployment records the commit and who deployed it.
• A database change that would destroy data fails the deployment instead of applying. Before every production release the schema is compared against production and the release stops if anything but the expected additive change appears.
• All database access goes through an object-relational mapper with parameterized queries. Inbound webhooks and scheduled jobs authenticate with signatures or secrets and refuse the request when the secret is missing. Outbound calls to firm-configured endpoints are checked against private and cloud-metadata addresses. Standard security headers are set: content security policy, HSTS, frame, content-type, referrer and permissions policies.
• Dependencies are pinned and installed from a lock file. Security advisories are tracked and patched; two library defects reachable from uploaded files were patched in September 2026.
• A structured internal security assessment of the whole platform was carried out in August 2026 and re-checked in September 2026; the defects it identified were fixed and the fixes confirmed in code.

9. Providers

Every provider that receives customer or personal information is published, with its country of processing and its purpose, in the register in our Privacy Policy. A provider is listed when the integration exists in the code and removed when it is removed. The Sub-processors and Vendors page explains what we require of each.

10. Data retention

Customer matters are kept for ten years from the date the file was created, which is also the minimum period for which a law firm must keep its prescribed financial records under Law Society of Alberta Rule 119.35. Deleting a matter archives it: it disappears from every ordinary screen, and it is held, with its documents, until the retention date. Nobody, neither the firm nor RealEstAi, can override the hold. The Data Handling and Retention page has the detail.

11. Personnel

Everyone who operates the platform is bound by the Personnel and Acceptable Use Policy: personal accounts with multi-factor sign-in, encrypted devices, no secrets outside the approved stores, read-only support access to customer matters, and no customer data in personal tools.

12. Incidents

The Incident Response Policy sets out severity tiers, how an incident is contained and investigated, and how affected firms, regulators and individuals are told. The affected firm always hears from us first.

13. Standards

The controls above are mapped to the CIS Controls v8.1 (Implementation Group 1), the NIST Cybersecurity Framework 2.0 and the Cloud Security Alliance Cloud Controls Matrix v4.1. The mapping and the completed workbooks are available to customers on request.

14. Exceptions and review

An exception to this policy is approved in writing by the Security Lead and recorded with the reason, any compensating measure and an expiry date. The policy is reviewed on a regular cadence, after any significant incident, and after any material change to the platform or its hosting; each review re-checks every statement against the code.

15. Reporting a concern

Report a suspected weakness to contactus@realestai.ca. We acknowledge every report and work with the reporter to confirm and fix the issue.