How Teardown Deck handles audit briefs, screenshots, project data, and support access.
This policy describes the commercial MVP data boundary for Teardown Deck. It is written for users who create SaaS CRO audit decks from their own source material and need a clear handling model before checkout.
Data we process
- Audit brief text, notes, and source context you enter into the generator.
- Uploaded screenshots or images used for preview, source framing, export, and delivery review.
- Project identifiers, deck JSON, version history, quality-check metadata, and export state.
- Delivery email, checkout session metadata, order status, and package selection.
- Operational events needed to diagnose failed generation, payment, export, deletion, or support workflows.
How we use it
We use project data to generate and edit the audit deck, keep project recovery working, unlock paid exports after checkout, support deletion requests, and diagnose service failures.
We do not use uploaded customer material for public case studies, advertising examples, model training, or third-party promotion unless the customer separately authorizes that use.
Storage and retention
- Anonymous projects are designed around a short recovery window and include an expiration model.
- Private project assets are stored for project preview, export, and delivery review.
- Stripe order records may be retained where payment, tax, refund, dispute, or fraud review requires it.
- Operational audit events are redacted and kept only for service reliability, security, and support review.
Deletion
Project deletion removes project records, private assets, version records, support access grants, and user project indexes where applicable. Payment records can be retained when required for payment, tax, refund, and dispute handling.
To request deletion or recovery help, use the support path and include the project id or checkout session id. Do not send access tokens in plain text unless support explicitly asks for a secure verification step.
Support access
Support access is scoped, time-limited, and audited. Support views are designed to redact sensitive tokens, hashes, and buyer contact details that are not needed for the support task.
Security boundaries
- Project access tokens are hashed in storage and are not intended for URL query strings.
- Uploaded images are validated and sanitized before storage.
- Public health endpoints expose only restricted summaries; detailed readiness requires a maintenance token.
- Generated copy and claims still require user review before client delivery.