Scoped
Broker Data Access
Encrypted
Encryption at Rest
ca-central-1
Data Residency
✓ Encryption at rest
Production database storage and backups are encrypted through Supabase's managed infrastructure. Connections to the database use SSL/TLS.
✓ Encryption in transit
Application traffic is served over HTTPS. HTTP requests are redirected to HTTPS on production domains we control.
✓ Canadian data residency
Primary database hosting is in Canada where supported by our database provider. Application hosting, email, analytics, and support services may process or transit data in other jurisdictions as described in our Privacy Policy and subprocessors list.
✓ Database isolation
Database access is restricted to authenticated connections through Supabase's connection pooler with SSL enforcement. Direct database connections are not used by the application. API keys are scoped per service and rotated periodically.
✓ Row-Level Security (RLS)
Broker-facing data access is scoped by broker identity at the API and database layers. We use row-level security where applicable, plus explicit ownership checks in service-role routes that require elevated database access.
✓ Brute force protection
Failed login attempts are tracked per email address. Five failures within a 10-minute window triggers a 30-minute account lockout. Ten or more failures triggers a real-time alert to the platform administrator.
✓ Session management
Sessions expire after 14 days of inactivity with rolling refresh. Session tokens are SHA-256 hashed before storage. Admin access requires Google OAuth with an explicit email allowlist.
✓ API action allowlists
Every API proxy maintains a hardcoded allowlist of permitted actions. Requests for unlisted actions are rejected with 403. Each portal (broker, admin, upload, client-facing) has its own scoped allowlist.
✓ Password hashing
Passwords are hashed with SHA-256 before storage. Plaintext passwords are never written to disk or logs.
✓ First-login terms gate
Brokers must read and acknowledge the Terms of Service and professional obligations before accessing the platform. Acknowledgment is recorded with a timestamp. The platform is inaccessible until this step is completed.
✓ Login attempt logging
Every login attempt (successful and failed) is logged with email address, IP address, and timestamp. Stored in a dedicated table with admin-only access. Used for brute force detection and post-incident investigation.
✓ Broker action history
All significant broker actions are recorded with timestamps: emails sent, client status changes, PDF generations, data exports, settings changes. This audit trail is per-broker and retained for the duration of the subscription.
✓ Automated system alerts
Automated monitoring sends email alerts for: failed nightly data rebuilds, stale data sync (>24h), failed Finmo API sync, login brute force attempts, and infrastructure errors. Alerts include diagnostic context for rapid triage.
✓ Security headers
All domains serve X-Frame-Options: DENY (clickjacking prevention), X-Content-Type-Options: nosniff (MIME sniffing prevention), and Strict-Transport-Security headers. Content Security Policy headers are applied on portals handling sensitive data.
✓ Daily automated backups
Supabase performs daily automated database backups with point-in-time recovery (PITR). Backups are encrypted and stored in the same AWS ca-central-1 region. Retention period is 7 days on the current plan.
✓ Application rollback
All application deployments are immutable and versioned on Vercel. Any deployment can be rolled back to a previous version within minutes via the Vercel dashboard. No data loss on application rollback.
✓ Nightly data rebuild
Mortgage opportunity data is rebuilt nightly from source records. If a rebuild fails, an automated alert is sent within minutes. The previous day's data remains intact and accessible. This means even in a worst-case data corruption scenario, recovery to the previous day's state is automatic.
RateGuard Pro is a small team. Internal access follows the principle of least privilege relative to team size.
✓ Admin access
Administrative access to broker data is restricted to authorized personnel via Google OAuth with an explicit email allowlist. There is no shared admin password. Admin sessions are separate from broker sessions.
✓ Team member scoping
Brokers can add team members to their own account. Team members authenticate with their own credentials and can only access the data belonging to their brokerage. They cannot access other brokers' data or admin functions.
✓ Vendor access
No vendor has standing access to production data. Supabase provides infrastructure, not data access. Vercel hosts application code only. Stripe handles payments in isolation. OpenAI processes only opt-in queries, never bulk data.
✓ Code deployment
All code is version-controlled in a private GitHub repository. Deployments go through Vercel's build pipeline. Production changes are committed, reviewed, and deployed through a documented process.
| Legislation |
Scope |
Key Requirements Addressed |
Status |
| PIPEDA |
Federal privacy law governing commercial use of personal information |
10 Fair Information Principles, mandatory breach notification (s.10.1), breach register maintained 24 months (s.10.3), third-party processor accountability (s.4.1.3) |
✓ Addressed |
| CASL |
Canada's Anti-Spam Legislation |
All commercial emails include unsubscribe mechanism (s.6(2)(c)), unsubscribe processed within 10 business days (s.11(1)), sender identification in every message, consent responsibility documented |
✓ Addressed |
| Quebec Law 25 |
Provincial privacy law (Bill 64), strictest in Canada |
Confidentiality by default (s.9.1), privacy impact assessments (s.3.3), data portability on request (s.27), incident register (s.3.5), Commission d'acces a l'information complaint path documented |
✓ Addressed |
Note: RateGuard Pro does not hold a SOC 2 certification. Our subprocessors (Supabase, Vercel, Stripe) do. A formal SOC 2 engagement is on the roadmap as the platform scales.
The following third-party services process data on behalf of RateGuard Pro. Each has been evaluated for security posture and data handling practices. A standalone register is maintained at /subprocessors.
Supabase
Database, authentication, file storage
DPA signed March 2026
SOC 2
CA Region
DPA
Vercel
Application hosting, edge functions, CDN
DPA via standard terms (automatic)
SOC 2
DPA
Stripe
Subscription billing and payment processing
DPA via standard terms (automatic)
PCI DSS L1
SOC 2
DPA
Resend
Transactional and campaign email delivery
DPA via standard terms
SOC 2
DPA
OpenAI
AI assistant (opt-in, broker portal only)
Zero data retention API, DPA via terms
SOC 2
DPA
Google Cloud Platform
Vision OCR for rate sheet extraction
DPA via Google Cloud terms
SOC 2
ISO 27001
DPA
A documented Incident Response Plan and a PIPEDA-compliant breach register are maintained. In the event of a breach involving personal information:
Immediately
Containment begins. Platform administrator notified. Breach register entry created with timestamp, affected systems, data categories involved, and estimated scope.
Within 72 hours
Affected brokers notified with a plain-language description of the incident, what data was involved, what actions we are taking, and recommended steps for the broker and their clients.
As required by PIPEDA s.10.1
Office of the Privacy Commissioner of Canada (OPC) notified if the breach creates a real risk of significant harm. Commission d'acces a l'information (CAI) notified for Quebec-resident data.
Post-incident
Root cause analysis conducted. Preventive measures documented and implemented. Breach register maintained for minimum 24 months per PIPEDA s.10.3. Affected brokers updated on resolution.
✓ Data minimization
We process only the mortgage data necessary to deliver the service: client names, contact information, mortgage balances, rates, terms, and maturity dates. We do not collect social insurance numbers, banking credentials, credit scores, or income verification documents.
✓ No data monetization
Client data is never sold, licensed, or shared with third parties for marketing or analytics. Data is used solely to provide the services described in our agreement with each broker.
✓ Data portability & deletion
Brokers can request or export their dataset in standard formats. Upon cancellation, client data is targeted for deletion within 90 days, subject to legal retention, backup, security, and operational requirements. Deletion status can be confirmed in writing on request.
✓ Cryptographic link signing
Sensitive action links, including unsubscribe links and broker review actions, use signed tokens to prevent URL tampering. Some legacy client update links remain supported for existing users while we migrate them to newer signed or random-token flows.
✓ Email compliance (CASL)
All broker-to-client emails sent through the platform include: sender identification (broker name, brokerage, licence number), a working unsubscribe link processed within 10 business days, and broker contact information. Brokers are responsible for obtaining and documenting consent for their own client communications. The platform enforces unsubscribe requests at the system level.
The following security headers are served on all RateGuard Pro domains:
Broker Data Ownership
Your data belongs to you. RateGuard Pro acts as a data processor under PIPEDA s.4.1.3. Brokers remain the data controllers for all client information uploaded to the platform. We process data solely on your instructions and for the purposes outlined in our Data Processing Agreement. We do not use client data for our own purposes, aggregate it across brokerages, or retain it beyond the 90-day post-cancellation window.