Does every role need a separate person?

Not necessarily. In small teams, people can hold several roles. Authorities and any necessary independent reviews must still remain clear.

Is administration also responsible for risk decisions?

Technical administrator rights do not confer business decision-making authority. Define separately who may assess risks and decide on treatment.

How can we test Kopexa before implementation?

Kopexa offers a two-week guided trial. Choose your own test case and try the workflow with the people involved. The initial conversation establishes what you need to test.

Introducing GRC software: Who takes responsibility for what?

When introducing GRC software, establish who owns each important outcome, who works on it and who may make decisions. A user account or a name attached to a task does not replace that clarification.

Start with a workflow you need in daily operations. For example: assess an open requirement, assign a measure and review implementation using evidence. This workflow reveals which roles are missing.

What must be clear before setup?

Define the first problem the implementation should solve. Do you want to find evidence reliably, treat risks or coordinate several companies? Without this decision, every existing spreadsheet appears to require importing.

Record three things: the first use case, the teams involved and the outcome against which you will judge the initial implementation. “Software configured” is insufficient. “The responsible person can follow an open measure through to verified evidence” is more specific. An ISMS software requirements checklist helps with selection.

NIST CSF 2.0’s GV.RR addresses clearly established and communicated responsibilities and authorities, including appropriate resources. The role model below is our practical implementation aid, not a project organisation prescribed by NIST. NIST CSF 2.0

Which roles does implementation need?

Role	Main responsibility	What must not be silently assumed
Management sponsor	Objectives, priorities, resources and escalation path	That the project can succeed alongside daily work without allocated capacity
ISMS/GRC subject-matter owner	Terminology, methods, workflows and business acceptance	That every operational task belongs to this person
Process or information owners	Business information, impact and appropriate treatment in their area	That IT alone can judge business significance
Measure owners	Implementation, status and required evidence	That completion already means verified effectiveness
Technical administration	Access, technical connections and agreed permissions	That administrator rights authorise risk decisions
Project coordination	Dates, dependencies, open questions and handover	That coordination can replace subject-matter decisions

One person can hold several roles in a small organisation. Still record the role in which they act. Where an independent review is required, the allocation must make it possible.

Separate project tasks from ongoing operations

Apply the roles to individual tasks. This example matrix is a starting point, not a statutory allocation of responsibility:

Task	Accountable for the decision	Performs the work	Reviews	Informed
Define pilot scope	Sponsor	Project coordination	GRC subject-matter owner	Teams involved
Migrate business data	Owner of the data area	Migration owner	Knowledgeable reviewer	GRC owner
Implement a technical measure	Responsible department owner	Operations	Person designated for acceptance	ISMS owner
Take over ongoing operation	GRC subject-matter owner	Future operational owners	Sponsor against agreed acceptance criteria	Users and support

Implementation involves migrating data, standardising terms and configuring access. For existing spreadsheets, our Excel-to-ISMS migration guide explains preparation. After launch, different routines are needed: onboarding employees, updating responsibilities when people change roles and reviewing business information.

For each one-off task, therefore add the corresponding operational question:

Import: Who maintains new and changed records after launch?
Permissions: Who reviews a change of job or organisational unit?
Policies: Who prepares a new version and who approves it?
Metrics: Who checks whether the data source still supplies complete, correct information?
Measures: Who provides cover and escalates when work does not progress?

A handover is useful only once these people know their workflow and can actually perform it.

Example: The platform is ready, but the work stalls

Fictional case: An organisation imports its list of measures. Every entry has a deadline. The information security officer is named as the owner of every item.

The pilot reveals that technical changes require operations, supplier evidence requires procurement, and policies require the respective business departments. The information security officer can coordinate the work, but cannot implement or approve every measure alone.

The team assigns implementation to the appropriate people and clarifies escalation. It then uses a real measure to test whether follow-up questions, evidence and business review work through to completion. Only this workflow shows whether the new allocation is workable.

Test responsibilities using a complete case

Take a manageable, sanitised case and work through it together. Our ISMS pilot project guide explains how to bound and evaluate this test:

Who recognises the need for action?
Who assesses its significance?
Who decides on the next step and required capacity?
Who implements the measure and provides evidence?
Who reviews the result?
Who acts if the result is insufficient or the deadline passes?

Record every point at which an answer is missing. These are implementation tasks, rather than reasons to add more mandatory fields.

How to test your initial workflow with Kopexa

Kopexa offers a two-week guided trial. Use it to test this kind of workflow with the people who will actually be involved.

In Kopexa, evidence is attached to measures that are mapped to controls. For policies, you can examine document versions with approvals and distribution through the Workforce Hub. Our article on policy versions, approval and acknowledgement explains the full workflow. Choose the process that best reflects your current problem.

What matters is whether your team can work with it: do participants find their task? Do they know what evidence is expected? After a follow-up question, is it clear who continues the work?

What belongs in the handover?

Record the production use case, owners and deputies, known limitations and the first joint review date. Also document which data or areas have not yet been migrated.

Implementation then ends beyond the import itself: it ends when the team can independently continue the agreed workflow.