Cost of compliance

In today's digital world, there is one end where everyone wishes to have all their information at their finger tips and on the other hand there are regulatory requirements which push to ensure that the information is available with the policy of least privileges and only on need to know basis. Balancing the two for financial industry is the most challenging hurdle today.

The open standards and "fin-tech" storm is creating more opportunities to open up to the digital front and conduct transactions across the corporate boundaries in a never-before environment. But yet the regulatory requirements usually tend to slow down this fast paced change. It is without doubt a mandatory requirement to meet the regulatory and compliance requirements but the cost of meeting these requirements has grown exponentially in the recent past.

Organizations at times fail to recognize this increasing cost. For the executive leadership, the cost of compliance is an important factor to consider. The the implementation teams, the compliance requirements are a must even if they have not been initially included. The project teams should always ensure that security, compliance and regulatory requirements are factored in for all projects being embarked upon. Even though one can start a project with quick wins hoping to delivery a "MVP - (minimum viable product)" in a short duration, they cost of compliance, more often than not, can de-rail the entire value proposition if any managed properly.

As quick example let us look at the the requirement to apply the security patches in a regular manner across all the systems. At the on-set, this seems more a like a standard practice which one would think is a given fact and not something which needs to be enforced and planned for. However, the reality is completely different. It is a lengthy and tedious process to patch systems. The process can result in multiple downtimes across the customer facing channels if these requirements of patching regularly are handled at the design phase itself. Once a security patch is released by the software / hardware vendor, it would first need to be validated in the specific environment in an organization. This is due to the fact that not all system implementations are consistent across organizations / products. To achieve this, organization push these patches across the test and development environments. Once validated there, they are then further promoted to the production environments. Even though the advancements in patch management and resilience of the systems is increasing but not everyone is at the latest technology level and hence applying these patches is a disruptive activity.

Add to the above the number of varied systems and the threat categorization of the issues addressed with the patches. Every system tagged for a missing patches usually tends to carry the same threat level as the patch. However, this is where I would insist that organizations put time and efforts to avoid it. A system which is customer facing has a higher level of threat than an internal systems which is accessed only by a select user based within the secured corporate network. If such a triage activity is not part of the process, the cost of compliance would be much higher compared to a process where triage is done correctly and tagging of threat levels is adjusted based on the risk profile of the systems rather than the standard published level. Note that the threat level associated with the patch is usually for the worst case scenario.

Organizations have today secured their network perimeter and have usually implemented segregated networks for users and systems. This itself is accounted for as an additional cost of compliance and security. So if such investments have already been made, the organizations should ensure that they capitalize on these and implement the re-categorization of threat levels. The biggest gain here will be the customer service improvement as now the focus can be on the most critical and most vulnerable systems rather than the entire estate resulting in smaller maintenance windows for systems exposed to the customers. At the same time, the resources, time and efforts needed to implement these patches across the estate in an acceptable time frame is also improved as the isolated systems with low threat levels can follow a different schedule than the critical and more higher threat level systems.

Another factor to consider in implementing new systems and "MVP" solutions is the fact that wether it is for 1 customer or a million customers, a regulatory requirement in a specific area is the same. For example, a report required by a regulatory body is the same whether the organizations have a smaller customer base or a large one. Another example is the compliance to international industry standards like VISA mandates, SWIFT mandates. If an organization has these systems within their landscape, it does not matter if they have a few customers or they are just opening up new avenues in this area to acquire more customers or an organization which has a large customer base; all of these organizations have to implement the same compliance mandates by the same deadlines. In such cases, the cost of the compliance for organizations pushing for a "MVP" solution will turn out to be much higher than those with a large customer case due to higher incomes and revenue streams from their large customer base.

To further enforce this concept, let us look at more examples. A simple transaction banking solution can be implemented as a quick win. It can be implemented in the most secure way meeting all the compliance and regulatory demands. However, this is transaction banking solution is not the only piece in the puzzle. At times, the regulatory requirements will mandate additional threat check systems and fraud management solutions. These will definitely increase the cost of the solution being implemented and could result a failed business case at the "MVP" level. In the initial stages, the organization might not have enough projections to make this "MVP" proposition a profitable one. It is in such a scenario where the executive management would have to take the call for a much longer term and high projection levels of business acquisition to make the call on investing in the solution even though it might be in the "RED" in the short term. Please beware that sometime there might be a push to bypass certain controls for a future release when the customer base increases or revenue streams become more viable. This should be very clearly documented and planned to avoid failure or contention or regulatory action in the future and yet keep the business line growing.