01
Create a read-only credential
Create the credential in PostHog with the minimum read scope, paste it into devguard, and the connection is live. The integration page in the product spells out the exact permissions.
Read-only checks on PostHog show your product analytics collect no more personal data than they need: IP addresses dropped from every event, and session replay either off or masking every input field.
3 read-only checks, run on a schedule. Each failure becomes a finding linked to a control. Every check is listed, none are “coming soon”.
Confirms the personal API key authenticates and can read the project via GET /api/projects/{projectId}/ (HTTP 200).
token-connectivity
Fails unless the PostHog project drops the IP address from every ingested event. Reads `anonymize_ips` on GET /api/projects/{projectId}/ and treats a missing or false value as a failure (fail-closed).
ip-anonymization-enabled
Fails if session replay is on for the PostHog project and its masking config turns off input masking. Reads `session_recording_opt_in` and `session_recording_masking_config.maskAllInputs` on GET /api/projects/{projectId}/. Replay off passes. With replay on, an unset `maskAllInputs` passes, since PostHog and posthog-js mask all inputs by default; only an explicit false fails. A missing `session_recording_opt_in` fails (fail-closed). This reads the project setting only: a `session_recording.maskAllInputs: false` in your posthog-js init can still unmask inputs and is out of reach of an API check.
session-recording-inputs-masked
Bring your current platform's test list, and we'll map it against these checks, gap by gap
Setup is minutes, not a migration project, and every step stays on your side
Create the credential in PostHog with the minimum read scope, paste it into devguard, and the connection is live. The integration page in the product spells out the exact permissions.
The first run starts right after connecting, then repeats on a schedule. Results are timestamped, so your evidence has a history, not a snapshot.
Passing results attach as evidence to the controls they support; failures become findings you triage. When the audit comes, the proof is already connected.
Open any page for its full check register.
You create and scope every credential yourself, and you can revoke it at any time. Checks only read; results and evidence are stored in Switzerland and stay exportable.
Yes. The checks authenticate with a credential you create and scope yourself, and only ever read configuration. devguard holds no write access to PostHog and remediates nothing silently.
A failed check becomes a finding linked to the control it supports, with the evidence attached. You decide the treatment. Nothing pages your engineers and nothing is auto-remediated.
Checks run from Swiss infrastructure, and results and evidence are stored in Switzerland. Everything is exportable, so your evidence stays yours.
20 minutes on how you run certification today. Bring your current test or control list and we'll map it against these checks, honestly and gap by gap.