Documentation

Getting started

A new organisation is ready the day it is created. There is nothing to install for the hosted service.

1. Your organisation is created with a first administrator, your currency and fiscal year.
2. The administrator chooses how people sign in: with single sign-on through your identity provider, with Measura accounts, or both. Single sign-on is set up in Settings → Single sign-on by your own administrator; it does not need us.
3. People are added under Settings → Users and roles, each with a role and, for risk owners, the business units they work in. Each person receives an invitation e-mail. With single sign-on, new people from your e-mail domain can also be let in automatically with a role you choose.
4. Business units and categories are set to match your organisation, and the first scenarios are written, usually in a workshop with the built-in templates and AI assistant.

Sign-in options

Measura supports two ways of signing in, and an organisation can use both: single sign-on with the work account people already have, and Measura accounts with a password and an authenticator app. On the sign-in page people type their work e-mail address, and Measura takes them the right way.

Single sign-on

Measura signs people in through your identity provider with OpenID Connect. Your provider confirms who they are under your own policies, including multi-factor authentication, and Measura opens with their role and only your organisation’s data.

Supported providers

• Microsoft Entra ID (Microsoft 365), single-tenant app registration.
• Google Workspace. Only accounts of your Workspace domain are accepted, never personal Google accounts using the same address.
• Any OpenID Connect provider that supports the authorisation code flow with PKCE and publishes its configuration, such as Okta, Auth0, Keycloak or OneLogin.

Setting it up

1. An administrator opens Settings → Single sign-on and chooses the provider. The page shows step-by-step instructions for that provider and the redirect URI to copy.
2. In your identity provider, register Measura as a web application with that redirect URI and copy the details it gives you (see below for Entra ID and Google).
3. Enter them in Measura together with your e-mail domains (the part after the @). The client secret is stored encrypted and is never shown again.
4. Check connection confirms Measura can reach the provider. Try signing in goes through the provider and back without changing who is signed in, and tells you whether that person would get in.
5. When the try works, switch on Use single sign-on.

Choices you make

• People not added yet. Either refuse them (an administrator adds people first), or let them join as risk owner, viewer or auditor. Administrator and risk lead are never given automatically.
• Require single sign-on. Closes other ways of signing in for people from your domains. Administrators keep a way in, so a wrong provider setting cannot lock everyone out.
• Domains. A domain belongs to one organisation only. Public e-mail services such as gmail.com cannot be used.

People who leave your company lose access when their work account is closed. Removing someone under Users and roles ends their access in Measura straight away.

Microsoft Entra ID

1. In the Entra admin centre: App registrations → New registration. Supported account types: this organisational directory only. Redirect URI: platform Web, the value from Measura’s settings.
2. From the Overview page, copy the Application (client) ID and the Directory (tenant) ID.
3. Under Certificates & secrets, create a client secret and copy its value. Note when it expires; a new secret is pasted into Measura’s settings before then.
4. Recommended: under Token configuration, add the optional email claim. Optional: under Enterprise applications, set Assignment required and assign the groups who may use Measura.

Measura asks only for openid email profile. No access to mail, files or the directory is requested.

Google Workspace

1. In the Google Cloud console, set the OAuth consent screen to Internal.
2. Under Credentials, create an OAuth client ID of type Web application, with the redirect URI from Measura’s settings.
3. Copy the client ID and client secret into Measura.

Measura accounts

For organisations without single sign-on, and as a second way in for administrators, Measura has its own accounts. They always use two factors: a password and a six-digit code from an authenticator app on the person’s phone (for example Microsoft Authenticator or Google Authenticator).

• Set-up. The invitation e-mail holds a link, valid for 7 days and usable once, where the person chooses a password and scans a QR code into their authenticator app.
• Passwords are at least 12 characters, may not contain the e-mail address and may not be a common password. They are stored only as Argon2id hashes.
• Codes change every 30 seconds and each one works once.
• Failed sign-ins. After five failed tries, sign-in for that account pauses for 15 minutes. The message is the same whatever was wrong, so it does not reveal which addresses have accounts.
• Forgotten password. “Forgot your password?” e-mails a link valid for one hour. Choosing a new password still needs a code from the authenticator app, so the e-mail alone cannot change it.
• Lost phone. An administrator chooses Reset sign-in for the person under Users and roles. Their password and authenticator are cleared, they are signed out everywhere, and they receive a new set-up link.

Confirming identity before approvals

Approving the risk appetite is a decision the board relies on, so Measura asks the approver to confirm it is them at that moment, even if they are already signed in. With single sign-on they sign in again at your provider; with a Measura account they enter their password and a code. The confirmation lasts 10 minutes and is recorded in the audit trail.

Roles and access

Each person has one role in an organisation. Approving the risk appetite is a separate right that an administrator gives to named people, whatever their role.

Hosting and data

Hosted service (standard)

• Hosted in the EU. No personal data in logs beyond a user id; IP addresses appear only as salted hashes in the audit trail.
• Each organisation’s data is kept apart in the database itself with row-level security, not only by the application. A test suite checks every part of the API against a second organisation’s data.
• Daily backups kept for 30 days, and the database can be restored to any point in time.
• Your data can be exported in full, as Excel and JSON, or deleted, by your administrator at any time.

On-premise (on request)

• The same software and features, installed in your data centre or private cloud with your database and backup routines.
• Sign-in works the same way: single sign-on through your identity provider, Measura accounts, or both.
• Installation and updates are agreed with your IT department.

E-mail

Measura sends a few kinds of e-mail: invitations, account set-up links, password resets and test messages. They come from Measura <no-reply@measura.dk>, are plain text with a simple HTML version, and carry no tracking.

• The text of a sent message is erased once delivered, because it may hold a one-time link. The audit trail records who received which kind of message, not its content.
• Administrators can send themselves a test message under Settings → E-mail and see the status of recent messages.
• On-premise: Measura sends through your SMTP server over TLS. Use a sender address on a domain you control, published with SPF, DKIM and DMARC records, so the messages are not treated as spam.

Security

• Sessions end after 1 hour without activity and after 12 hours in any case. Session cookies are HttpOnly, Secure and SameSite=Lax; only a hash of the session token is stored. Every changing request carries a CSRF token.
• Single sign-on uses the authorisation code flow with PKCE, state and nonce. ID tokens are checked for signature, issuer, audience, expiry, nonce and e-mail domain. Provider tokens are not stored.
• Secrets such as single sign-on client secrets and authenticator keys are encrypted at rest. Passwords are hashed with Argon2id.
• Audit trail. Every change, sign-in and failed sign-in is recorded with who and when, in a per-organisation hash chain that shows if history was altered. The application can add to the trail but never change it.
• Reproducible results. Every number is stored with the inputs, random seed and engine version that produced it, so a board report can be recalculated years later with the same result.
• Browser protection. A strict content security policy, no third-party scripts in the product, and protection against framing.
• Software supply chain. Measura uses only open-source components under permissive licences (MIT, Apache-2.0, BSD and similar), checked automatically on every change.