Hosting and encryption

• Deployment definitions target DigitalOcean for hosting. Database, file storage and job execution depend on configuration; this page does not certify the current production settings. See the code-derived subprocessor directory for processing pathways.
• Production web and API traffic uses HTTPS. GoodQA responses include HTTP Strict Transport Security (HSTS) so supported browsers continue using HTTPS.
• Replayable integration credentials are additionally sealed by GoodQA with authenticated AES-256-GCM encryption. New credential envelopes are bound to their organization, project, resource, provider, and purpose so copying ciphertext to a different context fails authentication.
• Passwords are hashed with Argon2id. API keys and refresh tokens are stored as one-way hashes rather than as reusable plaintext values.
• Uploaded files and recordings are private by default. GoodQA checks current membership on every new request for a file before issuing a short-lived signed storage URL, and verifies stored size and, where the format supports it, the file signature server-side.
• Removing someone from an organization or project stops their new requests for its files at once. A signed storage URL they were already given is not withdrawn when someone’s access is removed: it keeps working until it expires, at most 15 minutes after it was issued. Removing access never takes back a copy someone has already downloaded.

Tenant isolation and access control

Customer isolation is enforced at the application layer. Data is scoped to an organization directly or through its project, and shared authorization helpers resolve the caller's membership before protected resources are returned. GoodQA does not currently claim database row-level security.

Role-based access control covers organization and project roles, custom roles, and bounded per-user grants. Protected actions check an explicit permission such as managing members, editing issues, executing tests, or connecting repositories. Cross-tenant requests are exercised by integration and adversarial tests.

GoodQA also has a dedicated support-elevation workflow whose grants are scoped to an organization or project, require a reason, expire automatically, remain revocable, and create audit records when granted, used, or revoked. That workflow is not yet the authorization path for every platform-administration view, so we do not present it as a universal control on administrator access.

Auditability and recovery

GoodQA records issue history and append-only audit events for selected security-sensitive and administrative activity, including membership and role changes, API-key scope changes, settings changes, and support elevation. Audit records identify the actor, scope, action, target, time, and—where the action requires one—the reason.

The platform-wide audit view is restricted to GoodQA administrators. A general organization-facing audit-log screen is not currently offered, so we do not present that as a customer feature.

Production data is backed up as part of our hosting configuration. Backup frequency and retention depend on that configuration and are not stated here as a commitment. These controls support recovery; they are not a published recovery-time or recovery-point guarantee.

Report a security issue

Email support@goodqa.app with the subject “Security report.” Include the affected GoodQA surface, steps to reproduce, and the impact you observed. Do not include passwords, API keys, live access tokens, or customer data in the first message, and do not test against data or accounts you do not own or have permission to use.

For ordinary account or product help, use the public Support page.