What the security questionnaire asks - and which answers hold

The most dangerous answer in a security questionnaire is not the missing one. It is the one that is too good.

The questionnaire arrives after the demo, once everybody has already said yes. It often runs to more than a hundred lines, it goes to IT security and to data protection, and it is read by people who read every answer twice. “All data is encrypted” sounds fine until somebody asks which data, with what, and who holds the key. At that point the sentence falls apart, and with it the credibility of every other answer on the form.

This article goes through what such a questionnaire actually asks of an analytics platform for visitor data, and how to build an answer that survives the review meeting. Which data arrives in the first place is covered in Privacy is an architecture decision. How data gets out and in is covered in Open interfaces. This one is about everything in between: who sees what, how a session is protected, what is encrypted, and what happens when a contract ends.

Three test questions for any answer

Before looking at individual controls, there are three questions you can put to any vendor's answer - ours included.

The third row looks the least important and matters most. A data protection officer hears the difference between anonymous and pseudonymous immediately, and respects a vendor who draws it unprompted. The reasoning is in Privacy is an architecture decision; here is only the wording that belongs on the form.

First question: who sees whose figures?

On a platform with many customers, the expensive question is not who gets in but whose figures someone sees once they are in. A store manager should see their own sites - not the store next door, and never another customer's. A wrongly set permission otherwise only shows up when someone else's figures appear in a screenshot.

Tenant separation holds up when three things are true:

• The check sits in the query layer, not in the interface. Then it applies to every analysis, including one added tomorrow, and to every call through the API.
• It closes when in doubt. A user with no assigned site sees nothing - not everything. The term is fail-closed, and it is the question to ask in the meeting: what does someone see if nobody has assigned them anything?
• Revocation takes effect at once. Someone who loses rights does not carry on working until their session expires.

A simple role model belongs with it. Two roles are enough on the customer side: an administrator who sees their own tenant with all sites, and standard users who see only the sites assigned to them. Every assignment is checked against the tenant's site list before it is saved, and every change is logged with its before and after state.

Second question: how is a session protected?

This is where the first test question is strictest. Every row has a value and a purpose:

None of these rows is exotic. This table is still where most questionnaires get stuck, because the vendor does not know the values or only offers an adjective.

Third question: what exactly is encrypted?

This is where the second test question pays off. “Encrypted at rest” is, on any cloud database, a property of the platform rather than the application. That is good and proper, but it is a provider control - and a good answer names it as one.

What the application itself should encrypt are the things that could do harm in the hands of someone with read access to the database: recipients' contact details, chat channel addresses, sensor credentials, signing secrets for events. AES-256-GCM is the standard for that, with key derivation and an authentication tag that makes any tampering visible.

The count data is a different case. It consists of whole numbers per site and minute from which no person can be reconstructed. Its protection lies in its structure, not in a key.

An answer that keeps these three layers apart is longer than “everything is encrypted”. It is also the only one that survives a review.

Fourth question: what ends up in the logs?

Logs are where personal data lands without anyone deciding it should. An error message records an email address, a debug entry a token, a delivery failure a full URL with credentials in it. The answer that holds is therefore a mechanism, not a policy:

• Redaction in every entry, by field name - password, token, authorization, cookie, email, IP address - and by pattern as well: email addresses and phone numbers masked, bearer tokens and JWTs removed.
• Errors that reveal nothing inside. No stack traces in production, database errors mapped to a handful of generic messages. Whoever sees an error message learns nothing about what sits behind it.
• Outbound calls hardened. A target a customer registers is checked at registration, on every change and again at delivery - with name resolution and normalisation of every way an IP address can be written, so that no internal target slips through in an unusual notation. Redirects are not followed. The term is SSRF hardening; what it means for alerts is covered in From number to action.

Fifth question: who changed what?

An audit log answers the question that comes first after any incident. It is useful when it is broad enough and does not lose entries quietly:

• Breadth: sign-in and session security, denied access, user, tenant and site administration, keys, event targets, alerts, export, deletion and access to data, calendars, configuration, sensors.
• No silent loss: entries are written in batches, every second or every 50 entries, with a flush on shutdown. A crash does not drop an entry unnoticed.
• Privacy inside the log itself: metadata is cleaned on write, and the IP address is pseudonymised on write.
• Access for the customer: the tenant's own audit log can be retrieved through the API with a read key - the route is described in Open interfaces.

Sixth question: how long does what stay?

The retention periods for count and behavioural data are in Privacy is an architecture decision. A questionnaire also asks about everything that operations produce:

The periods are enforced by a daily run with around 35 rules. A rule that points at a data set that does not exist reports itself as misconfigured - not as compliant. It is the same stance as everywhere else in this article: a check that found nothing because it never ran must not look like one that had nothing to find.

Seventh question: what happens when a contract ends?

This is the question most often forgotten and most regretted when it matters. A clean process has four steps:

1. Day 0, lock: sign-in locked; alerts, reports, events and API switched off. Data intake keeps running so that a reversal leaves no gap.
2. 30 days reversible: within that window, reversal is a switch. Nobody loses their history over a misunderstanding at contract renewal.
3. Deletion cascade: after that, a scheduled run removes the tenant's and its sites' data sets as well as the accounts at the identity provider, in batches that resume after an interruption.
4. Dry run by default: the irreversible run is a dry run by default, behind a kill switch. It goes live only deliberately - not through a configuration error at three in the morning.

Access and erasure for data subjects under Art. 15 and Art. 17 GDPR run through a tenant-bound API with a register, export, deletion and dry run.

What the sensor brings along

Part of the questionnaire concerns the device on the ceiling, not the software. The seals and certificates of the sensor ranges belong to the manufacturer, and that is how they should appear in the answer - as a property of the hardware, not as a statement about the platform. What each one means is covered in Privacy is an architecture decision. An answer that keeps the two apart is more precise, and therefore more credible.

What belongs in the tender

1. Where does the tenant and site check sit - in the interface or in the query layer?
2. What does a user with no assigned site see?
3. Does revoking rights take effect at once, or only when the session expires?
4. Which values apply to idle timeout, absolute session length, CSP and HSTS?
5. Which fields does the application encrypt itself, and what does the platform underneath provide?
6. How is personal data kept out of logs and error messages?
7. Which actions are recorded in the audit log, and how does the customer get at it?
8. Which retention periods apply to operational data, and how are they enforced?
9. What happens in the 30 days after a contract ends, and how is final deletion triggered?

How we do it

The ANALYSIT Counting System separates tenants in the query layer and closes when in doubt: an empty site assignment means no access. Site assignments are validated against the tenant's site list before they are written, role and assignment changes are audited with their before and after state, and any reduction of rights invalidates running sessions immediately.

Sign-in runs through Auth0 with OAuth2/OIDC and session regeneration. Browser sessions end after 30 minutes idle and after 8 hours at most, are bound to the user agent via HMAC and are revoked server-side through a revocation marker. On top of that come a Content Security Policy with a nonce per request, HSTS with preload, X-Frame-Options DENY and nosniff.

Secrets and contact details are encrypted with AES-256-GCM, every log entry passes through PII redaction, errors appear without a stack trace, and outbound calls are hardened against SSRF. The audit log is designed as append-only, covers more than 60 action types and can be retrieved for your own tenant through the REST API. Around 35 retention rules run daily, and a tenant that leaves stays reversible for 30 days before the deletion cascade, a dry run by default, is switched live.

If a security questionnaire is on its way to you, talk to us. We answer it with values, not adjectives.