Newtown Platform — Privacy Policy
Effective date: 2026-10-13 Last updated: 2026-10-13 Version: 1.2
This Privacy Policy explains how Newtown Analytics LLC ("Newtown," "we," "us") handles personal information in connection with the Newtown Platform (the "Service") and our website.
Newtown is a business-to-business company. The Service is not directed to individuals for personal use.
1. Two very different kinds of data
Almost every privacy question about this platform turns on which of these you mean.
Account data — where we are the controller. A small amount of information about the people who administer and sign in to the Service. We decide how it is used, and this Policy governs it.
Customer Data — where we are the processor. The business records that flow from a customer's source systems into their warehouse: invoices, charges, orders, customer records, payroll and banking records, and whatever else their connectors carry. These frequently contain personal information about *the customer's* customers and staff. The customer decides what to connect and why. We process it only on their instructions, under our [Data Processing Addendum](./data-processing-addendum.md).
If you are an individual whose data appears in a Newtown customer's warehouse, contact that company — we cannot answer for them, and we will refer you to them.
2. Account data we collect
We hold very little, and we do not build user profiles.
| What | Where it comes from | Why | |---|---|---| | Work email address | Your Google sign-in | Authenticate you; identify your workspace | | Email domain | Derived from your address | The domain *is* the workspace identifier | | Company name | Derived from your domain, editable by you | Display; billing | | Invite code, who redeemed it and when | Signup | Prove how a workspace came to exist; prevent abuse | | Session cookie | Created at sign-in | Keep you signed in for up to 24 hours | | Billing contact, payment method | You, via our payment processor | Take payment | | Support and other correspondence | You | Answer you | | Operational logs and telemetry | The Service | Run, secure, and debug the Service |
What we deliberately don't take. Our Google sign-in requests only the openid email scope. We do not receive or store your name, your profile photo, or your Google account identifier, and there is no user-profile record anywhere in the Service.
Where your email address does get written down. For completeness: the invite record that created your workspace stores the redeemer's address; the session cookie carries your address and workspace; and sign-in events are written to our operational logs. The session cookie is signed, not encrypted — its contents, including your email address, are readable by anyone who has the cookie.
Access tokens in logs. Machine access to the Service can use a token carried in a URL path. Because it is in the URL, it is written to our server request logs on every request, along with the calling client's user agent. That is a property of how URLs are logged, not a deliberate choice, and it is why we recommend OAuth and why we will rotate a token on request.
Payment cards. Card details go to our payment processor (currently Stripe) and are handled under its terms and PCI compliance. We never see or store your full card number. We receive only what we need to run the account: last four digits, card brand, expiry, billing contact, and subscription status.
Cookies. One strictly necessary cookie: the signed session cookie above. We run no advertising, analytics, tracking, or third-party marketing cookies on the application.
3. How we use account data
- To provide, operate, secure, and support the Service
- To authenticate you and enforce workspace boundaries
- To bill you and collect payment
- To communicate with you about the Service — outages, changes, security, billing, support, and contractual notices
- To detect, investigate, and prevent abuse, fraud, and security incidents
- To comply with legal obligations and to establish or defend legal claims
Where the GDPR or UK GDPR applies, our legal bases are contract, legitimate interests (security, abuse prevention, service improvement, and B2B communications about a service you already use), and legal obligation (tax and accounting).
We do not sell personal information. We do not share it for cross-context behavioral advertising. We do not use it for advertising at all.
We do not use account data or Customer Data to train, fine-tune, or develop machine-learning models, and we do not permit our AI provider to do so on our behalf.
4. Marketing
If you are a prospect, we may email you about Newtown's services under our legitimate interest in B2B outreach, and with your consent where required. Every marketing email carries an unsubscribe link and we honor it; those emails are sent from our Google Workspace accounts, and we do not use a third-party marketing-automation platform. We do not send marketing to workspace users based on their use of the Service without asking first. Service, security, billing, and contractual notices are not marketing and you cannot unsubscribe from them while you hold an account.
5. Customer Data — the data connectors carry
When a customer connects a source, business records land in a warehouse and are transformed into models the Service serves back to their AI client. Those records commonly include names, email addresses, billing and shipping addresses, phone numbers, transaction and invoice histories, subscription records, and — depending on the connector — payroll and bank account details.
For that data:
- The customer is the controller (or "business"); we are the processor (or "service provider").
- We process it only to provide the Service, on the customer's documented instructions, as set out in the Data Processing Addendum.
- We do not use it for our own purposes, do not sell it, do not share it for advertising, and do not train models on it.
- Newtown staff access to a workspace's content is off by default for new workspaces; the customer can turn it on, off, or on for 1 hour, 24 hours, or 7 days from the console, and can see a log of every staff access to the workspace's content while it is enabled. Workspaces that existed before these controls were introduced have access on and can be switched off. Regardless of the setting: automated platform operations (nightly builds and modeling runs, connector health checks, dormancy and billing notices) continue; operational, billing, and provisioning metadata containing no workspace content (name, plan, status, usage, health) remains visible to us; and access reasonably necessary to protect the security or integrity of the Service or to comply with law remains possible. The setting does not cover infrastructure-level administrators of our own cloud environment, who can technically reach stored data; that access is governed by confidentiality obligations, internal access controls, and cloud audit logs, not by the setting.
Source credentials. For sources connected through our ingestion provider, credentials are entered directly into that provider's own authorization window and never pass through our systems. For the small number of sources we support directly — currently Stripe — the customer supplies a read-only, restricted-scope key to us; we validate it with the provider, store it in Google Secret Manager, and read it server-side only. It is never written to a database, a log line, or an API response.
What our staff tooling shows. The staff warehouse inventory panel displays metadata only — dataset and table names, row counts, sizes, column counts — and does not display row contents, precisely because raw connector tables carry personal information. Separately, and by design, two parts of the Service do read row values: the schema profiler samples values from low-cardinality text columns in order to generate the onboarding interview and business context, and relationship verification stores a small number of example join-key values. Both happen only for tables where the customer has enabled "Sample values when profiling", which is off by default for all workspaces. Where enabled, those values are stored in the workspace's context and can appear in prompts we send to our AI provider.
Before the first build. Until a customer's first dbt build completes, the Service serves a raw connector dataset directly to their AI client, rather than governed models. Those are the tables carrying the most personal information.
Special categories. The Service is not designed for health information or children's data, and our Terms prohibit connecting sources carrying them without a separate agreement. Government identification numbers, bank account and routing numbers, cardholder data, biometric identifiers, and precise geolocation are permitted where they arrive through a standard connector, because accounting, payroll, banking, and payment connectors carry them; no additional technical safeguard is applied to them, and none of these restrictions is technically enforced.
6. Where your data goes
Our vendors are listed, with role and location, in the [subprocessor annex](./subprocessors.md) to our Data Processing Addendum. In summary:
| Vendor | What it does | What reaches it | |---|---|---| | Google Cloud Platform | Hosting, database, object storage, secrets, and the BigQuery warehouses | Account data and all Customer Data | | Google (Sign-In) | Authentication | Your email address and domain | | Google Workspace | Our own email, documents, and support correspondence | Anything you send us, and anything we send you | | Fivetran | Ingestion from customer sources | Source credentials (entered directly with them), the loader credential for your warehouse, and the records they sync | | Anthropic | The model our internal data-modeling agents call | Business context, schema, table and column names, metric definitions, dbt model source, change-request text, and query text; sampled column values and example join-key values only where the customer enabled sampling | | GitHub | Hosts each customer's generated dbt project | Model SQL, tests, documentation, schema and column names | | Stripe | Payment processing | Billing contact and payment method |
What we send to our AI provider. Our modeling and surveying agents call Anthropic's API when a Newtown operator runs a pass on a workspace and on a nightly schedule for every active workspace. Prompts can include accumulated business context, warehouse schema, table and column names, metric definitions, dbt model source, change-request text, and — for questions asked through your AI client — that query's SQL text, which can contain literal values. Row values from your tables are not sent or stored unless you enabled "Sample values when profiling" for that table (off by default); where enabled, sampled values from low-cardinality columns and example join-key values can appear in prompts. The query-serving path calls no model at all.
Your own AI client is not our vendor. When you connect Claude, ChatGPT, or another AI client to the MCP endpoint, query results travel to that provider under your own account and your own agreement with them. We do not control it and are not a party to it. Read their retention and training terms before connecting a workspace holding sensitive records.
International transfers. We operate in the United States and our infrastructure runs in U.S. regions; warehouse datasets we provision default to a U.S. multi-region location. A customer who connects their own warehouse may locate it wherever they choose, including outside the U.S. Using the Service from outside the U.S. means data is transferred to and processed in the United States. Where the GDPR or UK GDPR applies, transfers rely on the European Commission's Standard Contractual Clauses, incorporated by our Data Processing Addendum.
7. How we protect it
We rely on our cloud provider's platform controls and on a few deliberate architectural choices:
- Encryption in transit. Every production endpoint is served over HTTPS by our cloud provider's front end. Encryption at rest is applied by default to all storage — warehouse datasets, control-plane database, object storage, and secrets — using provider-managed keys. Customer-managed encryption keys are not offered.
- Tenant isolation at the warehouse layer. Each customer gets a dedicated cloud project with its own scoped service account, so a query in one workspace cannot reach another's data. There is no shared multi-tenant dataset.
- Source and warehouse credentials never touch the database, a log line, or an API response. They live only in the cloud provider's secret manager. This applies to credentials; it does not apply to the URL-path access token described in Section 2.
- Sessions expire after 24 hours. Workspace membership is verified server-side against Google's signed token, never trusted from the browser.
- OAuth 2.1 with PKCE is available for machine access and is what we recommend.
Being straight with you about the limits: Newtown is a small company and holds no SOC 2, ISO 27001, HIPAA, or PCI certification. We provide a customer-visible log of Newtown staff access to your workspace's content (see above; it does not cover infrastructure-level administrator access or cloud provider logs), and we do not make a backup or recovery commitment — warehouse contents are re-ingestible from your sources and the generated project is held in version control, but you should keep your own copies of anything you cannot afford to lose. Our current security posture, in more detail and kept up to date, is described in Annex II to the Data Processing Addendum and in our security overview, available on request.
No system is perfectly secure. If we discover a breach affecting account data we control, we will notify you without undue delay at your notice address, and where the law requires, the relevant authorities. Breaches affecting Customer Data are handled under the Data Processing Addendum, which commits us to notify the customer without undue delay and in any event within 72 hours of confirming an incident.
Report a security issue to security@newtowndata.io.
8. How long we keep it
| Data | Retention | |---|---| | Session cookie | 24 hours | | Account and workspace records | Life of the account, then suspended and deleted three months after termination — earlier on request | | Customer Data in a warehouse we provisioned | Life of the account, then deleted with the cloud project three months after termination — earlier on request | | Business context, glossary, and metric definitions | Same as above | | Generated dbt repository | Same as above | | Invite records, including the redeemer's email address | Retained as the record of how a workspace was created. There is no automated deletion job for these today; we delete them on request | | Machine-authorization records (registered clients and issued tokens for MCP access) | Not deleted automatically when a workspace closes; deleted on request | | A source credential you supplied to us directly | Retained in the secret store until you ask us to delete it, or the account is closed and you request deletion | | Billing and tax records | 7 years, as required by U.S. tax law | | Operational logs | Our cloud provider's default log retention, currently 30 days |
Closing a workspace suspends access and disables credentials; we can restore it on request for 30 days after closure, and staff permanently delete no earlier than 30 days after closure, with the three-month outer date above unchanged. Deleting a cloud project is not instantaneous — the provider holds it in a recoverable state for roughly 30 days before permanent deletion. Backups and logs age out on their own schedules. Nothing that survives is used for any purpose other than completing the deletion.
9. Your rights
If you hold an account with us, email privacy@newtowndata.io to access, correct, delete, or export your account data, or to object to or restrict a processing activity. We verify you through your workspace email address and will respond within 45 days, extendable by a further 45 where the law permits and we tell you why. Under the GDPR and UK GDPR we respond within one month, extendable by two.
If you are an individual whose data appears in a customer's warehouse, we are the processor, not the controller. Contact the company you dealt with. If you contact us we will refer you to them and, where the law requires, notify them of your request.
Depending on where you live you may have rights to know, access, correct, delete, port, opt out of sale or sharing (we do neither), limit use of sensitive information, appeal a refusal, and not be retaliated against for exercising a right. Residents of California, Colorado, Connecticut, Virginia, and other U.S. states with comprehensive privacy laws have these rights; so do individuals in the EEA, UK, and Switzerland, who may additionally complain to their supervisory authority.
We do not carry out automated decision-making that produces legal or similarly significant effects about individuals.
10. Children
The Service is for businesses. It is not directed to anyone under 18 and we do not knowingly collect account data from children. Our Terms prohibit connecting sources carrying data about children under 13, or under 16 where local law requires parental consent. If you believe a child's data has reached us in error, write to privacy@newtowndata.io and we will delete it.
11. Changes
We may update this Policy. For material changes we will give at least 30 days' notice to your notice address or by in-product notice, and update the date above. We keep an archive of prior versions.
12. Contact
Privacy: privacy@newtowndata.io · Security: security@newtowndata.io · Legal: legal@newtowndata.io
Newtown Analytics LLC · New York · United States
EU/UK representative. The Service is offered to customers in the EEA, UK, and Switzerland, so Article 27 GDPR and its UK GDPR equivalent apply. [OPEN — an Article 27 representative has not yet been appointed.] Appoint one (a paid EU representative service, e.g. DataRep or VeraSafe) and name them here, with their contact details, before this Policy is served to an EEA, UK, or Swiss customer.