Compliance Software: Assessing Functions and Comparing Solutions

Defining the required functions

The first selection decision concerns the software’s purpose. Should it provide access to changes in applicable regulations? Should it coordinate the implementation of internal requirements? Or should it check whether the prerequisites for a specific action have been met? These tasks are related, but require different functions and data.

A compliance management system also encompasses more than its technical support. ISO 37301 addresses the establishment, implementation, assessment, and improvement of such a management system within an organization. Purchasing an application is not equivalent to this. ^[1]

For procurement, a brief description of the operational problem is more useful than “We need more compliance.” For example, a manufacturer wants to prevent material from being used while a specified check is still outstanding. It needs a connection between material identity, the check result, and permitted use. Another operation initially wants to record its site-specific obligations and assign responsible people. Here, the focus is on organizing those obligations.

The starting point should be described together with the people who carry out the process, hold operational responsibility for it, and provide technical support. This discussion should also cover what already works reliably. An existing system does not need to be replaced if the missing function can be added effectively.

Before selecting software, an organization must decide which production process to digitize first. Suitability and priority are separate questions: frequency, consequences of errors, and available information help determine where to start.

The U.S. Department of Justice’s guidance on evaluating corporate compliance programs distinguishes between design, adequate resources, and effectiveness in practice. In its U.S. enforcement context, it evaluates the organization’s program, not software certification. For software selection, this provides a useful question: can the intended controls be demonstrated in the actual workflow? ^[2]

Compliance tools differ by their intended use

Solutions with different areas of focus are offered under the label compliance management software. The following classification helps with an initial shortlist. It shows which tasks different compliance tools can cover; individual products may combine several tasks.

For batch-based manufacturing, an Electronic Batch Record system is a concrete system type: the key question is whether each batch produces a complete execution record with review and release.

These different areas of focus can also be seen in vendor descriptions: examples include legal registers, permit management, and the organization of inspections. Other offerings connect configurable workflows with tasks, forms, and approvals. Such information helps identify the scope offered. Whether the functions are suitable for your own operations still needs to be checked through specific evidence.

A suitable solution may have a limited scope. If legal changes are already assessed elsewhere, an application for operational implementation may be the right addition. If both are to be combined, vendors must demonstrate how a changed requirement actually reaches the affected processes.

From operational requirements to verifiable selection criteria

For regulated markets, a sound shortlist starts with the specific product, activity, site, and intended use. The label “for regulated industries” does not establish which domain-specific rules and evidence an offered configuration covers.

For medicinal products, cannabis, narcotics, and other controlled substances, the specific combination of product and activity must be determined separately. The same applies to tobacco, cosmetics, food and feed, as well as biocides and plant protection products. Similar operational processes do not establish a shared set of legal requirements. Even within one market, manufacturing, storage, and supply may raise different selection questions.

The requirements list should therefore describe what must observably work in your own operations. The illustrative example here is a manufacturer that wants to allow incoming material to be processed only after an internally specified check. A small selection matrix can be derived from this:

This classification is not a general ranking. For another operation, connection to the inventory system may be the most important exclusion criterion. Functions should therefore be classified by their importance for the specific use before the vendor demo.

Each mandatory criterion needs a responsible person and an agreed form of evidence. The statement “supported” remains incomplete until it is clear whether the function is available immediately, requires configuration, or still needs to be developed.

For computerized systems used in GMP activities, the European Commission’s Annex 11 (2011 version) specifies how requirements should be documented: required functions should be based on risk assessment and remain traceable throughout the lifecycle. Supplier assessment and suitable test scenarios are also addressed. This is a sector-specific basis for selection criteria, not a universal requirement for all markets listed here. ^[3]

MHRA section 6.19 makes clear for GMP systems that validation for intended purpose requires an understanding of the system’s function within the process. Supplier test data cannot be accepted in isolation from configuration, intended use, and the user’s IT infrastructure.^[5] For selection, suppliers should therefore explain which evidence covers the planned M-62 configuration and which tests remain to be performed in the customer’s environment. A general “validated” claim does not answer this question.

PIC/S addresses data management and integrity from the procurement stage in its GMP/GDP guidance. Requirements should be reflected in the specifications; the extent of validation of data integrity controls depends on system and process criticality and the risk to product quality. Validation also needs supporting administrative and physical controls and user training.^[6] For the comparison, this means documenting the critical controls, remaining tests, and the contributions required from supplier and customer before comparing costs. It does not prescribe an identical testing package for all the markets discussed here.

Representing the work process beyond the input form

An input form is first of all an interface. It may collect data, trigger a controlled process, or form part of an application closely connected to operations. Its appearance says little about what the software does after the data is saved.

For automated compliance evidence, the software must connect recorded results to the activity performed and the affected item. Without that connection, staff have to reconstruct the context manually for later review.

The comparison must therefore examine the connection between the recorded information and the work concerned:

This comparison sets out questions to check, not a ranking of software classes. Structured input may be entirely sufficient for data collection alone. However, if the application is meant to restrict the use of material on hold, it must reach the action that determines that use. A visible message alone is not evidence of this.

For approvals and releases, it helps to distinguish between a processed document and permitted use. An approval workflow makes those decision relationships visible in the process. When selecting software, it is not enough for an approval field to exist somewhere: the vendor should demonstrate its specific effect in the agreed process.

A real operational case as a test for the product demo

A presentation often shows the intended normal process. For selection, all vendors should also work through the same case prepared by the company. This allows differences to be assessed using a common example.

In the illustrative example, material lot M-62 arrives. It has been recorded but is not yet authorized for use. Document D-62 is available; the required review has not been completed. The operation then wants to stage 12.5 kilograms for production order P-84. These details form an arbitrarily chosen test scenario, not an industry-specific release requirement.

The demonstration comprises four steps:

1. Check the unresolved state. A person carrying out the work attempts to stage the material. The vendor shows whether the operation is rejected, only a warning appears, or a justified exception is provided for. The result is compared with the previously defined requirement.
2. Carry out the substantive review. The responsible person reviews the available information. The demo must show which processing status they assess and whether their decision actually enables the intended material use.
3. Observe the transition between systems. If an inventory system is to be connected, the transfer is deliberately interrupted. Which side shows which status? Who detects the error? How is a retry prevented from executing the same staging operation multiple times?
4. Hand the case over to someone who was not involved. They receive the intended view or an export and should be able to identify which material was involved, what was decided, and whether staging succeeded. Missing context is recorded as a review finding.

The value does not lie in a flawless performance. It lies in documenting requirements, observed results, and open issues. A promised adaptation does not count as a test already passed. Nor does a successful demo amount to full acceptance of the eventual system.

The selection case must also test whether role-based process control actually prevents an unauthorized action. Relevant changes and their review must remain traceable in the audit trail. A displayed role or a mere list of timestamps does not establish these effects.

Test operation where the work takes place

The selection case includes the actual workplace. Gloves, ambient noise, changing devices, and the available connection can determine whether an interface works in daily use. A legible desktop view does not yet answer these questions.

Smartglasses can provide work instructions in the user’s field of view. Vendors describe the use of smart glasses for instructions and for documenting inspection and maintenance tasks. This is an input method offered on the market, not evidence of its suitability for every workplace.

Voice input can be tested in your own selection case as another integration option: for example, a person dictates an observation, checks the recognized input, and assigns it to the open operation. For voice control, it is also necessary to define which actions a command may trigger and when deliberate confirmation is required. Error detection, shared devices, feedback, and an alternative interaction method also need to be checked.

These options are useful if they make the work process easier and preserve its operational context. When they provide digital work instructions, the version appropriate to the activity must be accessible and usable at the workstation. The demonstration should therefore test whether the intended access method works reliably under actual working conditions.

Implementation, ongoing operations, and subsequent costs

The price used for comparison should cover the same scope of services and a jointly agreed period of use. In addition to licensing, the assessment should include setup, data migration, interfaces, devices, training, support, and later changes. The effort required from your own employees also counts.

A particularly revealing question is who implements an operational change after launch. Can a person with operational responsibility prepare an adaptation within the intended configuration framework? Does the vendor need to act? How is the change checked before it reaches ongoing operations? A low entry price says little about this.

At least the following points should be comparable in writing for each vendor:

• Scope of services: Which requirements are included in the proposal, which are optional, and which remain open?
• Implementation: What work and data must the customer provide, and who handles setup and checks?
• Operations: Who manages access, updates, backups, and incidents? Which services are agreed?
• Expansion and exit: What do additional sites or users cost, and how are data delivered together with the context needed?

For the last point, the presence of an export button is not sufficient selection evidence. The export must be usable for the intended purpose; data integrity is essential to the reliability of the information produced. The effort required for any necessary validation or other formal evidence must be planned separately based on the specific use.

A blanket answer to the question of the best solution for small and medium-sized businesses would therefore be of little help. Alongside the mandatory criteria, the people and skills available matter: who can implement and support the application and assess it from an operational perspective when changes occur?

During the subsequent implementation of workflow software, data transfers, alternative arrangements, and operational handover are first tested within the pilot scope. Selection must therefore also identify which prerequisites the organization still needs to establish.

Regulatory finding

Finding: The FDA found that a pharmaceutical manufacturer had not adequately controlled administrative privileges for modifying and deleting files in its laboratory data system.^[4]

Assessment: For software selection, this highlights the need to test permissions in the intended configuration. A description of roles or a list of available security features does not demonstrate which actions a particular account can actually perform. This finding concerns pharmaceutical CGMP; it is not a universal requirement for every market discussed here.

Review question: Can the vendor demonstrate with a test account that prohibited changes and deletions are blocked in the agreed configuration?

Letter dated 22 August 2025 · Source checked on 18 September 2026.

This section presents the selected regulatory finding as stated at the time of the letter. Company responses and subsequent developments are not assessed here; this account does not describe the company’s current compliance status.