What we hold
- Your account email and organisation name
- The domains, brand names, and published content you ask us to protect
- Scan findings, evidence captures of third-party pages, and case history
- Billing status from Stripe — never card numbers
Security
What we hold, how it is protected, and what we have not done yet.
You are considering giving a vendor your brand assets and your published content. That deserves a straight account rather than a wall of badges — including the parts where the honest answer is “not yet”.
Data
What we actually store
Less than you might assume, and deliberately so. The narrowest data set is the cheapest one to protect.
What we never hold
- Your customers’ personal data
- Card numbers or bank details
- Credentials to any of your systems — we need no access to them
- Health records, and we are not built to receive any
Controls
Current posture
In place
Encryption in transit and at rest
TLS 1.2+ everywhere, HSTS with preload. Google-managed encryption at rest on all stored data.
In place
Tenant isolation enforced twice
Ownership is checked in the API and again in database security rules, so an API bug alone cannot expose another customer’s data.
In place
Secrets never in code or images
All credentials resolve from Google Secret Manager at runtime. None are baked into the container.
In place
Credentials rejected at write time
The database refuses documents containing password, token, apiKey, or cookie fields. We are structurally unable to store your secrets.
In place
Backups and point-in-time recovery
Daily backups with seven-day retention, PITR enabled, and delete protection on the production database.
In place
Unprivileged runtime
The application container runs as a non-root user with no shell access.
In place
Written security policies
Information security, access control, change management, incident response, data retention, vendor management, and risk assessment. Available under NDA.
Scope
What we are and are not built for
GDPR and UK GDPR: we act as a processor for the limited data above. A DPA is available on request, and standard contractual clauses are in place with our subprocessors.
PCI DSS: out of scope by design. Stripe handles payments in a hosted checkout, so card data never reaches our servers.
HIPAA: not applicable. We do not receive, process, or store protected health information, and we will not sign a BAA. If your use case would put PHI in front of us, we are the wrong vendor and we will say so.
Vendor security review: we keep a completed security questionnaire, written policies covering access control, change management, incident response, retention, and vendor management, and a control assessment mapped to the AICPA Trust Services Criteria. Ask and we will send the package, along with a straight answer about anything it does not cover.
Subprocessors
Who else touches the data
| Subprocessor | Purpose | Region |
|---|---|---|
| Google Cloud (Cloud Run, Firestore, Secret Manager) | Application hosting and data storage | United States |
| Firebase Authentication & Hosting | Sign-in and static site delivery | United States |
| Stripe | Payment processing. Card data never reaches our systems. | United States |
| Google Gemini | Classification of scan results | United States |
| Transactional email provider | Alerts and takedown correspondence | United States |
We will give notice before adding a subprocessor that processes customer data.
Disclosure
Found a vulnerability in our systems?
Report it to security@alphaguard.live. We will acknowledge within two business days and keep you updated until it is fixed. We will not pursue legal action against anyone who reports a finding in good faith, stays within their own test account, and does not access or destroy other people’s data. We do not currently pay bounties, and we will say so rather than let you assume otherwise.
To dispute a takedown notice you received from us, write to abuse@alphaguard.live.