GDPR Self-Assessment with Evidence

Measure: All data processing purposes are disclosed in the Privacy Policy. Telemetry is opt-in only with explicit consent prompt. No hidden data collection.

Evidence: Privacy Policy published at docs.sigmashake.com/policies/privacy-policy. Telemetry consent prompt shown on first use with default set to "No".

Measure: Data collected for authentication, billing, and optional anonymized telemetry only. No secondary use, no advertising, no profiling, no data sales.

Evidence: Data flow documented in threat model. Telemetry schema is limited to: anonymous install ID, version, OS, command, and decision type. No file paths or content.

Measure: Only the minimum data required for each function is collected. CLI evaluates tool call metadata only — never reads source code. Authentication uses OAuth with minimal scopes (read:user, public_repo).

Evidence: OAuth scope documentation. Telemetry schema contains 7 fields total, none containing user content or PII.

Measure: User identity data sourced directly from OAuth providers (GitHub, Google) and kept current via each login. Users can update their profile through the identity provider.

Evidence: Authentication flow refreshes profile data on each login session.

Measure: Sessions expire after 24 hours. Audit logs are capped and rotated automatically. Account deletion removes all associated data.

Evidence: Session TTL: 24h (enforced by KV expiry). Audit log cap: 50,000 rows with automated batch rotation.

Measure: All data encrypted at rest (AES-256 via Cloudflare) and in transit (TLS 1.3 minimum). OAuth tokens encrypted with AES-GCM before storage. Security headers enforced on all services.

Evidence: Qualys SSL Labs Grade A. HSTS active. HttpOnly + Secure cookies. AES-GCM token encryption with random IV per token.

Measure: Authentication data: contract performance (Art. 6(1)(b)). Billing data: contract performance + legal obligation. Telemetry: consent (Art. 6(1)(a)) — opt-in only.

Evidence: Lawful basis documented per processing activity in the Privacy Policy.

Measure: Privacy Policy discloses: identity of controller, purposes, lawful basis, recipients, retention periods, data subject rights, and right to lodge a complaint with a supervisory authority.

Evidence: Published at docs.sigmashake.com/policies/privacy-policy. Accessible from every page footer.

Measure: Users can view their profile, subscription status, published rulesets, and device bindings through the Accounts dashboard. Additional data export available on request.

Evidence: Self-service dashboard at accounts.sigmashake.com. Manual export requests handled within 30 days via security@sigmashake.com.

Measure: Full account deletion cascade: removes user record, sessions, published rulesets, device bindings, Stripe customer, GitHub token revocation — all in a single request.

Evidence: Deletion endpoint: POST /api/settings/delete. Cascade covers 7 data stores. Deletion is immediate and irreversible.

Measure: Rulesets are stored in YAML format and can be exported from the Hub. User account data is available in structured JSON format on request.

Evidence: Ruleset YAML export via Hub API. Account data export available via security@sigmashake.com.

Measure: Privacy by default: telemetry off by default, minimal OAuth scopes, no PII in telemetry, local-first CLI architecture. The CLI never uploads source code.

Evidence: Zero-trust architecture documented in THREAT_MODEL.md. Default telemetry setting: disabled.

Measure: Consent is granular, opt-in, freely-withdrawable, and not bundled with contract performance. Telemetry consent is collected separately from the account terms. The consent register snapshot is published monthly by the consent-config collector and includes consent scope, version of the privacy notice, and lawful-basis tag.

Evidence: sigmashake-compliance/src/collectors/monthly/consent-config.ts. Withdrawal flow: settings dashboard + DSR pipeline.

Measure: Customer DPA template at docs/compliance/dpa-template.md (Annexes I–III) incorporating SCCs 2021/914 Module Two (C → P) for international onward transfers. The complete Article 28(2) sub-processor list is published as a machine-readable JSON feed at compliance.sigmashake.com/api/v1/sub-processors.json — referenced by Annex III. Sub-processor DPA freshness, TIA freshness, and onboarding gate state are tracked by the sub-processor-snapshot collector (monthly).

Evidence: docs/compliance/dpa-template.md, docs/compliance/sub-processor-management.md, GET /api/v1/sub-processors.json, sub-processor-snapshot collector (monthly).

Measure: Article 30(1) controller RoPA + Article 30(2) processor RoPA generated monthly by the ropa-snapshot collector from the canonical system-description.ts (identifying every system holding personal data or data class ≥ 3) plus the vendor register. Each activity records: purposes, categories of data subjects, categories of personal data, recipients, third-country transfers, retention periods, security measures, and lawful basis.

Evidence: sigmashake-compliance/src/collectors/monthly/ropa-snapshot.ts. Output evidence available via /api/v1/audit-package on request.

Measure: Cryptography policy (docs/compliance/cryptography-policy.md) defines approved primitives (Ed25519, AES-256-GCM, TLS 1.3, SHA-256, HMAC-SHA-256, Argon2id), a 90-day rotation cadence for signing and HMAC keys, and an explicit prohibited list (SHA-1, MD5, 3DES, RC4, AES-ECB, ECDSA-P256 without DPIA). All D1 queries are parameterized; subprocess calls use array-based spawn; nonce-based CSP with X-Frame DENY + HSTS preload. Penetration-test sweep (Claude Opus 4.7, May 2026) shipped 3 defense-in-depth hardenings — open-redirect, input-shape validation on /api/v1/verify, and public-feed minimisation.

Evidence: docs/compliance/cryptography-policy.md. secrets-age (daily) + sso-signing-key-age (weekly) + rotation-smoke (daily) collectors. Pen-test commit log in sigmashake-compliance.

Measure: Article 33(2) processor obligation: notify the customer-controller within 72 hours of becoming aware. Article 33(1) controller obligation: notify the relevant supervisory authority within 72 hours where breach is likely to result in a risk to data subjects. Article 34: communicate to data subjects without undue delay where the risk is high — practical SLA 14 calendar days. The breach-notification-record collector tracks every incident, the 72h DPA SLA timer, and the 14d data-subject SLA timer; missed deadlines automatically open compliance gaps.

Evidence: docs/compliance/breach-notification-procedure.md, sigmashake-compliance/src/collectors/monthly/breach-notification-record.ts.

Measure: DPIA procedure follows EDPB WP-248 with the 9-criteria significant-risk test. The dpia-register collector inventories existing DPIAs and detects DPIA candidates from the canonical system-description (data class ≥ 4, special-category processing, large-scale monitoring, or vulnerable-subject processing). Currently no in-scope system triggers Art. 35(3) mandatory DPIA conditions.

Evidence: docs/compliance/dpia-procedure.md, sigmashake-compliance/src/collectors/quarterly/dpia-register.ts.

Measure: Outbound transfers to non-adequate third countries are governed by the European Commission SCCs (Implementing Decision 2021/914), with the UK Addendum / IDTA and Swiss FADP-adequacy addenda where applicable. A Transfer Impact Assessment is performed per sub-processor per EDPB Recommendations 01/2020 (Schrems II), refreshed every 365 days. Per-org Cloudflare D1 regional residency keeps EU-customer data within the EU; Stripe billing transfers to the US under SCCs.

Evidence: docs/compliance/international-transfer-procedure.md, sigmashake-compliance/src/collectors/quarterly/tia-snapshot.ts, public sub-processor feed.