What you are asked to run, and what leaves your network.

What you are being asked to run

Docusense is a set of containerised services with their own data stores. It is not an agent installed on user machines, and it does not need access to a mail server, a file share, or a directory beyond the identity provider you point it at.

Application services

A web interface and an API. The API applies every access check and owns questionnaires, review changes, search, processing jobs, and generated responses.

PostgreSQL

The system of record. Users, customers, questionnaires, items, answers, policies, and processing history live here.

Vector store

Derived search indexes. Nothing here is a source of truth, so it can always be rebuilt from the database.

File storage

The original uploaded files and the generated PDF responses, kept so a reviewer can always open the source.

Document processing

The parsers that convert PDF, Word, Excel, and PowerPoint files into text, including optical character recognition and table extraction where a source needs it.

Model endpoints

Completion, embedding, reranking, and document processing models. These are the only components whose location differs between the two deployment options.

In a managed deployment we run all of this. In a self-hosted deployment you run all of it, and the core deployment can operate without an internet connection.

The isolation boundary

The boundary is the tenant, which is the subscribing organization. Every tenant's instances have their own application stack, PostgreSQL database, vector store, persistent file storage, internal network, and runtime secrets. Knowledge and questionnaire data are not shared, matched, or exposed across tenants.

Three terms are used precisely throughout the product and it is worth fixing them before a security review. A tenant is your organization and the isolation boundary. Acustomer is a business record inside your tenant, meaning one of the companies you answer questionnaires for. An instance is one environment belonging to your tenant, either production or sandbox.

Docusense offers an option to match a question against answers given for other customer records. That means other customers inside your own tenant. It can be disabled, and it never means matching across tenants.

Identity and sign-in

Sign-in is configurable so it can follow whatever policy you already enforce. Docusense supports passwords, passkeys, multi-factor authentication, Microsoft Entra ID, and other OpenID Connect providers.

Where a federated provider is used, a user is identified by the pair of issuer and subject rather than by the subject alone, because a subject identifier is only unique within its issuer. Sessions can be invalidated for a user without touching other accounts.

If you already run single sign-on with conditional access and your own MFA policy, that is the arrangement we would expect. Docusense then trusts your provider and does not hold a password for those users at all.

Who can see what

Authorization has two independent layers, and both apply.

The first is a permission profile. Every non-administrator account derives its permissions from a profile, and a profile is a matrix of individual permissions grouped by area, covering customers, questionnaires, answers, products, library and search, operations, administration, and system settings. Permissions are individual rather than bundled into fixed job titles, so a profile can be shaped to match a role you already have. Some permissions are scoped rather than on or off, and some depend on others being granted first.

The second is customer assignment. Access to customers can be set to none, to assigned customers only, or to all customers in the tenant. Assignment decides which questionnaires a person can open regardless of what their profile permits, so a specialist can be given a capable profile and still see only the accounts they work on.

The library and maintained reusable answers are tenant-wide by design, because they are shared reference material rather than customer records.

Access checks are applied in the API rather than in the interface, so they hold for any client. Records outside a user's scope are reported as not found rather than as forbidden, which avoids confirming that a record exists to someone who may not access it.

Where data goes

This is usually the question that decides the review, so it is worth being exact about it.

Self-hosted

The application, document processing, and every model service run in your environment. Documents, prompts, embeddings, and generated text stay inside your network. The core deployment can operate air-gapped. You control the infrastructure, identity, recovery, updates, and model capacity.

Managed

We operate an isolated environment for your tenant in the Netherlands. Managed AI model infrastructure is shared across tenants. Prompts and documents sent to it are processed without being retained by the model service and without being used for training. If your requirement is that no document content is processed on infrastructure shared with anyone else, the self-hosted option is the one that meets it, and we would rather say so than argue the point.

In both options, what the models actually receive is described on theretrieval page. It is the question, the retrieved passages, and the instructions for that step.

Where the AI models run

Model endpoints are configuration rather than architecture. An instance holds a set of configured servers and models, and each model is registered for one purpose. The application asks for the active model of a purpose, so an endpoint can be replaced without any change to the application.

That has a practical consequence for a self-hosted deployment. You are not committed to one vendor's models. Any endpoint that speaks the expected interface can be configured, including models you host yourself on your own hardware, and different purposes can be served by different providers.

Upgrades, backups, and recovery

A managed tenant receives one production instance and two sandbox instances. Upgrades are scheduled per tenant and are not pushed automatically. A release can be applied to a sandbox and tested against your own data and processes before you schedule the production upgrade.

The managed backup baseline is one immutable full snapshot per day, stored off-site in the same hosting region. Backup frequency and retention are agreed with you during setup and can be changed for your tenant afterwards.

Database and storage encryption can be configured at several layers to meet the requirements agreed with your team. There is no single fixed encryption design applied to every tenant, so this is a conversation to have during setup rather than a specification to read off a page.

Incident response detail, support hours, response targets, and availability terms are specific to each customer agreement. We would rather negotiate those with you than publish a standard promise that does not fit your situation.

In a self-hosted deployment, backup, recovery, patching, and capacity are yours. The vector store is derived data and can be rebuilt from the database, which usefully reduces what a recovery plan has to cover.

Questions worth asking us

If you are assessing Docusense against your own controls, these are the questions we would ask in your position. A technical session can be arranged with the people who built it rather than with an account manager.

• Which of our identity providers do you support, and what happens to a user when we deprovision them there?
• What exactly leaves our network in the deployment we are considering, and what is retained at the other end?
• Show us the permission matrix and how a profile maps onto the roles we already use.
• What does a processing failure look like to a reviewer, and what does an administrator see?
• Walk us through the upgrade path, including how we test a release before it reaches production.
• What are the backup, encryption, and retention arrangements you can agree for our tenant?
• How do we get our data out, in what format, if we stop using Docusense?