Built to be
trusted with your SIN.

There are no servers of ours sitting online waiting to be broken into. Each request runs in its own short-lived, isolated process and disappears when it finishes — which removes a whole class of attack before it starts.

• No direct database access from the client. All database reads and writes go through authenticated server-side API routes. The database service-role key never leaves the server.
• Every API route verifies the session token before touching any data. Unauthenticated requests return 401.
• Users can only access their own data. Every query is scoped to the authenticated user's ID. There is no way to request another user's records.
• Admin routes are double-gated. Middleware checks the admin role claim, and each admin API route re-validates the role independently.
• Admins require MFA. Every admin account must have multi-factor authentication enabled (TOTP authenticator app). Admin routes that write data additionally verify the MFA claim is present in the session token — a stolen admin password alone cannot modify data.
• Lease documents use signed URLs that expire after 60 minutes. There is no permanent public URL for any lease file.
• Payment webhooks are signature-verified. We reject any webhook that doesn't include a valid provider signature to prevent spoofed payment events.

Five independent signals run on every payment we detect, before it can count toward a rent record. Anything they flag is rejected outright or held for a human reviewer.

• S1Category blacklist. Transactions categorized by the bank-data provider as mortgage, car loan, or student loan payments are auto-rejected — they cannot be reclassified as rent.
• S2Account-holder name collision. We compare the tenant-reported landlord name against the transaction counterparty name using Jaro-Winkler similarity. A high match (suggesting self-payment) flags for manual review.
• S3Matcher confidence floor. Any payment below our rent-matcher's confidence threshold is flagged, not reported, even if other signals are clean.
• S4New-tenant scrutiny. First three months of a tenant's payment history receive tighter thresholds; a clean track record relaxes them.
• S5Manual review queue. All flagged payments land in an admin adjudication surface with the full transaction category, counterparty name, match confidence, and historical context. Only a reviewer can promote them to "Reported" status. Payments rejected in review are never sent to the bureaus.

Every privileged action writes to one of two append-only audit tables. Neither table has a DELETE endpoint exposed — records can only be added.

• Automated daily backups of the primary database, retained 7 days.
• Migrations are version-controlled. Every schema change is written as idempotent, version-controlled SQL and applied through a reviewed process.
• Infrastructure as code. Application configuration and database migrations are version-controlled. A total-loss rebuild is measured in hours, not days.
• Stateless compute. Because serverless functions hold no state, a hosting outage redirects traffic automatically across edge regions with no data risk.

We maintain a written incident response plan covering detection, containment, eradication, recovery, and post-incident review. Key commitments:

• PIPEDA-aligned breach notification. In the event of a breach involving real risk of significant harm, affected individuals and the Office of the Privacy Commissioner of Canada are notified as soon as feasible — our internal target is within 72 hours of confirmation.
• Runbook-driven response. Incident categories (data exposure, credential compromise, vendor outage, fraud incident) have predefined response steps covering roles, escalation paths, and evidence preservation.
• Plan review cadence. Runbooks are reviewed and revised as our architecture evolves, with incident learnings folded back in after each event.
• Active-incident disclosure. Any incident materially affecting availability, data integrity, or user data is communicated directly to affected customers via the email on their account, in addition to any regulatory notifications required.

Security researchers are welcome. If you believe you've found a vulnerability in Elite Tenants:

1. Email security@elitetenants.com with details and reproduction steps.
2. Do not publicly disclose the issue until we've had a reasonable window to investigate (we target acknowledgement within 72 hours).
3. Do not access, modify, or exfiltrate data that isn't your own. Use your own test accounts.
4. No automated scanning against production (credential-stuffing lists, DDoS, etc.).

We don't currently run a paid bug bounty, but we publicly acknowledge valid reports with the reporter's consent.

Every third-party provider in our stack holds independent security certifications. We don't build what we can safely buy from a certified provider.