ISMS pilot project: Test the workflow, not just the interface

A demo shows what software can do. A pilot shows whether your team can work with it. You do not need a copy of your entire ISMS. You need a bounded case, clear expectations and people who will actually use the workflow later.

This test plan is our practical recommendation for software selection. It does not assume a fixed pilot duration. For the broader comparison of criteria, see our ISMS software guide. The pilot is about applying those criteria.

Choose a case with a real handover

Use a workflow you already know. For example: a recovery test reveals a gap. A responsible person needs to address it, attach new evidence and have the result reviewed.

The case should involve at least two roles and a decision. If one person enters the data and approves everything themselves, you barely test collaboration.

Keep the scope small: one process, one associated risk or requirement, one measure and a few pieces of evidence. Use sanitised test data unless real information is necessary for the assessment. Agree beforehand who may view and change which data in the pilot system.

Write down expectations before the supplier demonstrates the workflow

Define observable outcomes. “Intuitive” is a judgement; “the responsible person finds their open task without assistance” is testable.

This table sets out questions to test, not guaranteed features of any particular product. Ask for each relevant workflow to be demonstrated in the intended configuration, then perform it yourselves.

Test a second pass

The prepared ideal case is only the beginning. Then change one condition: the responsible person is absent. The evidence does not cover the period. A measure has been closed despite an unanswered question.

Observe whether the people involved recognise the deviation and can continue processing the case. This reveals whether the system provides guidance or whether you fall back on email and verbal instructions.

Check the view available to each role too. An administrator may be able to see everything; that says little about whether a business user finds the right information. Conversely, confidential content they do not need should not be shared simply to make the test easier.

Record observations and assessments separately

A test record does not need to be a novel. One row per observation is enough if it supports a decision.

Separate product limitations from setup errors. A missing role assignment may be correctable. An essential function that does not exist is a different result. Planned functions count as fulfilled only once they are available and tested within the agreed scope.

Test the eventual exit too

Ask how you can retrieve your data after the pilot. Have an available export demonstrated using a small dataset. Check whether it is understandable for your purposes and which content, files or relationships it excludes.

This goes beyond an abstract feature list. You establish the effort involved in a later move or internal downstream processing. Record unresolved export questions alongside open questions about everyday use.

Decide on the basis of the cases

There are three possible outcomes: the workflow meets your needs; it works after clearly specified adjustments; or an essential requirement remains unresolved.

Avoid an overall score that offsets a genuine exclusion criterion against many minor convenience points. The decision should show which tasks you can perform better in future and which limitations you consciously accept.

Try Kopexa for two weeks with support

Kopexa offers a two-week guided trial. You can try the workflow yourselves and discuss open questions with us.

Use a sanitised test case throughout: set your expectations, test with the roles involved and examine a deviation from the ideal case too. Record what works and where you need support. After two weeks, you have your own observations to inform the decision.

Discuss with us which workflow you would like to test during the trial.