The Hosting Section of a Security Questionnaire, Answered
Every vendor security questionnaire has a hosting section, and it is the one that most often goes back and forth. The questions it asks, the answers for a shared workspace and for a dedicated instance, and the positions behind them.
Security questionnaires vary in length, but the hosting section asks the same handful of things in every template: where the records are, who else is there, how they are separated, whose key encrypts them, and how they are backed up. This is the reference sheet for that section, written for the reviewer who has to fill it in.
The questions, and both sets of answers
| Question | Shared workspace | Dedicated instance |
|---|---|---|
| Is customer data stored in a shared database? | Yes, separated per organization by the application | No. One database, one organization |
| How is data separated? | Every request is tied to its organization; a request that cannot establish one returns no records | By deployment: no other organization’s records exist in the database |
| Is data encrypted at rest? | Yes, under one key for the shared service | Yes, under a key generated for the instance |
| Are background jobs isolated? | One shared queue | A queue and scheduler that run for the instance only |
| Where are files stored? | With the shared service | In storage belonging to the instance |
| Are backups segregated? | Part of the shared service’s backups | A backup set of the instance’s own |
| Which address do users sign in at? | awraops.com | The instance’s own subdomain on awraops.com |
| Who operates it? | AWRA | AWRA |
Two rows deserve a sentence more than a table cell allows. The separation row on the shared side describes a failure mode as well as a mechanism: the system is built so that an unscoped request sees an empty result, not a full one. And the encryption row is the reason a dedicated instance answers the key-separation question at all. Encryption at rest is per deployment, so a separate deployment is what produces a separate key. Where your data lives covers the same ground from the residency side.
The most useful answer on a questionnaire is the one the next reviewer does not have to query.
What sits behind each answer on a dedicated instance
A dedicated instance, layer by layer
Address and certificate
Its own subdomain, served over its own TLS certificate.
Application
Its own system user and web processes on the server, running for one organization.
Background work
Its own queue worker and scheduler, so no other organization’s jobs share its queue.
Database
A database holding one organization, and a database user with access to nothing else.
Encryption key
Data encrypted at rest under a key generated for the instance.
Files
Attachments, documents and exports in storage of the instance’s own.
Backups
A backup schedule and backup set belonging to the instance.
Release
The same code as the shared service, updated on the same schedule.
What a dedicated instance shares, stated for the record
A reviewer should hear these from the vendor rather than discover them. The code release is common to every customer. The hosting region is the same as the shared service’s. The sub-processor register is the same published list. On the Dedicated tier, the physical server is shared with other dedicated instances, each with its own database, processes and key, and never with the shared service. The Dedicated server tier places the instance on a machine of its own.
Three positions held on purpose
- One codebase. A dedicated instance is never a customised fork. That is what keeps it on the current release, with current security fixes, rather than on a version only one customer runs.
- We operate it. Servers, updates and backups stay with us. A reviewer gets one accountable operator rather than a split between vendor software and customer infrastructure.
- Region belongs to the deployment. It is never presented as an account setting, because a setting would imply a guarantee that the infrastructure does not make.
For the wider questionnaire beyond hosting, the security overview and the trust center are the places to start, and ten questions for any vendor is the buyer’s version of this page.
Checks a reviewer can ask us to evidence
Is the database single-organization?
Ask for
A statement in the contract or order form.
What it confirms
The isolation is an obligation, not a description.
Is the encryption key unique to the instance?
Ask for
Confirmation that the instance has its own application key.
What it confirms
Key separation follows from deployment separation.
Who are the sub-processors?
Ask for
The published register, with regions.
What it confirms
The full list of parties that touch the data.
Is the instance current?
Ask for
The release it is running.
What it confirms
It matches the shared service.
For the reviewer
On a shared workspace, the hosting section is answered with a description of how organizations are separated. On a dedicated instance, most of it is answered with “one organization”. Both are accurate. The second is shorter, and it is the one that tends not to come back with follow-up questions.
The short version of the hosting section
A dedicated instance of AWRA, run by us, used by your organization alone.
See the dedicated instanceFrequently asked questions
What does the hosting section of a security questionnaire ask?
Usually where data is stored, whether the database is shared, how organizations are separated, whose key encrypts data at rest, whether backups are segregated, and who operates the infrastructure.
Does a dedicated instance have its own encryption key?
Yes. Encryption at rest is per deployment, so a dedicated instance is encrypted under a key generated for it alone.
Does a dedicated instance share a server?
On the Dedicated tier it shares a physical server with other dedicated instances only, each with its own database, processes and key. The Dedicated server tier gives it a machine of its own.
Is a dedicated instance a customised version of the product?
No. It runs the same code as the shared service and is updated on the same schedule.
