MakeMyMonth

Security Overview

Version 1.0 · Updated August 19, 2026
Master Subscription Agreement · Data Processing Addendum · Privacy Policy

This document describes how MakeMyMonth is built, what data it holds, and what controls protect it. It is written for the person at your dealership or dealer group who has to approve a new vendor. We have tried to be straightforward about what we do and do not have today.

1. The most important thing: we never touch your customer data

MakeMyMonth records how many ups, demos, write-ups, appointments, and sold units a salesperson had. It does not store any information about the people who buy cars from you. No buyer names, no addresses, no credit applications, no financing details, no deal jackets, no full VINs.

For a dealership, that matters: your obligations under the FTC Safeguards Rule and the Gramm-Leach-Bliley Act attach to your customers’ nonpublic personal information. MakeMyMonth never receives that information, so adding it does not expand the footprint of systems holding customer NPI, and a compromise of MakeMyMonth could not expose your customers’ financial data. It remains your responsibility to oversee us as a service provider; we support that with this document, the DPA, and an annual security questionnaire.

2. What we do hold

We store	We do not store
Employee name and work email Role and store assignment Income goal and average commission Daily activity counts Appointment counts Commission tracker entries (date, stock #, partial VIN, amount) Sign-in timestamps	Customer/buyer information of any kind Credit applications or financing data Social Security numbers Driver’s license numbers Bank accounts or card numbers Payroll or HR system records Biometrics or precise location Full VINs

3. Architecture

Frontend. Static HTML and JavaScript, no build step and no server-side application code of our own. Served by Vercel over HTTPS.
Backend. Supabase — managed PostgreSQL, authentication, and scheduled jobs. Application logic that touches data lives in the database itself as SQL functions and row-level security policies, not in a separately maintained server.
Email. Resend, called server-side from scheduled database jobs, for sign-in codes and daily activity reports.

Dependencies. No build step and no package manager in the deployed artifact. The only third-party code in the browser is two pinned, integrity-checked libraries (see Section 13); there is no transitive dependency tree to audit.

The client application authenticates directly against the database platform using a publishable (anonymous) key. That key confers no data access on its own — every read and write is evaluated against row-level security policies tied to the signed-in user’s identity. Privileged credentials never appear in client-side code.

4. Access control

Row-level security is enabled on every table holding user data — profiles, months, entries, events, and dealerships.
A salesperson can read and write only their own records.
Managers and administrators are scoped to their own store by security-definer functions that resolve the caller’s dealership at query time. A manager at one store cannot read, write, or enumerate users at another store, including through the reporting and export features.
Scoping is enforced in the database, not in the browser. Bypassing the user interface does not bypass the policy.
Role changes are restricted to administrators.

5. Account provisioning

The Service is invite-only, and your store controls the roster.

An administrator adds an employee’s work email to the store roster.
When that person signs in, they are matched to the invite and given the role and store the administrator assigned.
An account created from an email address not on any roster is quarantined — marked inactive, shown a pending screen with no data, and excluded from all reports and manager views until an administrator approves it.
Deactivation is immediate and is performed by your administrators, not by us.

6. Authentication

Primary method is a one-time code emailed to the user’s work address.
Users may optionally set a password; password storage and hashing are handled by the authentication platform.
Sessions use platform-issued tokens with automatic refresh and expiry.
Because the primary factor is control of the corporate mailbox, access effectively inherits your email provider’s own controls, including any multi-factor requirement you enforce there.

7. Encryption and data residency

In transit: TLS on all connections; HTTPS enforced.
At rest: encryption provided by the managed database platform.
Secrets: third-party API keys are stored in the database platform’s encrypted vault, never in source code or client-side files.

Data residency — please note. Our database is hosted in Canada (Supabase, ca-central-1). Application hosting and email delivery operate from the United States. If your organization has a US-only data residency policy, raise it with us before signing — it is addressable, but we would rather tell you now than have it surface during a review.

8. Backups and recovery

Automated encrypted backups are maintained by the database platform, with point-in-time recovery.
Because the application is static and versioned in source control, restoring service means restoring data; there is no bespoke server image to rebuild.
Deleted data may persist in encrypted backups until the normal rotation overwrites it.

9. Logging and monitoring

Sign-in events are recorded per user and surfaced to your managers as login frequency.
Database, authentication, and hosting logs are retained by our platform providers and are available to us for investigation.
Administrator alerts fire on new account signups, so unexpected enrollment attempts are visible quickly.

10. Subprocessors

Provider	Role	Location	Their compliance posture
Supabase, Inc.	Database, auth, scheduled jobs	Canada	SOC 2 Type II; HIPAA-capable tier
Vercel Inc.	Hosting and CDN	US / global edge	SOC 2 Type II; ISO 27001
Resend	Transactional email	United States	SOC 2 Type II

Customers receive at least 30 days’ notice before we add or replace a subprocessor handling personal information, with a right to object. See DPA Section 6. Verify each provider’s current certifications directly with them; we report their status as published, not as audited by us.

11. Incident response

Security issues can be reported to support@makemymonth.com; we will acknowledge within one business day.
On confirming an incident we contain it, assess scope using platform logs, remediate, and notify affected customers.
Contractual notification commitment: without undue delay and within 72 hours of becoming aware of a breach affecting personal information, per DPA Section 7.
We do not operate a paid bug bounty. Good-faith reports are welcome and we will not pursue action against researchers who report responsibly and do not access other customers’ data.

12. Personnel

MakeMyMonth is a small company. Access to production data is limited to named administrators, is used only to operate and support the Service, and is subject to confidentiality obligations. We do not offshore support or grant third-party contractors access to customer data.

13. Where we are today, plainly

Control	Status
Row-level security enforced in the database	In place
Per-dealership isolation for managers	In place
Invite-only access with quarantine of unknown accounts	In place
Encryption in transit and at rest	In place
Secrets held in an encrypted vault	In place
Automated encrypted backups with point-in-time recovery	In place
No consumer or financial data in scope	By design
SOC 2 Type II report for MakeMyMonth itself	Not yet — our infrastructure providers hold SOC 2 Type II; we do not
Independent penetration test	Not yet — planned before general availability
Pinned versions and integrity hashes on third-party scripts	In place
Enforced multi-factor authentication inside the app	Not yet — access currently inherits your email provider’s controls
Single sign-on (SAML/OIDC)	Not yet — on the roadmap for dealer groups

Third-party scripts are pinned and integrity-checked. The application loads two open-source JavaScript libraries from public content delivery networks. Both are pinned to an exact version — no rolling “latest” tags — and both carry a SHA-384 Subresource Integrity hash. If the delivered file does not match the expected hash byte for byte, the browser refuses to execute it. A compromise of the CDN, or any tampering in transit, results in the script failing to load rather than running modified code against your users.

14. Shared responsibility

We secure the platform. Your dealership is responsible for:

Keeping your roster current and deactivating departed employees promptly.
Securing the corporate email accounts that receive sign-in codes — ideally with multi-factor authentication at the email provider.
Limiting who holds manager and administrator roles.
Giving employees any notice required before enrolling them, as set out in the MSA and DPA.
Ensuring your people do not enter customer or financing data into the Service.

15. Contact

Security questions, questionnaires, and incident reports: support@makemymonth.com