Data Usage Policy

This Data Usage Policy explains, in operational and technical terms, how 7seven handles the data you and your workspace members entrust to us. It complements but does not replace our Privacy Policy (which describes our legal commitments under PIPEDA, Quebec Law 25, CCPA/CPRA, and other applicable privacy laws) and our Terms of Service (which sets out the contract between us).

Where this policy conflicts with the Privacy Policy or Terms of Service, those documents control. This policy is informational and reflects our current practices; like the Privacy Policy, it may evolve as the Service evolves (see Section 18). For enterprise customers who need a binding Data Processing Agreement (DPA), email legal@7seven.dev.

We classify the data we handle into the following categories. This classification drives how each category is stored, processed, retained, and exposed to sub-processors.

For workspace metadata, content, AI outputs, and integration data, the workspace owner is the controller and 7seven acts as the processor on the owner’s behalf. For account, operational, and security data, 7seven is the controller.

The following walkthroughs describe how data physically moves through the system on each major user action.

Recording a voice note

1. Your browser captures audio through the standard microphone API after you grant permission.
2. The audio file is uploaded directly to a Supabase Storage bucket scoped to your workspace; the first path segment is your workspace identifier, and row-level security restricts access to authenticated members of that workspace.
3. A database trigger notifies a dedicated transcoding worker hosted on Google Cloud Run (United States). The worker downloads the audio, normalizes the format, and writes the transcoded file back to the same workspace-scoped path.
4. The worker sends the transcoded audio to our AI transcription provider (currently Groq, United States) and receives a transcript in return. The audio binary is not retained by the worker after the request completes.
5. The transcript is written to the database alongside the voice note record. AI summarization (Section 4) then runs against the transcript.
6. The original audio file is automatically deleted from Storage according to your plan’s retention window (Section 8). Transcripts and tickets are retained until you delete them.

Connecting GitHub

1. You install the 7seven GitHub App from the GitHub marketplace and select which repositories to share.
2. We receive the installation identifier and, on a scheduled basis, fetch repository metadata: file paths and the contents of small manifest files (such as package.json and README.md). We do not fetch, transmit, cache, or process the source code of your repositories.
3. That metadata is stored in the database, scoped to your workspace, and used as grounding context for AI suggestions.
4. Uninstalling the GitHub App from your GitHub organization terminates further metadata fetches; we delete cached metadata from our database within seven days of uninstall.

Connecting Linear

1. You authorize 7seven via Linear’s OAuth flow with the scopes required to read and write issues you choose to import.
2. The OAuth token returned by Linear is encrypted at rest with an application-managed key before it is written to the database. Plaintext tokens are never stored on disk and are held only in memory during request handling.
3. When you initiate an import, we fetch issues from the Linear API and create corresponding tickets in your workspace. Imported tickets are workspace content under your control.
4. Disconnecting Linear from Workspace Settings causes the token to be deleted from the database and prevents further reads or writes against your Linear instance.

Connecting Jira

1. You authorize 7seven through Atlassian’s OAuth flow. We request read-only scopes (read:jira-work, read:jira-user, and offline access for token refresh) — 7seven reads from Jira but never writes back to your Jira instance.
2. On completion, we discover your accessible Atlassian site and store its identifier and URL, together with the access and refresh tokens Atlassian returns. The tokens are encrypted at rest with an application-managed key before they are written to the database; plaintext tokens are held only in memory during request handling. Atlassian rotates the refresh token on each refresh, and we persist the rotated token atomically.
3. When you initiate an import, we page through the issues in the project you select and, for each issue, fetch its comments and attachments. Attachment binaries are downloaded from Jira and uploaded to the same workspace-scoped Storage bucket used for ticket attachments (first path segment is your workspace identifier, enforced by row-level security). Imported issues become tickets, and imported comments and attachments become workspace content under your control.
4. To attribute imported issues, comments, and assignments to the right person, we store limited metadata about the Jira users referenced by that content: account identifier, display name, email address (where Jira exposes it), and avatar URL. Imported authors begin as unclaimed “shadow” records and can later be matched to a workspace member.
5. Disconnecting Jira from Workspace Settings soft-deletes the integration and scrubs the encrypted tokens from the database, preventing further reads against your Jira instance. Already imported tickets, comments, attachments, and member records are preserved as workspace content; delete them in-app if you no longer want them.

Authentication and sign-in

1. You initiate sign-in. Cloudflare Turnstile issues a bot-detection challenge.
2. On success, you are redirected through Google’s OAuth flow. Google returns your name, email, profile picture, and an account identifier.
3. Supabase Authentication creates a session and sets a session cookie. Subsequent requests are authenticated by that cookie.
4. We do not store passwords. 7seven does not currently offer its own second factor; configure two-factor authentication on your Google account directly.

Billing and subscription changes

1. When you upgrade or change a plan, you are redirected to a Lemon Squeezy-hosted checkout page where you enter payment details. 7seven never sees, processes, or stores full card numbers, CVV, or banking credentials.
2. Lemon Squeezy collects applicable sales tax (US sales tax, Canadian GST/HST/QST, VAT, etc.) and processes the charge. Lemon Squeezy is the Merchant of Record.
3. On a successful charge, Lemon Squeezy sends a webhook to our backend. The webhook payload contains your subscription status, plan tier, seat count, and a customer identifier.
4. Our backend writes the subscription record and updates the workspace plan inside a single transactional database operation, so a partial write cannot leave you with paid status on one side and free status on the other.
5. A transactional email confirming the change is sent via Resend to the workspace owner’s email address.

7seven uses third-party AI providers for two operations: transcription of voice recordings and summarization of transcripts into structured tickets. This section describes exactly what is sent to each provider.

Transcription

Provider: Groq, running OpenAI’s Whisper large-v3 model (United States).

Sent: The transcoded audio file only. No identifying metadata about you, your workspace, or any other user is sent in the transcription request.

Returned: A transcript with word-level timestamps.

Summarization

Provider: Google (Gemini API, United States).

Sent:

• The transcript text from the previous step.
• If your workspace has at least one GitHub repository connected and the AI feature requires grounding (such as suggesting files), a structured prompt context containing repository file paths and the contents of small manifest files (typically package.json, README.md, and similar). Source code is never included.
• A system prompt defining the JSON output schema we expect (title, summary, severity, suggested files, suggested fixes, tags, etc.).

Returned: A structured ticket draft. AI outputs are treated as suggestions and are subject to the disclaimers in our Terms of Service.

7seven does not train its own AI models on Customer Content on any plan. We retain transcripts and ticket drafts only to display them to you in the product; we do not feed them into any internal training pipeline.

A sub-processor is a third-party service that processes data for 7seven on our instructions. The following table lists our current sub-processors, the categories of data each one processes, and the region in which each one operates.

Before we add or replace a sub-processor that materially changes how a category of personal data is handled, we will provide at least 30 days’ advance notice by updating the table in Section 5 and posting an entry on this page. We will not change a significant infrastructure provider (such as our database, hosting platform, or AI-summarization provider) without prior notice.

To receive sub-processor change notices by email, send a request with the subject line “subprocessor notifications” to legal@7seven.dev from the email address associated with your account. You will receive notice at the same time, and via the same channel, as we post the update.

7seven is operated from Canada, and the substantial majority of our sub-processors are located in the United States. Data you and your workspace members submit through the Service is stored and processed in the United States by default. Cloudflare and Vercel operate global edge networks; cached static responses and request-edge metadata may transit additional regions, but business data at rest lives in the United States.

We do not currently offer data-residency choices (for example, EU-only or Canada-only storage). Customers with strict residency requirements should email legal@7seven.dev before subscribing so we can confirm whether the Service meets your obligations.

Retention is enforced by automatic background processes and by user actions. The table below summarizes the default behavior for each category. The Privacy Policy is the authoritative source for legal-retention statements; this table operationalizes them.

Our security controls are designed around a layered model: the network protects the application, the application protects the database, and the database protects each row.

• Encryption in transit. All connections between your device and the Service, and between the Service and its sub-processors, use TLS (currently TLS 1.2 or higher).
• Encryption at rest. Production database storage, object storage, and backups are encrypted at rest by Supabase using AES-256 by default. OAuth tokens for third-party integrations (currently Linear and Jira) are additionally encrypted at the application layer (AES-256-GCM) with application-managed keys before being written to the database.
• Row-level security (RLS). All workspace-scoped tables are protected by PostgreSQL row-level security policies. Membership is checked through a dedicated security-definer helper rather than ad-hoc joins, so a query made with an authenticated user’s credentials cannot read or modify data outside the workspaces that user belongs to.
• Storage bucket scoping. Every object in our storage buckets carries the workspace identifier as the first path segment, and bucket policies enforce that scoping — even a leaked anonymous key cannot list or download objects from a workspace the authenticated user does not belong to.
• Service-role boundaries. Privileged database operations (webhooks, cron jobs, atomic multi-table writes) use scoped security-definer functions whose execute permissions are revoked from anonymous and authenticated roles and granted only to a dedicated service role. This prevents a leaked anonymous or authenticated key from invoking privileged paths.
• Bot protection. Sign-in is gated by Cloudflare Turnstile to deter automated account creation and credential-stuffing attempts.

Service-role credentials, webhook secrets, OAuth client secrets, third-party API keys (AI providers, Lemon Squeezy, Resend), and the application-managed encryption keys used to protect OAuth tokens are stored in hosted secret managers provided by our hosting and infrastructure platforms. Secrets are not committed to source control. We rotate keys and secrets as part of operational hygiene, on staff change, and in response to any suspected compromise.

Multi-tenancy is enforced primarily at the database row level. Application code that reads workspace-scoped data always executes under an authenticated user’s credentials so that row-level security applies. Privileged service-role code paths explicitly scope queries by workspace identifier before executing. Storage paths, database queries, and authorization helpers are all aligned so that the workspace identifier is the consistent isolation boundary across the system.

Data from unrelated workspaces is not commingled in AI prompts, email templates, or analytics events. Aggregated and de-identified product metrics may be computed across all workspaces, but in a form that does not allow re-identification of any individual workspace or user.

Our database and storage layers are backed up by our infrastructure provider on a regular schedule, with point-in-time recovery available within the provider’s retention window (typically up to 30 days). Backups are encrypted at rest and stored in the same region as production data.

Backups exist for disaster recovery and operational rollback, not as a customer-facing data-export mechanism. Data you have deleted from the production system will continue to exist in backups until those backups age out of the rotation window. We do not selectively restore individual records from backup as a routine support operation; backups are restored only in response to a service-wide incident.

We monitor the Service through a combination of structured application logs, infrastructure-level metrics, error and performance telemetry (Sentry), and sub-processor-provided anomaly detection (Supabase, Cloudflare). Sign-in failures, rate-limit events, abnormal AI-pipeline usage, and webhook authentication failures are surfaced into alerts.

If we become aware of a personal-information breach — an actual or reasonably suspected unauthorized access, disclosure, loss, or destruction of personal data — the following response process applies:

• Triage within 24 hours of becoming aware of the suspected incident: scope the affected data categories, accounts, and workspaces; preserve evidence; and engage the relevant sub-processors.
• Customer notification without undue delay and in any event within 72 hours of confirming a breach that creates a real risk of significant harm. Notification is sent to the workspace owner’s account email and, where applicable, surfaced as an in-app banner. We will describe the nature of the incident, the data categories involved, the steps we are taking, and the steps you should take.
• Regulatory notification to the Office of the Privacy Commissioner of Canada, the Commission d’accès à l’information du Québec, and any other applicable supervisory authority within the timeframes required by law (generally 72 hours under Quebec Law 25 and PIPEDA reporting thresholds).
• Post-incident written summary to affected workspace owners within 30 days of containment, describing root cause and remediation.

Report a suspected security issue, vulnerability, or active incident to legal@7seven.dev. Please include enough technical detail to reproduce the issue and avoid using a publicly accessible channel to share sensitive details. We do not currently operate a paid bug bounty, but we appreciate good-faith disclosures and will not pursue legal action against researchers who comply with Section 10 of our Terms of Service.

Security is a shared responsibility. We protect the platform; you protect your account and the content you choose to upload. Specifically, you are responsible for:

• Account security. Sign in only via your own Google account; configure two-factor authentication on that Google account; do not share, lease, or transfer your account credentials.
• Workspace membership. As a workspace owner or admin, you are responsible for who you invite to your workspace, the role you grant them, and removing members who should no longer have access.
• Content you upload. Do not record or upload content that violates the acceptable-use section of our Terms of Service, including content containing government-issued identifiers, payment-card numbers, individual medical records, or other sensitive personal information about yourself or others.
• Integration scopes. Grant only the scopes you intend; review installed GitHub apps and authorized Linear and Jira (Atlassian) connections periodically; disconnect integrations you no longer use.
• Devices. Keep the devices you sign in from up to date and protected by standard operating-system security controls.
• Reporting. Promptly notify us at legal@7seven.dev of any suspected unauthorized access to your account or workspace.

The Privacy Policy describes your legal rights. This section describes the operational workflow for exercising them.

For requests about content in a workspace you do not own, we may direct you to the workspace owner, who is the controller of that content (see Section 2).

7seven is not currently SOC 2 or ISO 27001 certified. We expect to begin SOC 2 Type II preparation following broader adoption of the Service.

On reasonable notice and no more than once per twelve-month period, paying customers may request a written security summary describing our current controls, the categories of data each sub-processor handles, the encryption and access controls described in Sections 9 through 11, and the breach-response process described in Section 13. The written summary takes the place of on-site or third-party audit rights until we complete SOC 2 Type II, at which point we will make the SOC 2 report available under standard confidentiality terms.

Before adding a new sub-processor, we evaluate (a) the sub-processor’s data-handling commitments, including whether it offers a paid or enterprise tier with explicit no-training and confidentiality protections; (b) its published security posture, certifications, and breach history; (c) the categories of personal data we expect to share with it; (d) the region in which it operates and the cross-border-transfer implications; and (e) whether a comparable provider already covers the same need.

We review our sub-processor list at least annually and on any sub-processor security incident, certification change, terms change, or change of control.

We may update this policy from time to time. When we do, we will post the new version here and update the effective date. For changes that materially affect how data is handled — including the addition or replacement of a significant sub-processor — we will provide advance notice of at least 30 days by email or in-app notice before the changes take effect. Non-material changes (clarifications, typo corrections, formatting) take effect on posting.

• General data and security contact: legal@7seven.dev
• Account deletion: delete@7seven.dev
• Sub-processor change notifications: email legal@7seven.devwith subject “subprocessor notifications”
• Enterprise Data Processing Agreement (DPA) requests: legal@7seven.dev
• Postal address: Hamilton, Ontario, Canada L8P 0A1