Data Processing Agreement

These are the data processing terms Obsidian Auto Inc. offers, published in full rather than held back behind a sales conversation. They apply to every Service VIN account as part of the Terms of Service. If you need a countersigned copy for your own records, email [email protected] and we will execute this document as written.

Annex II describes the technical and organisational measures actually implemented, verified against the running codebase, including the measures we do not have. It is stated at the narrowest width that is true, so that you can rely on it.

This Data Processing Agreement (the DPA) forms part of, and is governed by, the Service VIN Terms of Service (the Agreement) between Obsidian Auto Inc., a corporation carrying on business as Service VIN with its registered office at 168 MacEwan Ridge Close NW, Calgary, Alberta T3K 3J4, Canada (the Processor), and the shop or business that holds the Service VIN account (the Controller).

Roles. The Controller determines the purposes and means of processing personal information about its own customers, prospects, vehicles, staff and transactions. Service VIN processes that information solely on the Controller’s documented instructions.

Where Service VIN is a controller. Service VIN acts as an independent controller, not a processor, for a narrow set of data: the account-holder’s own identity and contact details, billing and subscription records, support correspondence, and — where enabled — product-analytics and error-monitoring data about use of the Service. That processing is governed by the Privacy Policy, not by this DPA.

Instructions. The Controller’s documented instructions consist of the Agreement, this DPA, and the Controller’s use of the Service’s features and configuration settings. Service VIN will not process personal information for any other purpose, and will inform the Controller if, in its opinion, an instruction infringes applicable data protection law.

Terms not defined here have the meaning given in the Agreement or in the Personal Information Protection and Electronic Documents Act (Canada) (PIPEDA). Personal Information means information about an identifiable individual that Service VIN processes on the Controller’s behalf. Sub-processor means a third party engaged by Service VIN to process Personal Information. Security Incident means a breach of security safeguards leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Personal Information.

This DPA applies for as long as Service VIN processes Personal Information on the Controller’s behalf: from creation of the Controller’s account until deletion under clause 13. It survives termination of the Agreement to the extent Service VIN retains any Personal Information.

Service VIN is shop-management software for vehicle detailing, paint protection film, vinyl wrap, window tint and ceramic coating businesses. Processing is carried out to provide the Service, which comprises:

• Customer and vehicle records — maintaining a CRM of the Controller’s customers and their vehicles.
• Quoting, invoicing and payment — producing quotes and invoices, taking card payments through a hosted payment page, and recording settlement.
• Scheduling and dispatch — booking jobs into bays and onto staff calendars, including a public online-booking storefront.
• Communications — sending and receiving SMS and email with the Controller’s customers, placing and receiving telephone calls, and recording and transcribing calls where the Controller has enabled that.
• Automated assistance — using large language models to draft messages, analyse call transcripts, summarise conversations and suggest follow-up actions, always on data belonging to the instructing Controller.
• Inventory, payroll accrual and reporting — film and material consumption, technician pay accruals, business reporting.
• Integrations — synchronising records with third-party accounts the Controller itself connects.

Derived from the Service’s actual database schema:

• The Controller’s customers and prospects — name, contact details, address, vehicles, purchase history.
• Individuals who contact the Controller — callers and texters who may never become customers.
• The Controller’s staff and technicians — including time-clock entries and accrued pay.
• Individuals who submit a public form or booking, and recipients of customer portal share links.
• Review authors, where a reviews integration is connected.

No special-category data is sought. The Service is not designed for health, biometric or government-identifier data, and the Controller is instructed not to enter it. Free-text fields cannot be technically prevented from receiving it; if the Controller does so, it does so as controller and at its own risk.

Both of these are architectural, not merely policy:

• Payment card numbers. Card payment is taken on a Stripe-hosted Checkout page. Service VIN’s servers and browser code never see a primary account number, expiry or security code, and no column in the schema holds one.
• Passwords. Authentication is delegated to Supabase Auth. No table in the schema defines a password column; the application only calls the provider’s sign-in and password-update interfaces.

Authorisation. The Controller gives general written authorisation for Service VIN to engage Sub-processors. The current list is published at /security/subprocessors.

Flow-down. Service VIN will impose on each Sub-processor data protection obligations no less protective than those in this DPA, and remains fully liable to the Controller for each Sub-processor’s performance.

Change notification. Service VIN will give at least thirty (30) days’ notice before a new Sub-processor begins processing Personal Information, by updating the published list and notifying subscribed contacts.

Objection. The Controller may object on reasonable data-protection grounds within the notice period. The parties will work in good faith toward a resolution; if none is reached, the Controller may terminate the affected portion of the Service without penalty on written notice, and receive a pro-rata refund of prepaid fees for the terminated portion.

Emergency replacement. Where a Sub-processor must be replaced urgently — vendor failure, a security incident, loss of a certification — Service VIN may do so with less notice and will notify the Controller as soon as practicable.

Service VIN will:

• process Personal Information only on documented instructions;
• not sell Personal Information, and not use it to build or improve any product other than by providing the Service to the instructing Controller;
• not use Controller Personal Information to train machine-learning models, and not permit any Sub-processor to do so (clause 15);
• implement and maintain the technical and organisational measures in Annex II;
• ensure that personnel with access are bound by confidentiality (clause 10);
• assist with data-subject requests (clause 11);
• assist with security, incident notification and privacy impact assessments, taking into account the nature of processing and the information available to Service VIN;
• delete or return Personal Information on termination (clause 13); and
• make available the information necessary to demonstrate compliance (clause 14).

Access to Personal Information is limited to personnel who need it to deliver or support the Service. All such personnel are bound by written confidentiality obligations that survive the end of their engagement.

Taking into account the nature of the processing, Service VIN will assist the Controller in responding to requests from individuals to access, correct, delete or port their Personal Information, and to withdraw consent.

• Self-service. The Service provides in-product access, correction, CSV export and deletion for customer, vehicle, job, quote, invoice and message records. Most requests can be satisfied without contacting Service VIN.
• Escalation. Where a request cannot be satisfied in-product, Service VIN will provide reasonable assistance within ten (10) business days of a written request.
• Requests received directly. If an individual contacts Service VIN directly, we will not respond substantively other than to acknowledge, will refer them to the Controller, and will notify the Controller promptly.
• Communications opt-out. SMS opt-out is honoured at the platform level: an opt-out recorded against a customer suppresses further automated messages.

Service VIN will notify the Controller without undue delay and in any event within seventy-two (72) hours of becoming aware of a Security Incident affecting the Controller’s Personal Information.

The notice will describe, to the extent known: the nature of the incident and the categories and approximate number of records concerned; the likely consequences; the measures taken or proposed; and a contact point. Where the full picture is not available within 72 hours, an initial notice will be given within that window and supplemented as the investigation progresses.

Service VIN will cooperate with the Controller in any assessment of “real risk of significant harm” under PIPEDA, and in any notification to the Office of the Privacy Commissioner of Canada, provincial regulators or affected individuals. Service VIN will maintain its own record of breaches of security safeguards as required by PIPEDA. Notification is not an acknowledgement of fault.

• The Controller may export its data through the Service’s export functions during the subscription term and for thirty (30) days afterwards.
• On written request within that window, Service VIN will provide a machine-readable export of the Controller’s Personal Information.
• After the 30-day window, Service VIN will delete the Controller’s Personal Information from active production systems within a further sixty (60) days.
• Encrypted backups are purged on the ordinary rotation schedule set by our infrastructure providers, which Service VIN does not lengthen. Personal Information persisting in a backup remains subject to this DPA until it is purged, is not restored into production, and is not accessed for any other purpose. Service VIN will state the retention period then in force on request.
• Service VIN may retain Personal Information where required by law, and retains aggregated or de-identified data that cannot reasonably be re-associated with an individual.

Service VIN will make available the information reasonably necessary to demonstrate compliance with this DPA, including its published security documentation at /security and Annex II below.

Current state, stated plainly. Service VIN holds no SOC 2, ISO 27001 or equivalent third-party attestation, and has not commissioned an independent penetration test. There is therefore no audit report to provide. Until one exists, the Controller may, no more than once in any twelve-month period and on thirty (30) days’ written notice, submit a written security questionnaire, which Service VIN will answer within thirty (30) days. On-site audits are available only where required by a supervisory authority or applicable law, at the Controller’s expense, subject to reasonable confidentiality and scheduling conditions, and must not compromise the security or privacy of other customers.

The Service uses third-party large language models to draft messages, analyse call transcripts and suggest follow-up actions. The Controller instructs Service VIN to make these calls as part of providing the Service.

• What is sent. Only the material needed for the specific task: a call transcript, a message thread, a customer display name and vehicle description, and the shop’s own profile, voice guidance and knowledge-base snippets. Transcripts are truncated before transmission.
• Which providers. Anthropic for all request-time generation and analysis. OpenAI for service-image generation only, and only where that optional key is configured. Twilio Voice Intelligence performs speech-to-text on bridged call recordings — audio is never sent to Anthropic or OpenAI.
• Training. Service VIN does not permit any model provider to train on Controller Personal Information. Anthropic’s and OpenAI’s commercial API terms state that inputs submitted through their APIs are not used to train their models. Service VIN relies on those vendor terms; it has not separately negotiated a zero-data-retention amendment with either vendor, so each vendor’s standard API retention window applies. If the Controller requires zero retention, raise it before signature.
• No solely-automated decisions with legal effect. AI output in the Service is a draft or a suggestion. Sending a message, accepting a quote or booking a job is an action taken by a human user of the Controller.

Service VIN is established in Canada. Personal Information is processed in Canada and in other jurisdictions where the Sub-processors listed at /security/subprocessors operate — principally the United States and, where product analytics is enabled, the European Union (PostHog EU Cloud is the configured default).

Under PIPEDA, a transfer to a third party for processing is a use, not a disclosure, and the transferring organisation remains accountable for the information. Service VIN accordingly discloses the transfer and the jurisdictions involved here and in the published sub-processor list; contracts with each Sub-processor for a comparable level of protection; and remains accountable to the Controller for information transferred.

Where the data actually sits. The production database, authentication and object storage run in AWS us-east-1 (Northern Virginia, United States), and application servers run in the hosting provider’s default US East region. Service VIN does not offer a Canadian or Quebec data-residency option, and states that here rather than leaving it to be inferred from the Processor’s Canadian address.

Quebec — Law 25. Where the Controller or its data subjects are in Quebec, communicating Personal Information outside Quebec requires an assessment of the privacy implications before the communication takes place. Service VIN performs that assessment for each Sub-processor it engages — considering the sensitivity of the information, the purpose, the protections committed to contractually, and the legal regime of the receiving jurisdiction — engages a Sub-processor only where the assessment supports adequate protection, and records the outcome in the published sub-processor list. This DPA constitutes the written agreement required for those communications. Service VIN will provide the Controller with the information reasonably necessary for the Controller’s own assessment on request.

The Controller is responsible for making the corresponding disclosure to its own customers — under PIPEDA generally, and under Quebec’s Law 25 or Alberta’s or British Columbia’s provincial legislation where those apply to it.

Where the Controller or its data subjects are in the EEA or the UK and the GDPR applies, the parties will enter into the European Commission’s Standard Contractual Clauses or the UK Addendum as applicable, and those clauses prevail over this DPA to the extent of any conflict.

This DPA is governed by the laws of the Province of Alberta and the federal laws of Canada applicable therein, and the parties attorn to the exclusive jurisdiction of the courts of Alberta. The parties intend this DPA to be interpreted consistently with PIPEDA and, where applicable to the Controller, with Alberta’s Personal Information Protection Act, British Columbia’s Personal Information Protection Act, and Quebec’s Act respecting the protection of personal information in the private sector as amended by Law 25. Nothing in this DPA limits any right an individual has under applicable privacy legislation.

In the event of a conflict, the order of precedence is: the Standard Contractual Clauses or UK Addendum where executed; this DPA; the Agreement; then any other document.

These are the measures actually implemented as of the date above. Each was verified against the codebase; the same facts with file-level citations are published at /security. Where a control is enforced only in part, this annex says so — a security annex that overstates is worse than no annex.

• 1. Tenant isolation. Every application table carries PostgreSQL row-level security. Isolation is expressed as a predicate on the caller’s active shop memberships rather than as an application-layer filter, so it holds even for a request that reaches the database API directly. Row-level security is additionally set to FORCE on all but one table, so it binds the table owner too.
• 2. Least privilege inside a tenant. Customer contact details, quotes, invoices, payments and per-job margin are gated in the database on a back-office permission predicate, not only in the interface. A technician account authenticated against the same shop reads zero rows from those tables. This is exercised by an adversarial test that boots a real PostgreSQL cluster, applies the production migration unchanged, and attacks it as a technician.
• 3. Encryption in transit. All traffic to the application and the database API is over HTTPS/TLS.
• 4. Encryption at rest. Database and object storage are encrypted at rest by the infrastructure provider. In addition, third-party integration credentials are encrypted by the application before they are written: AES-256-GCM with a random 96-bit nonce and a 128-bit authentication tag, under a 32-byte key held only in the server environment and never in the database.
• 5. Credential handling. Passwords are never received or stored by Service VIN. Public API keys and platform impersonation tokens are stored only as SHA-256 hashes. Customer share-link tokens are stored in plaintext but carry a mandatory expiry and can be revoked.
• 6. Webhook integrity. Every inbound webhook that carries or triggers processing of Personal Information verifies a cryptographic signature over the raw request body before the payload is trusted, and fails closed. Outbound webhooks to Controller-controlled endpoints are signed with a per-endpoint HMAC-SHA256 over a timestamp and the raw body.
• 7. Auditability. Domain events, material consumption, AI credit consumption, technician pay accrual and platform-administrator actions are recorded in append-only ledgers. Append-only is enforced by the database: those tables have SELECT and INSERT policies and no UPDATE or DELETE policy, so no client of the data API can rewrite history. The privileged service credential used by our own background workers bypasses row-level security by design and is therefore not constrained by that enforcement; it is confined to webhook, background-job and platform-administration code paths.
• 8. Access control. Role- and permission-based access within a shop. Privilege-escalation paths through the data API were closed by a dedicated hardening migration, including a database trigger preventing the platform-administrator flag from being set by anything other than the service credential.
• 9. Object storage. The documents bucket is private. There are no anonymous object URLs; every read is a short-lived signed URL (one hour internally, fifteen minutes for customer-facing portal links), and the object path is itself the tenant boundary.
• 10. Abuse resistance. Public, unauthenticated surfaces are rate-limited by a durable sliding-window counter in the database, so the limit holds across serverless replicas.
• 11. Telemetry minimisation. Where error monitoring is enabled, cookies, the Authorizationheader, request bodies and URL query strings are stripped before an event leaves the server. Where product analytics is enabled, collection is first-party only: no third-party script, no vendor SDK in the browser, no DOM autocapture. The hosting provider’s own Web Analytics and Speed Insights features are a separate, separately switched processing activity: cookieless, restricted by configuration to a redacted route template rather than a full URL or query string, and suppressed entirely for a data subject signalling Do Not Track or Global Privacy Control.

Measures not in place, stated for completeness:

• No SOC 2, ISO 27001 or equivalent third-party attestation.
• No independent penetration test.
• No multi-factor authentication for Controller user accounts.
• No customer-managed encryption keys.
• No contractual data-residency guarantee; hosting regions are vendor defaults and are not pinned in configuration.
• No automated retention or deletion schedule for call recordings, which are held by the telephony provider.
• The application sets no Content-Security-Policy or other custom security response headers of its own.

To request a countersigned copy of this DPA, raise a question about a clause, or report a security issue, see the security overview for our contact address and responsible-disclosure process.