Data Governance

This page explains how we handle the business data a customer shares with us during a Maverick engagement or loads into the Maverick Console: who decides, what we take, how long we keep it and how it is deleted. It applies to Speedloop Technologies, an offering of Speedloop Auto Private Limited (India), 2nd Floor, Plot No. 296, Sector 10, PCNTDA, Pimpri Chinchwad, Pune, Maharashtra 411039, India. Questions: maverick@speedloopauto.com.

The controls below are product controls, not a certification. The legal terms for each customer are set in a signed agreement and data processing addendum.

Roles: you decide, we build

• The customer is the controller of its data. It decides what may be collected, why, who may see it and when it must be deleted.
• Speedloop is the processor (or "service provider" under U.S. state laws). We describe our role as the customer's data architect: we help structure, store and understand the data, on the customer's written instructions.
• A Speedloop person acts in a customer's controller role only with that customer's approval, and the grant is recorded with a reason.
• Speedloop is separately responsible, as a controller, for its own business records about customers and prospects, such as contracts, invoices, account administration and sales contacts. Our Privacy Policy covers those.

We are not a data broker

• We do not sell, rent or trade customer data, and we never move one customer's data to another customer.
• Each customer is a separate tenant in the Console. Every database function checks that a Purpose, dataset and record belong to the same tenant.
• What we learn about how to run engagements well may improve our consulting method. Customer records themselves are never reused for another customer.

Data minimisation

• We ask only for the data the chosen outcome needs. A first engagement usually works from a small number of structured exports and interviews, not system-wide access.
• We prove each use case on sample, synthetic or masked data first, and admit real records only when they are needed.
• Where it serves the task, we prefer aggregated, generalised, masked or synthetic data. We call data de-identified, never "anonymous", and we treat de-identified data as data that could still identify someone if combined with other sources.
• Before a dataset is loaded, we consider how sensitive it is, how unique each record is and what it could reveal if joined with other data.

Real data needs an approved processing register

The Console refuses non-fictional records for a customer until a Speedloop administrator has approved an in-date processing register for that tenant. It records:

• the customer's controller contact and Speedloop's role;
• the purpose of processing;
• the categories of data and the places the data subjects are in;
• the legal basis and the contract reference;
• the approved subprocessors and the transfer path;
• the retention period and the next review date.

Editing the register withdraws the approval until it is reviewed again.

Markings and Purposes

Data is marked so that people see only what their task needs:

Every read happens under a Purpose: a defined task with an owner, assigned datasets and allowed markings. Access is requested with a reason, approved by someone other than the requester, and expires (90 days by default, 365 days at most). Fields with a marking the Purpose does not allow are masked. See the Security Overview for details.

Knowing where data came from

Every dataset records its sources, how trustworthy its facts are (documented, reported, field-checked or unknown), the consistency checks it passed, how fresh it is and which source wins when sources disagree. Every record carries its source, owner, as-of date and evidence state. Lineage runs from the original file, through a checksum, to the dataset and the records built from it.

Retention

• By default each dataset is kept for 365 days. The customer can set a different default for its tenant, and the period is agreed per engagement in the processing register.
• These are product defaults, not legal retention periods. The customer decides the right period for its data.
• At the end of an engagement we return or delete customer data as the agreement says.

Deletion lifecycle

1. Request. A deletion is requested in the Console with a reason. Who asked, when and why are recorded.
2. Soft delete. The data is hidden at once. It can be restored during the tenant's restore window, 7 days by default.
3. Hard delete. After the window, the data is permanently removed, together with its revision history, comments, attached files and copies in pending change sets. Stored files are purged by an hourly job with retries, and overdue purges raise an alert.
4. No re-ingestion. A hard-deleted record or dataset is never brought back by a later data load.

Copies in our hosting provider's backups expire on that provider's backup schedule. We have not yet tested a full restore from backup, and we make no backup or restore guarantee.

Legal hold

A customer controller or a Speedloop administrator can place a legal hold on a dataset, with a reason. While the hold is in place the dataset cannot be hard-deleted. Only a Speedloop administrator can release it, and both steps are recorded in the audit log.

Exports

Exports follow the tenant's export setting, stay within the user's Purpose and markings, and are recorded in the audit log.

AI and data categories

• External AI is off unless the customer enables it. Each tenant's setting is off, demo data only, or approved with a reference and an expiry date.
• The customer can restrict which data categories may be sent to the AI provider. If a request falls outside the setting, it is refused.
• When AI is used, the provider (currently Anthropic) receives the user's question and the Purpose-scoped records needed to answer it, with masked fields still masked. Each call is logged without its prompt content.
• We do not use customer data to train our own models. The AI provider's own data handling is governed by its terms, which we review with the customer before AI is approved for real data.

Demonstration data

The Console's demonstration companies and every record in them are fictional and labelled as such. We use synthetic data for demonstrations, training and testing, never a customer's real records.

Data-subject requests

When a person asks to see, correct or delete personal data held in a customer's tenant, the customer decides the response, because it is the controller. We:

• pass the request to the customer without delay if it reaches us first;
• record the request in the Console's rights register with its type, jurisdiction, verification status, due date, owner and outcome;
• help the customer search, export, correct or delete the data within the approved scope.

We do not act on an unverified request by deleting data automatically.

Incidents

Security incidents are recorded in the Console's incident register with severity, affected data, containment and the time the customer was notified. If an incident affects a customer's data, we notify the customer without undue delay, with a target of 72 hours from when we become aware of it, so it can meet its own legal deadlines.

Before real customer data

The controls above are built and tested on fictional data. Before we admit a customer's real data we also need: a signed agreement and data processing addendum naming the customer as controller, a review of the laws that apply to that customer and its data subjects, an agreed retention period, an incident response plan and a named Speedloop person accountable for the tenant.