Data Processing Addendum
Effective date: 26 September 2026
This Addendum forms part of the Terms of Service between you ("Customer") and Trueness Corp, a trade name of the individual microentrepreneur (microempreendedor individual) registered in Brazil under CNPJ 63.887.933/0001-62, of Avenida Paulista, 1374 - Bela Vista, São Paulo - SP, 01310-100, Brazil ("Trueness", "we", "us"). It applies automatically from the date you accept the Terms of Service. You do not need to sign it, ask for it, or fill in a form to get it — it is published here because there is nobody here to email it to you.
If your organisation requires a counter-signed copy, email trueness.lab@gmail.com and we will sign this document unaltered. We do not negotiate redlines to it; the reason is in section 13.
1. Which of us is which
Our role is split, and both halves are stated here so neither is inferred.
| Data | Trueness is | Customer is |
|---|---|---|
| Everything synced between the Customer's Stripe account and the Customer's HubSpot portal — the Customer's own CRM records, invoices, subscriptions, and the Customer's own customers' contact details | Processor (operador) | Controller (controlador) |
| The Customer's own account data — the administrator's login, billing records, support correspondence, product usage events | Controller (controlador) | The Customer's staff are the data subjects |
This Addendum governs the first row only. The second row is governed by our Privacy Policy, Part A.
Stripe and HubSpot are not our sub-processors. We do not send Customer data to them. We read from one and write to the other under the Customer's own credentials, into the Customer's own accounts, under the Customer's own agreements with those companies. They are the Customer's processors or independent controllers, not ours. Our sub-processors are the parties we engage, listed at trueness.io/subprocessors.
2. Definitions
"Applicable Data Protection Law" means, as each applies: Regulation (EU) 2016/679 ("GDPR"); the GDPR as it forms part of the law of the United Kingdom ("UK GDPR") together with the Data Protection Act 2018; Brazil's Lei nº 13.709/2018 ("LGPD"); and any other data protection law applicable to a party's processing under this Addendum.
"Customer Personal Data" means personal data within the first row of section 1, processed by us on the Customer's behalf.
"Data subject", "personal data", "personal data breach", "processing", "controller", "processor" and "supervisory authority" carry the meanings given in the GDPR; their LGPD equivalents (titular, dado pessoal, incidente de segurança, tratamento, controlador, operador, autoridade nacional) are to be read alongside them.
"Sub-processor" means a third party we engage to process Customer Personal Data.
3. Subject matter, duration, nature and purpose; data and data subjects
| Required item | The answer for this service |
|---|---|
| Subject matter | Mirroring the Customer's Stripe billing records into app objects in the Customer's HubSpot portal, comparing the two daily, reporting every record where they disagree, and maintaining a dated record of every sync decision |
| Duration | For as long as the Customer's subscription or installation is live, plus the retention periods in section 10 |
| Nature of the processing | Reading, structuring, storing, encrypting, comparing, reporting on, exporting and destroying. Read-only from Stripe. Writes go only to app objects and to trueness_-prefixed roll-up properties inside the Customer's own HubSpot portal. Never to HubSpot's native invoice, subscription, payment, quote or order objects |
| Purpose | Delivering the service to the Customer under the Terms of Service, and nothing else |
| Types of personal data | Contact identifiers (email, name, phone); company identifiers (company name, domain, billing address); tax identifiers (value and type); and billing metadata linked to them (subscription, invoice and payment identifiers, amounts, currency, status, period dates, proration, credit-note references). No payment card data and no payment-instrument attribute of any kind. No special categories under GDPR Article 9 or sensitive data under LGPD Article 5, II. No children's data |
| Categories of data subjects | The Customer's own customers, and the Customer's staff named on those records |
4. Processing only on documented instructions
4.1 We process Customer Personal Data only on the Customer's documented instructions, including in relation to transfers to a third country, unless required to do otherwise by law that applies to us. Where such a law applies, we will tell the Customer before processing, unless that law forbids us from doing so on important grounds of public interest.
4.2 The Customer's documented instructions are: (a) this Addendum; (b) the Terms of Service; (c) the configuration the Customer sets in the product; and (d) any further written instruction the Customer gives us that is consistent with the service. The Customer instructs us to: mirror its Stripe billing data into its HubSpot portal, detect and report discrepancies, retain the audit trail, and produce exports on request.
4.3 We will tell the Customer if, in our opinion, an instruction infringes Applicable Data Protection Law. We may suspend the affected processing until the instruction is withdrawn or amended.
4.4 We will not use Customer Personal Data to train any model, build any benchmark or dataset, enrich any product, market to anyone, or for any purpose of our own. We will not sell it. There is no exception to this clause.
4.5 The Customer warrants that it has a lawful basis for the processing it instructs, that it has given its own data subjects whatever information Applicable Data Protection Law requires, and that its instructions comply with that law.
5. Confidentiality
5.1 Exactly one natural person has access to production systems and therefore to Customer Personal Data. There are no employees, contractors, support tiers or shared accounts.
5.2 That person is bound by the confidentiality obligations of the Terms of Service directly, as the operator of Trueness Corp, and those obligations survive the end of this Addendum.
5.3 If that ever changes, every additional person with access will be bound by a written confidentiality obligation no less protective than this section before being given access, and we will update our sub-processor page and our security description accordingly.
6. Security measures
6.1 We implement and maintain the following technical and organisational measures. They are described specifically so they can be checked, rather than asserted so they cannot.
| Area | Measure | GDPR Art. 32 reference |
|---|---|---|
| Encryption in transit | TLS 1.2 or higher on every connection | 32(1)(a) |
| Encryption at rest | AES-256-GCM | 32(1)(a) |
| Pseudonymisation | Applies once the append-only history ships. Personal identifiers are held in a separate encrypted store under a key unique to each data subject; the history holds only opaque references, never a personal-data value. Before then the free Drift Report resolves identifiers in memory for each pass and stores none of them | 32(1)(a) |
| Credential protection | The Customer's 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. Additional authenticated data binds each ciphertext to its tenant | 32(1)(b) |
| Tenant isolation | PostgreSQL row-level security, enforced at the query planner rather than by application code | 32(1)(b) |
| Access control | Least-privilege cloud IAM with no static cloud credentials anywhere; deployment authenticates by workload identity federation; multi-factor authentication with a hardware security key on every administrative system | 32(1)(b) |
| Administrative accountability | Support access to a tenant requires a written reason, writes an administrative record visible to the Customer in its own activity view, and has no silent path | 32(1)(b) |
| Payment data | No payment card data and no payment-instrument attribute is processed or stored at any point. Payment-instrument fields are removed from every payload in memory before it is written to disk, and the removed paths are recorded | 32(1)(b) |
| Monitoring hygiene | Contact names, emails, phone numbers, addresses, tax identifiers, request bodies and payment-instrument fields are stripped before any event reaches our error-monitoring provider | 32(1)(b) |
| Availability and restoration | A nightly encrypted logical dump retained 35 days, plus point-in-time restore. A dump whose row counts fall below the previous night's fails the job and raises an alert | 32(1)(c) |
| Integrity | Coming in a later release, once the history ledger ships: every sync decision will be written once and never altered, update and delete permissions on those tables will be revoked at the database with a trigger rejecting the attempt, each entry will be hash-chained to the previous one, and a weekly checkpoint will be written to storage under a retention lock that nobody, including us, can lift early | 32(1)(b) |
| Regular testing | A restore drill and a wind-down drill run quarterly against a disposable database branch, and each writes a dated record. Automated dependency and vulnerability scanning runs in the build pipeline | 32(1)(d) |
6.2 We hold no third-party security certification and make no claim to one. Section 6.1 describes what exists. If the Customer requires an independent attestation, section 13 explains how we would approach it.
6.3 We may update these measures, provided the overall level of security is not reduced.
7. Sub-processors
7.1 The Customer gives general written authorisation for us to engage sub-processors. The current list, with each one's purpose and processing location, is published at trueness.io/subprocessors and forms part of this Addendum.
7.2 We give 30 days' written notice, by email to the Customer's registered administrator and by updating that page, before a new sub-processor begins processing Customer Personal Data or before an existing one's role changes materially.
7.3 Within those 30 days the Customer may object in writing on reasonable data-protection grounds. We will work with the Customer to find an alternative. If we cannot, the Customer may terminate the affected part of the service, and we will refund any unused prepaid term on a pro-rata basis.
7.4 Each sub-processor is engaged under a written contract imposing obligations that in substance protect Customer Personal Data no less than this Addendum does. Where a sub-processor fails to meet those obligations, we remain fully liable to the Customer for its performance.
7.5 Where we must replace a sub-processor urgently — because it has failed, or has become a security risk — we will notify the Customer as soon as we are able, and clause 7.3 still applies.
8. International transfers
8.1 Two separate legs, two separate mechanisms. We state both, because a claim that one covers the whole chain would be false.
| Leg | Mechanism |
|---|---|
| EEA → Brazil (to us) | An adequacy decision under Article 45 GDPR. No Standard Contractual Clauses, Binding Corporate Rules or other Chapter V transfer tool is required. Commission Implementing Decision (EU) 2026/179 of 26 January 2026 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. Its scope was confirmed on 23 September 2026 from the EUR-Lex record and corroborating legal commentary, which agree that it covers private-sector as well as public-sector processing, but not yet by reading the instrument end to end. We have no Customer established in the EEA, so nothing relies on it today; the full read happens before the first one is accepted, on the same trigger as the Article 27 representative |
| Brazil → United States (to our infrastructure) | Carried by each sub-processor individually: either its EU-US Data Privacy Framework certification, or the Standard Contractual Clauses in its own data processing agreement. We verify each one's status at signing, record the mechanism and the date checked in an internal register, and re-verify annually. Adequacy for Brazil does not cover this leg and we do not claim that it does |
| 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. |
| Brazil → outside Brazil, for a Brazil-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: the service is not sold to customers established in Brazil |
8.2 Processing location. Customer Personal Data is processed in the United States — compute
in Google Cloud us-east4 and the database in Neon aws-us-east-1, both in Northern Virginia. The
service is administered by one person from São Paulo, Brazil. We do not offer EU-region hosting.
8.3 If adequacy changes. If Commission Implementing Decision (EU) 2026/179 is suspended, repealed or annulled, or ceases to cover this processing, we will, within 30 days of that taking effect, execute the Commission's Standard Contractual Clauses (currently those in Implementing Decision (EU) 2021/914, controller-to-processor Module Two) with each affected Customer, or put another valid Chapter V mechanism in place, and notify each affected Customer that we have done so. Adequacy decisions are reviewed by the Commission at least every four years; this clause exists because that is a foreseeable event, not a remote one.
8.4 We will not make an onward transfer of Customer Personal Data to a country outside those described here without a valid transfer mechanism.
9. Assistance with data subject rights
9.1 Requests from data subjects come to the Customer, who is the controller. If a data subject contacts us directly, we will not respond on the merits; we will tell them to contact the Customer, and tell the Customer that they did. Acting on such a request ourselves would be processing outside the Customer's instructions.
9.2 We assist the Customer with the following, within 10 business days of a written instruction:
| Request | What we do |
|---|---|
| Access and portability (GDPR Arts. 15, 20; LGPD Art. 18, II and V) | Produce every record referencing the data subject, in JSON and CSV, with the encrypted identifiers resolved |
| Erasure (GDPR Art. 17; LGPD Art. 18, IV) | Destroy the data subject's encryption key — see section 11 |
| Full export of the Customer's own data | Self-serve, at any time, without asking us. The export bundle verifies on its own, without Trueness |
| Full deletion of the Customer's tenant | Destroy every subject key, then delete every tenant-scoped row |
| Rectification (GDPR Art. 16; LGPD Art. 18, III) | The correction is made in Stripe. Trueness is a one-way projection of Stripe and holds no write path back to it; the next daily pass propagates the corrected value. We will confirm when it has |
9.3 These paths are built and exercised against synthetic tenants in our build pipeline before each release. An untested deletion path is a contractual promise that cannot be kept, and we do not intend to make one.
9.4 We also assist the Customer, taking into account the nature of the processing and the information available to us, with its obligations under GDPR Articles 32 to 36 — security, personal data breach notification, data protection impact assessment and prior consultation.
10. Retention, return and deletion
10.1 While the subscription is live:
| Data | Retention |
|---|---|
| The history — every sync decision, every discrepancy, how it closed | 13 months, rolling, on every paid plan. It is not a plan fence. Export is unlimited and self-serve |
| Raw Stripe events | 90 days, then the payload is removed and an empty receipt row is retained |
| Personal identifiers in the encrypted store | Life of the installation plus 30 days |
| The Customer's Stripe and HubSpot credentials | Deleted in the same database transaction that handles the uninstall or disconnection. We attempt remote revocation first, while we still hold a usable token, and delete locally whether or not that succeeds |
| Chain checkpoints | 400 days, under a retention lock. They contain no Customer Personal Data |
10.2 After termination. Customer Personal Data remains readable and exportable for 90 days after the subscription ends. At the end of that period it is destroyed as described in section 11 — or earlier, on the Customer's written instruction.
Why the window exists. The history has audit value the Customer may need after it has left — a question about last year's invoices does not stop being asked because the subscription did. The Customer may shorten the window to zero at any time by instructing deletion.
10.3 Uninstalling is not termination. Uninstalling the HubSpot app deletes our copy of the Customer's credentials but does not delete the history, and does not cancel the subscription. A Customer who reinstalls expects the record to still be there; a Customer who wants it gone can ask, and that is a separate and explicit act.
10.4 What we keep after deletion, and why. Administrative access records and erasure records are retained for 7 years. They contain no personal data beyond an internal identifier that resolves to nothing once the key is destroyed. They are the evidence that the deletion happened.
10.5 We provide written confirmation of deletion on request.
11. How erasure actually works
11.1 The history is append-only. Rows are never updated and never deleted; that is enforced by the database, and it is the entire evidentiary value of the product. Erasure and immutability are both absolute requirements, and only one structure satisfies both.
11.2 Personal data is never written into the history. Identifiers live in a separate store, encrypted under a key unique to each data subject. The history holds only opaque references.
11.3 Erasure is executed by destroying that data subject's key. On a verified instruction we: (a) resolve the internal subject identifier; (b) delete the key; (c) delete the lookup entry; (d) delete the ciphertext as hygiene — the erasure already happened at step (b); (e) write an append-only erasure record containing no personal data; and (f) append an entry to the history recording that an erasure occurred, without recording whose.
11.4 The effects, stated plainly:
- The data is permanently unreadable everywhere it exists, including in every backup ever taken, from the moment the key is destroyed. No backup is touched, and no restore-delete-redump cycle is needed — the procedure many vendors describe and few perform.
- Row counts do not change and the hash chain still verifies. The record still proves what
happened to an invoice and no longer says whose it was. A reference that no longer resolves
renders as
[erased]in the product and in every export. - A backup restored from before an erasure would restore the wrapped key, so the restore runbook replays the erasure record as a mandatory final step. The restore is not complete until it does.
11.5 Erasure is irreversible and has no undo. It requires a typed confirmation of the subject's identifier and writes an administrative record. There is no bulk-erasure interface.
12. Personal data breaches
12.1 We notify the Customer of a personal data breach affecting Customer Personal Data without undue delay and in any event within 48 hours of becoming aware of it. The clock starts at awareness, not at confirmation and not at containment.
12.2 The notice will contain, as far as we know it at the time: the nature of the breach; the categories and approximate number of data subjects and of records concerned; our data protection contact; the likely consequences; and the measures taken or proposed. We will send the notice even where some of those figures are still unknown, and supplement it as we learn more. A fast incomplete notice beats a slow complete one, and the deadline attaches to the notice rather than to its completeness.
12.3 We do not notify a supervisory authority or the Customer's data subjects on the Customer's behalf. That is the Customer's obligation and the Customer's decision. We give the Customer what it needs to meet its own 72-hour clock.
12.4 Where we are the controller of our own account data, our own notification obligations under GDPR Articles 33 and 34, and under LGPD Article 48 with ANPD Resolution CD/ANPD No. 15/2024, apply separately.
12.5 We keep a record of every personal data breach, its effects and the remedial action taken.
13. Audits
13.1 We make available all the information necessary to demonstrate compliance with this Addendum. That information is already published: this document, the sub-processor list, the trust page and the security overview.
13.2 In addition, we will answer one written security questionnaire per Customer per calendar year, within two business days of receiving it.
13.3 We do not offer on-site audits or inspections, and we do not take calls. We are a one-person operation and cannot honour an on-site commitment; agreeing to something unhonourable would be worse than declining it. Where Applicable Data Protection Law gives the Customer an audit right that clauses 13.1 and 13.2 do not satisfy, the parties will discuss in good faith a proportionate alternative at the Customer's cost, and we will not unreasonably withhold cooperation.
13.4 The Customer will treat anything we disclose under this section as confidential.
14. Records of processing
We maintain a written record of the categories of processing carried out on behalf of each Customer, the identity of each controller and sub-processor, the transfers described in section 8, and a general description of the measures in section 6. We make it available to a supervisory authority on request. We do not rely on the Article 30(5) derogation for small organisations, because our processing is not occasional.
15. The LGPD provisions
15.1 We act as operador for Customer Personal Data and process it under the Customer's instructions, per LGPD Article 39.
15.2 The Customer, as controlador, determines the legal basis under LGPD Article 7 for the processing it instructs.
15.3 Our encarregado — the channel for data subjects and for the ANPD under LGPD Article 41 — is reachable at trueness.lab@gmail.com, and is published at trueness.io/privacy and trueness.io/subprocessors.
15.4 We keep records of processing operations under LGPD Article 37 and maintain the security measures required by LGPD Articles 46, 47 and 49, as described in section 6.
15.5 For any transfer originating in Brazil that requires it, the standard contractual clauses established by ANPD Resolution CD/ANPD No. 19/2024 apply, adopted in full and without modification.
16. The EU representative
No representative is designated at the date of this Addendum, because we have no Customer established in the European Union. We will designate one under GDPR Article 27, and publish its name and full postal address in our Privacy Policy and on our sub-processor page, before the first such Customer is accepted — or sooner, if our processing otherwise falls within Article 3(2) GDPR.
Once designated, the representative may be addressed by supervisory authorities and by data subjects, in addition to or instead of us, on all issues relating to our processing. The representative will not be one of our sub-processors.
Where we accept Customers in the United Kingdom, a separate representative under UK GDPR Article 27 will be designated on the same basis. An EU representative does not satisfy the UK obligation.
17. Liability, term and precedence
17.1 This Addendum takes effect when the Customer accepts the Terms of Service and continues for as long as we process Customer Personal Data.
17.2 The limitations and exclusions of liability in the Terms of Service apply to this Addendum, and the Customer's and our total liability under both together is capped as stated there, to the extent Applicable Data Protection Law permits. Nothing in this Addendum limits either party's liability to a data subject, or to a supervisory authority, under Applicable Data Protection Law.
17.3 If this Addendum and the Terms of Service conflict on the processing of Customer Personal Data, this Addendum governs. If this Addendum conflicts with the Commission's Standard Contractual Clauses where those are in force between the parties, the Clauses govern.
17.4 If a court or a supervisory authority holds any clause invalid, the rest continues in force.
17.5 We may update this Addendum where a change in law or in our operations requires it. We will give the Customer 30 days' notice of any change that materially reduces the protections here, and the Customer may terminate the affected service within that period with a pro-rata refund of unused prepaid term if it does not accept the change.
17.6 Governing law and venue are as stated in the Terms of Service: the laws of the Federative Republic of Brazil, and the courts of the City of São Paulo.
18. Contact
| Purpose | Contact |
|---|---|
| Data protection, LGPD encarregado | trueness.lab@gmail.com |
| GDPR Article 27 representative in the Union | Not yet designated — section 16 explains when |
| UK GDPR Article 27 representative | Not yet designated; required only if we accept UK Customers |
| A counter-signed copy of this Addendum | trueness.lab@gmail.com |
| A security questionnaire | trueness.lab@gmail.com |