For security, legal and procurement reviewers. The documents we sign and publish, plain answers to the questions vendor questionnaires ask most, and who to email for the rest. Every answer below links to the page that holds the binding wording, and that page controls if the two differ.
Documents
| Document | What it covers |
|---|---|
| Security and data handling | What the API stores, key handling, encryption, sub-processors, incident notice |
| Data Processing Agreement | Roles, instructions, sub-processors, transfers under the Standard Contractual Clauses |
| Service Levels | Availability target, how it is measured, support response targets, maintenance notice |
| Vulnerability Disclosure Programme | Scope, safe harbor, response times, coordinated disclosure |
| security.txt | The machine-readable contact and policy pointer (RFC 9116) |
| Accessibility Statement | WCAG 2.2 AA target, current conformance status, known limitations |
| Privacy Policy | What personal data we hold about customers and site visitors, and why |
| Terms of Service | The standard terms for self-serve use of the API and MCP server |
| Status | Live availability and incident history for the API and MCP server |
Questions reviewers ask
These are the answers we give most often, taken from the pages above. If your questionnaire asks something that is not here, send it to us. We would rather answer it than guess at what you need.
| Question | Answer | Where it is written |
|---|---|---|
| Do you store the text of our queries? | No. API request content is held in memory for the length of the request and is not written to a database or a log. | Security, section 1 |
| Is our data used to train models? | No, not ours and not our providers’. Language-model sub-processors operate under zero-data-retention terms. | Security, section 5 |
| How is data encrypted? | AES-256 at rest for the database and document storage. TLS 1.2 or higher in transit, TLS 1.3 where the client supports it. HTTP is rejected. | Security, section 4 |
| How are API keys protected? | We authenticate against a SHA-256 hash of the key. Revocation takes effect at once. Each key is rate-limited and can spend only the credits on its account. | Security, section 2 |
| Can access be restricted by IP address? | Yes, on enterprise plans. | Security, section 2 |
| Who are your sub-processors, and do you give notice of changes? | The register, with regions and the data each one handles, goes to customers and their counsel on request. We give at least 30 days’ notice before adding one. | Security, section 6 |
| How do you handle cross-border transfers? | Transfers of personal data from the EEA or UK are made under the EU Standard Contractual Clauses. We give at least 30 days’ notice before moving primary Customer Data to another country. | DPA |
| How quickly will you tell us about a breach? | Without undue delay and within 72 hours of becoming aware of a confirmed incident that affects your data. | Security, section 7 |
| Do staff use multi-factor authentication, and who can see our data? | Staff use multi-factor authentication and production access is limited to what the work needs. We do not read the content of application matters unless you ask for support or we are diagnosing an incident. | Security, section 8 |
| Do you scan dependencies for known vulnerabilities? | Yes, routinely. | Security, section 8 |
| How is customer data separated in the application? | Logical isolation with row-level security on database queries and object-store reads, role-based access, admin-enforceable TOTP two-factor authentication, and audit logs of sign-ins, permission changes, uploads, sharing and deletions. | Security, section 9 |
| What happens to our data when we leave? | Matters and documents are exportable for 30 days after cancellation, then deleted. API request content is never stored. Billing records are kept for up to seven years. | Security, section 9 |
| What availability do you commit to? | A 99.5% monthly target for the Data API and MCP server, measured by an external monitor and published on the status page. A contractual SLA with service credits is available on an enterprise order form. | Service Levels |
| How do researchers report a vulnerability? | By email. We acknowledge within 72 hours, triage within 5 business days, and follow a 90-day coordinated-disclosure timeline. Good-faith research is covered by a safe-harbor commitment. | Vulnerability Disclosure Programme |
| Is the site accessible? | We build to WCAG 2.2 AA and describe ourselves as partially conformant. We have not had an external accessibility audit and do not claim full conformance. | Accessibility Statement |
Requesting more
Email contact@vaquill.ai for any of the following:
- The current sub-processor register, with regions and the data each one handles.
- A completed copy of your own security questionnaire.
- A signed DPA, or a redline of ours against yours.
- A contractual SLA with service credits, IP allow-listing, or a dedicated deployment.
Tell us the vendor-review process you are working to and the date you need to finish, and we will say what we can supply by then. You can also use the contact page.