General IT settings

Inspect technical environment information and platform configuration.

General IT Settings

The General IT Settings screen is the control centre for your DPMS platform's most fundamental security and operational parameters. Every user in your organisation is affected by what is configured here — even though they will never visit this screen themselves. IT administrators typically come here during initial platform setup and return whenever a security policy changes, a compliance audit raises a finding, or the organisation adopts new token-management rules. Think of it as the single source of truth for how long sessions stay open, how timestamps appear across the system, and how long API credentials remain valid.

How to open it

Navigate to this screen by opening the main left-hand sidebar in DPMS and clicking IT Settings, then General. The direct URL is /it/settings/general.

Access requirements: You need at least read access to IT Settings to view this screen at all. Without it, DPMS shows a "403 Forbidden" page instead, and the IT Settings menu item does not appear in your sidebar. To make changes, you also need edit access to IT Settings. If you can see the screen but the Edit button is greyed out, your role includes read-only access — hover over the button to see a tooltip confirming this.

What you see

When you arrive at the General IT Settings screen, the main content area shows a single, clean card titled General. There are no tabs, no charts, and no expandable panels — just four labelled rows, each displaying a configuration field on the left and its current value on the right. The values are displayed in a visually distinct style so you can take in the current configuration at a glance.

In the top-right corner of the card sits the Edit button. If your role allows editing, the button is active and clickable. If not, it is greyed out and shows an explanatory tooltip on hover. A breadcrumb trail at the top of the page confirms exactly where you are within DPMS.

The four fields shown are:

Timezone — the time standard applied to all dates and timestamps across the platform
Session Time (Inactivity) — how many minutes of idle time trigger an automatic logout
Session Time (Activity) — the maximum number of hours any session can remain active, regardless of user activity
Token Lifetime — the maximum number of days an API token can remain valid before it must be renewed

Working with this screen

Configuring session timeouts for the first time

When your organisation first goes live on DPMS, the session timeout values may still be at their defaults. Before users start working on sensitive personal data records, you should align these values with your security policy.

Navigate to IT Settings → General and review the current values. If they do not match your policy — for example, your policy requires a 20-minute inactivity timeout and an 8-hour hard session limit — click Edit.
On the edit form, clear the Session Time (Inactivity) field and type your target number of minutes. Note that this field only accepts whole numbers up to two digits, so the maximum you can type is 99. If your policy requires a value above 99 minutes, contact your Priverion support team.
Move to the Session Time (Activity) field and enter the maximum session duration in hours (again, up to two digits). Remember that these two limits work together: DPMS ends a session at whichever threshold arrives first. If you set inactivity to 20 minutes and activity to 8 hours, most sessions will end due to inactivity long before the 8-hour ceiling is reached — but a user who is continuously active for 8 hours will be logged out regardless.
Click Save. DPMS sends the new values to the server and, on success, shows a confirmation notification and returns you to the read-only view. Critically, the new inactivity timeout takes effect immediately in your own current browser session — not just for future logins. If you set a very short value, be ready for your own session to end quickly.

Updating the timezone after a company relocation or merger

If your organisation moves its primary operations to a different time zone, every timestamp in DPMS — on audit logs, task deadlines, ROPA records, vendor assessments, and notification delivery times — needs to reflect the correct local time.

From the read-only view, click Edit.
Click the Timezone dropdown. A searchable list of all available time zones appears. Type the name of your target time zone to filter the list, then click the correct entry to select it.
You do not need to change any other fields. Click Save. DPMS sends the updated timezone to the server alongside the unchanged session and token values.
After the success notification, return to the read-only view and confirm the new timezone is displayed. Then spot-check a few dated records elsewhere in DPMS — for example, an audit log entry or a task deadline — to make sure they display as expected in the new timezone.

Heads up: Timezone changes affect how all existing timestamps are displayed across DPMS, including historical records. Dates are stored internally in UTC, so no data is lost — but you should verify the display before informing your team.

Enforcing a token rotation policy

If your information security team mandates that API tokens must expire within a set number of days — a common requirement under ISO 27001 and similar frameworks — this is where you configure that ceiling.

Navigate to IT Settings → General and note the current Token Lifetime value. If it is blank, very high, or set to zero (which may allow tokens to persist indefinitely), it likely needs adjustment.
Click Edit, then locate the Token Lifetime field and enter the maximum number of days. This field accepts up to three digits, so values between 1 and 730 days (approximately two years) are valid. The server enforces a hard maximum of 730 days.
Click Save. Going forward, any new API tokens created in the IAM module will be subject to this ceiling.

Heads up: Existing tokens that were issued before this change — and that were originally given a longer lifetime — are not automatically invalidated. After setting the token lifetime, review and rotate long-lived tokens separately in the IAM settings.

Reviewing settings before a security audit

A Data Protection Officer or compliance officer preparing for an audit (for example, ISO 27001 or a GDPR supervisory authority inspection) often needs to document the current session and token expiry policies.

If your role gives you read access but not edit access, navigate to IT Settings → General. All four values are visible. The Edit button is visible but greyed out — this is expected and confirms that your role is correctly scoped to read-only. Note or screenshot the values for your evidence pack. No API calls are made; nothing changes in the system as a result of your visit.

Field reference

Timezone — Select from the searchable dropdown list of all available time zones. This controls how all date and time values are displayed throughout DPMS — in the user interface, in exported documents, and in email notifications. Required; the dropdown always shows the currently saved value pre-selected. If the saved value does not match any option in the list (for example after a server migration), the raw saved string may appear as the label — verify the value after saving.
Session Time (Inactivity) — Enter a whole number between 1 and 99. The unit is Minutes. This is the number of minutes a user can remain idle before DPMS automatically ends their session. Accepts only digits; decimals and negative numbers are not permitted. If left empty, DPMS may fall back to a system default — always enter an explicit value.
Session Time (Activity) — Enter a whole number between 1 and 99. The unit is Hours. This is the hard ceiling on total session duration, regardless of whether the user is active. A user who works continuously will still be logged out once this many hours have passed since they logged in. Accepts only digits. Works alongside the inactivity timeout — whichever limit is reached first terminates the session.
Token Lifetime — Enter a whole number between 0 and 730. The unit is Days. This defines the maximum validity period for API tokens issued within DPMS. A value of 0 may allow tokens to be created with no expiry, depending on how individual tokens are configured in the IAM module. The server-side maximum is 730 days. Accepts only digits; up to three characters allowed.

How this connects to the rest of DPMS

The General IT Settings screen sits at the foundation of DPMS's security configuration. Changes here propagate platform-wide:

Session inactivity timeout: Once saved, the new inactivity value takes effect immediately across all active browser sessions — including your own. Every page in DPMS uses this value to power the automatic logout timer. An incorrectly short value disrupts productivity; an incorrectly long value leaves sessions exposed.
Active session maximum: Works as a hard ceiling alongside the inactivity timeout. Affects every user on every DPMS screen.
Token Lifetime: Feeds directly into the IAM (Identity and Access Management) module. Any screen or workflow in DPMS where API tokens can be created or managed — for integration partners, automated processes, or the MCP agent — will enforce this value as the upper bound on token validity.
Timezone: Affects every date and time displayed anywhere in DPMS — task deadlines, audit logs, ROPA records, DPIA timestamps, vendor assessment dates, and email notification scheduling. Changing this setting is a platform-wide event that touches historical display as well as future entries.

After configuring this screen, you may want to:

Verify session timeout behaviour by testing a login under the new settings.
Review existing API tokens in the IAM module to identify any that exceed the new token lifetime limit.
Communicate timezone changes to your team before they cause confusion in scheduled tasks or notification timing.

Tips & common pitfalls

Tip: After saving a new inactivity timeout, your own browser session starts counting down immediately under the new value. If you set a short timeout (such as 5 minutes) while testing, be prepared to log back in quickly.

Heads up: Existing API tokens are not automatically invalidated when you reduce the Token Lifetime. The new value applies only to tokens created after the change. You must manually review and rotate long-lived tokens in the IAM module.

The two-digit limit on session time fields is enforced at the keyboard level. You cannot type a value greater than 99 — the field simply stops accepting characters. If your policy requires a longer session window, contact Priverion support.
Saving without making changes still triggers an API call. If you click Edit and then Save without changing any fields, DPMS will still send a request to the server and show a success notification. This is harmless but can be surprising.
The Edit button is always visible — even to read-only users. It is greyed out and shows a tooltip when you lack edit access. This is intentional: it signals that the functionality exists, and that your current role does not grant editing rights.
The Token Lifetime field is labelled under IAM in the translation system. Even though it appears on this General settings screen, its effect is felt in the IAM module. If you are searching for token-related settings, this is where they live.
Changing the timezone changes how historical dates are displayed, not how they are stored. Dates are stored internally in UTC. After a timezone change, spot-check audit logs and task deadlines in other DPMS modules to confirm they display correctly.

General IT settings