The texts that bring every employee into the ISMS also keep almost all of them out of the tool it runs in; here is the access matrix that falls out of the clauses, and where one product draws the lines.
Commission Implementing Regulation (EU) 2024/2690 sets out the NIS2 risk-management measures for a named set of digital providers: DNS and cloud providers, data centers, managed and managed security service providers, online marketplaces and a few more. Its annex is unusually concrete about security governance, and two of its sentences pull in opposite directions.
Point 1.2.2: "The relevant entities shall require all personnel and third parties to apply network and information system security in accordance with the established network and information security policy, topic-specific policies and procedures of the relevant entities."
Point 11.2.2(a): the entities shall "assign and revoke access rights based on the principles of need-to-know, least privilege and separation of duties".
The first sentence brings everyone in. The second keeps nearly everyone out. The tool you run your ISMS in sits under both at once, because it is where you ask people to take part and it is also a network and information system with access rights of its own.
Most teams resolve the tension by picking one sentence. Either everyone who owns a control gets an account with edit rights, or only the compliance team has accounts and everyone else takes part by email. The first fails 11.2.2(a). The second produces participation nobody can attribute. Neither is necessary.
The word "role" does two jobs in compliance, and it helps to separate them before designing anything.
A responsibility role says who has to act. Point 1.2.1 asks entities to "lay down responsibilities and authorities for network and information system security and assign them to roles". Recital (27) names the roles it has in mind: "chief information security officer, information security officer, incident handling officer, auditor, or comparable equivalents." In practice the list runs further: the owner of the backup control, the approver of the supplier file, the person who confirms the access review for the finance system.
An access role says what a login can do in a given system. That is point 11.2: provide, modify, remove and document access rights, on need-to-know and least privilege.
The AICPA Trust Services Criteria behind SOC 2 keep the same split. CC1.3 is about responsibility: management "establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives", and its point of focus asks management to "assign responsibility and segregate duties as necessary at the various levels of the organization." CC5.3 places that responsibility where the work is: accountability for control activities sits "with management (or other designated personnel) of the business unit or function in which the relevant risks reside." CC6.3 is about access, and it is the one that carries the operative words: access is authorized "based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties".
ISO/IEC 27001:2022 readers can find their own clauses through ENISA's mapping table for the regulation. It maps point 1.2 to clause 5.3 and controls A.5.2, A.5.3 and A.5.4; point 8.1 (awareness) to clause 7.3 and A.6.3; point 11.1 to A.5.15 among others; point 11.2 to A.5.3 and A.5.18; and point 11.3 to A.8.2. ENISA attaches a caveat worth keeping: "The mapping table should not be interpreted as a measure of equivalency among different standards or frameworks."
Note where segregation of duties appears in that mapping. A.5.3 sits under both 1.2 and 11.2. It is a responsibility question and an access question at once, which is exactly why the two kinds of role get confused.
The rule I take from these texts: responsibility decides who must act and who signs off; access decides which surface a person gets. A control owner needs to be reachable, accountable and able to deliver. None of that requires the right to edit the risk register.
It is easy to treat the compliance tool as the place where access policy is written, and forget that the policy applies to it too. The annex leaves no room for that. Point 11.1.2(a) asks access control policies to "address access by persons, including staff, visitors, and external entities such as suppliers and service providers". The ISMS tool holds the risk register, open treatment actions, incident timelines and audit findings. That is a map of where the organization is weakest. Few systems deserve need-to-know more.
It follows that administrators of the ISMS tool are privileged accounts, and point 11.3 applies to them. Point 11.3.2(a) asks for "strong identification, authentication such as multi-factor authentication, and authorisation procedures for privileged accounts and system administration accounts", and point 11.3.2(c) asks entities to "individualise and restrict system administration privileges to the highest extent possible". Point 10.1.2(b) adds the human side: "mechanisms to ensure that all users with administrative or privileged access are aware of and act in accordance with their roles, responsibilities and authorities".
Three more lines in point 11.2 turn into requirements for the tool itself. Point 11.2.2(e) asks for "a register of access rights granted". Point 11.2.2(f) asks entities to "apply logging to the management of access rights". Point 11.2.3 asks for a review "at planned intervals" with the results documented. If your ISMS tool cannot tell you who holds which role and who changed it, you cannot run that review on the tool that is supposed to host your other reviews.
Small organizations get an honest carve-out. Recital (5) accepts that "micro-sized entities might find it difficult to segregate conflicting duties and conflicting areas of responsibility" and points to "compensating measures such as targeted oversight by the entity's management or increased monitoring and logging." If two people run everything, the answer is a log someone else reads.
Here is the matrix I would draw before inviting anyone into an ISMS tool, whichever tool it is. Each row is a population, the surface it needs, the thing it must be unable to do, and the text that asks for it.
| Population | Who, typically | Surface | Must be unable to | Anchors |
|---|---|---|---|---|
| Administrators | ISMS owner, information security officer, one deputy | Configure the tool, manage members, edit every register | Act without MFA; act without leaving a log entry | 2024/2690 11.3.2(a), (c); 11.2.2(f); ENISA: A.8.2 |
| Readers | Management body, control owners who need context, internal risk functions | Read the registers, take part in discussion | Change a register entry | 2024/2690 1.2.3, 11.2.2(a); CC6.3 |
| Independent reviewer | Certification auditor, internal audit | Read everything, including the change history | Change anything, including comments | 2024/2690 1.2.5, recital (27); ENISA: A.5.3 |
| Participants | Every other employee, often contractors | Their own assigned items: confirm, complete, attach, report | See the registers; see colleagues' items | 2024/2690 1.2.2, 8.1.1, 10.1.1; CC5.3; ENISA: 7.3, A.6.3 |
| Named contacts | Supplier contacts, external advisors, people being referenced as owners | None: they are named in records | Sign in at all | 2024/2690 11.2.2(d) |
Three rows deserve a comment.
Readers are the row that is easiest to skip. Point 1.2.3 requires that "at least one person shall report directly to the management bodies on matters of network and information system security", and a management body that reads the reports it approves is better placed than one that gets a PDF. Readers need the whole picture and no write access. Giving them editor rights in case they need to fix something is exactly what point 11.2.2(a) rules out.
The independent reviewer is where segregation of duties becomes concrete. An auditor who can edit what they are auditing has stopped being independent, and a comment is an edit too: it changes the record the next reader sees. The reviewer's surface is read-only, all of it.
Participants are the largest population, and the one whose surface needs the most design. Point 8.1.1 wants employees "aware of risks" and applying "cyber hygiene practices", and point 10.1.1 wants them to "understand and commit to their security responsibilities". Neither asks for access to the ISMS. They ask for a place where a person meets their own part of it.
A participant surface is only least-privilege if a few rules hold. I would test any tool, or any home-built portal, against these five.
For the offboarding side, point 11.5.4 asks entities to deactivate identities "without delay" once they are no longer needed. Deactivation is easier to do quickly when it does not destroy the history an auditor will ask about later.
Everything above works with any tool. Here is where devguard draws the lines, limits included; the changelog has the release dates.
devguard has six organization roles, and the invite dialog describes each in one line. Admin "manages members, settings and every register". Member "reads every register and takes part in comments". Auditor "inspects everything in the application but cannot change anything, not even a comment". Employee "uses the employee portal only, for policies, trainings, tasks and incidents". External is "a contact with no access to the application or the portal, kept on the roster to be referenced". Owner is not in the picker; it is reached by transferring ownership. Those map onto the five rows in order, with Owner and Admin as the administrators.
The portal is the participant surface. An Employee who signs in lands there and cannot reach the admin app. Inside it they see only what is attached to them: tasks assigned to them or to a responsibility role they hold, documents assigned the same way, evidence where one of their roles is owner or approver, and incidents they reported. Anything else behaves as if it were not there. They can attach files to an evidence request and mark it done, but approving it, which is what sets the next review date, stays in the app with the people in that evidence's approver role. That authority comes from the responsibility role, not the access tier: a Member in the approver role can approve, and an Admin outside it cannot. Incident reporters file and add notes; the owner keeps severity and status. Switching the portal or one of its sections off closes the pages, including bookmarked links.
On the administrator side, the organization can require two-factor authentication, and invitations, role changes, removals, ownership transfers and deactivations each leave an entry in the audit log, which no role can edit. Deactivation blocks access without deleting the person's history, and it revokes grants to connected apps.
Two things it does not do, and each has a cost.
It has no custom or per-register roles. A Member reads every register; you cannot make a reader who sees the risk register and not the incident log. Six fixed roles are easy for an auditor to understand and for a review to check; I think that is worth more than fine-grained permissions, but it is a trade. If you need tighter reader scopes, the Member role is too wide for you, and the portal plus responsibility roles is the narrower tool.
It has one administrator role that both grants access and edits every register. The tool does not separate managing who gets in from managing the content. In a small team that split often has nobody to hand the second half to. If your risk assessment says you need it, it has to come from a compensating measure outside the role model: the audit log read by someone who is not an administrator, the kind of monitoring recital (5) names for micro-sized entities. An Auditor seat is a reasonable home for that reader.
Employees count toward the plan's user limit like any other member; External contacts take no seat.
Before the next invitation goes out, write down the five rows for your organization, with names. Then run your planned access review from point 11.2.3 against the ISMS tool first. Every other review is recorded in it, which makes it the one system whose access list you want settled first.
devguard gives each of those populations its own surface, from the Auditor role to the employee portal: devguard.ch.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.