01
Infrastructure & Encryption
✓ 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.
02
Access Control & Authentication
✓ 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 and IP address. Five failures within a rolling 10-minute window temporarily block additional attempts from that identifier until the window clears. Authentication events are logged for review and abuse detection.
✓ Session management
Sessions expire after 14 days of inactivity with rolling refresh. Session tokens are long, high-entropy random values, transmitted only over TLS and stored in our access-controlled application database, which is encrypted at rest by our managed infrastructure. Admin access requires Google OAuth with an explicit email allowlist.
✓ API action allowlists
Sensitive API surfaces use endpoint-appropriate controls, including session tokens, admin OAuth allowlists, signed action tokens, webhook or cron secrets, rate limits, and action allowlists where applicable. Legacy exceptions are tracked in the security hardening register and remediated in scoped releases.
✓ Password hashing
Passwords are stored using one-way cryptographic hashing, never in plaintext, and are never written to disk or logs in readable form.
✓ 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.
03
Monitoring & Audit Trail
✓ 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
Key broker, authentication, and security actions are recorded with timestamps across event and security-log tables, including login attempts, emails sent, client status changes, PDF generations, and selected settings changes. A unified audit trail is part of the ongoing hardening roadmap.
✓ 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
Our domains serve security headers including X-Content-Type-Options: nosniff (MIME sniffing prevention), Strict-Transport-Security (HTTPS enforcement), and X-Frame-Options (clickjacking prevention; set to DENY or SAMEORIGIN depending on the surface). Content Security Policy headers are applied on portals handling sensitive data.
04
Backup & Recovery
✓ Managed database backups
The database runs on Supabase's managed infrastructure, which provides backup and recovery capabilities. Restore procedures and evidence are maintained internally and are reviewed as part of security readiness.
✓ Application rollback
Application deployments are versioned on Vercel, allowing a prior application version to be restored when needed. An application rollback changes deployed code; it does not itself restore or alter database records. Recovery timing depends on the incident and the recovery procedure required.
✓ Nightly data rebuild
Certain derived mortgage-opportunity data is recomputed from source records on scheduled runs. Failed runs are designed to preserve prior records and surface an operational alert. Database restoration is a separate managed recovery process and is not guaranteed to be automatic.
05
Internal Access Controls
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 managed infrastructure. Vercel hosts application code and runtime functions. Stripe handles payments in isolation. AI providers process only the prompts, documents, or context needed for requested AI features.
✓ 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.
06
Canadian Privacy Compliance
| 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), 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. Provider assurance materials are reviewed where available and appropriate to the service used.
07
Subprocessors
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
Amazon Web Services
Underlying cloud infrastructure used by Supabase
Vercel
Application hosting, edge functions, CDN
Stripe
Subscription billing and payment processing
Resend
Transactional, service, and broker-authorized email
OpenAI
AI-assisted features and text processing where enabled
Google
Workspace, Gmail, Apps Script, Sheets, and related operations
Microsoft
Identity and Microsoft Graph email integrations
Zoom
Meeting registration and related event workflows
Anthropic
AI features, document parsing, assistant tools
AssemblyAI
Audio transcription where enabled
Railway
Rate Scout extraction service hosting
08
Incident Response
A documented Incident Response Plan and breach register process 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 without unreasonable delay 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 records are maintained for minimum 24 months where required by PIPEDA s.10.3. Affected brokers updated on resolution.
09
Data Handling
✓ Data minimization
We process only the data needed for the enabled service. This may include client identity and contact information, mortgage details, property information, and qualification inputs such as income, debts, liabilities, and credit score where provided. The Service is not designed to collect social insurance numbers, banking credentials, income verification documents, or government-issued identification, and brokers must not upload them.
✓ 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.
10
HTTP Security Headers
Security headers commonly served across RateGuard Pro domains include:
X-Frame-Options
DENY or SAMEORIGIN depending on the surface - prevents clickjacking by restricting iframe embedding
X-Content-Type-Options
nosniff - prevents MIME-type sniffing attacks
Strict-Transport-Security
Enforced via Vercel - all traffic over HTTPS
Referrer-Policy
Enforced via Vercel defaults
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 or aggregate it across brokerages. After cancellation, deletion is handled through a documented internal process with a 90-day operational target, not a guaranteed deadline, subject to legal retention, security, operational requirements, and ordinary backup expiry.
Security Contact
Privacy Officer
jeff@rateguardpro.ca
For privacy inquiries, data access requests, or to report a security concern.