Data Classification is the backbone of security strategy. As it enables an organization to evaluate its information assets and then plan security investment allocation to prioritized items.
Buoyed by data protection regulations, many organizations have developed data retention, archival and deletion programs. These programs ensure that personally identifiable data is not processed in the organization against any privacy regulations. However, the implementation of such projects does not always guarantee data protection and compliance in future. Because organization’s business change can drive many changes in its existing IT landscape. IT changes to complement business can include one or more of the following:-
- Procurement or development of new systems
- Addition of new data fields in existing IT systems or applications
In the scenarios, mentioned above, organization’s IT function has to ensure that the changes do not bypass existing data compliance controls. There are two ways to ensure data compliance in such a situation. One way is to involve IT risk and security team in the design phase of the mentioned changes. From an ideal world perspective, this looks like the right approach. Because this approach ensures that data compliance concerns are identified and resolved at the initial phase of any new change. However, things are not as simple as they look in the real world. The potential roadblocks this approach always has to weigh against include some of the following.
- Project/ Change management teams tend to prioritize security controls lower than having the change implemented as soon as possible.
- Personal, budgetary and business drivers such as ‘early to market’ make change managers oppose having data compliance review during the design phase. This is despite the fact that that leaves the organization exposed to high risks in terms of financial penalty and brand damage.
The other approach is to do a periodic audit of all changes happening across IT landscape to identify any systems which might have become non-compliant data protection regulations because of the implemented changes. As can be directly concluded, this approach comes with the disadvantage of being passive and retrospect in nature. In effect, this approach works for organizations that intentionally or unknowingly have higher risk acceptance. Because using this approach, there is always a window of time when the organization is actually non-compliant to data regulations. But in a practical world, quite a few organizations use this approach. The perceived benefits of this approach are exactly opposite to the disadvantages that change management/ project teams find in the above approach.
Assuming, that an organization decides to do periodic data audits, then following is the illustrative list of actions it needs to perform:-
- Identify the data source, which has documentation and audit trails for all changes and incidents implemented across the IT systems. Usually, this could be IT service support, change management tools such as SNOW, Remedy etc.
- For each change analyze the changes which have been made. Check if there are any additions to DB schema either by way of new tables or new data fields which retain personal data. If there are such cases identified, then these changes will need data protection controls to be applied to them.
While this article illustrates the methodology for ensuring data compliance by either integrating data protection controls as part of software development life cycle (preemptive) or by data compliance audits against changes already implemented (retrospective), there are strong reasons to believe that the former method should be the preferred way to go. Some of the reasons for the same have been already explained in early sections of the article.
Authored By - Indranil Chakravorty
TCS Cyber Security Practice