banner

Thales Blog

Security Service Level Agreements

July 13, 2015

George Mills George Mills | More About This Author >

Like a HazMat 2Service Level Agreements (SLAs) directly involve continuous effort and improvement, significant technical investments and integration; and whether implied or explicit all business have them. Once an organization is consistently meeting their SLAs, the tolerance for change decreases and so goes the saying, "if it ain't broke, do not fix it".

Now we have a new, often implied Security SLA meaning "though shalt protect my data or you will not keep or earn my business". Being entrusted to protect one's own and others' data also means the new Security SLA must include direct and indirect data protection standards and compliance mandates, or accept the economic and legal consequences.

ClickToTweet:  Security SLAs - Opening the door to new customers & business  http://bit.ly/1HqN2AO pic.twitter.com/I3XhPzrHfo

CSOs and staff will concur there is a challenge in addressing the new Security SLA while at the same time not impacting existing SLAs. Customers demand certain levels of service and now also demand that their data is protected. CSOs, as such, are dedicating more time to respond answering the Information Security questions in RFPs that have a heavy focus on data

protection. Also, they are participating in meetings to explain their security programs and capabilities to the prospective customers' Risk and Compliance Officers (not IT Security people).

In parallel, CSOs and staff are in continual discussions with executive management,   department heads and internal audit groups about reducing risk and meeting compliance mandates. However, part of those discussions is also addressing the predictable risk to internal and external Service Level Agreements when it becomes necessary to add new security components to tackle evolving or new Security Level Agreements.

Technical infrastructures have been built to be resistant and reliable but is there not concern and trepidation about adding another new security component to the finely tuned SLA engine? So one can offer up a new saying, "if it ain't broke, do not fix it; and if you need to better secure it, do not break it" (as maybe happened the last time).

It is fair statement that Security Level Agreements are requiring advanced security controls and safeguards for protecting data. In many cases, encrypting confidential and sensitive data wherever it may rest and in whatever form it is has become mandatory - a 'must have' to keep moving forward and avoiding significant exposure and risk.

Also, many are realizing that protecting data is like having a 'HazMat' suit; it can open the door to new customers and/or additional business opportunities.  From Retail, HR, CRM, Financial, Supply Chain, Engineering, Legal, eComm, and Managed Services to the respective data being processed and stored, the new Security SLA is becoming a permanent fixture of doing  business.