Version 1.0 · Effective 26 April 2026
This Data Processing Addendum ("DPA") forms part of the agreement between you ("Customer", the data controller) and Augmt Pty Ltd ("Lantern", "we", "us", the data processor) for use of the Lantern service (the "Service"). It applies whenever Lantern processes Personal Data on Customer's behalf.
By using the Service, Customer accepts this DPA. Where applicable law requires a counter-signed addendum, the Customer may request one at [email protected].
For Personal Data processed in connection with the Service:
This DPA does not apply to Personal Data Lantern processes as an independent Controller — for example, Customer's billing contact details, login records of the Customer's own administrators, or aggregated/anonymised analytics. Those are governed by our Privacy Policy.
| Element | Description |
|---|---|
| Subject matter | Provision of the Lantern visual bug reporting and frontend monitoring service |
| Duration | For as long as Customer uses the Service, plus any retention period required by law |
| Nature | Storage, retrieval, transmission, structured analysis (including AI-assisted bug diagnosis), notification routing |
| Purpose | Capturing, storing, displaying, and routing bug reports, error events, and session context for Customer's chosen recipients |
| Categories of Data Subjects | Customer's employees and contractors with dashboard access; end-users of Customer's website who report bugs or whose errors are captured passively |
| Categories of Personal Data | Names and email addresses; user-supplied bug content; screenshots and screen recordings of Customer's site; browser metadata; IP addresses; URLs visited; console/network errors |
| Special categories | None intentionally collected. Customer is responsible for instructing end-users not to include special-category data in free-text bug reports. |
Lantern will:
Customer authorises Lantern to engage the Sub-processors listed at lantern.augmt.xyz/sub-processors.html ("Sub-processor List") to process Personal Data.
Lantern will:
Customer may object to a new Sub-processor in writing within the 30-day window with reasonable grounds. If we cannot agree on a resolution, Customer may terminate the affected portion of the Service for cause.
Lantern will provide reasonable assistance to Customer in responding to Data Subjects exercising their rights under Applicable Data Protection Laws (access, rectification, erasure, restriction, portability, objection). Most requests can be self-served by Customer through the dashboard. For complex requests, Customer may contact [email protected] and Lantern will respond within 10 business days.
If a Data Subject contacts Lantern directly with a request relating to Customer's data, Lantern will forward the request to Customer without acting on it (unless Customer has instructed otherwise).
Lantern will notify Customer of a Personal Data breach without undue delay and in any case within 72 hours of becoming aware. Notice will include, to the extent then known: the nature of the breach, categories and approximate number of Data Subjects and records affected, likely consequences, and the measures taken or proposed to address the breach.
Lantern will provide reasonable cooperation and assistance to Customer in investigating, mitigating, and notifying authorities or Data Subjects of the breach as required.
On termination of the Service or on Customer's written request:
Lantern will make available, at Customer's reasonable request and no more than once per 12-month period, the documentation necessary to demonstrate compliance with this DPA — including the most recent SOC 2 / ISO 27001 reports (when available), penetration test summaries, and policies referenced in Annex 2.
Where SOC 2 or equivalent third-party audits do not satisfy Customer's audit requirements, Lantern will, on reasonable notice (at least 30 days), permit Customer (or a mutually-agreed independent auditor bound by confidentiality) to conduct an audit of Lantern's data-protection practices, at Customer's cost, during business hours and in a manner that does not unreasonably interfere with Lantern's operations.
Where Lantern transfers Personal Data originating in the EEA, UK, or Switzerland to a country not deemed adequate by the European Commission, Lantern relies on the EU Standard Contractual Clauses (Module 2: Controller-to-Processor) and the UK International Data Transfer Addendum, which are incorporated by reference into this DPA.
The current Sub-processor data flows are described at /sub-processors.html.
Each party's liability under this DPA is subject to the limitations set out in the main Lantern Terms of Service. This DPA terminates automatically when the agreement for the Service terminates, except for clauses that by their nature survive (Sections 7, 8, and any indemnities).
Where there is a conflict between this DPA and the main Terms of Service, this DPA prevails on data-protection matters. Where the SCCs apply and conflict with this DPA, the SCCs prevail.
See Section 3 above.
| Area | Measure |
|---|---|
| Encryption in transit | HTTPS/TLS 1.2+ on all customer-facing endpoints, via Cloudflare |
| Encryption at rest | AES-256-GCM for OAuth tokens (Jira, Slack, Bitbucket) and TOTP secrets; database encryption at rest provided by Neon Postgres; R2 object storage encryption provided by Cloudflare |
| Authentication | JWT-based session tokens with KV-backed revocation; PBKDF2-SHA256 password hashing; magic-link and Google OAuth options; opt-in time-based one-time-password (TOTP) two-factor authentication available to every customer account at no additional cost; per-route role-based access (member / admin / owner) |
| Anti-abuse on login | Cloudflare Turnstile (CAPTCHA replacement) on the password login endpoint to mitigate credential-stuffing and bot traffic; KV-backed per-identity rate limits as a second layer |
| Tenant isolation | All database queries scoped by org_id; access controls verified at every API route |
| PII redaction on error capture | Two-layer scrub on every inbound error event before persistence. Widget-side: sensitive query parameters (token, access_token, password, code, email, otp, session, etc.) and the URL hash fragment are stripped before any URL leaves the browser. Server-side: regex matchers replace email addresses, JWTs, AWS access key IDs, Stripe API keys, GitHub personal access tokens, Authorization: Bearer values, and US Social Security numbers with typed placeholders before fingerprinting, symbolication, database write, and any downstream notification. Form input values are masked by default in session replays; password and payment-card fields are blacked out in screenshots. |
| Audit logging | Mutations recorded to an immutable audit log including actor, action, IP, user agent |
| Rate limiting | KV-backed per-identity limits on auth, pin/comment ingest, and error capture endpoints |
| Vulnerability disclosure | Public policy at lantern.augmt.xyz/#security; RFC 9116 file at /.well-known/security.txt |
| Backup and recovery | Neon Postgres point-in-time recovery (7 days); R2 object versioning where applicable |
| Logical segregation of environments | Production deployment isolated from staging/dev; secrets managed via Cloudflare Workers secrets |
| Personnel | Access on a need-to-know basis; departing personnel access revoked within one business day |
| Incident response | Documented internal runbook (docs/dsar-runbook.md); 72-hour breach notification per Section 7 |
Maintained as a living document at /sub-processors.html. Subscribe at that page for advance notice of changes.
Questions about this DPA, or to request a counter-signed copy: [email protected].