AXLR8 have clients with many years of data in their systems and so have provided tools to clean up their data manually. However, the job has become too large and the volume of information requests and SARs has risen to a point where an automated tool is justified. That brings efficiencies but also requires care to make sure that complex rules to run on the data.
Automation
Specify rules.
First we ask that you specify your rules. In any jurisdiction we have found that the statutes governing the destruction rules for public and other bodies can be interpreted in many ways. For example, just taking Scottish local authorities alone, the OSIC rules have been interpreted by different public bodies to mean:
- three years for FOISA/EIR and six years for SARs (or any IR that has a Review or Appeal)
- Three years for both SAR and FOISA/EIR but 6 years if there has been a Review or Appeal
The above all run monthly and there is a facility to produce Destruction Logs However, yet a third authority has a rule that runs annually:
- three calendar years for everything ( the implication being that, just before the automated process runs on 1st January, there will be material that is 4 years old)
See if you can guess which clients we are talking about from their PDL (public disclosure log) on their website!
Retention Safety Net Report
The RSNs (Retention Safety Net) reports, as their name suggests, list the data that will be deleted if the data destruction process goes ahead. This is an essential tool as it allows a team to look through for any queries and check the accuracy the destruction business rules.
The RSN reports allow the manager to filter on certain rules (e.g. “Three years for FOI requests but 6 years if there has been a review“, or “All applicants data if their request is out of date BUT not if they have another current or in date IR“)
Obviously, you need to enter a deletion date as well. The personal data and IRs that will be deleted from the system on the 15th of the month will not be the same as the 27th. The reason for that is that is ten more days have passed and more items may have dropped out of retention period by that time. As another example, it is sometimes the case that items that were due for deletion on 3rd January are not now for deletion on the 5th January. This could happen where an applicant puts in a new request on, say, 4th January, and their record is hence to be kept on the system (although their original IR may remain on the list for deletion).
First Run
Following the above checks, the first run will be signed off by all. It is often the case that the first run is very large. Many of our clients have been using the system for ten years and only recently applied, e.g., a three year retention period. Thus there are frequently up to 10,000 or 20,000 contacts and IRs to be deleted in total on the first run. The angst of missing something in the cautious pre-checks listed above are much alleviated once the organisation is compliant directly after the process has run. This compliance with the retention rules is only temporary as more data is already starting to predate the retention period! So, the next couple of cycles we repeat the pre-checks and run the process again.
Trial for a couple of cycles
If you run the system for a couple of cycles (normally two months elapsed time), then the reviews before and immediately after the event can flag up queries. If that happens, an immediate restore of the data can make sure there is zero/minimum. For example, it could be run at a time when no new IRs were likely to come through the self service form and when the team are not using the system. In the unlikely event that a new IR arrives, you can re-enter it manually and leave notes for potential future auditors.
Run unattended
Once you are comfortable that the business rules are working, the attitude should be “trust but check”. Say the automated process runs on 25th of every month. At any point running up to that time, you may wish to run the Retention Safety Net reports to see if any people or IRs are included that should not be. Sometimes a human can see things that were simply not predicted when the destruction business rules were signed off.
Destruction log
AXLR8 users can create a destruction log with skeleton information about the contacts (people) whose private data has been deleted and the information requests that have been removed from the system. This can only be a skeleton with key numbers and dates and outcomes because many of the fields of information contain data that must be deleted. For example applicant data and any description of SARs would contain precisely the data we are required to delete. So, the RSN reports may be run and then those columns can be deleted leaving the skeleton information ready for appropriate records keeping.
If any of the above raises any queries, please do not hesitate to contact AXLR8 on 01344 776500, Teams or our email support@axlr8.com.
