PostHog Handbook Library / Company

1,500 words. Estimated reading time: 7 min.

# Security & Privacy

Auto TL;DR

## At a Glance

This long page covers these main areas. The list is generated from the article headings, so it updates with every handbook rebuild.

1. Overview
2. Multi factor authentication
3. YubiKeys for infrastructure accounts
4. Setting up your YubiKeys
5. Mobile device management (MDM)
6. SOC 2
7. GDPR
8. PostHog's obligations as a Data Processor

It is critical that everyone in the PostHog team follows these guidelines. We take people not following these rules very seriously - it can put the entire company and all of our users at risk if you do not.

### Overview

We maintain a robust security program that follows best practice in order to meet the needs of our PostHog Cloud customers, making PostHog the ideal solution for customers who have GDPR, SOC 2, or CCPA obligations themselves. PostHog Cloud customers own the data they send to us for processing. We collect and analyze data about the use of PostHog Cloud by our customers, but that data does not include the user data that customers send to us to process on their behalf.

This page covers SOC 2, GDPR, and CCPA compliance.

For information about security advisories and CVEs, see our advisories & CVEs page.

### Multi-factor authentication

All team members are required to enable multi-factor authentication (MFA) on their accounts. Passkeys are the preferred method for securing all accounts — they are phishing-resistant, easy to use, and supported by most major services including Google Workspace, GitHub, 1Password, and macOS.

Please set up passkeys for Google Workspace and GitHub at the very least. If you are new, please do this within your first week so you don't get locked out.

It is recommended to have most passkeys saved in 1Password itself, which will allow you to use them from your phone.

#### YubiKeys for infrastructure accounts

YubiKeys are required for certain infrastructure-specific accounts as determined by the security team. If your role requires access to these accounts you will be told by the team - if in doubt ask in #team-security.

We recommend purchasing:

- One YubiKey 5C Nano for use with the work computer (can be left plugged in most of the time)
- One YubiKey 5C NFC (or YubiKey 5Ci if you have an older iPhone model) for use with mobile devices, and as backup

##### Setting up your YubiKeys

1. Register your YubiKeys with each required service. The security team will let you know which accounts need YubiKey authentication.
2. Always register both keys with every service so the second acts as a backup if you lose one.
3. Disable OTP mode — avoid spamming OTPs if you accidentally touch your YubiKey by installing the YubiKey Manager or by running `brew install ykman && ykman config usb --disable OTP`

### Mobile device management (MDM)

We use Fleet to manage all of our laptops. It applies targeted policies that raise the security baseline of every device, including:

- minimum password length
- screen lock
- auto-install of software updates
- auto-provisioning of software like 1Password
- absence of static SSH keys on the filesystem

We also use Fleet to investigate supply chain attacks, for example to see whether any laptops have been exposed to a malicious package or browser extension.

We chose Fleet because they are open source and a transparent company. In the same spirit, all of the policies we provision are stored in git at PostHog/fleet-gitops. Any employee can see the same data our security team sees by clicking the Fleet icon in the macOS menu bar and choosing "My device".

Fleet does not see:

- your screen
- your messages or photos
- what you type
- which URLs you visit

### SOC 2

These policies are also relevant for GDPR (see below).

### GDPR

For the purposes of GDPR, customers use PostHog in one of two ways:

- PostHog Cloud
- Self-hosting a hobbyist PostHog instance

If a customer is using PostHog Cloud, then PostHog is acting as Data Processor and the customer is the Data Controller. We have some GDPR obligations to the customer's end users here.

If a customer is self-hosting PostHog then they are both the Data Processor _and_ the Data Controller because they are responsible for their PostHog instance. We do not have access to any of their user data, so we do not have specific GDPR obligations to the customer's end users here.

#### PostHog's obligations as a Data Processor

We have reviewed our architecture, data flows and agreements to ensure that our platform is GDPR compliant. PostHog Cloud does not directly interact with our customers’ end users, nor does the platform automatically collect personal data. However, our customers might collect and send personal data to PostHog for processing.

PostHog does not require personally identifiable information or personal data to perform product analytics, and we provide extensive controls for customers wishing to minimize personal data collection from their end users. We provide separate guidance for our customers on how to use PostHog in a GDPR-compliant way in our Docs.

Technical and Organizational Measures ('TOMs')

- We maintain an extensive security policies to ensure we are managing data responsibly - see above.
- We enter into Data Processing Agreements ('DPAs') with PostHog Cloud customers when requested - you can generate a DPA here. We maintain a register of all DPAs we have entered into.
- Customers can choose whether to host data on our AWS servers in the EU (eu-central-1 in Germany) or the US (us-east-1 in Virginia). If data transfer is required from the United Kingdom, EU, or EEA to our US based AWS environment, we rely on EU Standard Contractual Clauses (SCCs).
- We are registered with the Information Commissioner's Office in the United Kingdom as Hiberly Ltd., which is the legal name for our UK entity.
- A list of sub-Processors is maintained as part of our DPA - we keep this to a strict minimum.
- Our Data Processing Register is available for viewing by any interested party upon request.

Charles Cook (VP Operations) is our assigned Data Protection Officer and is responsible for overseeing compliance. Customers can email privacy@posthog.com for any questions relating to GDPR or privacy more generally.

### CCPA

Under the California Consumer Privacy Act (CCPA), PostHog as a Service Provider to PostHog Cloud customers only. This is similar to the Processor definition under GDPR. We include a CCPA Addendum in our Privacy Policy.

We give all PostHog customers the tools to easily comply with their end users' requests under CCPA, including deletion of their data. We provide separate guidance for our customers on how to use PostHog in a CCPA-compliant way in our Docs.

We receive data collected by our customers from end-users and allow them to understand usage metrics of their products. We don't access customer end-user data unless instructed by a customer, and customer data is never sold to third parties. We do not have access to data collected by our customers who are using a self-hosted version of PostHog from end-users at all, unless they give us access to their instance.

### Pen tests

We conduct these annually, most recently in May 2025 - you can find the report in our Trust Center.

### Responsible disclosure

Security vulnerabilities and other security related findings can be reported via our vulnerability disclosure program or by emailing security-reports@posthog.com. Valid findings will be rewarded with PostHog swag.

For information about current and past security advisories and CVEs, see our advisories & CVEs page.

### Reporting phishing

If you receive a phishing email/text/whatsapp, it's useful to report it to the security team so that they can make other employees aware. Take a screenshot and post it in `#phishing-attempts`. You may be asked to forward the email to security-internal@posthog.com for further inspection.

### Secure communication (aka preventing social engineering)

We follow several best practices to combat social engineering attacks. See Communication Methods for more information.

### Impersonating users

To provide a great customer experience, PostHog employees may occasionally need to access customer data or log in as a user (i.e. impersonate them). We allow this access when it's necessary to deliver our service, following these guidelines:

1. Only impersonate when there’s a clear, demonstrable benefit for the customer.

For example, to investigate an incident, resolve a support issue, or review a customer’s setup to give recommendations on how to use PostHog more successfully.

1. Do not make any changes to a customer’s setup without explicit consent.

Exceptions to this are cases where we are reacting to incidents or bad configurations that are negatively impacting PostHog services in order to protect ourselves _and_ the customer.

1. Ask for permission whenever possible.

While this isn’t always feasible, such as during an active incident, it’s best practice to inform the customer before accessing their account. When a customer raises a support ticket, we take this as consent to be able to impersonate their account and investigate based on the contents of the ticket. Customers will not be actively asked for permission by our support engineers when they are investigating a ticket, and the customer should inform us in the ticket if they explicitly do not wish for our support engineers to access their account.

1. Use good judgment.

If you’re unsure whether impersonation is justified, or if a customer might object, either seek their consent or find another way to get the information (for example, by checking our internal PostHog instance).

Canonical URL: https://posthog.com/handbook/company/security

GitHub source: contents/handbook/company/security.md

Content hash: `deb61783cbd8a828`

Static reader notes

- `MDX_COMPONENT_STATIC_ADAPTER`: Adapted interactive MDX components for static reading: PrivateLink, SOC2.