Explainer for a works council

1

Start with the hard part

What does exist is a control your employer applies in its own tenant: an application access policy, which tells Exchange to refuse this application access to any mailbox outside a named group. It is applied by your employer's Exchange administrator, not by the supplier, and it can be verified by your employer and by you.

The product does two things about this rather than leaving it to trust. It gives the administrator the exact command that applies the policy, and it then tries to read a mailbox that should be outside the policy and reports whether it was refused. That probe is the evidence: a policy that is in place produces a refusal, and a policy that was never applied does not.

If your employer has not put mailboxes in scope at all, none of this applies, and the mail permission is not requested. That is worth establishing first, because it is the question everything else turns on.

2

What the product is for

It finds out where personal data is stored across an organisation's files and, where the employer chooses, its mail. The output is an inventory: this site contains national identity numbers, roughly this many, in these documents, shared this widely.

The reason an employer wants this is ordinary. An organisation is required to know what personal data it holds and where, and most do not. The reason a works council should look at it carefully is equally ordinary: a system that reads everything in order to describe it is a system that could be used to read everything.

3

What it records

Content is read into memory, classified, and discarded when the job ends. What is written down is a note about the document, and the note is: where it is, what category of personal data it contains, how many values, how confident the classification is, and a position such as a page, a sheet or a cell.

The value at that position is never recorded. This is not a policy that could be relaxed by a setting: there is no column in the database that could hold it, and the supplier's own test suite plants known values, runs them through the system, and then searches the database, the queue, the notification payloads and the worker's temporary storage for each of them. If any turned up, the build would fail.

Two things are recorded that are worth knowing about. The filename and the folder path are kept, so that a reviewer can open the document itself with their own permissions. And the account that owns a site, a drive or a mailbox is recorded, which is the only place an individual is named.

4

What it cannot do, and why that is a fact rather than a promise

• It cannot search for an individual's data. There is no function that takes a person and returns where their data is. The supplier calls this a subject locator and has deliberately not shipped it, on the ground that it is the highest-risk feature in the product.
• It cannot display content. Nothing is stored, so there is nothing to display. The one exception is a masked snippet, which is off, which only an administrator can turn on, which is audited, and which at this stage is a place in the design rather than a working feature.
• It cannot monitor conduct, productivity or communications. It produces findings about documents and containers. No rule in it produces an outcome about a person.
• It cannot change anything. It holds read access only: it cannot move, delete, label, share or unshare a file, and it cannot send anything.

5

Where it runs and who else is involved

The workspace is pinned to one region when it is created and cannot be moved. Frankfurt is what is offered, with Stockholm by arrangement. The database, the website and the machine that reads content all run in that region.

Four sub-processors are used, all processing in the EU. Content reaches two of them: the host that runs the reading machine, where it exists in memory for the life of a job, and a classification service that receives short passages where pattern matching cannot decide. The published register names all four and says which two.

Microsoft and Google are not the supplier's sub-processors. They are your employer's own processors under your employer's own agreements, and the files and mail already sit with them.

6

What is genuinely difficult, stated by the supplier

• The mail permission is tenant-wide and the control that narrows it belongs to the employer. The product verifies it and cannot enforce it.
• Filenames and folder paths are personal data and the product keeps them. It keeps them because a finding nobody can open is a finding nobody can act on, and it is a real trade rather than a technicality.
• An inventory of where personal data lives, by container and by owner, is useful for purposes other than the one it was built for. The controls against that are access roles and an audit log, and they are controls in your employer's hands.
• A classification can be wrong. An item that could not be read is recorded as not read with the reason, and an item that could not be classified confidently is marked for review rather than clean, but a finding is still an input to a judgement rather than a judgement.
• No accuracy figure is published, because none has been measured yet. Any number quoted to you about how much this product finds is not one the supplier has published.

7

Questions to put to your employer

Each of these has an answer the product can evidence. An employer who cannot answer one of them has not finished deciding.

• What exactly is in scope? Name the sites, the drives and, if any, the mailboxes.
• Are mailboxes in scope at all? If yes, why, and what was considered instead?
• If mail is in scope, has the application access policy been applied, by whom, on what date, and what did the product's probe report?
• Is the owner view turned on? Who can see it, and what is it used for?
• Are masked snippets turned on? They should not be; confirm it.
• What are the retention periods for findings, scan records and audit records?
• Who has which role in the workspace, and who can change a setting?
• Will we see the audit log, or a report from it, on a regular basis?
• Has a data protection impact assessment been completed, and may we see it?
• What happens if a finding concerns a document a named individual owns? Who acts on it, and what is the process?
• Will the results be used in any performance, disciplinary or investigatory process? Record the answer.
• When will the decision to use the product, and to include mail, be reviewed?

8

What an agreement might sensibly cover

Where your jurisdiction provides for an agreement between the employer and a works council on the use of technical systems, the items below are the ones this product actually makes verifiable. They are offered as a starting list, not as a draft.

• The scope, named, and a requirement that any extension of it is agreed in advance.
• Whether mailboxes are included, and if so the group, the application access policy, and evidence of the probe.
• That the owner view and masked snippets stay off unless agreed, with the audit log as the evidence.
• That findings are not used in a performance, disciplinary or investigatory process.
• Who holds which role, and that role changes are notified.
• Retention periods, and that they are not extended without agreement.
• A periodic review, with the audit log and the scan record as the material for it.
• That the council is told before a new sub-processor is added, which the supplier notifies thirty days in advance.