# Organisations & Users --- ## Overview ISMS CORE Platform supports multi-tenant operation — multiple organisations can run on a single platform instance with full data isolation. Within each organisation, role-based access control determines what each user can see and do. User and organisation management is an **Admin** function. This chapter covers the settings relevant to all roles. --- ## Organisations Each organisation in the platform represents an independent tenant — a company, subsidiary, or separate organisational scope. Organisations do not share data. ### Organisation Settings Administrators can configure the following per-organisation in **Admin → Organisation**: | Setting | Description | |---------|-------------| | **Organisation name** | Legal or operating name | | **Country** | Jurisdiction for policy localisation (CH, AT, BE, DE, FR, GB, IT, LU) | | **Industry sector** | Used for framework relevance recommendations | | **Active projects** | Which project is the default active project per product family | **Country setting and policy localisation:** When the country is set, policy documents are rendered with jurisdiction-specific regulatory references. For example, setting the country to `DE` causes GDPR references to appear alongside relevant BDSG references, and the Datenschutzbehörde (DSB) to appear in place of the generic "supervisory authority" token. See [Introduction](01-introduction.md) for the full list of supported jurisdictions. --- ## Users ### Roles There are six roles. A person has **one role in each organisation** they belong to. | Role | What they can do | |------|-----------------| | **Viewer** | Reads everything in the organisation (controls, policies, assessments, evidence, gaps, risks, reports, dashboards) and manages their own account. Cannot change anything else. | | **Auditor** | Everything a Viewer can, plus **raises findings** (creates gaps), **accepts or flags evidence**, and uses the AI assistant, ISMS Compass, IP look-up and KPI snapshots. Cannot create, edit or delete the records being audited — by design, an auditor is independent of what is audited. | | **Control Owner** | For the **control groups assigned to them**: uploads, edits, submits and deletes evidence; raises and updates gaps; fills in assessment items; edits remediation actions. Reads everything else. Cannot approve evidence, create assessments or projects, or delete remediation actions. | | **ISMS Manager** | All compliance work on **all** control groups: projects (policies, implementations, checklists), assessments, risk register, BIA, EBIOS RM, CSRM, collections, third-party risk, regulatory modules, NIST CSF, report generators, approving or rejecting evidence, QA checks of a project, and pushing gaps to Jira / ServiceNow. | | **Admin** | ISMS Manager rights plus users and groups, organisation settings, connectors, custom frameworks, notification settings and the event and audit logs. | | **Super Admin** | Everything in every organisation, plus platform-wide operations: creating and archiving organisations, giving access to other organisations, library content, feeds and threat-intelligence sources, library-wide QA, the System page. Assigned at the platform level. | The **Roles & permissions** tab of the in-app Help (**Help → Roles & permissions**) has the complete tables, area by area, with a short description of every role. ### Managing Users (Admin only) Navigate to **Admin → Users** to: - **Add a user** — click **Add User**, enter email, username, full name, an initial password and the role. For a Control Owner, also choose the assigned control groups. - **Edit a user** — change role, name, assigned control groups, or (Super Admin only) the organisation - **Disable a user** — revokes access without deleting the account - **Delete a user** — removes the account; their entries in the audit log stay, with the email address they acted under - **Reset MFA** — for a person who lost their authenticator and backup codes - **Locked sign-ins** — when a card **Locked sign-ins** appears above the user list, someone is currently locked out. Five wrong passwords from one address lock **that address for that account only** (5 minutes, doubling up to 15 minutes; 60 for administrators), so a stranger who knows an e-mail address cannot lock the real user out from their own address. An account is locked **as a whole** only when wrong passwords arrive from many different addresses (credential guessing from rotating addresses). Use **Unlock** (that account and address), **Unblock IP** (that address for every account of your organisation) or **Unlock account**; the user can sign in again immediately. Every unlock is written to the audit log. Super Admins see the locks of all organisations; an Admin sees their own. A role or control-group change applies at the person's next action. ### Control groups for a Control Owner A **control group** is a group of related controls (for example *A.5.15 Access control*). A Control Owner works **only on the control groups assigned to them**: 1. Open **Admin → Users** and click **Add User** (or **Edit** next to an existing Control Owner). 2. Choose the role **Control Owner**; the field **Assigned control groups** appears. 3. Pick the control groups and save. Outside their groups a Control Owner can only read. A Control Owner **with no assigned group can read everything but cannot change anything** — assign at least one when you create the account. ### Groups of people **Admin → Users → Groups** lets an Admin create named groups of users (for example *Internal audit team*) and add or remove members. Groups are an organising tool only: **they grant no permission and cannot restrict a role**. Permissions always come from the role and, for Control Owners, from the assigned control groups. ### Working in several organisations Consultants and implementers often work for several clients. A **Super Admin** can give an existing account access to another organisation, with its **own role** there: **Admin → Users → Access from other organisations → Give access**. - Anyone who belongs to more than one organisation sees an **organisation switcher** at the top of the sidebar. Choosing another organisation changes the role, the control groups and all data to that organisation's. - The password, MFA and account status stay with the person's **home organisation**. - An Admin of an organisation can change or remove the access of its members; the change applies at the person's next action. - Nobody can give themselves access, and the Super Admin role cannot be given this way. --- ## Multi-Factor Authentication (MFA) MFA is TOTP-based (Time-based One-Time Password) — compatible with Google Authenticator, Authy, Microsoft Authenticator, and any RFC 6238-compliant TOTP app. ### Setting Up MFA 1. Navigate to **System → MFA Setup** 2. Scan the QR code with your authenticator app 3. Enter the 6-digit code displayed in the app to confirm 4. **Save the 8 backup codes** — these are one-time-use codes for recovery when your device is unavailable ### Logging In with MFA After entering your email and password, you are prompted for your 6-digit TOTP code. The code auto-submits when 6 digits are entered — you do not need to click a button. If you have lost access to your authenticator app and your backup codes: - Contact your organisation's Admin to reset your MFA - Admins can reset MFA from **Admin → Users → Edit user** ### MFA Policy MFA enforcement is configured by the administrator. When enforced: - Users without MFA set up are prompted to complete setup at next login - Users cannot bypass the MFA step --- ## System Event Log Navigate to **Admin → System → Event Log** for an immutable audit trail of all platform actions. Every create, update, delete, import, and login event is recorded with: - Timestamp - User identity - Action type - Resource affected (document ID, user ID, etc.) - IP address The event log cannot be modified or deleted. It is the authoritative record of who did what and when — essential for ISO 27001:2022 Annex A.8.15 (Logging) and Annex A.5.26 (Response to information security incidents) audit requirements. Export the event log as CSV from the log view. --- ## Third-Party API Keys (Super Admin) The platform uses outside services — the NVD and VulnCheck vulnerability feeds, the threat-intelligence feeds and IP look-ups, and Anthropic (Claude AI) for the AI assistant, ISMS Compass and Claude QA. Their keys are managed by the **Super Admin** under **Admin → API keys** (the page is not shown to any other role). The keys are platform-wide: one key serves every organisation. - Three tabs: **Vuln Feeds**, **TI Feeds** and **System**; one card per key. - **Add key / Replace key** stores the key encrypted. A saved value is never shown again. - The **Enabled** switch turns a saved key on or off without retyping it; **Remove** deletes it. - A key takes effect at the next feed run or request — no restart. - New installations enter their keys here. Installations upgraded from an earlier version had the keys already in the `.env` file imported once (they show as *Migrated from .env*); those `.env` lines can then be deleted. Until they are, a key that is switched off or removed here still falls back to its `.env` value. - If the page warns that `PLATFORM_KEY_ENCRYPTION_SECRET` is not set, keys cannot be saved yet; the operator adds that secret to `.env` and recreates the backend, feeds and threat-intel containers. --- ## Admin Panel — Content Management The Admin panel (**Admin → First-Run Setup**) is where platform content is imported and re-synced. This is typically a one-time operation at deployment time, repeated when content is updated. As a non-admin user, you do not need to use this panel — it is documented in [PLATFORM.md](../PLATFORM.md) for administrators.