Skip to content
VEYQON
Trust · Operate/SEC

Encryption, isolation, and an audit trail.

The controls a security review asks for, documented and independently tested — including how the agents are constrained, which is the question most reviews now open with.

SOC 2 Type II·ISO 27001·Published sub-processors

What it does · 29 capabilities/01

The controls, by the section of the questionnaire.

Arranged to match how a security review is actually structured, so the person filling in your questionnaire can work down the page rather than hunt.

01

Data protection

At rest, in transit, and in between.

  • Encryption in transit

    TLS 1.2 or above on every connection, including between internal services, with modern cipher suites only.

  • Encryption at rest

    Database, object storage, and backups encrypted, with keys managed in a dedicated key service.

  • Customer-managed keys

    Available on dedicated deployments, so revoking a key is a control you hold rather than one you request.

  • Field-level protection

    Credentials and secrets stored encrypted and never readable back through the interface or the API.

  • Backups encrypted and tested

    Point-in-time recovery, with restores exercised rather than merely configured.

02

Access control

Who gets in, and what they reach once in.

  • SSO and MFA

    SAML 2.0 and OpenID Connect against your identity provider, with MFA enforced by your policy rather than ours.

  • SCIM provisioning

    Joiners, movers, and leavers applied automatically, which is what makes access review tractable.

  • Row- and field-level permissions

    The same model for people, API keys, and agents. There is no privileged path with looser rules.

  • Session control

    Configurable timeouts, device session listing, and remote revocation.

  • Our own access

    Support access to your instance is opt-in, time-bound, logged, and visible to you — not a standing privilege.

03

Agent constraint

The section most questionnaires have only recently added.

  • Agents inside the permission model

    An agent is scoped exactly like a user, with row- and field-level rules applied before inference, not after.

  • Explicit tool permissions

    A named list of permitted actions per agent. Capability is granted, never inferred.

  • Hard ceilings

    Value, period, document-type, and volume limits that cannot be crossed however the agent is prompted.

  • No training on your data

    A contractual term rather than a setting, covering every model option we offer.

  • Prompt injection posture

    Retrieved content is treated as data, never as instructions. An agent's permitted actions come from its configuration, not from a document it read.

  • Full attribution

    Every agent action on the audit trail with its inputs, its reasoning, and the limit that permitted it.

04

Assurance and testing

Evidence from somebody other than us.

  • SOC 2 Type II

    Reported annually, available under NDA, with the current bridge letter on request.

  • ISO 27001

    Certified information security management system, with the statement of applicability available.

  • Independent penetration testing

    At least annually and after significant architectural change, with a summary letter shareable.

  • Vulnerability management

    Dependency and container scanning in the pipeline, with published remediation targets by severity.

  • Responsible disclosure

    A published policy and a route for researchers that does not require them to find a sales address.

05

Resilience and response

What happens when something goes wrong.

  • Incident response

    A documented plan with defined severities, exercised rather than filed, and named roles rather than a distribution list.

  • Breach notification

    Committed timelines in the contract, aligned to GDPR obligations, rather than left to best endeavours.

  • Business continuity

    Recovery objectives stated as numbers, and tested, with the results available to you.

  • Status and history

    A public status page with incident history, including the ones that were our fault.

06

Privacy and residency

Where the data is and who else touches it.

  • Region pinning

    Data, backups, and inference pinned to a chosen region.

  • Published sub-processors

    A current list with notice before it changes, so your own DPIA stays accurate.

  • Data processing agreement

    Offered as standard with SCCs where transfers require them.

  • Retention and deletion

    Configurable retention, legal hold, and documented deletion on termination with a certificate.

A security review/02

How to get through one quickly.

Most of the delay in a software security review is waiting for documents. These are ready before you ask.

  1. 01

    Documents

    SOC 2 Type II, ISO certificate and statement of applicability, penetration test summary, and the DPA, under NDA.

  2. 02

    Questionnaire

    A completed CAIQ and a standard answer set, so your team is reviewing rather than transcribing.

  3. 03

    Architecture

    A session with an engineer rather than an account manager, covering isolation, keys, and agent constraint.

  4. 04

    Your own test

    Penetration testing your instance is permitted, with a notification process rather than a prohibition.

The spec/03

The specification.

The rows most questionnaires ask for, in one place.

In transit
TLS 1.2+, modern ciphers, internal services included
At rest
Database, storage, and backups; CMK on dedicated
Identity
SAML 2.0, OpenID Connect, SCIM, enforced MFA
Support access
Opt-in, time-bound, logged, visible to you
Agents
Same permission model; explicit tools; hard ceilings
Model training
Never on your data — contractual
Assurance
SOC 2 Type II, ISO 27001, annual penetration test
Residency
Region-pinned data, backups, and inference
Breach notice
Contractual timelines aligned to GDPR
Exit
Open-format export and documented deletion
Where it stops/04

What we will not claim.

A trust page that only lists strengths is not a trust page. These are the honest edges.

A certificate is not a guarantee
SOC 2 and ISO describe how we run the service against a defined scope on a defined date. They are evidence, not a promise that nothing will ever go wrong.
Self-hosted security is shared
On your own hardware, patching, network controls, and physical security are yours. We document what we would do; we cannot do it for you.
Agents change the risk surface
Constraining them well is the point of the design, but an autonomous system acting on your ledger is a new category of risk and should be reviewed as one.
We publish incidents
Including the ones that were our fault. If a status history with no incidents in it is what you are looking for, that is a vendor who does not publish them.

Next step

Bring one process. We will run it live.