Ticket Recon
Policy

Cryptography and Data Security Policy

How Ticket Recon protects customer data in transit, at rest, and at the secret-storage layer across the service.

Product Ticket Recon
Company Ticket Recon
Effective Date April 14, 2026

This Cryptography and Data Security Policy describes the security controls and encryption practices Ticket Recon uses to protect customer data handled through the Ticket Recon software, web application, and related services (collectively, the "Service"). This policy is intended to reflect current Ticket Recon implementation practices and should be reviewed periodically as the product evolves.

1. Security Architecture

Ticket Recon is built on Google Firebase and Google Cloud services for authentication, database, hosting, and server-side processing. The Service uses user authentication, role-based access controls, Firebase App Check, reCAPTCHA protections, security-event tracking, and server-managed controls to protect access to customer data and sensitive actions.

2. Encryption in Transit

Ticket Recon uses HTTPS/TLS (TLS 1.2 or higher) for all web traffic between browsers, Ticket Recon-hosted endpoints, and supported third-party services where applicable. This helps protect data against interception while in transit across public networks. Internal service-to-service communication within Google Cloud infrastructure also benefits from Google's default encryption of data in transit.

3. Encryption at Rest

Ticket Recon relies on Google Cloud and Firebase managed infrastructure for storage of core service data. Those platforms provide encryption at rest using AES-256 (or equivalent) as part of the underlying managed infrastructure. Ticket Recon does not represent this as a substitute for customer-side governance, but it is part of the baseline protection model for stored service data.

4. Application-Level Encryption for Secrets

In addition to provider-managed security controls, Ticket Recon applies application-level encryption to certain marketplace credentials and similar secret values before they are stored server-side. Current marketplace secret storage uses AES-256-GCM encryption in the application layer. Encryption keys are managed server-side and are not accessible to client-side code or end users. Ticket Recon is designed so that raw saved marketplace secrets are not returned back to the browser after they are stored.

5. Authentication and Password Handling

  • Customer authentication is handled through Firebase Authentication, which applies industry-standard password hashing (scrypt) before storage.
  • Ticket Recon personnel do not view user passwords in plaintext through the normal product workflow.
  • Ticket Recon supports account verification, password-reset flows, and optional multi-factor authentication (MFA) controls as part of the account security model. MFA options are provided through Firebase Authentication capabilities.
  • The current product does not provide a normal front-end "log in as user" or silent impersonation workflow.
  • Admin and member-access controls are enforced through authenticated identity and server-side authorization checks.

6. Access Control Model

Ticket Recon uses authenticated, role-aware access controls and Firestore security rules to scope data access. User-owned workflow records are generally restricted to the authenticated user. Admin-only operations are further restricted to enabled admin accounts. Certain records, including security and operational records, are server-managed and not writable by standard client sessions.

7. Application Integrity and Abuse Protection

  • Ticket Recon uses Firebase App Check and reCAPTCHA protections to help verify trusted app sessions and reduce automated abuse.
  • Protected backend routes may reject requests that do not present valid App Check context.
  • Session-control records and related security state are used to support account integrity and session management.
  • Rate limiting and request throttling are applied to sensitive operations to mitigate brute-force and denial-of-service attempts.

8. Logging, Audit, and Security Events

Ticket Recon maintains internal security and operational records such as security events, audit-style logs, member-activity records, and session-related state. These records support abuse prevention, troubleshooting, incident review, access monitoring, and support operations. Availability of customer-facing audit reporting may vary by feature, but significant security and admin actions are designed to leave internal traces.

9. Secrets and Integration Handling

  • QuickBooks and marketplace integrations are only enabled when the customer configures them.
  • Webhook destinations such as Slack and Discord are stored only when the customer enables those integrations.
  • Credentials and tokens are retained only as needed to maintain the requested integration and workflow.
  • OAuth tokens used for third-party integrations (e.g., QuickBooks) are stored server-side and are not exposed to client-side code.
  • Temporary authorization or lock-state records used for server operations are designed to expire automatically after short intervals.

10. Support Access and Operational Controls

Ticket Recon does not treat customer data as open internal browsing material. Internal access is limited to legitimate operational needs such as support, security review, troubleshooting, migration, or legal compliance. Customers should nonetheless assume that authorized Ticket Recon personnel may be able to access customer data when necessary to operate or support the Service, and Ticket Recon contractually and operationally expects such access to be handled with care.

The front-facing admin surface is focused on account and security controls rather than direct browsing of another user's workflow data. In the current product, admin tooling can expose limited support metadata such as account status, session state, last-login details, last action summaries, last-run summaries, and activity-log exports, but it is not intended as a general-purpose viewer for user-owned saved runs, row-level reconciliation data, or uploaded workflow content.

11. Incident Response

Ticket Recon maintains an incident response process to address security events. In the event of a confirmed security breach affecting customer data, Ticket Recon will:

  • Investigate the scope and impact of the incident.
  • Take reasonable steps to contain and remediate the issue.
  • Notify affected customers and relevant authorities as required by applicable law.
  • Document the incident and any corrective actions taken.

12. Vulnerability Reporting

If you believe you have discovered a security vulnerability in the Service, please report it responsibly by emailing support@ticketrecon.com with a description of the issue. Ticket Recon will acknowledge receipt and work to investigate and address confirmed vulnerabilities in a timely manner.

13. Data Deletion and Credential Cleanup

Ticket Recon supports deletion of certain user accounts and stored records through product controls and support processes. Integration credentials may be removed when integrations are disconnected or related records are deleted. When encrypted secrets are deleted, the associated ciphertext is removed from storage. As with most cloud systems, limited residual copies may remain in short-lived logs, provider-managed backups, or recovery systems for a reasonable period before final aging out.

14. Security Limitations

No technical control can eliminate all risk. Ticket Recon uses administrative, technical, and operational safeguards intended to reduce unauthorized access, disclosure, alteration, and misuse. This policy describes current controls, but it does not guarantee that incidents can never occur.

15. Policy Review and Contact

Ticket Recon reviews this policy at least annually and may revise it as the Service, its integrations, or its security architecture changes. Questions about this policy may be sent to support@ticketrecon.com.