1. Hosting and location
| Operator | Queantic LLC, Worcester, Massachusetts, United States. |
|---|---|
| Hosting location | United States. All application servers, databases and mail infrastructure are in U.S. data centres and administered from the United States. |
| Data residency | No customer or visitor data is stored, processed or replicated outside the United States. |
| Administration | Infrastructure is administered by Queantic directly. There is no outsourced operations provider and no offshore development contractor with access to production. |
2. Encryption
Stated field by field rather than as a single sentence, because a single sentence is how vendors end up overstating this.
| What | Protection |
|---|---|
| All traffic to and from the site | TLS. Certificates are issued and renewed automatically; renewal runs daily and does not depend on anyone remembering. |
| Mail in transit | SMTP over STARTTLS on submission, with DKIM signing and SPF and DMARC published for every sending domain. |
| Account passwords | Hashed and salted. Never stored or recoverable in plaintext; a reset issues a new credential rather than revealing the old one. |
| Stored service credentials | Encrypted at field level with libsodium authenticated encryption, keyed from an installation secret held outside the database. |
| Payment card data | Never touches our infrastructure. Card entry and storage are handled entirely by Stripe; we hold a customer reference and nothing else. |
| Disks at rest | Not encrypted today. See the open items in section 8. |
3. What we collect about your visitors
This section is usually the one that decides a public-sector evaluation, so here is the actual shape of the data rather than a privacy promise.
- There is no per-visitor record. The analytics table holds aggregate counters — by country, city, browser, operating system and referring page — plus a probabilistic sketch used to estimate unique visitors. There is no row per visit, no session identifier and no visitor profile, because the schema has nowhere to put one.
- Nothing is written to the visitor's browser. No cookie, no local storage, no fingerprint. There is no analytics JavaScript in the page at all — collection is a single image request — which also means there is no third-party script on your site that could be compromised upstream.
- Geolocation never leaves this server. A visitor's country and city are resolved against a 5.7-million-row IP2Location database held locally. No address is sent to a geolocation API, so there is no geolocation subprocessor to disclose and nothing to cache.
- One qualification, stated because it is the honest version. On lower-volume sites a truncated hash of the visitor's IP is kept so that unique-visitor counts are exact rather than estimated. That hash is not currently salted, and an unsalted hash of an address is enumerable by someone determined enough. It is being changed to a salted, rotating scheme. We are telling you because you would be right to ask, and a vendor whose answer is "it's hashed, don't worry" has not answered.
4. Access control
- Authorisation is server-side, always. Every route that touches a site resolves the requester's access against a single membership check before rendering anything. Access is never enforced by hiding a link.
- Least privilege on hand-off. The role a site owner is handed can change what the site says and how it looks, and cannot install code, manage users, alter hosting or touch billing. That boundary is defined once, in code, and projected onto every site rather than configured per site.
- Separation of duties. Operator functions are gated on a single definition of "operator" and are not reachable by a customer who administers their own site.
- Sessions. Signed, with a lax same-site policy, and invalidated on password change. A sign-out destroys the session token rather than only clearing a cookie.
- State-changing operations carry CSRF tokens, and the privileged surfaces are audited against a single declared permission table rather than per-handler checks.
- No multi-factor authentication yet. See section 8.
5. Monitoring
- Application availability is probed every five minutes — the public site, the application, the API, the webhook endpoint, the database and mail, each checked independently.
- The host is checked every ten minutes by a separate liveness job that can restart a failed component without a person present.
- Certificates and domain registrations are checked daily for approaching expiry, because the most common avoidable outage is an expired certificate.
- Results are public. Every component's 90-day history is on our status page, with no login. We do not ask you to take uptime on trust; read it.
- Rate limiting and bot classification run on the collection path, so abusive traffic is identified rather than counted.
6. Incident response
- Detection. Availability probes, the daily expiry check and an internal event log that records privileged and unusual actions; the log raises an alert by mail at its highest severity.
- Triage, within one hour of detection during business hours. Scope, cause and whether any customer data is implicated.
- Containment before explanation. The affected component is isolated or rolled back first. Our gates are designed to fail closed, so a component that cannot make a decision withholds rather than exposes.
- Notification. If an incident affects your site, you are told — what happened, what was affected, what we did. If personal data is implicated, we notify you within 72 hours of becoming aware, with enough detail for you to meet your own notification duties.
- Written follow-up. For anything beyond a brief outage, a written account of cause and the change made, and an entry on the public status page.
Report a suspected vulnerability or incident to us directly through the contact page. We will fix it and credit you if you want the credit. Please give us time to patch before disclosing publicly.
7. Subprocessors
The complete list. Anything not named here does not touch your data.
| Who | For what | What they can see |
|---|---|---|
| Stripe | Payments and invoicing | Billing contact and payment details. No site content, no visitor data. |
| Hosting provider (U.S.) | Compute and storage | Has physical custody of the disks. No application-level access, and no account with us. |
| Let's Encrypt | TLS certificates | Domain names only, which are public by nature. |
| Domain registrar | Registration and DNS, where we hold the domain for you | Registration contact details. |
No analytics processor, no advertising network, no customer data platform, no content delivery network with access to your traffic. There is nothing to remove from that list, because nothing was added to it.
8. Open items
Published rather than omitted. An evaluator who asks the right questions finds these in half an hour, and a vendor who waited to be asked has told you something about themselves.
- Scheduled, offsite backups. There is no automated backup schedule today. Archives have been taken by hand. This is the single most important item on this list and it is being closed first; until it is closed, we will not quote you a recovery point or recovery time objective, because we would be making it up.
- Full-disk encryption at rest. Not in place. The sensitive fields are individually protected as set out in section 2, which is not the same thing and is not presented as the same thing.
- Multi-factor authentication for administrative accounts. Not implemented. Authorisation is strong and server-side; the second factor is missing.
- Salting the per-visitor hash. See section 3.
- Independent penetration test and accessibility audit. Neither has been performed. The accessibility audit is in progress.
If any item in section 8 is a pass/fail requirement in your solicitation, we cannot meet it today. Ask us for the current status before you score it — this page is dated, and the list is getting shorter.
This document is part of Queantic's vendor packet. The rest of the packet — and the two items we supply on request rather than publish — are listed on the procurement page. Questions about anything in it: ask us directly.