Manage Learn to apply best practices and optimize your operations.

Service-level agreement management: Defining security policy roles

Does your security plan include expectations or incentives for SLAs? Lawrence Walsh explains why setting standards for your enterprise is essential.

ontractual stipulations and service-level agreements (SLAs) are nothing new to anyone who's contracted for goods or services. You specify how services are to be delivered, on what timetable and to what level. Anything that falls outside those terms is a breach of contract that could result in reduced payments, rebates or service cancellations.

Enterprises employ security SLAs in their outsourced contracts, imposing such requirements for scanning service providers' networks for vulnerabilities, patching and change management expectations and checking periodically for quality control.

Such SLA provisions make sense, if for nothing else than to ensure you're getting what you paid for.

But what if you are the service provider and the customer is one of your own business units? The principles of an SLA can be just as effective internally as they are with external, contracted parties.

Before you say corporate security policies already cover such matters, consider this: Does your security policy assign responsibility and expectations? Does your policy have penalties and incentives? Can you measure performance based on the policy statement?

Increasingly, enterprises are using SLAs as a means of codifying the process defined by their security policies. Let's look at how SLAs can be applied in practical terms.

Setting expectations: An SLA between the security department and business units establishes what is expected of both sides of the security equation. For instance, the security team will agree to guarantee a certain level of network availability (five-9's or whatever), install critical patches and deploy AV signatures within prescribed time frames. Like-wise, the business unit will agree to maintain hardened configurations on workstations and servers and not deploy new applications without a security review.

Assignment of resources/responsibilities: SLAs can be bidirectional, meaning the two parties assume mutual responsibilities for security tasks and goals. For example, the security department could require that each line unit has a person responsible for coordinating and implementing security controls. In return, the security team will devote more of its bandwidth to critical business functions.

Measuring success: An SLA gives enterprises a benchmark for measuring performance. It would be a knock against the security team if it missed an AV signature deployment and allowed a virus to infect the network. A string of failures could be used for disciplinary action against individuals responsible for implementing security. Of course, the same principle applies to successes. Performance bonuses could be tied to a security team's track record for meeting prescribed tasks.

Budgeting: Not every SLA failure is avoidable. A lack of budget and resources could cause lapses in response time and security performance. An SLA can give CISOs and security managers the ammunition they need to justify the expense of additional FTEs, equipment and services. Likewise, an SLA metric could demonstrate ROI on security investments.

Establishing and enforcing internal SLAs isn't rocket science. It's about setting an expectation, putting a process in place and standing behind it. Security practitioners often cry for a means to demonstrate their value to the enterprise. Signing on an SLA's dotted line could fill that need.

About the author:
Lawrence Walsh is the executive editor of Information Security.

Dig Deeper on Data privacy issues and compliance