Workplaces that run breath alcohol tests before clocking in or before deploying vehicles or equipment end up holding information that can be linked to individuals, such as test times, the people tested, and results. These breath test records can serve as evidence that the check procedure set on site was carried out. On the other hand, if records whose check purpose has ended keep piling up on devices and in several file storage locations, it becomes hard to tell needed data from unnecessary personal information.
Here, the retention period is the period during which you have decided to keep records, and destruction is the work of removing data whose period has ended so it can no longer be used or accessed. A breathalyzer can store results in its internal memory, and the same results can also be copied to operating software, servers, work PCs, and printouts. So deciding on a retention period and actually destroying every copy must be connected in a single operating procedure.
Distinguish the purpose and status of records before the period
Before applying the same retention period to all breath test results across the board, sort out why each piece of data exists. Routine pre-shift or pre-deployment check results, data related to an objection or internal review of a specific result that is still in progress, and data for which a separate retention requirement has been confirmed can differ in their use and end point. If you copy the period from another industry or another workplace as is, you may end up keeping records longer than the actual purpose of collection requires.
A retention period is hard to carry out if you set only a number. You need to define, for each type of data, the starting point for counting: whether to count from the test date or from the date the objection handling or related review ended. File creation dates and monthly folder names can differ from the test date, so it is safer not to decide what to delete from file names alone.
Article 29 of Korea's Personal Information Protection Act requires personal information controllers to take technical, administrative, and physical safety measures, including establishing an internal management plan and keeping access logs. This article itself does not set a specific retention period for breath test records. However, the need for a system to manage who accesses records and through what procedure data whose reason for retention has ended was handled also connects to retention and destruction procedures.
Record the starting point and exception end date in the retention table
In operating documents, rather than writing only a period such as "keep breath test records for X years," write down the criteria for deciding when retention ends and the scope of destruction together. For the same judgment to be made at each periodic review even when staff change, the record type, the start date for counting, and the exception conditions need to be visible at a glance. In particular, design exception retention so it applies only to the specific cases that need it, not to all data.
| Data to distinguish | Criterion for deciding retention has ended | Where to destroy and what to check |
|---|---|---|
| Routine check results | Confirm the period set from the test date has ended | Check the breathalyzer, operating software, server, and downloaded files |
| Results under objection or review | Confirm the objection or review has ended | Keep only the needed cases on an exception list and set a re-review date |
| Printed or forwarded data | Confirm the purpose of forwarding and need for retention have ended | Check printouts, email attachments, and copies in shared folders |
| Data included in backups | Confirm when the backup rotates out and whether it can be restored | Check whether individual deletion is possible, access restrictions, and re-checks after restoration |
You may consider recording on the exception list the reason for retention, who approved it, and the date to review it again. For example, if an objection to one person's test result is in progress, identify that result and the related data needed and set them aside as an exception. If you vaguely leave the whole month's result file as an exception, many records may continue to be kept even after the review of a single case has ended.
Confirm the scope of destruction by storage location, not by data type
Deleting results from the device screen or device memory does not make every copy disappear with them. Files downloaded with the operating software, originals stored on a server, compiled files in shared folders, email attachments, external storage devices, and paper printouts are each separate storage locations. Rather than writing only "test records" on the list of items to destroy, write down where they are actually stored so you can find omissions.
As a hypothetical example, consider a case where, during a scheduled month-end destruction, the breathalyzer's internal records were deleted and then the staff member found last month's result file on the desktop of a work PC. The fact to observe is that deletion on the device was finished but the same personal information remains in another location. After interpreting whether the file is a copy of records whose retention period has ended or whether there is a specific reason to keep it, such as objection handling, choose the action of destroying the electronic file or registering it on the exception list as a specific case.
The completion criterion in this case is not just deleting one PC file. You need to confirm that items whose retention period has ended are gone from the defined storage locations, that cases kept as exceptions have a reason and a re-review date, and that printouts and forwarded copies were also within scope. With this criterion in place, the same omission will not be repeated at the next scheduled destruction even if the person in charge changes.
For backups, consider whether records reappear after restoration
Backups may be kept differently from files in active use. Records deleted from the screen or server can reappear when a past backup is restored, so check deletion in the current storage and handling in backups separately. Within the scope of technical staff, check whether individual records can be deleted from a backup directly, whether older backups are rotated out on a set cycle, and whether items to be deleted reappear after a restore, and reflect the findings in your policy.
If a backup makes immediate individual deletion difficult, you can record that situation and the set rotation conditions. In the meantime, you need to restrict who can access or restore the backup and review whether rotation-based deletion took place as scheduled. If you keep it with no retention end date just because it is a backup, past copies may remain even though the operating data was deleted.
How far the delete function of the breathalyzer and operating software in use reaches, and whether data can be recovered after deletion, are things to confirm in the product manual and the supplier's guidance. Summarizing your current environment at the same time, such as the software version, the path by which results were downloaded, and how they are stored on servers or PCs, helps narrow the scope of what to check. It is important not to assume that a specific model's features are the same on other equipment.
Record destruction results without recreating the original data
When destruction is finished, record the execution date, the period and scope of records handled, the storage locations, who carried it out, who verified it, and any exceptions or failures. Comparing the scope of the deletion request with the actual results lets you find missed folders or storage that was not handled. If there is a storage location where deletion failed, do not mark it complete; record who will act on it again and when, and manage it as follow-up work.
There is no need to attach result files or lists of people tested to the destruction record again in order to prove destruction. It is enough to write the scope and the fact of execution, such as "routine check results for a specific period were handled on the breathalyzer, server, and work PC." This reduces the chance that proof of destruction becomes a new stored copy of personal information.
Scheduled destruction is closer to recurring operating work based on the retention table and the storage location list than to a one-time event to clean up data. If the end dates for exception data are also reviewed on the scheduled destruction calendar, you can reduce the problem of records being kept virtually forever because of objection handling or reviews that have already ended. When the retention period, starting point, exception end date, and destruction results for each storage location are linked, the principle of setting a period is completed by actual destruction.
