trust
security, privacy, and how pilar handles data.
This page describes how Pilar handles data, security, and regulatory obligations. It is the technical reference we ask CISOs, DPOs, and procurement teams to review before deployment.
For a shorter summary, see the "what you see, what you don't" section on our home page. For the full detail, keep reading.
Some implementation details — including specific rate-limit budgets, dependency version pinning, and internal escalation procedures — are held back from public documentation for defensive reasons. These are available under NDA to enterprise prospects and customers during due diligence.
Data separation — what employers see and don't see
Employer separation is architectural.
Pilar is designed so that no individual employee's financial data is ever accessible to their employer. This separation is enforced at multiple layers and cannot be overridden by administrative action or contractual request.
Employers with active Pilar deployments have access to:
- —Activation rate (percentage of employees who have logged in)
- —Aggregate engagement metrics (average sessions, course completion)
- —Anonymous wellbeing score movement (org-wide, over time)
- —Anonymous NPS responses (aggregated, never linked to identity)
- —Content performance data (which chapters are completed most)
- —Aggregate opt-in demographic data (org-wide only)
Employers never have access to:
- —Any individual employee's financial account information, balances, transactions, income, savings, debts, or net worth
- —Any individual employee's stated financial goals or plans
- —Any individual employee's session-level activity or content history
- —Any individual employee's identity in connection with wellbeing scores, NPS responses, or aggregate reports
- —Aggregated cohort data below a minimum group size sufficient to prevent re-identification
This separation is enforced through:
- —Physical database separation: employee identity data is stored on a distinct instance from financial and behavioural data, so a compromise of either surface cannot re-link the two
- —Application-layer ownership checks enforced by a single reusable authorisation dependency across every endpoint that touches user-owned resources, covered by a dedicated test suite
- —Audit logging of all administrative access to production data
- —External security audit programme (see Section 4)
Data protection — encryption, storage, access
All employee data is encrypted at rest and in transit.
Encryption in transit
- —TLS enforced end-to-end with modern cipher suites
- —HTTP Strict Transport Security enabled with preload eligibility
- —Enforced at both the CDN edge and the application layer
Encryption at rest
- —AES-256 encryption of all databases and backups
- —Field-level encryption applied to a defined set of sensitive columns, on top of full-disk encryption
- —Encryption key management via managed cloud secret providers, with per-deployment rotation on any suspected exposure
Authentication and password handling
- —User passwords are cryptographically hashed via Supabase Auth using industry-standard algorithms
- —Strong password requirements aligned with NIST SP 800-63B guidance; no arbitrary character-class rules
- —Password strength assessed at registration
- —Asymmetric JWT verification against Supabase JWKS on every authenticated request
HTTP security headers (applied to every response)
- —Content-Security-Policy
- —Strict-Transport-Security (HSTS)
- —X-Frame-Options
- —X-Content-Type-Options
- —Referrer-Policy
- —Permissions-Policy
Data residency
- —Employee data is stored in EU regions across all subprocessors (see Section 5). No employee personal data is transferred outside the EEA for processing or storage.
- —Where a subprocessor operates infrastructure outside the EEA (backup regions or metadata), data transfer is governed by European Commission Standard Contractual Clauses and supplementary technical measures consistent with Schrems II guidance.
Access to production data
- —Access to production databases is limited to named engineering personnel, requires hardware-key two-factor authentication, and every access event is logged.
- —Application code is designed so that no operational task requires reading an individual user's financial account information. Database administrator access exists for infrastructure operations but is logged and subject to audit review.
Regulatory posture — MiFID II, PSD2, GDPR, DORA
Pilar operates in Europe under the following regulatory framework.
MiFID II
Pilar provides financial information and educational content. Pilar does not provide investment advice, portfolio management, or personal recommendations as defined under MiFID II Article 4(1)(4). Pilar does not manage client assets and is not authorised as an investment firm. Educational content is designed by CFA-charter holders and reviewed by academic partners; no output from Pilar constitutes a personal recommendation to any individual.
PSD2
Pilar currently ingests bank account data via user-uploaded CSV statements, with no direct connection to bank APIs. Where Pilar introduces direct account information services in future, integration will be via licensed Account Information Service Providers (AISPs) operating under PSD2 authorisation. Pilar does not initiate payments, hold customer funds, or perform any Payment Initiation Service Provider (PISP) functions.
GDPR
Pilar acts as a data controller for individual user data and processes data on the basis of user consent (Article 6(1)(a)) and contract performance (Article 6(1)(b)). Where an employer contracts Pilar for its workforce, Pilar remains the controller of individual employee data; the employer is not a joint controller of individual data and cannot compel disclosure of it under any contractual provision. Employer aggregate reporting is provided pursuant to a separate processing basis.
DORA
Pilar is not currently in scope of the Digital Operational Resilience Act as a regulated financial entity. We monitor operational resilience standards applicable to our fintech-adjacent operations and align to them where relevant.
Data Protection Officer: [email protected]
Regulatory / compliance: [email protected]
Security certifications and audits
Pilar's current security posture:
External security audit programme
Pilar has completed one comprehensive external security audit and is beginning a second in September 2026. The first audit produced a multi-phase remediation programme covering credential hygiene, input validation, authorisation, injection resistance, security headers, rate limiting, JWT hardening, and CI security scanning. All critical and high findings from the first audit have been remediated and independently re-verified. A summary of findings and remediations is available under NDA to enterprise prospects and customers.
Penetration testing
Full external penetration test scheduled for Q4 2026. Report will be available under NDA to enterprise prospects and customers.
ISO 27001
Certification programme initiated in Q1 2027. Target completion: Q2 2027. Progress and interim controls documentation available on request.
SOC 2 Type II
Under evaluation for 2027, subject to demand from enterprise customers.
Continuous security scanning (in production today)
- —Static application security testing (SAST) on every commit
- —Dependency vulnerability scanning with automated pull requests on any published CVE, and disciplined patching within the CVE publication window
- —Secret scanning in the codebase and pre-commit hooks
- —Regular expression denial-of-service (ReDoS) static analysis and runtime timing checks
- —All security-scanning jobs are required to pass before deployment
We do not currently hold ISO 27001 or SOC 2 certifications. We are transparent about this. Our security architecture is designed to meet the substantive controls of both frameworks in advance of formal certification.
Subprocessors
Pilar uses the following subprocessors:
Infrastructure and hosting
- —Vercel — frontend hosting (US company, EU data region)
- —Railway — backend hosting (US company, EU data region)
- —Supabase — database and authentication (US company, EU data region)
- —Cloudflare — DNS, WAF, CDN (global with EU processing)
Communication and support
- —Resend — transactional email (US company)
- —Cal.com — booking (EU-hosted, open source)
Analytics and observability
- —Vercel Web Analytics — privacy-first, cookie-free, EU processed
- —Sentry — application error tracking (US company, EU data region)
We maintain up-to-date data processing agreements with all subprocessors listed above. Where a subprocessor is US-headquartered, data transfer is governed by Standard Contractual Clauses and, where applicable, EU-US Data Privacy Framework certification.
We notify customers of new or changed subprocessors 30 days in advance, via email to their designated account contact.
Data retention and deletion
Pilar retains data only as long as necessary to provide the service and meet legal obligations.
Active users
- —Personal profile and financial data: retained for the duration of active account use
- —Session logs and engagement data: 24 months
- —Audit logs (system access): 24 months
Deactivated users (employee leaves employer)
- —Automatic data anonymisation triggers 90 days after account deactivation, unless the user has migrated to a personal subscription or has objected to anonymisation within the 90-day window
- —Anonymised aggregate data may be retained indefinitely for product improvement and academic research
User-initiated deletion
- —Individual users can request full account deletion at any time via their account settings or by writing to [email protected]
- —Deletion is completed within 30 days of request
- —Confirmation of deletion is sent to the user's registered email
Employer-initiated data return
- —Employer-level aggregate reports are retained for 24 months after contract end, then deleted
- —No individual employee data is ever released to a departing employer, regardless of contract terms
Legal holds
Data subject to a legal hold (e.g., regulatory investigation) is retained for the period required by law and remains subject to standard security controls throughout.
Incident response and breach notification
Pilar maintains an incident response plan covering:
- —Detection: continuous CI security scanning; automated dependency vulnerability alerts; application error tracking via Sentry; anomaly logging with alerting on threshold breach
- —Triage: severity classification within 4 hours of detection
- —Containment: immediate isolation of affected systems where applicable
- —Notification: affected users notified within 72 hours of confirmed personal data breach, in accordance with GDPR Article 33 and 34
- —Post-incident review: written incident report within 14 days, shared with affected customers
Customer notification contacts are collected during onboarding and kept up to date via annual review.
We have not experienced a security breach to date. Should one occur, we commit to timely, honest, and detailed communication.
Authentication and account security
Users
- —Strong password requirements aligned with NIST SP 800-63B guidance; no forced rotation, no arbitrary character-class rules
- —Password strength assessed at registration
- —Two-factor authentication available for all users via any standard authenticator app (Google Authenticator, Authy, 1Password, and equivalents)
- —Passkey (WebAuthn) support planned for 2027
- —Suspicious login detection: unusual location, device, or pattern triggers step-up authentication
Employer administrators
- —Two-factor authentication required for all employer admin roles
- —Single sign-on (SAML) available on request
Application-level protections
- —Per-user and per-endpoint rate limiting enforced at both the application layer and the CDN edge
- —Explicit ownership checks on every endpoint that touches user-owned resources, covered by a dedicated test suite
- —Strict request-body validation on every write endpoint
Pilar personnel
- —All Pilar accounts protected by hardware security key (WebAuthn)
- —Production database access requires hardware-key two-factor authentication; every access event is logged
- —No shared credentials
Responsible disclosure and contact
Security and compliance contact
Security researchers and responsible disclosure: [email protected]
Data protection and GDPR requests: [email protected]
General compliance questions: [email protected]
We respond to security disclosures within 48 hours and welcome responsible disclosure. No formal bug bounty at this stage; we credit reporters publicly with permission.