Privacy Policy
Effective date: 26 September 2026 Controller / operator: Trueness Corp (CNPJ 63.887.933/0001-62), Avenida Paulista, 1374 - Bela Vista, São Paulo - SP, 01310-100, Brazil, Brazil Data protection contact: trueness.lab@gmail.com
1. The one thing to read first: we wear two different hats
Almost every mistake in a policy like this comes from blurring these two roles, so we separate them before anything else.
| Your account data | Your billing data and your customers' data | |
|---|---|---|
| Examples | Your administrator's name and email, your company's billing details, your support emails to us, how you use the product | Your Stripe customers' names, emails, phone numbers, addresses and tax identifiers; your subscriptions, invoices, payments, refunds and credit notes |
| Our role | Controller (LGPD: controlador) | Processor (LGPD: operador) |
| Your role | Data subject, or the employer of one | Controller (LGPD: controlador) |
| Governed by | This policy | Your instructions, under our Data Processing Addendum — not by this policy |
Part A of this policy covers the first column. Part B describes, for transparency, what happens in the second — but the terms that actually bind us there are in the DPA, and the decisions about that data are yours, not ours.
2. Who we are
Trueness is built and operated by Trueness Corp, a trade name of the individual microentrepreneur (microempreendedor individual) registered in Brazil under CNPJ 63.887.933/0001-62, at Avenida Paulista, 1374 - Bela Vista, São Paulo - SP, 01310-100, Brazil.
| Role | Contact |
|---|---|
| Data protection contact, and LGPD encarregado under Art. 41 | trueness.lab@gmail.com |
| GDPR Article 27 representative in the Union | Not yet designated — see below. We have no customers established in the European Union at the date above |
| UK GDPR Article 27 representative | Not yet designated, and required only if we accept United Kingdom customers |
| Everything else | trueness.lab@gmail.com |
On the Article 27 representative, stated plainly because a missing name invites the wrong conclusion. We are not established in the European Union. Where we process the personal data of people in the Union, Article 27 GDPR requires us to designate a representative there in writing.
We have not designated one yet, because we do not yet have a customer established in the European Union. We will designate one, and publish its name and full postal address on this page, before we accept our first such customer — or sooner, if we become aware that our processing otherwise falls within Article 3(2) GDPR. Not at a revenue threshold, and not when somebody complains.
Once designated, you may address the representative instead of, or in addition to, us on any matter relating to our processing. Designating one does not reduce our own responsibility or liability. In the meantime, anything you would raise with a representative you can raise with us directly at trueness.lab@gmail.com, and we will answer it.
We do not rely on the Article 27(2) derogation. That derogation requires processing to be occasional, to exclude large-scale special-category data, and to be unlikely to result in a risk. Our processing is continuous and runs daily across our customers' whole customer bases, so the first condition alone defeats it.
On the encarregado. LGPD Article 41 requires a controller to appoint one and, under §1, to publish their contact details clearly. ANPD Resolution CD/ANPD No. 2/2022 relaxes the formal appointment for small-scale processing agents, provided a communication channel exists. We publish a contact either way, because a published channel is the point of the rule.
Part A — where we are the controller
This Part covers the personal data of our own customers' staff: the person who installs Trueness, the person who pays for it, and the person who emails us.
3. What we collect, why, and on what legal basis
| What | Where it comes from | Why we have it | Legal basis — GDPR | Legal basis — LGPD |
|---|---|---|---|---|
| Account identity — name, work email, HubSpot user id, HubSpot portal id and portal name | You, at installation, through HubSpot's OAuth flow | To create your account, to authenticate you, to know whose portal is whose | Art. 6(1)(b) — performance of a contract | Art. 7, V |
| Billing details — billing name, billing email, company name, billing address, tax identifier, country, and the payment status Stripe reports back to us | You, at checkout, through Stripe | To take payment, to issue invoices, to keep the tax records Brazilian law requires | Art. 6(1)(b), and Art. 6(1)(c) for the retention of tax records | Art. 7, V and Art. 7, II |
| Support correspondence — the emails you send us and our replies, including anything you attach | You | To answer you, and to keep a record of what was asked and answered | Art. 6(1)(b) and Art. 6(1)(f) | Art. 7, V and Art. 7, IX |
| Product usage events — which screens were opened, which reports were run, which plan was chosen, which errors occurred, tied to your portal id | Automatically, in the product | To find and fix faults, to see which parts of the product are used, to detect abuse | Art. 6(1)(f) — our legitimate interest in operating and improving a service you pay for | Art. 7, IX |
| Administrative records — the record written whenever a support session touches your tenant, and the record of an erasure we performed on your instruction | Automatically | So you can see what we did, and so we can prove what we did | Art. 6(1)(c) and Art. 6(1)(f) | Art. 7, II and Art. 7, IX |
| Security and access logs — application access records associated with the service | Automatically | Security, fault diagnosis, and the retention duty in Article 15 of Brazil's Marco Civil da Internet | Art. 6(1)(c) and Art. 6(1)(f) | Art. 7, II |
Our legitimate interests, stated rather than asserted. Where we rely on legitimate interest, the interest is: keeping the service running, diagnosing faults, preventing abuse of a free tier, and being able to show a customer what we did inside their account. We have considered that our customers' staff would reasonably expect each of these from a product of this kind, and none of it involves profiling, advertising, or any decision made about a person by a machine. You can object — see section 8.
We never ask for, and we never want: government identifiers of individuals, health data, biometric data, racial or ethnic origin, religious or political opinions, trade-union membership, sexual orientation, or anything else that is a special category under GDPR Article 9 or sensitive data under LGPD Article 5, II. We do not knowingly process children's data. Trueness is sold to businesses only.
4. What we never collect, from anyone, ever
No card data. No card number, no security code, no PIN, no magnetic-stripe or chip data — and also none of the fields that are not cardholder data, such as the card brand, the last four digits, the expiry month or year, the funding type or the card fingerprint. These are removed from every payload in memory, before anything is written to disk, and we record which paths were removed so we can prove it.
This is true because of how the product authenticates, not because of a filter we added afterwards. Trueness connects to Stripe through Stripe's app framework with read-only permissions and does not use Stripe Connect. It has no authorisation to move money and no interface that returns a card number to it. Trueness is consequently outside the scope of the PCI DSS.
No payment collection by us. Your card details are handled by Stripe, our payment processor, under Stripe's own terms. We see that a payment succeeded or failed, and the billing details you gave Stripe. We never see the card.
5. Who else sees it
- Our sub-processors, listed with their purpose and location at trueness.io/subprocessors. That page is part of this policy.
- Nobody else. We do not sell personal data. We do not share it with advertisers or data brokers. We run no advertising network and no third-party analytics script on the product.
- Authorities, where we are legally required to disclose. In Brazil, the content of stored records is released only under a court order, as Article 10 of the Marco Civil da Internet requires. Where we are permitted to tell you first, we will.
- A buyer of the business, if the company is ever sold or merged. You would be told before any personal data changed hands, and the buyer would be bound by this policy or by one no less protective.
6. How long we keep it
| What | How long | Why that long |
|---|---|---|
| Account identity | For as long as the installation exists, then 30 days | So a reinstall inside a month does not lose your settings |
| Billing and tax records | 5 years after the relationship ends | Brazilian commercial and tax record-keeping. Five years is the conservative figure; the contador confirms the exact period, and we will shorten it here if it proves shorter |
| Support correspondence | 3 years from the last message in the thread | So we can answer "what did you tell us last time" |
| Product usage events | 13 months | The same window the history will use, so a fault can be explained against the same period |
| Administrative access records and erasure records | 7 years | They are the evidence that we did what we said. They contain no personal data beyond an internal identifier |
| Application access logs | 6 months, as required by Article 15 of the Marco Civil da Internet, then deleted unless a court has ordered otherwise | Brazilian statutory duty on an application provider organised as a legal entity |
| Backups | 35 days, rolling | Disaster recovery |
Everything about your customers' data — which is Part B, where you are the controller — has its own retention table in section 11 and in the DPA.
7. Where your data is processed, and how it gets there
We are in Brazil. The computers are in the United States. Those are two separate transfers and they are carried by two different mechanisms. We set out both, because a vendor that claims one mechanism covers the whole chain is either careless or hoping you will not check.
| Leg | Mechanism |
|---|---|
| EEA → Brazil (to us) | An adequacy decision. No Standard Contractual Clauses are required. Commission Implementing Decision (EU) 2026/179 of 26 January 2026, adopted under Article 45 GDPR, found that Brazil provides an adequate level of protection. Brazil's ANPD adopted the reciprocal decision under LGPD Article 33 by Resolution CD/ANPD No. 32 of 26 January 2026. The two were announced together on 27 January 2026 |
| UK → Brazil | Not yet determined, and it does not need to be. We have no customer established in the United Kingdom. Before accepting one we will confirm the UK position on transfers to Brazil and appoint a UK representative if one is required — the same trigger as the EU representative. (The EU's adequacy decision for the United Kingdom, renewed 19 December 2025 to 27 December 2031, governs transfers to the UK and is not the answer to this one.) |
| Brazil → United States (to our infrastructure) | Carried by each sub-processor. Either the EU-US Data Privacy Framework where that sub-processor is certified, or the Standard Contractual Clauses in its own agreement. We check the mechanism when we sign, record what it was and the date we checked, and re-check annually |
| Brazil → anywhere, for a Brazilian-established customer | The standard contractual clauses established by ANPD Resolution CD/ANPD No. 19/2024, adopted in full and without modification. In practice this does not arise: Trueness is not sold to customers established in Brazil |
Processing locations. Compute runs on Google Cloud in us-east4 (Northern Virginia). The
database is Neon in aws-us-east-1 (Northern Virginia). Error monitoring is Sentry, in the United
States. Our uptime monitor is in the European Union and sees no personal data. The service is
administered by one person, from São Paulo.
Why the United States and not Europe. Trueness sits between HubSpot and Stripe and has to be close to both; both are primarily in the United States for non-EU accounts. We do not offer EU hosting today. If your procurement requires it, tell us — we would rather lose the deal honestly than describe a region we do not run in.
If adequacy is withdrawn. The Commission reviews adequacy decisions at least every four years and may suspend or repeal one. If the decision for Brazil is suspended, repealed or annulled, we will put Standard Contractual Clauses in place within the period stated in the DPA, and tell you when we have.
8. Your rights, and how to use them
If you are one of our customers' staff, you have the rights below over the data in Part A. Email trueness.lab@gmail.com. We answer within 30 days, or sooner where the law requires it, and we will tell you if we need longer and why.
| Right | What it means here |
|---|---|
| Confirmation and access (GDPR Art. 15; LGPD Art. 18, I and II) | We tell you whether we hold data about you and give you a copy |
| Rectification (GDPR Art. 16; LGPD Art. 18, III) | We correct anything wrong. Most account fields you can correct yourself |
| Erasure (GDPR Art. 17; LGPD Art. 18, IV and VI) | We delete your data, except where we must keep it — tax and commercial records under Brazilian law, access logs under the Marco Civil, and anything needed to establish, exercise or defend a legal claim |
| Restriction (GDPR Art. 18) | We stop processing while a dispute about accuracy or lawfulness is resolved |
| Portability (GDPR Art. 20; LGPD Art. 18, V) | Where we process on the basis of your consent or a contract, and by automated means, we give you a machine-readable copy |
| Objection (GDPR Art. 21) | You can object to anything we do on the basis of legitimate interest. We stop unless we have compelling grounds that override yours, and we will tell you what they are |
| Withdraw consent (GDPR Art. 7(3); LGPD Art. 18, IX) | Where we ever rely on consent, you can withdraw it at any time. Withdrawing it does not undo what was lawful before |
| Information about sharing (LGPD Art. 18, VII) | We tell you which public and private bodies your data was shared with — see section 5 |
| Complain (GDPR Art. 77; LGPD Art. 18, §1) | To your own supervisory authority in the EEA, to the ICO in the United Kingdom, or to Brazil's ANPD. You can also address our EU representative directly. We would rather you came to us first, but you do not have to |
No automated decisions. We make no decision about any individual by automated means that produces a legal effect or similarly significantly affects them, and we do not profile people. The product's automated decisions are about records — whether an invoice in HubSpot matches one in Stripe — not about people.
Proving who you are. Before we act on a request we need to be reasonably sure who is asking. We will ask you to verify from the email address we already hold, or by another proportionate means. We will not ask you for an identity document to answer an access request about an email address.
Part B — where we are the processor
9. What this part is, and what it is not
When you connect Trueness to your Stripe account and your HubSpot portal, everything that flows between them is yours. You decide what is processed and why. We act on your instructions. The binding terms are in the Data Processing Addendum, which is incorporated into the Terms of Service and which you can download without asking anyone for it.
This section describes what happens, because your own transparency notice to your customers may need to say it.
10. What flows through, and what does not
| Category | Fields | Whose data |
|---|---|---|
| Contact identifiers | Email, name, phone | Your customers |
| Company identifiers | Company name, domain, billing address | Your customers |
| Tax identifiers | Tax id value and type | Your customers |
| Billing metadata | Subscription, invoice and payment identifiers; amounts; currency; status; period start and end; proration; credit-note references | Relates to the above |
| Platform identifiers | Stripe object ids, HubSpot object ids, your HubSpot portal id | — |
| Never | Card data and every payment-instrument attribute; special categories under GDPR Article 9; sensitive data under LGPD Article 5, II; children's data | — |
What we do with it: read your Stripe billing records and your HubSpot portal, compare the two every day, and report every record where they disagree. A dated record of every sync decision, kept so the reason is still there months later, is coming in a later release. Nothing else. We do not use your data or your customers' data to train anything, to build a benchmark, to enrich a dataset, or to market to anyone.
11. How long we keep your data, and how deletion works
What is in service today, before the rest of this section applies. The free Drift Report reads your Stripe account and your HubSpot portal, compares them, and keeps the report it produced — Stripe identifiers, company names, amounts and dates — together with the raw Stripe events it read. It does not yet keep the permanent, append-only history described below, and it does not yet use the separate encrypted identifier store that goes with it. Rows marked with the history arrive when that does.
| What | How long |
|---|---|
| Report snapshots — your daily reports and the records they were computed from | The 90 most recent |
| Raw Stripe events | 90 days, then the payload is removed and an empty receipt row is kept |
| Credentials (your Stripe and HubSpot tokens) | Deleted in the same database transaction that handles your uninstall |
| With the history: every sync decision, every discrepancy, how it closed | 13 months, rolling, on every paid plan. Exportable at any time, without asking us |
| With the history: personal identifiers in the encrypted store | Life of the installation plus 30 days |
| With the history: after you cancel | Readable and exportable for 90 days, then destroyed — or sooner if you instruct erasure. The window exists because the history has audit value you may need after you have left |
| With the history: after that, if the app is also uninstalled | 30 days' notice with an export link, then destruction |
| With the history: chain checkpoints | 400 days, under a retention lock. They contain no customer data |
How erasure works today. There is no append-only record yet, so there is nothing here that cannot be deleted. When you instruct us to erase a person, or to delete your account entirely, we delete the rows. That is the whole mechanism. For the free Drift Report it is also the right one — a simpler answer than the one below, and we would rather give you the simple true answer than the impressive one.
How erasure will work once the history ships. We describe it now because it is the first question a reviewer asks, and because it is a decision that had to be taken when the database was designed rather than added afterwards.
The history will be append-only: rows never changed and never deleted, which is what will make it worth anything. So personal data will never be written into it. Identifiers will live in a separate store, encrypted under a key unique to each individual, and the history will hold only references.
When you instruct us to erase someone, we will destroy that person's key. From that moment their
data is permanently unreadable everywhere it exists — in the live database and in every backup we
have ever taken — without a single backup being touched. The row counts do not change. The chain
still verifies. A reference that no longer resolves renders as [erased]. The record still proves
what happened to an invoice and no longer says whose it was.
If we ever restore a backup taken before an erasure, the restore is not complete until the erasure log has been replayed against it. That step is in the runbook and the restore is not signed off without it.
Requests from your customers come to you, not to us. If one of your customers contacts us directly, we will point them to you and tell you they did. Acting on their request ourselves would be processing outside your instructions.
Both parts
12. Security
- In transit: TLS 1.2 or higher, everywhere.
- At rest: AES-256-GCM.
- Credentials: your Stripe and HubSpot tokens are encrypted under a per-tenant key, which is itself wrapped by a key held in a managed key service that never leaves the service boundary.
- Tenant isolation: enforced by PostgreSQL row-level security, at the query planner.
- Cloud access: least-privilege, with no static cloud credentials anywhere.
- Human access: exactly one person can reach production, with multi-factor authentication and a hardware security key. Support access to your tenant requires a written reason, writes a record you can see, and cannot happen silently.
- Error monitoring: personal fields, request bodies and payment-instrument fields are stripped before an event leaves our systems.
- Testing: a restore drill runs quarterly and is recorded.
We hold no third-party security certification and we will not imply that we do. What is listed above is what exists.
13. If something goes wrong
If personal data we hold is breached and you are our customer, we will tell you within 48 hours of becoming aware of it — deliberately inside your own 72-hour regulatory clock — and we will give you what Article 33(3) requires you to report: the nature of the breach, the categories and approximate numbers of people and records affected, the likely consequences, and what we have done about it. We will send that notice even when some of those numbers are still unknown, because a fast incomplete notice beats a slow complete one.
Where we are the controller and the breach is likely to result in a risk, we notify the relevant supervisory authority within 72 hours and, where the risk is high, the affected individuals without undue delay. Where Brazilian data subjects are affected and the incident may cause relevant risk or damage, we notify the ANPD and the affected individuals within the deadline set by ANPD Resolution CD/ANPD No. 15/2024.
14. Cookies and tracking
Our marketing site sets no cookies at all. Not one — not a preference cookie, not an analytics cookie, nothing. It is a static site: it ships no JavaScript, stores nothing in your browser, and loads no script, stylesheet, font or image from any third party. There is no advertising cookie, no analytics script and no tracking pixel, on the site or in our emails.
The product sets the cookies it needs to work, and only those. When you sign in to the application there is a session cookie so you stay signed in, and a preference cookie so the interface remembers your choices. Both are strictly necessary to provide a service you asked for, so we do not show you a consent banner for them — one would be theatre, since declining would only mean the product could not sign you in.
The report share link — the expiring, revocable link you can forward to a colleague who has no HubSpot seat — sets no cookie, carries no analytics and contains no third-party origin. It records only that it was opened and a non-reversible fingerprint that lets us count one opening twice instead of once; the IP address and browser string themselves are never stored, and the salt used rotates daily so openings cannot be joined across days.
If we ever add anything that is not strictly necessary — an analytics tool, for instance — we will ask for your consent first and this section will say so before it happens, not afterwards.
15. Changes to this policy
We will post any change here with a new effective date. Where a change materially affects how we handle personal data, we will email the administrator on each account at least 30 days before it takes effect. We will not make a material change retroactive.
Previous versions are available on request from trueness.lab@gmail.com.
16. How to reach a human
| Data protection, LGPD encarregado | trueness.lab@gmail.com |
| GDPR Article 27 representative in the Union | Not yet designated — section 2 explains when |
| UK Article 27 representative | Not yet designated; required only if we accept UK customers |
| Everything else | trueness.lab@gmail.com |
We answer in writing. There is no phone number — not for sales, not for support, and not for this. That is a deliberate design of the business, stated so you are not left waiting for a call that was never coming.