Security & trust

Access

Password plus compulsory two-step verification (TOTP) for every user, without exception.
You confirm a new device with a code by email; after that it stays trusted for thirty days.
Signing in is limited to five attempts per minute per account. The authenticator code and the device code also have a limit.
Passwords are stored only as a hash (bcrypt), never as readable text.

Separation per organisation

Every organisation has its own database and its own address.
The databases are on the same database server: it is a separation per database, not a separate server per client.
A session or a connection of one organisation does not exist at the address of another.
A session cookie applies only to its own address and cannot be read by scripts.
We manage the platform from a separate admin environment with its own accounts. An account of an organisation cannot sign in there, and an account of the admin environment cannot sign in to a workspace.
Signing in to the admin environment requires a password and an authenticator, or a passkey; on a new device, a code by email is added.
From the admin environment we can create an organisation, temporarily block it and delete it. During a block, nobody can sign in to its workspace; its data remains.
Of what an organisation has in PrivaSearch, the admin environment shows only counts, statuses and timestamps, such as the number of documents and accounts and the size of the storage. It shows no names of projects, folders or documents, no text from a document, no pseudonyms and no entries from the activity log of the organisation.
The one exception is the accounts: we can see the name, the email address, the role and the status of each account of an organisation, block or unblock an account and resend an open invitation. Every time that list is opened and each of those actions is recorded in a log of the platform administration; the actions also appear in the activity log of the organisation, under the name Platform administration.
From the admin environment we can view along in the workspace of an organisation, as the support account Platform administration. Each time, this requires the password of the platform administrator and a reason from a fixed list; the start, the reason and the end are recorded in a log of the platform administration.
Viewing along is read-only and lasts at most one hour: every change is refused, and after sixty minutes the session ends by itself. While it runs, a bar at the top of every screen of the workspace says that Platform administration is viewing along.
The support account sees what an administrator of the organisation sees who is not a member of any project, such as the accounts, the activity log and the settings. It cannot open a document, an original or extracted text, cannot search and cannot reveal a pseudonym.
An attempt by the support account that is refused appears in the activity log of the organisation, under the name Platform administration. The start and the end of viewing along do not appear there; they appear in the log of the platform administration.
The support account is not an account of the organisation: it is not in its list of users, does not count anywhere and cannot sign in with a password, an authenticator or a passkey. We cannot sign in as a user of an organisation.

Data and encryption

Personal data is replaced by pseudonyms before indexing. Nothing is searchable until a staff member has released the text.
The link between pseudonym and person is stored encrypted in a separate vault.
The keys for the vault and for the encrypted fields are derived per organisation from a master key; the master keys are the same for all organisations.
Originals are kept in private object storage without public access, with a separate path prefix per organisation.
Encryption of stored files is a property of the storage the application runs on. The application does not encrypt originals itself; its configuration check checks the setting of the storage.

Permissions and oversight

Project membership determines who sees what, with the roles reader, editor and manager. Administrators get no automatic access to documents.
Any member of a project can open the original of a document, also with the reader role. That role limits what someone may change. Every download is logged.
Any member of a project can read the extracted text of a document that is waiting for the privacy review, also with the reader role. That is the text of the original, before pseudonymisation. Every view is logged.
Revealing one pseudonym in the pseudonymised text requires write access to the project. Every reveal is logged.
If a membership or a permission is missing, there is no access. Refused access is recorded in the activity log.
Every entry in the activity log is chained to the previous entry with a hash; a periodic check recalculates the chain.
The activity log contains no document content and no search queries.

Connections and browser

The connection with SharePoint is read-only.
An AI assistant connects via OAuth 2.1 with PKCE and receives only released, pseudonymised passages. Access tokens expire after eight hours.
Every page runs under a strict security policy for scripts and styles (Content Security Policy) and cannot be loaded in a frame of another site.
The browser does not keep a response and sends no referrer to another site.

Development

There is one quality gate for the source code: formatting, static analysis at level 9 without a list of exceptions, and a check on dependencies.
The automated tests run on the same kind of database as the service itself. Separate tests guard the separation between organisations.
Keys and passwords are not in the source code; the application reads them from the environment.
Every sentence about technology on this page is guarded by an automated test: if the sentence no longer holds, the test fails.

Part of Art. 21(2)	How PrivaSearch fills this in	Where the proof is
b) Incident handling	You report a vulnerability or incident by email; we confirm receipt. In the event of a data breach in your environment, you receive the information you need for your own notification.	Security , Data processing agreement
d) Supply chain security	Every party we engage is listed in the overview of sub-processors, with the purpose and the place of processing. We announce a change in advance.	Sub-processors , Data processing agreement
e) Security in development and maintenance, and the handling of vulnerabilities	One quality gate for the source code, automated tests on the same kind of database as the service itself, and a reporting point for vulnerabilities.	This page, under Development , Security
g) Basic practices and training	Two-step verification is compulsory for every user. Without a valid AI literacy training, the workspace does not open.	Security
h) Cryptography and encryption	An encrypted vault for the pseudonyms, encrypted fields in the database with a key per organisation, and passwords as a hash.	Security
i) Access policy	Access per project with roles, no automatic access for administrators, and an activity log that also records refusals.	Security
j) Multi-factor authentication	Password, authenticator and a confirmation by email for a new device.	Security

Control	How PrivaSearch fills this in	Where the proof is
5.15 Access control	Access per project with roles. If a membership or a permission is missing, there is no access.	Security
5.34 Privacy and protection of personal data	Pseudonymisation before indexing and a compulsory check by a staff member.	How it works , Security
8.5 Secure authentication	Password, authenticator and device confirmation, with a limit on the number of attempts.	Security
8.10 Information deletion	A retention period per project. A daily clean-up deletes originals, search fragments and pseudonyms whose period has expired.	Retention periods
8.11 Data masking	Pseudonyms instead of personal data in everything that is searchable. Revealing is only possible within PrivaSearch and is logged.	Security
8.15 Logging	An activity log per organisation, with refusals and without document content; the entries are chained together with a hash.	Security
8.24 Use of cryptography	An encrypted vault, encrypted fields with a key per organisation, and passwords as a hash.	Security
8.25 and 8.29 Secure development and testing	One quality gate for the source code and separate tests for the separation between organisations.	This page, under Development

Article	How PrivaSearch fills this in	Where the proof is
Art. 5(1)(e) · Storage limitation	A retention period per project, with deletion when it ends.	Retention periods
Art. 25 · Data protection by design	Pseudonymisation before indexing and a compulsory check by a staff member.	How it works
Art. 28 · Processor	A data processing agreement is part of every agreement.	Data processing agreement
Art. 30 · Records of processing activities	PrivaSearch drafts the register entry for this processing, derived from the set-up of your environment.	GDPR & AI Act
Art. 32 · Security of processing	The technical and organisational measures, in the form of the data processing agreement.	Security
Art. 33 · Notification of a personal data breach	In the event of a data breach in your environment, you receive the information you need for your own notification.	Data processing agreement
Art. 35 · Data protection impact assessment	PrivaSearch drafts a DPIA starter document, with a risk analysis and the measures.	GDPR & AI Act

Part	How PrivaSearch fills this in	Where the proof is
Art. 4 · AI literacy	A built-in training with a refresher after one year. Without a valid training, the workspace does not open and the connection with an AI assistant is refused as well.	GDPR & AI Act , Security
Oversight · Human oversight	Nothing is searchable until a staff member has released the text.	How it works
Transparency · Traceable answers	A search result refers to the document and the page where the passage is.	How it works
Logging · Traceability	The activity log records who did what and when, also for a connection with an AI assistant.	Security

What we secure, and where you can check it.

Six themes, in the application itself.

Access

Separation per organisation

Data and encryption

Permissions and oversight

Connections and browser

Development

Per framework: the requirement, how it is filled in and the proof.

NIS2 Directive and Cyberbeveiligingswet

ISO/IEC 27002:2022

GDPR

EU AI Act

Reporting a vulnerability or incident.

Which parties are involved.

A question about security, or need a document?

Read also