Data Handling Statement (DRAFT — Short Form)
DRAFT — NOT LEGAL ADVICE. Working draft for attorney review. Placeholders marked
[BRACKETED]. Do not deliver to a customer in this state.Purpose of this document. This is a short-form alternative to the full Data Processing Addendum, intended for enterprise prospects whose legal teams will accept a concise data-handling statement when the data flow is genuinely minimal. Many will. Some will still require the full DPA — keep the long form ready for those.
URLs not yet determined. Domain selection and the URL structure for legal documents are open. The expectation is that legal documents will live under a subfolder of the main company page dedicated to the product, e.g.,
agenticbookmarks.com/legal/.... Every[…URL]placeholder in this document will resolve to a path under that subfolder; the specific paths are not yet fixed. Cross-document references using these placeholders should remain consistent so that a single find-and-replace pass can populate them later.
Data Handling Statement
Super Mega Lab LLC ("Super Mega Lab") provides the Agentic Bookmarks VS Code extension and related components (the "Services") to [CUSTOMER LEGAL NAME] ("Customer") under the agreement between the parties (the "Agreement").
This statement summarizes the Personal Data that Super Mega Lab Processes in connection with the Services. It is intended to satisfy Customer's diligence requirements where the limited nature of the Processing makes a full Data Processing Addendum unnecessary. A full Data Processing Addendum is available on request.
Capitalized terms not defined here have the meanings given under the EU General Data Protection Regulation ("GDPR") or equivalent applicable data protection law.
1. What Super Mega Lab does NOT receive
The Services are designed so that Super Mega Lab does not receive, Process, or store any of the following:
- Source code, file contents, file paths, or file names.
- Repository names, remote URLs, branch names, commit hashes, commit messages, or other version control metadata.
- Prompts, AI completions, model inputs or outputs, or assistant conversations.
- Editor activity, keystrokes, telemetry events, or product-usage analytics.
- Diagnostics, error reports, or crash dumps.
- Repository visibility status (the Services determine repository visibility on the user's machine by querying the applicable repository host directly; this information is not transmitted to Super Mega Lab).
The Services contain no telemetry, no analytics, and no behavioral event logging.
2. What Super Mega Lab does Process
Super Mega Lab's Processing in connection with the Services is limited to the following:
| Field | Source | Purpose | Retention |
|---|---|---|---|
| Internal user identifier | Generated by Super Mega Lab | Internal record key | Account lifetime + 90 days |
| Email address | Provided via Polar.sh at subscription | License association, support, account communications | Account lifetime + 90 days |
| Polar customer identifier | Provided by Polar.sh | Reconciliation with billing system | Account lifetime + 90 days |
| Account creation timestamp | Generated by Super Mega Lab | Account lifecycle | Account lifetime + 90 days |
| IP address | Network connection to Super Mega Lab's license/auth server | TLS connectivity, abuse prevention | [Not retained beyond [N] days in transient connection logs] |
| Entitlement token contents | Issued by Super Mega Lab | Authenticate Pro feature use | Tokens are short-lived and not separately retained server-side once issued |
Super Mega Lab does not Process special categories of Personal Data (Article 9 GDPR) or Personal Data of children.
3. Roles of the parties
With respect to the data described in Section 2:
- As to end-user account data (the user identifier, email, Polar customer identifier, and account creation timestamp): Super Mega Lab acts as an independent controller for the limited purposes of license verification, entitlement issuance, account communications, and support. Customer is not the controller of this data; Super Mega Lab is.
- As to billing data: Polar Software, Inc. ("Polar") acts as merchant of record and as the controller for payment Personal Data. Super Mega Lab does not receive payment instrument data, billing addresses, or transaction histories from Polar.
- As to Customer's source code and development data: as set out in Section 1, Super Mega Lab does not receive this data, and therefore is neither controller nor processor of it.
Because Super Mega Lab does not Process Personal Data on Customer's behalf, the typical Article 28 controller-processor relationship does not arise from Customer's use of the Services. If Customer's data protection regime nonetheless requires a written processor agreement, Super Mega Lab's full Data Processing Addendum is available on request.
4. Sub-processors and other recipients
The third parties that handle the data in Section 2 are:
| Recipient | Role | Data |
|---|---|---|
| Polar Software, Inc. | Merchant of record; subscription management | Provides email and customer identifier to Super Mega Lab |
| Vercel (including Vercel Postgres for the database) | Hosting of license/auth server and database; TLS termination | All data in Section 2; transient connection logs |
| Resend | Sending transactional account emails | Email address |
The current list is maintained at [SUBPROCESSOR-LIST-URL].
5. Security
Super Mega Lab maintains technical and organizational measures appropriate to the limited nature of the data, including:
- TLS 1.2 or higher for all network communication.
- Encryption at rest for the user database and backups.
- Least-privilege access controls and authentication with [SSO / MFA].
- Signed entitlement tokens, verified locally by the Services.
- A documented incident response procedure.
A full description is available in Super Mega Lab's security overview at [SECURITY-OVERVIEW-URL] and in Annex 2 of the full Data Processing Addendum.
6. International transfers
To the extent Super Mega Lab's receipt of email and Polar customer identifier constitutes a transfer of Personal Data from the European Economic Area, the United Kingdom, or Switzerland to a third country, the parties rely on the following transfer mechanism: [Standard Contractual Clauses (Module One, Controller-to-Controller) executed between Super Mega Lab and Polar / available on request from Super Mega Lab]. Customer's own use of the Services does not itself involve a transfer of Customer Personal Data to Super Mega Lab, because Customer Personal Data (in the development-data sense) is not transmitted to Super Mega Lab.
7. Security incidents
Super Mega Lab will notify Customer without undue delay, and in any event within seventy-two (72) hours after becoming aware, of any security breach materially affecting the data described in Section 2 in a manner relevant to Customer's end users.
8. Data subject requests
End users may exercise their data protection rights (access, rectification, deletion, portability, objection) by contacting contact@supermegalab.com. Given the limited data Processed, Super Mega Lab can typically fulfill such requests within thirty (30) days.
9. Deletion on termination
On termination of the Agreement, Super Mega Lab will delete the data described in Section 2 within [ninety (90) days], except that backups may persist for up to [six (6) months] in accordance with Super Mega Lab's backup rotation, after which they are overwritten or destroyed. During this period, the data remains subject to the security and confidentiality obligations of the Agreement.
10. Changes to this statement
Super Mega Lab may update this statement from time to time. The current version is published at [DATA-HANDLING-URL]. Material changes will be communicated through the channel Customer has designated for account notices.
11. Contact
For questions about this statement or Super Mega Lab's data practices: contact@supermegalab.com
Acknowledged and accepted (optional)
Some Customers will require this statement to be countersigned. Others will treat it as a unilateral disclosure attached to the Agreement. Either is acceptable.
| Customer | Super Mega Lab LLC |
|---|---|
| Signature: __________________________ | Signature: __________________________ |
| Name: ________________________________ | Name: ________________________________ |
| Title: _______________________________ | Title: _______________________________ |
| Date: ________________________________ | Date: ________________________________ |
Drafting Notes (REMOVE BEFORE DELIVERY)
How to use this document
- First-line response to enterprise procurement / security teams who ask for a DPA. Many will accept this and move on. The ones who insist on a full Article 28 DPA get the long-form draft.
- Attachment to security questionnaires as supporting documentation — often it lets you check the "DPA available" box without negotiating one.
- Public-page candidate at
[DATA-HANDLING-URL](e.g.,[licensor.com]/legal/data-handling). Publishing it publicly heads off a lot of inbound diligence.
Why this works (and when it doesn't)
This statement leans on a structural argument: because Super Mega Lab never receives Customer's development data, the typical controller-processor relationship doesn't arise — and a DPA is a controller-processor instrument. The data Super Mega Lab does hold (email, polar_customer_id, IP for transport) flows from the end-user-as-data-subject and from Polar, not from Customer-as-controller.
This argument lands well with sophisticated legal teams, especially those who have read the EDPB guidance on processor/controller status. It does not land with:
- Procurement teams running a checklist that says "must have signed DPA". For them, run the full DPA template.
- Customers in regulated industries (healthcare, financial services, public sector) where signed processor agreements are a flat policy regardless of actual data flow.
- Customers who interpret the email + Polar ID flow as Customer Personal Data being processed on their behalf. (Defensible position; not the only one.)
Items requiring decision
- Privacy email and public URL for this statement.
- Sub-processor list URL and security overview URL.
- Hosting provider, region, email provider in Section 4.
- IP retention in Section 2 (must match operational reality and the long-form DPA).
- Transfer mechanism in Section 6 — whether you have or need SCCs with Polar, and whether you offer SCCs to Customer on request.
- Whether to make this signature-optional or signature-required. Some customers want a countersignature; others treat it as a notice.
- Whether to publish publicly. Recommendation: yes — preempts a meaningful share of inbound DPA requests.
Companion documents
- Long-form Data Processing Addendum (already drafted) for customers who insist on Article 28 form.
- Privacy Policy (public; consistent with this statement).
- Sub-processor list page at the URL referenced.
- Security overview / trust page at the URL referenced.