Which measures are actually built in.

Access

• A password plus mandatory two-step verification (TOTP) for every user, without exception.
• A new device is confirmed with a code by e-mail and is then trusted for thirty days; users and administrators can revoke devices and sign out everywhere.
• Attempts to sign in, to verify and to confirm a device are limited per route.
• Without valid AI literacy training the workspace does not open, and the connection with an AI assistant is refused as well.

Separation and permissions

• Every organisation has its own database and its own address. Accounts, sessions, trusted devices, connections with AI assistants, documents and the activity log are stored in that database; a session or a connection of one organisation does not exist at the address of another.
• The databases of the organisations are on the same database server and are accessed with the same database account. It is a separation per database, not a separate server per customer.
• Within an organisation, project membership determines who sees what, with the roles reader, editor and manager. Administrators get no automatic access to documents.
• Fail-closed: if a membership, an identity or a permission is missing, or the retention period has expired, there is no access and no processing. Denied access is recorded in the activity log.
• For documents from SharePoint, every delivery includes a live check under the user's Microsoft identity that they may still see the document there.
• We administer the platform from a separate administration environment with its own accounts, apart from the accounts of the organisations. An account of an organisation cannot sign in there, and an account of the administration environment cannot sign in to a workspace. Signing in to the administration environment requires a password and an authenticator, or a passkey; on a new device a code by e-mail is required as well.
• From the administration environment we can create, temporarily block and delete an organisation. During a block nobody can sign in to its workspace and no connection works; its data stays in place and is reachable again once the block is lifted.
• Of what an organisation has stored in PrivaSearch, the administration environment shows only counts, statuses and times: how many projects, documents, accounts and connections there are, how much storage it uses and when someone last signed in, uploaded and synced. 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: for an organisation we can see the name, the e-mail address, the role and the status of every account, block or unblock an account and resend a pending invitation. Every time that list is opened and each of those actions is recorded in a log of the platform administration. A block, an unblock and an invitation are also recorded in the activity log of the organisation, in the name of Platform administration.
• From the administration environment we can view the workspace of an organisation, as the support account Platform administration. This requires the password of the platform administrator and a reason from a fixed list every time; the start, the reason and the end are recorded in a log of the platform administration.
• Support access is read-only and lasts one hour at most: 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.
• 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 is recorded in the activity log of the organisation, in the name of Platform administration. The start and the end of the support access are not recorded there; they are 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, is not counted 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 pseudonymisation

• Original documents are kept in private object storage without public access. All organisations share that storage; each organisation has its own path prefix in it, and the application refuses any path outside it.
• Encryption of stored files is a property of the storage on which the application runs: the application does not encrypt originals itself. A configuration check in the application checks the setting of that storage; it rejects storage on the server's own disk for production.
• Personal data is replaced with pseudonyms before indexing. Nothing is searchable until an employee has checked the pseudonymised text and has explicitly released it.
• The link between pseudonym and person is stored encrypted in a separate vault. Revealing a single pseudonym is only possible within PrivaSearch, requires write access to the project and is logged.
• Every member of a project can open the original of a document, including with the role reader. The role reader limits what someone may change, not what they can see. Every download of an original is logged.
• Every member of a project can read the extracted text of a document that is awaiting the privacy review, including with the role reader. That is the text of the original, before pseudonymisation. Every view of that text is logged.
• The keys for the vault and for the encrypted fields in the database are derived per organisation from a master key. The master keys themselves are the same for all organisations.
• The activity log records who did what and when, including refusals — but no document content and no search queries. Every organisation has its own activity log, in its own database.
• Every entry in the activity log is chained to the previous entry with a hash; a periodic check recalculates the chain.

Connections

• The connection with SharePoint is read-only: there are no write operations towards SharePoint.
• An AI assistant connects via OAuth 2.1 with PKCE at the organisation's own address: the assistant registers itself and the user approves the connection. There are no separate access codes. The assistant receives only released, pseudonymised passages and never files, file names or pseudonym links. Access tokens expire after eight hours and can be revoked per user; they are issued with the same key pair for all organisations, and a token of another organisation is refused because it does not exist there.
• The website and the application run under a strict security policy for scripts and styles (Content Security Policy).

Retention and deletion

A retention period applies per project. When it expires, PrivaSearch blocks access and deletes the originals, search fragments and pseudonyms — unless a legal hold has been recorded. The periods per type of data are on the page retention periods.

Reporting a vulnerability or incident

If you find a vulnerability, e-mail security@privasearch.ai with a description and the steps to reproduce it. We confirm receipt and keep you informed about the fix. We ask two things: test only with your own account and not with other people's data, and do not make the vulnerability public before it has been fixed. If you are a customer and suspect a data breach in your environment, report it to the same address; we provide the information you need for your own assessment and any notification within 72 hours (Article 33 GDPR).

Read also

• What is a data breach? Examples, notification duties and your first 72 hours
• Is ChatGPT safe? What happens to your data and which settings you control