Security Practices

1. Payment Security

All payments are processed by Stripe, a PCI DSS Level 1 certified service provider. Card details are entered directly into a checkout form served and rendered by Stripe. That form runs on Stripe's own domain inside an isolated frame, so card numbers, expiry dates and security codes are transmitted from your browser to Stripe without passing through Altilos servers, application code or logs.

Altilos never receives, stores or has the ability to retrieve your full card number. What we retain against an order is limited to Stripe's own identifiers, the plan purchased, the amount and currency, any add-ons selected, and the payment status.

Payment confirmations reach us as signed webhooks from Stripe. Every delivery is verified against a shared signing secret before it is acted on, and any request that arrives unsigned or with an invalid signature is rejected outright. Verified events are recorded by their unique Stripe event identifier, so a replayed or duplicated delivery cannot cause an order to be processed twice.

2. What Data We Hold

We practise data minimisation: the service only collects what is needed to deliver a research report and to contact you about it.

What we store

• •Contact details. Your name, work email address, company and phone number.
• •Order records. The plan purchased, amount, currency, status, add-ons, and the corresponding Stripe and CRM identifiers.
• •Your research brief. The answers you submit describing your category, target consumers, locations and the questions you want answered.

What we never store

• •Card and bank details. These stay with Stripe, as described above.
• •Passwords. Altilos has no user accounts and issues no passwords, so there are no credentials of yours for an attacker to steal, reuse or crack.

Your research brief is commercially sensitive, and we treat it that way. It is used to produce and deliver your report and is not sold, published, or shared with other customers. The categories of personal information we process, and the purposes we process them for, are set out in full in our Privacy Policy.

3. Encryption

Every connection to Altilos is served over HTTPS using TLS. We send a HTTP Strict Transport Security header with a two-year lifetime covering all subdomains, which instructs browsers to refuse any future plain-text connection to us — this closes off downgrade attacks and protects visitors on untrusted networks.

Customer records are held in managed PostgreSQL provided by Neon, which encrypts data at rest and requires TLS for connections from our application. Traffic between our application and the third-party services listed below travels over TLS-protected APIs.

4. Access to Your Brief

After payment you receive a private link to the onboarding form where you set out your research brief. Because there are no accounts or passwords, that link is the credential — so it is designed to fail safely.

• •Unguessable. Each link carries a 256-bit token drawn from a cryptographically secure random number generator.
• •Never stored in usable form. We keep only an HMAC-SHA256 hash of the token, computed with a secret held in our server environment and never written to the database. Someone who obtained a copy of the database could not reconstruct a working link from it.
• •Short-lived. Tokens expire fourteen days after they are issued.
• •Single-use. A token is marked as used once the brief is submitted, and will not open the form again.
• •Scoped to a paid order. A token is only honoured while its order is in a paid state, and is rejected otherwise.

If you believe your onboarding link has been seen by someone else, email info@altilos.com and we will invalidate it and issue a new one.

5. Application Security

Input handling and data access

• •Server-side validation. Every submission — checkout requests and research briefs alike — is validated against an explicit schema on the server. Validation performed in the browser is treated as a convenience for the visitor, never as a security control.
• •Parameterised queries. All database access goes through parameterised statements, so values supplied by a visitor are passed as bound parameters and are never concatenated into SQL. This is the structural defence against SQL injection.
• •Contextual output encoding. Pages are rendered through React, which escapes interpolated values by default, mitigating cross-site scripting.

Browser-enforced protections

We set response headers that constrain what a browser will do with our pages, so that a single injected string cannot escalate into a working attack:

• •Content-Security-Policy restricting scripts, styles, frames, images and network connections to our own origin and the specific Stripe origins that checkout requires. Plugin content is blocked outright, and the document base URI and form submission targets are pinned to our own origin, which blocks form-hijacking.
• •X-Frame-Options: DENY and a `frame-ancestors 'none'` directive, so our pages cannot be embedded in a third-party site for clickjacking.
• •X-Content-Type-Options: nosniff, preventing browsers from reinterpreting a response as a type we did not declare.
• •Referrer-Policy: strict-origin-when-cross-origin, so paths and query strings are not leaked to external sites in the referrer header.
• •Permissions-Policy denying access to the camera, microphone, geolocation and other device APIs the site has no reason to use.

We also suppress the framework version banner, so our responses do not advertise the exact software versions we run.

Secret management

• •API keys and signing secrets are supplied only as environment variables in the deployment platform, and are excluded from version control.
• •Modules that read secrets are marked server-only, which makes it a build failure — not a silent leak — for credential-bearing code to be pulled into a browser bundle.
• •Only the Stripe publishable key, which is designed to be public, is ever exposed to the browser.

6. Infrastructure and Sub-processors

Altilos is built on managed infrastructure rather than servers we patch ourselves, which means operating-system and platform hardening is handled by providers who do it at scale. We use the following sub-processors:

Stripe maintains PCI DSS Level 1 certification, and Vercel and Neon each maintain their own independent security certifications for the platforms they operate. Their certifications cover their infrastructure, not the Altilos application itself — see the next section.

7. Retention and Deletion

We keep customer records for as long as needed to deliver your report, support you afterwards, and satisfy the tax and accounting obligations that attach to a completed sale. Expired and used onboarding tokens are retained only as hashes and carry no ability to access anything.

You can ask us to correct or delete your personal information at any time by emailing info@altilos.com. Where we are required to retain a record of a transaction for legal reasons, we will tell you what we must keep and why. The rights available to you, and how we handle such requests, are described in our Privacy Policy.

8. Certifications and Compliance

We would rather be accurate than impressive: Altilos is not currently SOC 2 or ISO 27001 certified, and we have not commissioned an independent penetration test. We do not operate a paid bug bounty programme. Any vendor that tells you otherwise about us is mistaken.

What we rely on instead is the combination described on this page: keeping card data entirely outside our systems, holding no passwords, minimising the personal data we collect, and building on infrastructure from providers who do hold current certifications. As Altilos grows, formal certification is on our roadmap, and we will update this page — with a new date at the top — when that status changes rather than in advance of it.

If your procurement process requires a security questionnaire, a data processing agreement, or written answers about any control on this page, contact info@altilos.com and we will work through it with you.

9. Security Incidents

If we become aware of a security incident affecting your personal information, we will investigate, take steps to contain it, and notify affected customers without undue delay, together with the regulators we are required to inform under applicable data protection law. We will tell you what happened, what data was involved, and what we are doing about it.

10. Reporting a Vulnerability

We welcome reports from security researchers, and we would much rather hear from you than from an attacker. Please send findings to info@altilos.com with the subject line beginning “Security”, including enough detail to reproduce the issue — the affected URL or endpoint, the steps you took, and what you observed.

We aim to acknowledge a report within five business days, and we will keep you updated while we work on a fix. Our machine-readable contact details are published at /.well-known/security.txt in line with RFC 9116.

When investigating, please do

• •Give us a reasonable opportunity to fix an issue before disclosing it publicly.
• •Use only test data and your own accounts, orders and onboarding links.
• •Stop as soon as you have demonstrated a problem, and tell us rather than exploring further.

Please do not

• •Access, modify or exfiltrate data belonging to another customer.
• •Run denial-of-service tests, load tests, or automated scanning heavy enough to degrade the service for others.
• •Use social engineering, phishing, or physical intrusion against our staff or our providers.

Testing against Stripe, Vercel, Neon or any other provider listed above is out of scope for us — please report those findings through that provider's own disclosure programme.