Security

Our principles

Pulzeo handles sensitive information: Google Ads account credentials, campaign metrics, budgets, business performance. Security is not a feature bolted on at the end. It is a constraint built into every technical decision.

• Less data collected means less risk. We store only what the service strictly needs.
• Isolation by default: each organization can access only its own data, enforced at the database level (Row Level Security).
• Systematic encryption of sensitive data at rest and in transit.
• Transparency: this page is deliberately detailed so that you can judge for yourself.

Data security

Encryption in transit

All communication between your browser, the Pulzeo application, the Google Ads API and our subprocessors uses TLS 1.2 or higher. No cleartext traffic is accepted.

Encryption at rest

Google Ads OAuth credentials (refresh tokens and access tokens) are encrypted with AES-256-GCM before being written to the database, with a separate encryption key stored in an application environment variable. A compromise of the database alone would not give access to the credentials.

All other business data (metrics, settings, accounts) is encrypted at rest by our database provider, using PostgreSQL’s native mechanisms.

Tenant isolation

Each Pulzeo organization sees only its own data. That isolation is enforced at three levels:

• RLS (Row Level Security) at the PostgreSQL level. Every query is filtered by organization_id before any data is returned, independently of the application code.
• Application-level checks in every API endpoint (defense in depth).
• Audit logs to track sensitive operations.

Authentication

User authentication relies on signed JWT tokens and short-lived refresh tokens. Passwords are hashed with a strong one-way function, with a unique salt per account, and are never stored in cleartext.

For your Google Ads accounts, we use Google’s OAuth 2.0 flow exclusively. Pulzeo never sees your Google credentials and does not store your Google password. You can revoke access at any time from your Google account.

Internal access policy

Access to Pulzeo’s production systems follows the principle of least privilege and is limited to what running the service strictly requires.

• Access to production admin consoles is restricted to Ecom Liberty’s technical team, which currently consists of the founder alone.
• Every third-party admin account used to operate Pulzeo is protected by multi-factor authentication (MFA).
• Application secrets (API keys, encryption secrets, OAuth client secrets) are stored exclusively in the hosting provider’s encrypted environment variables and are never committed to the source repository.
• Access to user data in cleartext (beyond anonymized metrics) occurs in only two situations: (1) at the user’s explicit request as part of technical support (debugging an issue you report to us), or (2) under a binding legal obligation (a duly served judicial order). Every such access is logged.
• Any subprocessor working on the production environment is bound by a non-disclosure agreement (NDA) and by the applicable GDPR obligations.
• When anyone (internal or external) finishes an engagement, all their access is revoked within 24 business hours.

Infrastructure

Pulzeo relies on providers recognized for their security:

• Application hosting with a SOC 2 Type II and ISO 27001 certified provider.
• Database and authentication with a SOC 2 Type II certified provider, with data stored in a European Union region.
• Google Ads APIs operated by Google (ISO 27001, SOC 1/2/3).

The names of these providers are disclosed to our business customers on request, through our contact form.

Backups and business continuity

Database backups

The PostgreSQL database is backed up automatically:

• Automatic daily snapshots, retained for at least 7 days under our current hosting plan.
• Continuous replication within the hosting region, for high availability.
• Snapshots are encrypted at rest and stored in the same jurisdiction as the primary database.

Restoration: indicative RPO and RTO

• RPO (Recovery Point Objective): 24 hours at most. In the worst case, the data created since the last daily snapshot is lost.
• RTO (Recovery Time Objective): 4 hours at most for an incident confined to Pulzeo, subject to the availability of the subprocessors involved.
• A documented restore procedure is tested periodically by the technical team.

Subprocessor continuity

Our critical subprocessors run their own continuity plans, with publicly documented SLAs. If a major incident affects one of them, Pulzeo provides updates on the situation as soon as possible (status page, email to affected users).

Monitoring and logs

All runtime errors in the application are collected in aggregated, anonymized form so that we can debug issues and detect anomalies. Credentials, passwords and other secrets are systematically filtered or masked (ya29.<redacted>) before anything is written to a log.

We actively monitor our critical endpoints (/api/google-ads/sync, /api/reports, the authentication endpoints) and apply rate limiting to prevent abuse.

Responsible disclosure

If you find a security vulnerability in Pulzeo, we would be grateful if you reported it responsibly rather than publishing it.

How to report a vulnerability

• Email security@pulzeo.com with a detailed description of the issue, the steps to reproduce it and, if possible, the estimated impact.
• We acknowledge receipt within 72 business hours and keep you informed of how it is being handled.
• We ask you not to exploit the vulnerability beyond what is strictly needed to demonstrate it, and not to disclose it publicly before it is fixed.

Indicative fix times (SLA)

Once a vulnerability is confirmed, we commit to a handling time based on its severity, as we assess it together with the researcher (on a scale inspired by the CVSS standard):

These times are internal targets communicated in good faith, not a contractual commitment. We inform the researcher who reported the vulnerability of any deviation.

What we commit to

• Keeping you informed of the status of the fix throughout the process.
• Crediting your contribution publicly if you wish (hall of fame, a mention in the release notes).
• Not taking legal action against security researchers who act in good faith and within this policy.

Security contact

To report a vulnerability, use the address given in the “Responsible disclosure” section above. For any other security question, use our contact form.

This English version is provided for convenience only. If it differs from the French version, the French version prevails.