How to Choose a 231-Model Software for Supervisory Board Workflows

This guide gives a practical approach to evaluate and compare 231-model software products: what to prepare before demos, the hands-on tests to run, a checklist of acceptance criteria and a weighted grid to score suppliers. It focuses on operational fit and testable evidence — not legal advice on Model adequacy or OdV duties.

Start from your real processes, not feature lists

Regulatory references (for example, obligations stemming from corporate liability frameworks or requirements intersecting with GDPR, ISO, NIS2 or DORA in some contexts) set the governance objectives, but they do not mandate a specific IT platform. So judge any product against the actual workflows you need to run: recipients, content, cadence, responsibilities and exceptions. A quarterly procurement review has different needs from an ad hoc inquiry opened after an anomaly is detected.

Before you contact vendors, prepare three representative cases: a recurring flow (e.g., quarterly purchases review), an extraordinary request (e.g., documentation requested after an incident) and a remediation action (corrective measures after a finding). For each, map who produces the information, who verifies completeness, and who decides whether further inquiry is required. This preparation prevents demos from being steered only by available UI elements instead of by your process needs.

For guidance on linking controls to evidence, see our operational approach to audit processes in 231 models at /en/blog/modello-231-audit-controlli.

Define observable acceptance criteria first

Turn general expectations into verifiable outcomes. “Document management” is too vague; instead define statements like: “Retrieve the specific version the OdV reviewed, distinguishable from later uploads.”

Below is a practical checklist to adapt to your organization. Not every product will implement every capability the same way.

• Responsibility

  • Demo test: assign a flow owner, then replace them with another user.
  • Expected outcome: the current owner is clear and the transfer is reconstructable.

• Reporting period separation

  • Demo test: open two successive collections for the same flow.
  • Expected outcome: documents and responses are not mixed across periods.

• Completeness tracking

  • Demo test: submit only some of the requested attachments.
  • Expected outcome: the request remains flagged incomplete and the missing items and rationale are visible.

• Versioning

  • Demo test: upload a correction to a document already reviewed.
  • Expected outcome: the earlier version remains identifiable and linked to the original review.

• Evaluation workflow

  • Demo test: record an outcome, then request integrations.
  • Expected outcome: receipt and evaluation are distinct steps in the history.

• Remediation

  • Demo test: link a detected deficiency to a corrective action.
  • Expected outcome: owner, deadline and evidence of closure are reconstructable.

• Export

  • Demo test: extract the case file for the flow.
  • Expected outcome: the export preserves documents and the contextual evidence trail.

For each criterion, record whether the capability is available out-of-the-box, requires configuration, or depends on external/manual activities. Ask who will maintain those configurations after go‑live.

A critical differentiation between vendors often appears when you test an incomplete response: does the system make the deficiency visible, or does it simply store an attachment and mark the case closed?

Run a demo against a complete scenario

A useful demo walks the whole lifecycle from request to closure. Use synthetic or anonymised data — don’t upload confidential documents into a vendor’s public demo environment.

Example scenario to test: the OdV requests a sample of service purchase files to verify compliance with an internal procurement protocol. The sample includes travel-related services such as business chauffeur services to make the test concrete. Prepare a request with a defined period, owner and deadline. Include an order, an authorization and an invoice in the sample, but intentionally omit one attachment and add one document related to the wrong period.

During the demo, check that the verifier can detect both anomalies, request an integration and keep the justification for the request visible. Then replace a previously reviewed document and verify it remains clear which version supported the initial assessment.

Finally, ask the vendor to produce a readable case file that doesn’t require navigating the system. The exported deliverable should show the original request, responses, detected deficiencies, integrations and the final outcome. Using the same scenario and documents across vendors makes comparisons meaningful.

Test late responses, replacements and negative outcomes

Don’t only test the happy path. Operational differences surface when deadlines are missed, owners change role mid-flow, or submissions are inadequate.

• Replace an owner while the request is still open. Confirm that pending tasks are not orphaned on a deactivated account and that prior actions retain correct attribution.
• Ask how overdue flows are identified and how reminders are documented.
• Introduce an outcome where a submitted document does not demonstrate control execution. The deficiency should link to a finding and corrective action without erasing the original verification. Closure of corrective actions must be supported by evidence of remediation, not just a completion flag.

Compare how vendors distinguish at least three states: information received, information verified, and deficiency resolved. If these all collapse into a single “completed” state, reporting can obscure outstanding work.

Check access controls, versioning and the audit trail

Document availability must not mean indiscriminate access. Define the roles you need in your organization: flow owner, coordinating function, OdV members and any authorised external parties.

In the demo, sign in with different profiles. Verify what each profile can see and modify, whether owners can access unrelated flows, and how access revocation and member replacements are handled.

Prove the audit trail by performing tangible actions: upload a file, replace it, change a deadline, reassign the owner and record an outcome. Review which events are logged, how attribution is shown and whether administrators or users can alter those logs. Our best practices for a verifiable audit trail at /en/blog/audit-trail-best-practices explain how to distinguish a useful history from a list of disconnected events.

Make sure the system preserves distinctions between the upload timestamp and the actual date of control execution and between the document’s creation period and when it was filed. This prevents a recent upload from giving the appearance of a recently completed verification.

Confidentiality, retention and exportability

Flows often contain personal data or sensitive corporate information. Principles of minimisation, limited retention and integrity/confidentiality — as articulated in GDPR Article 5 and similar data-protection frameworks — must be applied proportionally to the context.

Ask vendors how access rules are configured, how organisational retention policies are enforced, and how deletions and backups are handled. Differentiate documented functional behaviour from marketing statements.

Also test exit scenarios: which export formats are available, which metadata are included, what documents are bundled and whether there are contractually stipulated costs or restrictions. An archive that only exports flattened PDFs may lose relationships between requests and evidences, version history or explanations of outcomes.

Include a hands-on export test where an external reviewer must be able to understand what was requested, which documents were evaluated and what issues remain open without relying on the original user to narrate the case.

Compare suppliers with a weighted scoring grid

Feature count alone is not enough. A platform may offer many modules yet still require manual steps to complete an OdV request.

Here is a sample weighting you can adapt before demos according to your organisation’s priorities:

• Flow and exception management — 25%: evidence from tests with delays, missing attachments and owner changes.
• Traceability and versioning — 25%: ability to reconstruct changes and identify the version reviewed.
• Access controls and confidentiality — 20%: tests with authorised and unauthorised users.
• Export and exit readiness — 15%: readable case file and contractual exit conditions.
• Configuration and day-to-day management — 15%: tasks required to launch and maintain the process.

Score each dimension 0–3: 0 = not demonstrated, 1 = relies mainly on external work, 2 = partially satisfied, 3 = fully satisfied with verifiable evidence. Record justification next to each score.

Keep essential (non‑negotiable) requirements separate from the overall score. If a critical confidentiality need isn’t met, a high score elsewhere should not override that disqualifying issue.

Estimate the post-purchase effort

Total cost-of-ownership goes beyond license fees: include initial configuration, document import, owner training and ongoing maintenance. Ask which activities are included in the proposal and which require professional services. Don’t assume everything is covered by the license.

For your pilot, choose a confined flow with known owners and readily available documents. Before release, make sure each request has an explicit period, a responsible owner, a deadline and clear completeness criteria. Defining these elements is organisational work — software cannot reliably infer them from a folder of attachments.

Measure within the pilot how long it takes to open a request, verify a response and produce the case file. Count the steps that still require emails or external spreadsheets. Those internal metrics are more valuable than vendor promises of generic savings.

A sustainable 231-model solution is one your team can run without constant vendor intervention. To verify this, have an owner and a verifier repeat the test after a short training session rather than letting the vendor’s demonstrator perform all tasks.

Frequently asked questions

• Can a document repository be enough for OdV workflows?

  • It may suffice for very simple needs if responsibility assignment, requests, outcomes and exceptions are tracked reliably elsewhere. The limitation appears when reconstructing an audit requires manually correlating emails, versions and meeting notes. The fit depends on the process, not the label on the product.

• Does uploading a document prove a control was executed?

  • No. The submission must be relevant to the control and period, and contain sufficient content to support the verification. Receipt of an attachment is not the same as assessment of its adequacy.

• Should the system close requests automatically?

  • Not necessarily. You must first decide who certifies completeness and who records the verification outcome. Automatic closure based solely on file presence risks hiding incomplete work.

• What is the decisive test before buying?

  • Have the software handle a complete flow with at least one exception and then export the case file. If an authorised reviewer can reconstruct responsibilities, documents reviewed, decisions and open questions from the export, the test yields a concrete basis for comparison.

Try AuditReady with your sample flow

AuditReady centralises evidence with ownership, versioning and a robust audit trail, and supports management of controls, findings and remediation activities. To evaluate it in your context, request a dedicated 231-model demo at /auditready/lp/modello-231 using one of your OdV sample flows: verify required steps, the exported case file and configuration items to address before adoption.

This document is intended as practical guidance for software evaluation and does not constitute legal advice.