Is it safe and compliant to analyse a sales team's email and calendar to map relationships?

This is a summary of how these deployments are normally structured, not legal advice. Your DPO or counsel decides what is lawful for your business.

Metadata versus content

The single most important distinction. Almost all the relationship signal lives in the headers: who wrote to whom, when, and whether there was a reply. The body of the message adds very little and carries almost all of the privacy risk.

A vendor that reads only metadata is doing something materially different from one that parses message bodies, and it is a far easier conversation with your security team. Ask the question directly, and ask for it in the contract.

What GDPR actually requires here

A lawful basis. Legitimate interests is the usual one for B2B relationship data. It requires a documented balancing test - your interest in the processing against the rights of the people whose data it is. Write it down before you deploy, not after.

Transparency. Both sides. Your employees need to know their mailbox metadata is being processed and why. The external contacts in the graph have rights too, which in practice means your privacy notice has to cover them.

Data minimisation. Collect the fields the product actually needs. "We ingest everything in case it is useful later" is the posture that fails an audit.

Deletion and access. You must be able to find and remove an individual on request. Ask the vendor to demonstrate this on a real record during the evaluation, rather than describing it.

Retention. Set a limit. Relationship data that decays in usefulness after two years should not be kept for seven.

What usually goes wrong

In practice, failures are organisational rather than technical:

• The tool is switched on without telling the employees whose mailboxes are read. This is the one that produces an internal incident, and it is entirely avoidable.
• Nobody writes the legitimate interests assessment, so there is nothing to show when it is asked for.
• The graph is pooled across the vendor's customers without that being understood at purchase. Some products do this by design; it is a legitimate model and a very different risk profile.
• Admin access is unscoped, so anyone can look up anyone's personal contacts.

A checklist before you deploy

1. Confirm in writing whether the vendor reads message bodies or metadata only.
2. Complete and file a legitimate interests assessment.
3. Update the employee privacy notice, and tell people in a channel they read.
4. Offer employees an opt-out, and make it real.
5. Agree where the data lives and whether it is pooled with other customers.
6. Agree a retention period and a deletion process, and test the deletion.
7. Scope admin access so the graph is not browsable by anyone who wants to look.

Where Orbb stands

Orbb processes relationship data inside the customer's own tenant with their consent, works from interaction metadata and public professional history rather than message content, and supports per-individual removal. If you are running a security review, ask us for the detail rather than taking a web page's word for it.