Blogs Francisco Aristiguieta, CIA Apr 07, 2021
Even if this was not the case, auditors know the importance of periodic self-evaluation to identify and manage risks and tighten our controls.
There are three aspects that can easily be missed during your self-assessments: who may want access to the data (beyond corporate data classification), data hand-offs between systems and teams, and how risks may be different on transient versus stable processes.
As a rule, if the data is not personally identifiable information (PII), then there is no risk. Right? Well, not really.
Different datasets have different levels of value for different people. Traditionally, we consider external data leaks to be the greatest treat, and so tax IDs, credit card numbers, and other PII are considered the most critical. We do this because this type of data may be attractive to hackers.
That said, auditors may be handling information that could be very harmful through internal data leaks — things hackers could not easily monetize or even care about. Examples include medical leave history, court-mandated salary retentions (garnishments), succession planning, or performance evaluations. These things require as much protection as PII to avoid unnecessary conflict in the team dynamics and possible legal consequences. This protection is needed even if the data is not explicitly linked to PII.
When auditors integrate data from several systems, it is most likely that different parts of the automated process are handled by the automation modules of each of these systems. This means it is very likely there are files that "get dropped" and are later "picked up" by different bots. When this happens, it is important to evaluate your level of comfort with the security of that temporal location where the file waits in transit.
To do this, consider what could happen to your file while in there, and when and how it stops being there. Key aspects include access to the temporal location, length of time in transition, and back-up/clean-up cycles of the location.
Finally, when you review your data flow, you must realize that you are really considering two processes: development and production. On the surface these may look similar, but they are different enough to have different risks.
In production you may end up with only one transition file (or none at all), but in development you are likely to have multiple versions of information as you test each step of your automated process. This risk gets compounded when different team members may be working on different steps of the process as you integrate several systems.
Even if these files and routines are created in "lower environments" (i.e., test version using stale or manipulated PII data), the development may leave instructions on how to access the live data or even leave behind test files in less than ideal locations.
Analytics programs are new business functions, and as such they have their own elements with independent objectives, risks, and controls. Self-reviews and QARs may attempt to focus on the key risks, but keeping in mind these three tips can help make sure internal auditors reduce the data breadcrumbs.