Security Package
Last updated 11 September 2026
A standard vendor-security questionnaire, answered here instead of in a spreadsheet that goes stale the day it is sent. Every answer is checkable against the product as it runs today — the source repository is private, but available to a prospective customer on request through support. Where a control is planned but not yet built, the answer says so — see the trust center for the fuller picture and the data inventory.
Company
- Who operates Sasquatch Privacy?
- Saasquatch Labs LLC operates Sasquatch Privacy at sasquatchprivacy.com.
- Does Sasquatch Privacy share infrastructure or data with other Saasquatch Labs products?
- No. It has its own Vercel project, its own AWS resources, and its own dedicated Supabase project — none of it shared with Sasquatch Social or any other product the company operates.
Hosting & data residency
- Where does the application run?
- The web app runs on Vercel. Scan workers run on AWS: Lambda for free scans, Fargate for paid audits.
- Which AWS regions are in use, and why more than one?
- Five: us-west-2, us-west-1, us-east-1, eu-central-1 and eu-west-2. Consent platforms key on the visitor's IP address, so a scan requested for the EU only produces an honest result if it actually egresses from the EU — we run a cluster in each region rather than spoofing a location from one.
- Where is scan and audit metadata stored?
- In one DynamoDB table in us-west-2, regardless of which region a given scan egressed from — the regional clusters run the browser and report back over a signed callback, they do not hold their own copy of the data. A Supabase Postgres project (smxnvcxctbbpyzvpkrtg) holds account, organisation and monitoring data, under row-level security.
Encryption
- Is data encrypted in transit?
- Yes. TLS on every connection, HSTS is preloaded on the web app, and the worker-to-app result callback is HMAC-SHA256 signed on top of TLS.
- Is data encrypted at rest?
- Yes: the DynamoDB scan-state table uses AWS-managed SSE and both SQS queues use SQS-managed SSE, both declared in the CloudFormation templates. Audit screenshots live in a private S3 bucket with SSE-S3 and every public-access block enabled — the worker can only write to it, and only under the audit prefix. Account and monitoring data live in Supabase Postgres, which encrypts its storage volumes by default.
Access & authentication
- How do customers authenticate?
- Accounts use Supabase Auth with magic-link email only — there are no passwords to leak. Organisation data is isolated by Postgres row-level security keyed on the authenticated user id, enforced in the database rather than in application code. A free scan is public with no login. A paid audit bought without an account is read back with a random possession token issued at purchase — anyone who has the token can view that one result, and a wrong or missing token gets the same generic 404 as a nonexistent one.
- How does the application authenticate to AWS?
- Vercel's own OIDC identity is federated into an IAM role (sasquatch-privacy-web) scoped to this project's DynamoDB table and SQS queue and nothing else. No AWS access key exists in the app's environment.
- How does CI authenticate to publish the worker image?
- The same pattern: GitHub Actions federates via OIDC into a separate IAM role (sasquatch-privacy-ci), trust-scoped to one repository, requesting only the id-token needed for that exchange.
- Who has administrative access to the AWS account?
- Today, one person, through a browser-authenticated root session with a roughly 12-hour lifetime — there is no scoped administrative IAM role yet. That is a known gap; creating one is the intended next step, not a control already in place. One long-lived credential exists by necessity: an IAM user permitted only to send mail through SES for sign-in links and alerts, because SMTP cannot use short-lived roles.
Data retention & deletion
- How long is a free scan kept?
- 30 days. A DynamoDB TTL attribute is set on the record at creation, so deletion happens automatically rather than depending on a cleanup job.
- How long is a paid audit kept?
- 365 days, via the same TTL mechanism, matching the 12-month retention stated in the Privacy Policy.
- Can a customer have something deleted early?
- Yes — a scan, an account, or everything attached to it. Request it through the support channel in security.txt and we do it within 30 days. There is no self-service delete button in the product yet.
Logging & monitoring
- What logs are kept, and for how long?
- CloudWatch Logs for the Lambda and Fargate workers, explicitly retained 14 days in the CloudFormation templates rather than left at the indefinite default. The web app's runtime logs are held under Vercel's own standard retention, which is not something we configure.
- Could those logs contain personal data?
- They can incidentally contain the domain someone asked us to scan. They do not contain scan tokens, the HMAC callback secret, Stripe keys, or the cookie/storage contents a scan observed — those are never passed to a log call.
- Are visitor IP addresses stored?
- An IP is used as a rate-limit key for up to 24 hours (the counters themselves expire on a DynamoDB TTL) and is never written onto a scan record. It is not retained beyond that window.
Development & supply chain
- What dependency scanning is in place?
- Dependabot, configured in .github/dependabot.yml: weekly npm updates (minor and patch grouped into one PR, majors surfaced separately for review) and monthly GitHub Actions updates. There is no separate SAST or container-scanning tool configured yet.
- Does CI gate what reaches production?
- A GitHub Actions workflow runs typecheck, lint, a formatting check, the test suite and a production build on every push and pull request, for both the web app and the scan worker. Whether these are set as required checks in GitHub's branch protection is a repository setting we do not assert here.
- How is the software bill of materials produced?
- At build time, from the lockfile: npm sbom --sbom-format cyclonedx, run against the web app and, separately, the worker. Published at /.well-known/sbom-web.cdx.json and /.well-known/sbom-worker.cdx.json.
Incident response
- Has there been a security or availability incident?
- One is on the public incident log on this page: a three-day outage of paid checkout, 2026-09-08 to 2026-09-11, caused by a mixed Stripe test/live configuration. No customer or scan data was affected; free scans were unaffected throughout.
- How would customers be notified of a future incident?
- Account owners are emailed directly through SES, and this incident log is updated. For a scan-level problem, the same alert channel a monitor uses carries the notice.
Business continuity
- Is scan and audit state backed up?
- Yes — DynamoDB Point-in-Time Recovery is enabled on the scan-state table, giving continuous backups for the trailing 35 days.
- Is evidence (screenshots, HAR files) backed up?
- Screenshots are stored in a private S3 bucket with SSE-S3 and a 12-month lifecycle. They are evidence attached to a report, not a system of record, so they are neither versioned nor replicated: a lost screenshot is regenerated by re-running the audit. HAR capture is not built.
Compliance posture
- Is Sasquatch Privacy SOC 2 or ISO 27001 certified?
- No. No third-party certification or audit of any kind has been completed. This page and the trust center it is part of are published in place of one, not as a stand-in claim that one exists.
- Has Sasquatch Privacy had a penetration test?
- No.
- What is Sasquatch Privacy's role under GDPR?
- We act as a processor for the technical observations made about a site a customer asks us to scan — the customer, as the site's owner, is the controller of that data. Once accounts and billing exist, we are the controller for that account and billing data. A data processing agreement is available on request. No formal compliance audit has been performed against this framing.
Subprocessors
- Who are the subprocessors, and what do they do?
- Vercel (application hosting); Amazon Web Services (scan and audit workers, storage, email delivery via SES — us-west-2, us-west-1, us-east-1, eu-central-1, eu-west-2); Supabase (accounts, organisations and monitoring data); Stripe (payments); GitHub (source control and CI). The full list, with purpose, is on the main trust center page.
- Is there a process for adding a new subprocessor?
- Not a formal notification process yet — there are no accounts to notify. The list above is the current source of truth and is updated here when it changes.
Vulnerability management
- How are dependency vulnerabilities found?
- Dependabot on the schedule described under Development & supply chain. There is no additional static analysis, container image scanning, or paid penetration-testing program in place yet.
- How do I report a vulnerability?
- Through /.well-known/security.txt, which names our support contact and links to the disclosure policy on the trust center page.
Sasquatch Privacy provides technical privacy observations and is not legal advice.
Need this in another format, or have a question this page does not answer? Reach us through support.