Privacy Policy

This Privacy Policy describes how QA Explorer ("we", "us", "our") collects, uses, stores, and shares information about you when you use the QA Explorer service (the "Service"). It is intended to be read together with our Terms of Service.

This document is a draft pending review by a qualified lawyer. Provisions in [brackets] are placeholders that must be filled in or revised by counsel before this document is final.

The Service is operated by [PLACEHOLDER: legal entity name, entity type, registration number, and registered address].

The data controller for personal information processed by the Service is [PLACEHOLDER: same legal entity, or DPO / EU representative / KVKK contact if applicable in the user's jurisdiction].

For privacy questions or data-rights requests, contact us at the address in Section 13.

We collect the following categories of information.

3a. Account data. When you create a QA Explorer account, we collect:

• Your email address;
• A bcrypt hash of your password (the plaintext password is never stored; we only retain the one-way hash);
• A server-generated session identifier, which is set as the qae_sid cookie in your browser;
• The timestamp of account creation;
• The timestamp at which you accepted the Terms of Service and this Privacy Policy. (Accounts created before the consent-acceptance feature shipped do not have this timestamp.)

3b. Scan submission data. When you submit a scan, we collect:

• The target URL you submitted;
• Timestamps for scan submission, start, and completion;
• The timestamp at which you confirmed authorization to scan the target (the authorization-consent checkbox on the scan-submission form);
• If you used the "scan the logged-in version" feature: the login URL and the test-account username/email you supplied, and (transiently, for the duration of the scan) the test-account password. Handling of the password is described in Section 5.

3c. Scan output data. After the scan runs, we store:

• Metadata about the pages crawled (URLs, page titles, status codes);
• Screenshots of the pages the Service visited. If you used the "scan the logged-in version" feature, these screenshots will show whatever the test account was permitted to see — including any data visible in the authenticated user interface;
• Console errors and network observations captured during the crawl;
• AI-generated findings (when the Service is operating in its Claude-API analysis mode) and probe-generated findings;
• The full QA report (rendered as Markdown, as a PDF, and as JSON metadata) produced for that scan.

3d. Lead emails. When an anonymous visitor downloads a QA report artifact (PDF or CSV), the Service captures the visitor's email address to gate the download. We store:

• The email address (lowercased);
• The scan ID associated with the first capture;
• The timestamp of first capture.

3e. Cookies. We use one functional cookie: qae_sid, which holds the opaque server-generated session identifier described in 3a. This cookie is used solely to keep you signed in. We do not use cookies for advertising or for cross-site tracking.

3f. Server logs and rate-limiting. Our application servers record routine request information: request method, path, response status, timestamps, the client IP address as reported by the platform's proxy, and error messages. Passwords are sanitized from error messages before logging. We also maintain per-IP rate-limit counters in Redis with short time-to-live values; these counters are used solely to prevent abuse and expire automatically.

We use the information described in Section 3 to:

• Provide, operate, and maintain the Service;
• Authenticate you and keep you signed in;
• Run the scans you submit and deliver the resulting QA reports;
• Diagnose and resolve technical issues;
• Communicate with you about the Service, your account, and changes to these documents;
• Detect and prevent abuse of the Service (for example, by enforcing rate limits);
• Comply with legal obligations that apply to us.

We do not sell your personal information. We do not use your personal information for behavioral advertising.

This section describes how we treat the optional test-account credentials you supply via the "scan the logged-in version" feature. It reflects current implementation behavior.

• The login URL and the test-account username/email are stored in our PostgreSQL database on the row for that scan, so the dashboard can show you the authenticated context the scan ran in. They are not encrypted at the application layer; their at-rest protection depends on the database host's encryption-at-rest configuration.
• The test-account password is never written to PostgreSQL. There is no column for it on any table. The API places the password into the BullMQ job payload, which is stored in Redis solely for the duration of the scan job.
• The password is dropped on successful scan completion. The job is configured with BullMQ's removeOnComplete option, which removes the job and its payload from Redis as soon as the worker finishes.
• On scan failure, the password is scrubbed from the failure record before that record is persisted in Redis. The worker explicitly overwrites the job payload to remove the credential object (and therefore the password) before the failure record is written; a defensive secondary scrub runs again on the BullMQ "failed" event.
• The password is redacted from logs and error messages. Any error message that contains the password is rewritten (substituting ***) before that message is stored in the database or printed to logs.
• Redis itself is not encrypted by our application. Our protection of the password while it transits Redis depends on the Redis instance's at-rest and in-transit security configuration provided by our infrastructure host. We do not add an application-layer encryption envelope.
• The password is sent to the target site once, when the Service navigates to your specified login URL and submits the login form. It is not needed thereafter — the Service captures and reuses the resulting session-cookie state for the remainder of the scan.

We do not share the password with any third party other than the target site itself.

This section describes our current data-retention behavior honestly. It does not promise automated deletion that we have not yet built.

Current state. Scan data is subject to automated retention controls: scans are automatically deleted after the retention windows listed below. (Short-lived operational data — rate-limit counters in Redis, lead-download tokens, and analyzer cost-budget keys — also has automatic expiration via Redis TTL.)

Retention windows. As of May 25, 2026, we enforce the following retention windows:

• Scan submission data, scan output data, and screenshots: 90 days for scans submitted by an authenticated user, and 30 days for scans submitted anonymously. After this period, scan data is automatically deleted;
• Lead emails are retained until deletion is requested or for a maximum of 12 months after last interaction.
• Account-related data is deleted within 30 days after a verified deletion request, unless longer retention is required by applicable law.
• Server logs are retained for up to 30 days, unless longer retention is required for security investigation or legal compliance.

This section was updated on May 25, 2026 to reflect the automated retention controls now in effect. Future changes will be noted via the in-app banner described in Section 12.

Deletion on request, available today. Regardless of automated retention, you may request deletion of any data we hold about you at any time by emailing the address in Section 13. We will respond to and act on deletion requests as promptly as practicable.

The Service relies on the following third parties. We have selected these providers because they are necessary for the Service to function, not for monetization or analytics on you.

• Anthropic (Claude API). When the Service is operating in its Claude-API analysis mode, scan-derived content — page text, page titles, captured probe findings — is sent to the Claude API for analysis. When the Service is operating in its built-in mock-analyzer mode, scan content is not sent to Anthropic. The active mode is an operational decision on our side; if which mode is in use matters to your use case, contact us at the address in Section 13.
• Railway. Our application servers, our PostgreSQL database, and our Redis instance are hosted on Railway's infrastructure. Railway therefore has technical access to the data we store, as part of providing that infrastructure.
• PostgreSQL is the primary database for account data, scan submission data, scan output, and lead emails. It is hosted on Railway (see above).
• Redis is used for the BullMQ job queue (carrying scan jobs and, transiently, the test-account password as described in Section 5), for rate-limit counters, for short-lived download tokens, and for analyzer cost-budget tracking. It is hosted on Railway (see above).

We do not sell your data to any third party. We do not transfer your data to any third party for marketing or advertising purposes.

Depending on the jurisdiction in which you reside, you may have one or more of the following rights with respect to the personal information we hold about you:

• The right to access the personal information we hold about you;
• The right to rectify inaccurate personal information;
• The right to request deletion of your personal information;
• The right to request portability of your personal information in a structured, machine-readable format;
• The right to object to or restrict certain processing;
• The right to withdraw consent, where processing is based on your consent;
• The right to lodge a complaint with a supervisory authority if you believe we have mishandled your personal information.

The exact scope of these rights depends on the law that applies to you. To exercise any of these rights, contact us at the address in Section 13.

8a. EU and EEA users (GDPR).

8b. Turkey (KVKK).

8c. California (CCPA / CPRA).

8d. Other jurisdictions.

We take the following measures to protect your information. These reflect current implementation; this document will be updated as practices change.

• Account passwords are hashed using bcrypt with a work factor of 12 before storage. The plaintext is never written to disk.
• Sessions are server-side rather than JWT; revoking a session is a database delete and takes effect immediately.
• The qae_sid session cookie is set with HttpOnly, Secure, and SameSite attributes appropriate to the deployment.
• Target-site test-account passwords are handled as described in Section 5: never written to PostgreSQL, scrubbed from failure records and logs, and dropped on completion.
• Data in transit between your browser and the Service is protected by TLS when the deployment platform terminates TLS in front of the application.
• We rely on the access controls and security practices of our infrastructure host (Railway) for the protection of data at rest.

No security measure is perfect. You are responsible for using a strong, unique password for your QA Explorer account and for notifying us promptly if you believe your account has been compromised.

Your information may be processed in countries other than the one you live in. In particular:

• Our infrastructure host, Railway, operates data centers in [PLACEHOLDER: region(s) — confirm based on the actual deployment region];
• Anthropic, when the Service is in Claude-analysis mode, processes scan-derived content on infrastructure that may be located in the United States;
• The operator of the Service is currently based in Turkey.

The Service is not directed to children under 18. We do not knowingly collect personal information from children under 18. If we learn that we have collected personal information from a child under 18, we will delete that information promptly. If you believe a child has provided us with personal information, contact us at the address in Section 13.

We may revise this Privacy Policy from time to time. The current version is always available at https://qaexplorer.com/privacy with the "Last updated" date at the top.

If we make material changes, we will display a visible in-app banner the next time you use the Service. Continued use of the Service after the "Last updated" date constitutes acceptance of the revised Policy. If you do not agree to the revised Policy, you must stop using the Service.

We do not commit to notifying you by email of changes to this Policy; the in-app banner is the notice mechanism.

To exercise the rights described in Section 8, to request deletion of data we hold about you under Section 6, or to ask any other question about this Policy, contact us at:

privacy@qaexplorer.com

We will respond as promptly as practicable.