Edit a user

Update profile, roles and permissions of an existing user.

Edit a User

The Edit a User screen is where you update an existing account in DPMS — changing someone's name or email, promoting them to a new role, enforcing two-factor authentication, or deactivating the account when someone leaves the organisation. Every permission check across the platform — from Records of Processing Activities to Risk Assessments — is based on what you configure here, so keeping user records accurate is a fundamental compliance hygiene task.

How to open it

Click IT Settings in the left-hand sidebar.
Select User Management from the IT Settings side menu.
Find the user you want to change in the list and click their row or the edit icon next to their name.

Permission required: You need the edit permission for IT Settings — User Management. Super Administrators have access by default. Users with read-only permission will not see the edit option, or it will appear greyed out with a tooltip explaining the missing permission.

What you see

The screen sits inside the standard IT Settings layout. On the left is a narrow vertical menu titled IT SETTINGS, with User Management highlighted as the active section. The right side, which takes up most of the screen, is the edit form.

At the very top of the form area you will see a breadcrumb trail — IT Settings › User Management — so you always know where you are. Below that, a content card contains the form itself, with a back-arrow button and the title User Management on the top left, and a prominent Save button on the top right.

The form fields are arranged in a single vertical column. A thin blue rule runs down the left edge of each input section — a visual detail you will recognise from every other edit screen in DPMS. The fields cover the user's identity (name, email), their role and organisational unit assignments, and three toggle switches for account-level settings: enforce two-factor authentication, mark the account as active or inactive, and allow or block local (username and password) login.

Working with this screen

Updating a user's name or email address

A common reason to open this screen is a straightforward data correction — for example, a colleague has legally changed their name, or the company has migrated to a new email domain and every account needs updating.

Open the edit form for the user as described above.
Click into the First Name or Last Name field and type the corrected value. Both fields are required; DPMS will warn you if you leave either blank when you try to save.
To change the login email, click the Email field and enter the new address. DPMS validates the format automatically and checks that no other account in your organisation uses the same address.
Click Save. A success notification confirms the change, and you are returned to the User Management list.

Heads up: If your organisation uses Active Directory synchronisation or SCIM provisioning (configured under IT Settings › Active Directory or IT Settings › IAM), DPMS may overwrite manual changes to names and email addresses the next time a sync runs. For accounts managed by an identity provider, make the change there first, then let the sync bring it across.

Heads up: If the user logs in via SAML or OAuth (SSO), their email address in DPMS must match exactly what the identity provider sends. Changing the email here without updating the corresponding record in your identity provider (for example, Entra ID or Okta) will cause their SSO login to fail.

Changing a user's role after a promotion or department move

Role assignments determine what every user can see and do in DPMS — from editing Records of Processing Activities to accessing IT Settings. When someone takes on new responsibilities, you need to update their role here.

Open the edit form for the user.
Find the Role selector. It shows the user's current role or roles. Click to open the list of available options. You will see predefined system roles such as Super Administrator, Data Protection Manager, Data Protection Coordinator, IT Administrator, IT Security Manager, Workflow Manager, Employee, and others, as well as any custom roles your organisation has configured.
Select the appropriate role (or roles, if the user needs more than one). If the promotion means a previous role is no longer needed, remove it from the selection.
Click Save.

The role change takes effect in the database immediately. However, the affected user's current browser session may still show their old permissions until they navigate to a new page or log out and back in. If you have changed a role and the user says they still cannot access something, ask them to log out and log in again.

Heads up: Only a Super Administrator can assign or remove the Super Administrator role itself. Removing that role from the last active Super Administrator in your organisation is blocked by the system — this protection prevents accidental lock-out.

Tip: If your organisation has SCIM group-to-role mapping configured in IT Settings › IAM, role assignments may be overwritten by the next SCIM sync. Check whether the role is being managed by the identity provider before making a manual change here.

Assigning a user to an organisational unit

Organisational units (departments, teams, or business divisions) are defined in the Compliance Settings. Associating a user with one tells DPMS to suggest that person as a responsible party on compliance elements owned by that unit — for example, processing activities, DPIAs, or vendor records.

Open the edit form for the user.
Find the Organisational Unit selector. Click it to see the units available in your organisation.
Select the unit or units that apply. If the user has moved departments, remove the old unit and add the new one.
Click Save.

Changing the organisational unit does not affect the user's role or their ability to log in. It mainly influences which elements they are suggested for in compliance workflows and which dashboards or reports include them by default.

Enforcing two-factor authentication on a specific account

Your company-wide two-factor authentication (2FA) policy is set in IT Settings › General. But sometimes you need to enforce 2FA for a specific high-privilege account — for example, all IT Administrators — even if the global policy does not yet require it for everyone.

Open the edit form for the user.
Find the Enforce Two-Factor Authentication toggle. When it is grey, the user follows the company-wide default. Click it to turn it blue (on), which forces this individual to use 2FA on every login regardless of the global setting.
Click Save.

The next time the user logs in, they will be prompted to set up or confirm their 2FA method. Users who already have 2FA configured are not disrupted. Users who do not have it set up yet will be guided through the setup flow at their next login.

If the company-wide 2FA policy is already enforced for all users, enabling this toggle on an individual has no additional effect.

Deactivating an account when someone leaves

When an employee leaves the organisation or goes on extended leave, you should deactivate their account to block access — without deleting any of the data or history they have contributed.

Open the edit form for the user.
Find the Active toggle. When the account is active, the toggle is blue. Click it to turn it grey (inactive).
Click Save.

From this point on, any attempt by the former employee to log in will be blocked. All records they were associated with — processing activities, tasks, DPIA assignments, audit log entries — remain fully intact with their name attached, preserving the audit trail.

To restore access (for example, if the person returns or the deactivation was a mistake), open the form again and switch the Active toggle back to blue, then save.

Heads up: Do not deactivate the last active Super Administrator account. DPMS prevents this to avoid a complete lock-out, but it is good practice to confirm that at least one other Super Administrator is active before modifying any Super Administrator account.

The Local Login toggle controls whether a specific user can authenticate using their DPMS username and password, independently of any SSO configuration active for your company.

Toggle on (blue): The user can log in with their DPMS password, even if the company uses SSO as the primary method. This is useful for emergency or break-glass administrator accounts that need to be accessible even if the SSO provider is unavailable.
Toggle off (grey): The user must authenticate exclusively through the configured identity provider (SAML, OAuth, or Entra ID). They cannot use a username and password to log in to DPMS directly.

To change this setting, open the edit form, find the Local Login toggle, switch it to the desired state, and click Save.

Heads up: If you disable local login for a user and the company's SSO configuration is broken or the user's SSO account does not exist, they will have no way to log in at all. Always test the SSO flow before disabling local login, and always maintain at least one Super Administrator account with local login enabled as a fallback.

Field reference

First Name — The user's given name as it appears throughout DPMS (on task assignments, audit logs, email notifications, and compliance records). Required. Cannot be left blank.
Last Name — The user's family name. Required. Cannot be left blank.
Email — The user's login email address. Must be a valid email format and must be unique within your organisation's DPMS tenant. Changing this field changes what the user types on the login screen (for local login) and must match the identity provider record if SSO is in use.
Role — One or more DPMS system roles. Determines everything the user can see and do across the platform. Available roles include Super Administrator, Data Protection Manager, Data Protection Coordinator, IT Administrator, IT Security Manager, IT Security Coordinator, Workflow Manager, IGDTA Administrator, IGDTA Group Representative, Employee, Case Agent, Assigned User, and Case Handler, plus any custom roles configured in your organisation.
Organisational Unit — The department(s) or team(s) the user belongs to, drawn from the organisational units defined in Compliance Settings. Influences which compliance elements they are suggested for and scopes certain reports.
Enforce Two-Factor Authentication — Per-user override that forces this individual to use 2FA on every login, regardless of the company-wide policy. Toggle on to enforce, off to follow the global default.
Active — Whether the account is enabled. Toggle off to deactivate the account and block login without deleting any data.
Local Login — Whether the user can authenticate with a DPMS username and password. Toggle off to enforce SSO-only login for this user.

How this connects to the rest of DPMS

The user record you edit here is referenced across virtually every part of DPMS. Role assignments govern every access-control check on every screen — if a role is wrong here, the user will either see things they should not or be blocked from work they should be able to do. The name, email, and organisational unit stored here appear on task assignments, in email notifications sent by workflows, in RASCI matrices on compliance elements, and in every audit log entry.

When you save changes on this screen, you are returned to the User Management index at IT Settings › User Management, where you can continue editing other accounts or review the full list.

Other screens and features that depend on what you configure here:

Role-based access control everywhere: Every module — ROPA, DPIAs, Risk Assessments, Vendor Management, Documents and Policies, Assessments, Incidents — checks the roles set here before showing or hiding features.
AI assistant features: The AI helper available on forms throughout DPMS attributes interactions to the authenticated user's record. Correctly identifying the user here ensures that AI-assisted work is logged against the right person.
Workflow assignments: Workflows use the responsible persons, approvers, and reviewers drawn from user records. If a user's name or email is wrong, they may receive notifications addressed incorrectly or may not receive them at all.
Active Directory / SCIM sync: If IT Settings › Active Directory or IT Settings › IAM › SCIM is configured, those integrations are the authoritative source for some fields. Manual edits here may be overwritten.
Password policy: The password requirements set in IT Settings › General apply to this user when they next set or reset their password.

Tips & common pitfalls

Heads up: If your organisation uses Active Directory synchronisation or SCIM, changes to name, email, and possibly role assignments made here may be silently overwritten at the next sync. Make changes in your identity provider (Entra ID, Okta, etc.) rather than in DPMS for accounts managed this way.

Heads up: Deactivating or removing the Super Administrator role from the only active Super Administrator account will leave your organisation unable to access IT Settings or manage users. Always verify that at least one other Super Administrator is active first.

Role changes are immediate but session-cached. The change is saved to the database instantly. The affected user's active session may still show old permissions until they refresh or log in again. If someone says a role change "hasn't worked", ask them to log out and back in.
Email changes and SSO must be kept in sync. If your company uses SAML or OAuth, the email in DPMS must match what the identity provider sends in the login assertion. Changing one without the other breaks SSO login for that user.
Disabling local login without a working SSO is a lock-out. Before turning off local login for any user, confirm that their SSO login works correctly. Keep at least one emergency Super Administrator account with local login enabled at all times.
The form shows the data as of when you opened it. If another administrator edits the same user in a different browser tab at the same time and saves, your tab still shows the old values. Refresh the page if you are not sure you have the latest data before making changes.