An SLA stands for service level agreement and is a documented agreement between a service provider and a customer that identifies the services required and the expected level of that service. SLAs play an important role in penetration testing. They establish a baseline understanding between the client and provider on what should be expected during the engagement. In this article, we will cover what an SLA is and how they are important for ensuring you get quality service from your service provider. 

The importance of SLAs in penetration testing

SLAs are essential in ensuring clients are satisfied with their pentest provider's performance. It's important to understand that SLAs do not define how the service is provided or delivered but rather focus on service standards. A good SLA is important because it sets clear boundaries and expectations between a customer and a provider. An SLA ensures services are delivered as expected and reduces the chances of disappointment. In the context of a pentest, some of the things you may want to include in your SLA are the testing methodologies that will be used, what infrastructure components will be tested when the testing will occur, the objective of the test and what will be included in the report. 

SLAs should be customized to your organization's needs and reflect the amount of sensitive data that could be exposed in a cyber attack. If your application(s) collects sensitive or confidential data, there should be an evaluation to see what realistic and suitable timelines are for your team. In addition to the testing itself, SLAs are important for setting the guidelines and priority for the dev team regarding remediated vulnerabilities to meet customer expectations. Overall, SLAs are the customers' chance to ensure the service meets their expectations.

Implementing SLAs

When implementing an SLA, it can be useful to use generic templates, but they will need to be customized based on your organization's specific needs. For example, the standard SLA timelines will not fit everyone, and it is crucial to set SLAs based on your particular situation​. The following specific information must be defined in your organization's Service Level Agreement (SLA):

• What needs to be done in any security-relevant situation;
• How often, by whom, by when; and
• An effective way to track your organization’s compliance with its own security policies.

It would be best if you had specific internal SLAs for addressing vulnerabilities discovered during scanning or pen-testing activities. These should be assigned a severity level appropriate to the type of vulnerabilities that it addresses. These could vary based on the risk potential of the specific target or the context around the vulnerability. 

Your SLA should mandate that known open security issues and/or defects should be tracked in a common database or issue-tracking system. This database should be regularly maintained and audited by a security leader. Any collection of issues approaching or expiring the SLA date should be discussed among management, security focals, and development to ensure that nothing is forgotten or overlooked. Regularly scheduled meetings with stakeholders could be an ideal way to discuss issues together.

How to meet SLAs

1. Set realistic expectations and SLAs

The first step to meeting your SLAs is to set realistic expectations for delivery. You won’t meet your  SLAs if there is no process for determining specific SLA-related numbers. These numbers need to take into account your IT and business context. Once you have quantified what it takes to meet your SLA’s goals, you can devise a process for meeting those targets. During the expectation setting, you should consider client and compliance requirements, not just your business requirements. 

2. Set different SLAs for different projects

Depending on the application (web/mobile, desktop, cloud etc), there may need to be different SLAs based on the context of the application. Some may have more sensitive requirements than others, which needs to be considered when defining your SLAs. Each project should be looked at on an individual basis to create SLA requirements that make sense based on that situation.

3. Make SLA internal work trackable

The only way you can be sure that you are meeting the requirements of your SLA is to have data on your performance. You should ensure you are tracking data from your team when meeting SLAs. For example, for each vulnerability found during a penetration test, track how long it took to remediate the vulnerabilities compared to your SLA’s expectations. If you can measure metrics surrounding SLA timelines, you will better understand where your team is succeeding and meeting SLA timelines and when they are not. A common method for this is to assign a timeline for remediation for each severity of vulnerability, such as 180 days for lows, 90 days for medium, 30 for high, 15 for critical etc. This way you can ensure that all vulnerabilities are being remediated in a timely manner and the criteria for success/failure is clear.

4. Regularly audit and review SLA timelines

Businesses and their environments are dynamic, things are always changing, and your SLAs should reflect continuous work and improvement. By reviewing and auditing regularly, you can change things that are not working for your team. You can also evaluate what is going well, how you succeeded, and how this can be implemented across the business.  

Conclusion

An SLA stands for service level agreement, and it is simply a documented agreement between a service provider and a customer that outlines the services required and the expectations around them. To meet an SLA, it's important for companies to have quantifiable expectations and to track your organization's ability to meet these expectations. SLAs are important because they ensure that service providers meet customer expectations. Some tips to help service providers meet SLAs include designing achievable SLAs, communicating SLAs to employees, and monitoring SLA compliance. Software secured offers its own vulnerability management portal to all clients that allow you to customize your SLAs based on each project's unique requirements. This helps us to ensure that all our clients are satisfied with the work that we provide and meet their own internal deadlines around vulnerability remediation.