Personal Data Inventory
Taloflow adheres to the principle of data minimization. The table below enumerates every personal data category we collect, the specific fields involved, the purpose of collection, the legal basis under GDPR, and where the data is stored.
Data Inventory
Identity
email, first_name, last_name, full_name
Account creation, login, user identification
Contract performance
Auth0 (primary), PostgreSQL (member_id reference)
Authentication
auth0_id, hashed password
Secure login, session management
Contract performance
Auth0 (passwords never stored by Taloflow)
Profile
Avatar URL, nickname
User experience personalization
Legitimate interest
Auth0, Redis (encrypted cache)
Organization
Company name, legal name, org_type
Multi-tenant workspace management, billing
Contract performance
PostgreSQL (group_header, other_setup JSONB)
Contact (Org)
Addresses, phone numbers
Billing, legal correspondence
Contract performance
PostgreSQL (within other_setup JSONB)
Financial (Org)
tax_ids, billing_code
Invoicing, tax compliance
Legal obligation
PostgreSQL (org setup), Stripe (payment processing)
Expert Profile
expert_email, title, bio, timezone, rate
Expert marketplace features
Consent
PostgreSQL (expert entity)
Session / Audit
member_id, email, session timestamps, event type
Security monitoring, audit trail
Legitimate interest
PostgreSQL (user_session, audit_event)
Activity
Evaluation opens/creates, dashboard loads
Product analytics, audit trail
Legitimate interest
PostgreSQL (audit_event)
Data We Do Not Collect
Taloflow does not collect any of the following:
Biometric data
Health or medical data
Racial or ethnic origin
Political opinions or trade union membership
Geolocation tracking (beyond IP-derived timezone for expert profiles)
Social media activity
Browsing history outside the Taloflow platform
Payment card numbers (handled entirely by Stripe; never touch Taloflow servers)
Payment card data is submitted directly to Stripe via Stripe.js and is never transmitted to or stored on Taloflow infrastructure.
Internal Identifier Architecture
All inter-service references use member_id (UUID), not email or name. The mapping between member_id and PII is held only in the organization-resolver service and Auth0.
No other service holds the member_id-to-PII mapping. This limits PII exposure to a single, tightly controlled boundary, consistent with the pseudonymization principle.
Was this helpful?