Before you sign a business software deal: how to set a minimum data quality bar that prevents nasty surprises

What business question should you ask before signing?

The right question is not “is this software powerful?”. It is: “which data must be correct, complete, and stable for this software to replace our spreadsheets and workarounds?”. Without that framing, companies often buy a promise of convenience and then discover a week of manual re-entry, duplicates, and business decisions that are impossible to explain to leadership.

The CNIL states that, in a controller–processor relationship, the contract must set out the subject matter, duration, purpose, and obligations of the parties, as well as the required security level; processing must also respect data minimisation and storage limitation. In plain English: the quality conversation is not just technical. It defines the exact scope of processing and the data truly needed for the service.

• Goal: define the minimum acceptable before paying, not after.
• The threshold should cover the data needed for the main use case, not the entire company archive.
• A good contract cannot fix inconsistent data; it mainly limits damage and clarifies responsibility.

A four-test method: usefulness, accuracy, completeness, stability

To avoid vague debates, use four simple tests. First: usefulness. Every field requested by the software must have an identified business use. If it has none, remove it from scope. That is the practical application of minimisation promoted by the CNIL. Second: accuracy. Measure the share of clearly wrong or contradictory values in a representative sample. Third: completeness. Check whether mandatory fields are filled to the level required by the process. Fourth: stability. Ask whether the data changes too quickly to remain reliable between entry and use; a record can be accurate but still too volatile for management reporting.

NIST defines data quality as fitness for intended use, which is a helpful way to escape the trap of “everything must be perfect”. The goal is not statistical perfection; it is fit for the business process you need to run. For a sales or service management tool, delivery address quality matters far more than a decorative free-text comment field.

• Test 1: every field has a written use.
• Test 2: sample visible errors.
• Test 3: separate mandatory and optional fields.
• Test 4: check stability between entry and use.

Fictional numerical example: the minimum bar that changes the decision

Fictional example: a services SME wants to buy business software to track interventions, customers, and reminders. It lists 12 fields in the future master data set. After a quick review of 200 customer records, it finds that 98% of legal entity names are correct, 91% of emails are valid, 87% of postal addresses are complete, but only 64% of contract end dates are filled in, and 22% of customer accounts have at least one duplicate.

The decision is not “let’s wait until everything is 100%”. The useful decision is: before signing, require at least 95% unique customer identifiers, 90% completeness for fields that trigger automated action, and a clear duplicate-cleansing rule before migration. Below that, the software may be good, but the operational outcome will be shaky. This is not a legal standard; it is a business success criterion you define with the vendor and internal teams. The real benefit is making the discussion objective instead of relying on the politest sales pitch on the market.

On the contractual side, the CNIL also reminds controllers that the processor must be able to demonstrate compliance and allow audits. That is useful leverage: before signature, ask for proof that the vendor can handle your data according to your rules, not just a polished demo.

• Fictional thresholds to adapt: uniqueness, completeness, validity.
• The threshold depends on the use case, not the total data volume.
• Focus on fields that trigger automated action.

The limitations you should acknowledge immediately

There are three important limits. First, minimum quality is never universal. Data that is acceptable for marketing segmentation may be insufficient for invoicing or for regulatory compliance. Second, a sample can mislead if errors are concentrated in one site, one team, or one legacy file. That is why you need to inspect outliers, not just averages. Third, some defects only appear in real usage, when teams bypass the tool because a mandatory field was poorly designed.

Also remember the transfer and hosting question. The CNIL stresses sufficient safeguards, including for transfers outside the EU when they exist. A software product can look excellent on paper and still be unsuitable if the contract, security, or data location do not fit your constraints.

• Minimum quality depends on the use case.
• Averages can hide poor-quality pockets.
• Contract, security, and data location are part of the same decision.

A 7-day action checklist

Day 1: appoint a business owner. Observable result: one person validates the indispensable fields. Day 2: list the 10 to 15 truly useful fields. Observable result: a mandatory/useful/unnecessary table. Day 3: sample 100 to 200 records. Observable result: a completeness and error rate per field. Day 4: define your minimum thresholds. Observable result: three written thresholds accepted by business and IT. Day 5: test the rule on a small real case. Observable result: one automated action that works or fails in a documented way. Day 6: have procurement and legal review the draft clause. Observable result: security, audit, return/deletion, and sub-processing obligations included. Day 7: ask the vendor to demo using your data or a realistic set. Observable result: a fact-based go/no-go decision, not a decision driven by enthusiasm.

• Business owner: validates scope.
• Procurement/legal: secure the clause.
• Vendor: proves capability on your data.
• Leadership: decides against explicit thresholds.