In short
- Private previews need a restricted link or named account and are excluded from search indexing.
- Reports are immutable and versioned. A correction creates a new artifact and preserves the original.
- Invalid or incomplete project data is not treated as approved or ready to publish.
- Report responsibly: security@staedy.com. We will not pursue good-faith researchers.
This summary is for orientation only. The full text below applies.
On this page
- 1. Access to private projects
- 2. Immutable artifacts
- 3. Validation before rendering
- 4. Data minimisation
- 5. Infrastructure and secrets
- 6. Email security
- 7. Payment security
- 8. Logging
- 9. Backup and recovery
- 10. Incident response
- 11. Reporting a vulnerability
- 12. Provider security
1. Access to private projects
Private previews and project environments require a restricted link or named account. Their routes are marked noindex, and access tokens are never included in analytics payloads or third-party requests. There are no analytics payloads on this site.
Links can be revoked, replaced or restricted on request. Operator access to production is default-deny and gated behind identity-aware access control with in-worker token validation.
2. Immutable artifacts
Approved project versions and publishing releases are recorded. A correction creates a new version rather than silently changing the approval record, so the presented and published states can be reconstructed.
3. Validation before rendering
Report payloads are validated against a canonical schema before anything is rendered. Invalid or incomplete data does not render.
AI provider failures remain visible in the internal research record rather than being converted into a confident finding. Models do not approve factual claims and cannot publish to a customer website.
4. Data minimisation
The service is designed around public business evidence and work contact details. Patient, client, guest and customer personal data is outside the intended scope and should never be sent to us.
Customer email addresses, payment data, website credentials, unpublished assets and private project feedback are never sent to AI providers used for guest-question research.
5. Infrastructure and secrets
Staedy runs on Cloudflare. Data is stored in the platform database and in private object storage that is not publicly reachable. Production capabilities that can cause external effects (provider calls, payment, email, publication) are gated and default to disabled.
Secrets are held in the platform secret store, never in source control, and are rotated on personnel or provider change.
Database migrations are forward-only, and restore procedures are exercised against disposable test resources rather than production.
6. Email security
Outbound mail is authenticated with SPF, DKIM and DMARC. Delivery and authentication results are recorded so that a delivery dispute can be resolved.
Email is not an inherently confidential channel. Report content is delivered through a private link rather than pasted into the body of an email wherever that is possible.
7. Payment security
Mollie processes card payments on Mollie Hosted Checkout. Qonto is used for the business account and invoice. Card data is entered directly with Mollie; Staedy never receives or stores full card numbers.
Payment webhooks are signature-verified and replay-protected before any state change is applied.
8. Logging
Security logs are designed not to contain full project content, payment data, email bodies, passwords or private link tokens. Retention is risk-based and short. See the retention table in the privacy notice.
9. Backup and recovery
The canonical business and approval record is backed up, and recovery is tested. Customers should still keep their own backups of the live website and delivered code or assets.
10. Incident response
Security incidents are triaged immediately on receipt. Where an incident involves personal data, we follow the breach process in the privacy notice, including notification to the supervisory authority within 72 hours where required and notification to affected people where the risk is high.
Affected customers are told what happened, what data was involved, what we have done, and what they should do.
11. Reporting a vulnerability
If you believe you have found a security vulnerability, email security@staedy.com with enough detail to reproduce it. We aim to acknowledge within one working day.
We will not pursue legal action against researchers who act in good faith, who:
- do not access, modify or delete data belonging to other people beyond what is necessary to demonstrate the issue;
- do not degrade or disrupt the service;
- do not publish details before we have had a reasonable opportunity to fix the issue;
- do not use the finding for extortion.
We do not currently operate a paid bug bounty. We do credit reporters who want to be credited.
12. Provider security
Providers are selected on the basis of their security posture and contractual commitments, and are documented under Subprocessors. Data processing agreements under Art. 28 GDPR are in place with processors, and international transfers are covered by the safeguards described in the privacy notice.