Using a properly specified system that is validated through CSV isn’t enough to prove that it is fit for purpose. There’s a need to monitor the system and the data within it to confirm that it actually is operating as expected and that Data Integrity really is maintained.

Locking records and data away in some form of closed or locked state where they never get accessed or reviewed is inviting trouble. If you access that data in say 20 or 30 years only to discover a problem then by that point it will very likely be too late.

It’s essential to have oversight over the data, the system and the supplier so you can actively check that Data Integrity is being maintained.

Examples include:

• regular reporting on proactive data checks done by the system to confirm that no data corruption or loss has taken place;
• review of the audit trail to ensure no unauthorised access or changes to the data have occurred;
• review of technical obsolescence risks and timely normalisation or migration of records and data into formats that remain legible and usable;
• monitoring against SLAs to ensure the supplier is delivering the required services;
• and active testing of exit strategies, incident response plans, and business continuity and disaster recover so you know that if the worst really does happen then you can recover and your data and records won’t be affected.

These are all things that need to be supported by the system and supplier and are all things that should be specified upfront in the URS.

This all helps ‘close the loop’ so there is confidence that the system wasn’t just specified, selected and validated as fit for purpose at the start of the process but has remained that way throughout the data lifecycle and that long-term Data Integrity really has been achieved.