People and departments

People and departments

This page explains where Soveryne gets its information about your people: how employees, departments and groups enter each product, what is stored, and how that information is protected.

The short version

ProductWhere people come fromWhat is stored about them
CommandTheir first sign-in. Departments and their members are entered in Command.Name, email address, role, and the departments they belong to
CounselTheir first sign-in, through your organisation's email domain or a personal invitationTheir account, plus their own chats, uploads and evidence, which stay private within your organisation
BAITTwo separate groups: the few people who run your awareness programme sign in; the employees who receive simulations come from your directory, through MESHFor employees: email address, first name and group. Results are reported per group, never per person.
ATLASOnly the people who act in ATLAS, such as the signatory of your scanning mandateNames of the people who sign, verify or authorise
MESHThe directories and cloud accounts you connect, such as Microsoft Entra and Google WorkspacePeople, groups, memberships and access as your directory reports them, visible only to MESH administrators

Accounts and sign-in

Nobody is imported to create an account. A person's account is created the first time they sign in with single sign-on, and they get their role from your sign-in rules. See Single sign-on.

In Command, Users & roles (under Organisation › Workspace administration › Manage access) lists everyone who has signed in. There you can:

invite a person by email address with a role, before they have ever signed in;
change a person's role;
deactivate a person who leaves. They can no longer sign in, even if their email domain is still allowed. Reactivate reverses it.

Departments (Command)

Departments decide who receives what:

A policy published from Command reaches only the members of the departments its controls apply to. A policy with no department reaches everyone on your organisation's email domain.
An evidence request can be sent to a department.

To set up departments:

1
In Command, open the profile menu and choose Departments.
2
Add each department with a Department name and an optional Description.
3
Add its members by Email address. You can add people before they have an account. They receive what they qualify for when they first sign in.

You can also add departments in step 2 of the Command set-up wizard.

Note
The IdP claim values field does not fill department membership from your identity provider's group claims yet. Add members by email address.

These rules protect your people:

If Command cannot read a department's members when it publishes, it sends to nobody. It never falls back to sending to everyone.
Someone who joins later receives only the documents their departments qualify for.
When you delete a department, its member list is deleted with it, so it can no longer grant access to anything.

Counsel

Counsel has no separate people list. Your staff get access through your organisation's email domain, and consultants from outside it through a personal invitation. Everything a person uploads, asks or submits in Counsel is private within your organisation: no other user can see it.

People receive the policies published to them, and the evidence requests sent to them, in their own Counsel account. See Counsel.

BAIT

BAIT keeps two groups of people strictly apart:

The programme team. The few people who design, approve and report on campaigns. They sign in like any other user. A campaign always needs two of them, because nobody approves their own campaign. Your Data Protection Officer must be one of them.
Employees. The people who receive simulations. They never use BAIT and are never named in it.

What BAIT needs for each employee: an email address, a first name, and a department or group. Groups are the unit of everything in BAIT. Campaigns are sent to groups, results are reported per group, and follow-up training is assigned per group.

How the employee list gets into BAIT. A BAIT administrator connects your directory in MESH, then chooses Sync now on BAIT's People page. BAIT brings in your groups and their members, and removes people who have left.

These safeguards protect your employees:

Results are reported per group, never per person. Follow-up training is assigned per group.
Identifying an individual is a separate, audited decision. It needs a Data Protection Officer on file, and the person who asks cannot be the Data Protection Officer.
Employee email addresses are encrypted when stored, and are not shown anywhere in the BAIT console.
If BAIT cannot read your employee list, it stops. It never treats a failed read as an empty company.
After the next directory sync, people who have left receive no more simulations, not even from a campaign that is already running. Closed campaigns keep their history.

See BAIT.

ATLAS

ATLAS holds no employee data. People appear in ATLAS only when they take a responsible action: the signatory of your scanning mandate, and whoever verifies a domain, records an attestation or authorises intrusive testing. These names form the audit trail.

MESH

MESH imports people from the directories and cloud accounts you connect, such as Microsoft Entra and Google Workspace. You find them under People and groups, Workload identities and Access inventory. Only MESH administrators see these views. They are read-only, and MESH never writes anything back to your directory. See MESH.

Asset criticality and crown jewels

An asset's criticality, and whether it is a crown jewel, are always set by a person: criticality in Command or in ATLAS, and crown jewels on the ATLAS map. An import or a scan never changes them. When an import reports an owner from your CMDB or cloud, Command shows it separately, as Owner at source.