PROCUREMENT
Procurement
One page for procurement. Data handling, security posture, sub-processors, residency, your right to leave with your data, compliance status, breach commitments, and every published document.
The core difference
Your data is yours. We refuse to sell it.
We refuse to sell it. We refuse to trade it. We refuse to collect what we do not need. Minimum collection is not a limitation here; it is the shield. The less we hold, the less anyone can take.
What Pallas holds
- Your name and avatar, for your profile
- Your organization name and billing metadata, for billing
- The WCAG scan findings and evidence you upload, at your discretion
- Operational records (scans run, findings changed, reports generated) in your own audit log
That is the whole list for your account; marketing email records are a separate system, described under Export and erasure below. Our user profile records carry a name and avatar. Your email address is held in the authentication record that signs you in, not in the profile record. No phone number and no postal address is stored in either.
What Pallas never collects
- No behavioral analytics or user profiling
- No cross-site tracking cookies
- No third-party analytics scripts (no Google Analytics, Segment, or PostHog)
- No marketing or advertising pixels
- No data-enrichment or people-lookup services
Cookies are limited to Cloudflare Turnstile session tokens and, on the checkout page only, Stripe. Nothing follows you across the web.
We do not sell your data to third parties, ever. We do not share it beyond the sub-processors listed below, and we do not aggregate it for marketing. Any user can export or delete their own account data, and an organization admin can export or delete the organization's data, at any time from within Pallas. See Export & erasure below.
Security posture
Security is infrastructure, on every tier including the smallest.
Authentication
OAuth-only, through Google Workspace and Microsoft Azure AD. Pallas stores no passwords, so there is no password-reset attack surface. No magic links (a common phishing vector) and no SMS codes (a SIM-swap vector).
Tenant isolation
Row-Level Security is enabled on every application table. Every query the application makes is scoped to the authenticated user's organization at the database layer, so cross-tenant reads and writes are refused by the query planner rather than by application code. Server-side operator functions run under least-privilege service credentials that bypass RLS by necessity; those functions are limited in scope, versioned in source, and covered by the audit trail below.
Encryption
AES-256 encryption at rest through Supabase-managed infrastructure and TLS in transit through Cloudflare and Supabase. Both are provided and attested by those providers; Pallas relies on their attestations rather than implementing either itself.
Audit trail
Every audit event is written to a tamper-evident audit log (SHA-256), so any modification, deletion, or reordering of historical events is detected. Lawful removals under our retention policy or under GDPR Article 17 are recorded as redaction entries in the same log, so a reviewer sees both what remains and what was lawfully removed and why. Daily anchor snapshots of the chain tip are retained; on request, we can export any anchor for you to verify independently, and anchors can be published externally for public verification.
This is enforced at the database level: an audit event cannot be silently modified or deleted. An attempt is either refused or recorded as a redaction with its reason attached.
Rows for compliance-relevant actions carry a 7-year retention floor at the database layer, and administrators cannot set it below the regulatory minimum. Anchor export and external publication are operator actions rather than an automated feed; we do not claim an automated external anchoring service.
Rate limiting
Authenticated endpoints are protected by per-user rate limits. Unauthenticated marketing endpoints (free scan, newsletter) are protected by combined IP and email rate limits.
Session security
JWT-based sessions via Supabase Auth. Refresh tokens rotate on use, limiting the value of any single captured token.
Known limitations
A risk we have accepted is still a risk you are entitled to see. This section names one we have not closed, why we have not closed it, and what stands in its place.
DNS rebinding against the scan proxy
What the limitation is. When you submit a URL, a Cloudflare Worker fetches that page on your behalf. The Worker validates the hostname you supplied before fetching it. The check and the connection are two separate moments, and a hostname that is public at validation time can resolve to a private address at fetch time. That is the DNS-rebinding case, and someone who controls the authoritative DNS zone for a domain controls what happens between those two moments.
Why it is not fixable at this layer. A Cloudflare Worker resolves DNS inside its own fetch call. The runtime exposes no hook to read the address a hostname resolved to, and no way to pin the connection to an address the code has already validated. Without one of those two, there is no point at which the Worker can compare the address it approved against the address it connected to. This is a property of the runtime, not a gap in the guard.
What is in place today. A hostname and IP-literal denylist blocks localhost, .local and .internal names, cloud metadata endpoints, loopback, link-local, unique-local, IPv4-mapped private addresses, and the private, CGNAT, and multicast IPv4 ranges, so the direct SSRF vector is closed. A 10 MB response cap is enforced against the declared Content-Length and again against the bytes actually received, so a rebind cannot be used to stream an unbounded response through the Worker. Scanned third-party markup renders on a dedicated origin with nothing in its storage, pinned shut with Content-Security-Policy, so markup retrieved through the proxy cannot reach the app's session, cookies, or IndexedDB. The Worker also states this residual risk in its own source, at the point the decision was made.
What limits the blast radius. This Worker egresses from Cloudflare's edge to the public internet. It is not inside a Lonia AI private network, no Pallas private network is reachable from it, and Workers have no cloud instance metadata service. A successful rebind lands the fetch on an address Cloudflare's egress does not route.
What a future fix would require. A resolving egress proxy: a service that resolves the hostname itself, validates the resolved address, and then connects to that address rather than re-resolving the name. No such service exists anywhere in our stack today, so this is new infrastructure with its own hosting, certificate handling, availability budget, and attack surface, not an edit to this Worker.
The partial mitigation we considered and did not take. Pre-resolving the hostname over DNS-over-HTTPS and rejecting private answers is a small change and does not close the finding. It is time-of-check to time-of-use: an attacker controlling the zone flips the answer between our resolution and the Worker's own. It would raise the attack cost from trivial to requiring a race, and in exchange it would add a DNS round trip to every scan and a new failure mode when the DNS-over-HTTPS endpoint is slow or unavailable.
Status. Accepted by the operator on 30 August 2026 at informational severity, on the recommendation of the pre-launch re-audit, which named no action before launch. We will revisit this if our stack gains an egress proxy or a private network, if the proxy is ever given access to a private network or to credentials, if Cloudflare's runtime gains address pinning or a resolved-address hook, or if the proxy's role widens beyond fetching public third-party HTML for scanning.
Sub-processors
6 sub-processors, each delivering a core function on our behalf under data-protection terms no less protective than our DPA. This list matches our sub-processors page entry for entry.
| Sub-processor | Role | Scope |
|---|---|---|
| Cloudflare | Hosting, CDN, and edge security | Workers, Pages, Turnstile challenge protection |
| Supabase | Application data | PostgreSQL database, authentication, object storage |
| Stripe | Payments and invoicing | Billing, tax calculation, customer portal |
| Resend | Transactional email | Invite emails and data-request notifications |
| OAuth sign-in provider | Authentication assertion (name, email, profile photo) at sign-in. No customer data is stored with Google by Pallas. | |
| Microsoft | OAuth sign-in provider (Azure AD) | Authentication assertion (name, email) at sign-in. No customer data is stored with Microsoft by Pallas. |
We give at least 30 days' notice before adding or changing a sub-processor. The authoritative list, with full data categories and each provider's own certifications, and the process for objecting to a change, is on our sub-processors page. To receive change notices, email support@lonia.ai.
Data residency options
United States
Application data in the Supabase us-east-1 region, served through Cloudflare's global edge network.
Residency is not the same as sovereignty. Data residency means your data is stored on servers in the stated region. Data sovereignty means your data is subject only to that region's law. Because Lonia AI is a US-registered company, US legal process may still apply to our records regardless of storage region. Quebec Law 25 and EU Schrems II considerations apply. Our Transfer Impact Assessment covering the sub-processor chain is published in the Documents section below.
Yours to keep or remove
Export and erasure, on your terms
Data export (DSAR)
Two exports, both self-service and always available to an organization admin from within Pallas. The full account export returns organizations, members, assets, scans, findings, reports, subscriptions, audit events, and retention policies as JSON. The report-level export returns findings, reports, and audit records as CSV and PDF, which is the format named in our DPA and Privacy Policy. Both are rate-limited to prevent abuse.
Account deletion
Any user can delete their individual account from Pallas Settings. Deletion cascades to their profile and organization memberships. Audit events recording actions that user took against an organization are not deleted with the account: they are retained to the 7-year regulatory floor described above and then purged. That is deliberate. An audit trail that a departing user can erase is not an audit trail, and the moment someone most wants those records gone is the moment an administrator most needs them.
One refusal case, stated rather than hidden: if you are the sole administrator of an organization, the deletion refuses until you promote another administrator or delete the organization itself. That prevents an organization nobody can manage. Nothing is deleted while the refusal stands.
Organisation deletion
Any organization admin can delete the entire organization from Settings. All organization content cascades: assets, scans, findings, reports, evidence uploads, and subscriptions. Audit events tied to the organization are retained for the 7-year regulatory floor before purge; the retention job runs daily.
Your data rights
Export and deletion are the two rights with a button. They are not the only rights you have. Depending on where you are, you can also ask for access to what we hold, rectification of anything wrong, restriction of processing, and you can object to processing or withdraw consent for marketing at any time. Pallas makes no automated decisions with legal or similarly significant effects about you; findings are advisory. You can complain to your own supervisory authority without going through us first.
Every right is named, with its legal reference and the exact steps to use it, on Your rights, by jurisdiction, covering the EU, UK, Ireland, the United States including California, Australia, and Canada. The step-by-step route, with and without an account, is at How to exercise your rights. We respond within 30 days.
Every right listed on that page is enforceable end to end. The delete-account button in the app is the same right you would email support to invoke.
No support ticket required. No form to fill out. No 30-day waiting period. The buttons are inside the app.
One boundary worth knowing. Marketing email is a separate system from your Pallas account. If you gave us an email address for a free-scan report, a resource download, or the newsletter, that record is held until you unsubscribe and is not removed by deleting your account in the app. Use the unsubscribe link in any of those emails, or write to support@lonia.ai and we will remove it.
Unsubscribing takes effect immediately. The link opens a page that asks you to confirm, and confirming deletes the address and every enrolment record attached to it. What we keep afterwards is a one-way SHA-256 fingerprint of the address, so that a later form submission cannot put you back on the list by accident; it is the only thing that outlives an unsubscribe and it cannot be turned back into your address. Section 2.4 of the Privacy Policy sets out how to have that removed as well.
Compliance frameworks
Compliant
Self-assessed against the framework's requirements. We do not currently hold a formal certificate for these; compliance is a matter of practice and documentation.
- GDPR (EU) (See our Data Processing Agreement)
- UK GDPR + Data Protection Act 2018 (See our Data Processing Agreement)
- PIPEDA (Canada) (See our Privacy Policy)
- Australian Privacy Act + APPs (See our Privacy Policy)
Product accessibility conformance
The frameworks above are statements about our own legal compliance. The standards below are statements about how this marketing site and the Pallas application measure against the accessibility criteria themselves, which is a different question with a different answer. Our published VPAT reports partial support against all three, so we do not list them as Compliant.
- WCAG 2.2 Level AA. Partially compliant, with the exceptions named (See our accessibility statement)
- Section 508 (US). Partially compliant, with the exceptions named (See our accessibility statement)
- EN 301 549 v3.2.1. Partially compliant, with the exceptions named (See our accessibility statement)
Aligned
Our posture matches the framework's baseline. A formal assessment or certification is deferred.
- SOC 2 Type II. No certificate is held today, and we do not claim one.
- Australian Essential Eight. Applicable controls aligned to the Maturity Level 2 baseline. Formal IRAP assessment deferred.
- HIPAA. Pallas is not designed to process PHI. A Business Associate Agreement program is not currently offered; customers with PHI processing needs should not upload PHI to Pallas.
Planned
Deferred until launch revenue supports the cost of assessment.
- ISO 27001. No certificate is held today, and we do not claim one.
- Cyber Essentials (UK). Planned post-launch.
- IRAP assessment (Australia). Deferred until an Australian federal contract warrants the cost.
We do not currently hold formal certifications for the aligned or planned frameworks.
Breach commitments
Customer notification
Without undue delay, and in any event within 72 hours of becoming aware of a breach affecting your data. This matches the commitment in our DPA; we do not wait for confirmation to start the clock.
Authority notification
Per jurisdiction: Ireland DPC within 72 hours, UK ICO within 72 hours, EU supervisory authority within 72 hours, Canada OPC under PIPEDA, and Australia OAIC under the Notifiable Data Breaches scheme.
Post-incident report
A full technical postmortem within 30 days for affected customers.
A sub-processor breach triggers the same 72-hour notification from Pallas to you once Pallas is notified; each sub-processor's own notice to Pallas is governed by that provider's terms.
Contact for compliance inquiries
General inquiries
Data protection, DPA, security disclosure, and legal notices
Response window: 2-3 business days. Sales calls by scheduled request only.
Availability and support targets
What we operate to, and where a contractual commitment starts.
Availability
Pallas targets 99.9% monthly availability for the application and its API, on commercially reasonable efforts. Pallas runs no uptime monitor and publishes no measured availability history. Maintenance windows are announced at least 48 hours in advance and are scheduled outside 08:00 to 18:00 US Eastern on business days wherever possible. The application and the marketing site run on Cloudflare and Supabase; where an underlying provider is the cause of an outage, our recovery is bounded by theirs.
For Starter, Growth, and Enterprise this is an operating target provided on commercially reasonable efforts, not a contractual service credit.
Support response targets
| Plan | Channel | First-response target |
|---|---|---|
| Free scan | Email to support@lonia.ai | Best effort, no target |
| Starter | 2 business days | |
| Growth | 1 business day | |
| Enterprise | 4 business hours |
First response means a human acknowledging your request and telling you what happens next, not a resolution. Targets apply during business hours, 09:00 to 17:00 US Eastern, Monday to Friday, excluding US public holidays. Security reports to support@lonia.ai are triaged ahead of the queue on every plan, including the free scan.
Vendor questionnaire answers
The rows most security questionnaires ask for, answered here so you do not have to open a thread for each one. Where we have not formalized something, the row says so. We would rather lose a deal on an honest answer than win one on a claim we cannot evidence.
| Item | Status | Detail |
|---|---|---|
| Responsible disclosure | In place | A published policy at /.well-known/security.txt, RFC 9116 conformant, with support@lonia.ai as the reporting address and a stated preferred language and expiry. We acknowledge reports within 2-3 business days. We do not operate a paid bug bounty and we do not require an NDA to report. |
| Vulnerability management and patching | In place | Dependency advisories are monitored through the package registry audit feed and platform security alerts, and are triaged by whether a request path actually reaches the affected code: an advisory in a build-time tool that never runs in front of a visitor is treated differently from one in shipped code. Platform-level patching for the database, edge network, and runtime is performed by Supabase and Cloudflare on their own schedules. We have not published a numeric remediation window, and we will not quote one here before we can hold it. The triage itself is written down: the current record covers every open advisory with the specific reason it is or is not reachable in this build, carries a review date, and is available on request from support@lonia.ai. |
| Change management | In place | Every change reaches production through version control: the hosting platform builds the site from the main branch on every push, and the build itself fails closed rather than degrading: a missing or invalid bot-protection key halts it and an incomplete content-security policy halts it, and both guards remove the dist directory so a failed build leaves nothing to deploy. The build command (npm run build) runs, in order, a TypeScript type check, a typography check, a published-document freshness check, the six written-claim verification gates, the unit test suite over the security and validation code (the SSRF guard, the report sanitisers, the redirect and download allowlists, the request parser, and the Turnstile verifier), the build, an automated accessibility test against every built page, a Turnstile configuration check against the built artifact, and a sweep of the built output for claims the approved-claims record forbids; a non-zero exit at any step fails the build and nothing deploys. Production configuration and secrets are held in the platform secret store and never in the repository. |
| Backup and disaster recovery | Aligned | Application data is held in Supabase managed PostgreSQL with provider-operated automated backups and point-in-time recovery, so the recoverable window is set by the provider tier rather than by a schedule we run ourselves. We do not publish a recovery time objective or recovery point objective, because a number we cannot yet evidence from a restore test is worth nothing on a questionnaire. |
| Business continuity | Aligned | The service runs on Cloudflare's edge network and Supabase's managed platform, so continuity for the infrastructure layer is inherited from providers rather than run in-house. Application data is held in a single Supabase region. We do not yet publish a tested business continuity plan document, and we will say so on a questionnaire rather than claim one. |
| Penetration testing | Not yet formalized | We do not publish a third-party penetration test report and have not committed to a fixed testing cadence. What we do run is documented and repeatable: an adversarial security review of the codebase, an automated accessibility test run against every release build, and dependency advisory monitoring. No date for an independent test is promised. If your process requires a current report before signing, tell us during procurement and we will tell you honestly where we are. |
| Personnel screening and security training | Not yet formalized | Pallas is operated by a single operator, and we do not publish a background-screening or annual security-training program. Access is limited by the same controls the product uses: OAuth-only sign-in with no passwords to share, least-privilege service roles, and a tamper-evident audit log over administrative actions that the operator cannot silently alter. |
| Cyber liability insurance | Not yet formalized | We do not publish a cyber liability policy or certificate. Where a contract requires evidence of cover, raise it during procurement and we will address it in the agreement rather than leave it unanswered here. |
If your questionnaire asks something not covered here or in the sections above, send it to support@lonia.ai and we will answer it directly. Answers we give more than once get added to this page.
What we can demonstrate and what we assert
A claim marked Demonstrated here is backed by an artifact in the repository that builds this site, and a release gate fails if it stops being true. A claim marked Asserted by us is a statement about the Pallas application, which is a separate system.
| Claim | Basis | What backs it |
|---|---|---|
| Marketing site is tested against WCAG 2.2 AA on every release | Demonstrated here | axe-core 4.11.x runs against every built page as a release gate; a violation fails the release. The gate has no layout engine, so colour contrast and target size are checked manually rather than by the gate. Overall conformance status is partially compliant and the exceptions are named on /accessibility. |
| No passwords are stored anywhere | Demonstrated here | There is no password field, reset flow, or credential store in this repository, and sign-in is delegated to Google and Microsoft OAuth. The application half is asserted. |
| The free scan does not store the page it analyses | Demonstrated here | The scanned page is parsed in a cross-origin sandbox in your browser; only summary counts and the top issues cross back, and the report builder discards the node arrays. See /privacy section 1.5 for what the proxy does and does not cover. |
| The build fails closed on a missing bot-protection key or an incomplete content-security policy | Demonstrated here | Both guards run in the build and remove the output directory on failure, so a broken build produces nothing that can be deployed by hand. Verified by the release command. |
| Row-level security scopes every query to your organization | Asserted by us | Enforced in the Pallas application's database, which is not part of this site. No independent audit report exists yet. |
| The audit trail is a tamper-evident audit log (SHA-256) and carries a 7-year retention floor | Asserted by us | Enforced by database triggers and constraints in the application, not by application code. Lawful removals are appended to a redaction ledger instead of vanishing. A verifier over the whole log and one over a single row exist. What a reviewer cannot check from this site is the database it runs in. Anchor export and external publication are manual operator steps, not an automated service. |
| Data is encrypted at rest and in transit | Asserted by us | Provided by Supabase and Cloudflare at the platform layer. Their own compliance reports are the underlying evidence and are available from them directly. |
| Deletion is self-service and cascades | Asserted by us | The controls are in the application. Note the boundary below: marketing email records are a separate system and are not covered by an in-app account deletion. |
| Per-tier seat, web-asset, document-asset, and scan limits | Asserted by us | The published numbers are consistent across every page of this site, but the enforcement lives in the application. If a limit ever stops being enforced, nothing on this site would notice. |
| SOC 2 Type II, ISO 27001, HIPAA BAA | Not held | No certificate is held today and we do not claim one. HIPAA is addressed as alignment, not as a signed BAA, and the frameworks section above says so. |
Where you need a claim converted from an assertion into an obligation, that is what a negotiated agreement is for: email support@lonia.ai.
Documents
Available to download now
Our full procurement pack is published openly. No request, account, email address, or sales conversation is required for any document below.
- Security whitepaper (PDF, approximately 209 KB)
How Pallas authenticates, isolates tenants, encrypts, audits, and retains data, with each control marked implemented, partial, or not implemented.
- Data Processing Agreement (PDF, approximately 159 KB)
The GDPR Article 28 terms, with UK, Swiss, Canadian, Quebec, and Australian obligations addressed where they diverge from the GDPR baseline.
This render is the public template and names Lonia AI as the party. Once terms are agreed, the executed version is issued to you on request at support@lonia.ai.
- Standard Contractual Clauses (Module Two) (PDF, approximately 237 KB)
The EU Standard Contractual Clauses as adopted by the European Commission, controller to processor, with Annexes I, II, and III completed for Pallas.
This render is the public template and names Lonia AI as the party. Once terms are agreed, the executed version is issued to you on request at support@lonia.ai.
- Institutional terms of service (PDF, approximately 123 KB)
The terms an institution contracts on, including plan and quota terms, data ownership, termination, and support commitments.
This render is the public template and names Lonia AI as the party. Once terms are agreed, the executed version is issued to you on request at support@lonia.ai.
- Data Protection Impact Assessment (PDF, approximately 185 KB)
Our Article 35 assessment of the processing Pallas carries out, including the risks we have not yet mitigated.
- Transfer Impact Assessment (PDF, approximately 158 KB)
Our post-Schrems II assessment of transfers to the United States, following the European Data Protection Board six-step methodology. An input to your own assessment, not a substitute for it.
- VPAT 2.5 with Accessibility Conformance Report (PDF, approximately 278 KB)
How the Pallas product itself measures against WCAG 2.2, Section 508, and EN 301 549, criterion by criterion.
- HECVAT-Full 4.1.6 (Higher Education Community Vendor Assessment Toolkit) (PDF, approximately 572 KB)
Completed higher-ed vendor assessment questionnaire, HECVAT-Full 4.1.6, with Pallas responses grounded in the control inventory.
- HECVAT-Full 4.1.6 workbook (Excel workbook, approximately 837 KB)
The same responses in the official HECVAT 4.1.6 template, for a reviewer who scores the questionnaire in their own tooling. Question text, identifiers, and the institution evaluation sheets are the published template, unaltered.
Every control claim in the procurement documents above is rendered from a single control inventory, with its implementation status and its limitations reproduced unaltered. A control we have only partly implemented says so in the document itself, not in a footnote. Each document lists every control it cites in its own appendix.
Request-only documents
These are issued to a named counterparty rather than published, either because they are executed instruments or because they are prepared for your specific jurisdiction:
- The executed version of any contract above, issued once terms are agreed
- A Data Processing Agreement or set of Standard Contractual Clauses adjusted for your jurisdiction, where the published terms do not fit it
Contact support@lonia.ai to request any of these. For the executed version of a contract, tell us your legal entity name and the jurisdiction of your establishment.
Published policies and terms
These are pages on this site rather than downloads. They are the governing text for everything above.
- Terms of Service. The agreement covering your use of Pallas.
- Privacy Policy. What we collect, why, how long we hold it, and every right you have by jurisdiction.
- Cookie Policy. What this site stores in your browser, which today is nothing of ours.
- Data Processing Agreement. The processor terms, also published as a PDF above.
- Sub-processors. The authoritative list, with data categories and change-notice process.
- Compliance standards. The standards Pallas scans against and what each one requires of you.
- Accessibility statement. Our own conformance, including where we are still only partially compliant.
- Accessibility enforcement directory. Who enforces these laws in each jurisdiction, and how to reach them.
Our commitment
This page reflects the posture of Pallas by Lonia AI as of 17 September 2026. We update it when the facts change. If you find a gap, tell us at support@lonia.ai.
Questions before you buy? Talk to us
We reply within 2-3 business days.