The Security Devil Is In The Master Services Agreement’s Details

An old expression, “The Devil is in the Details”, underscores that the most problematic aspect of something is in its details. Nothing is more true from an Information Security perspective when using vendors for data processing services or software. Your company invests time, money, and effort to secure its digital assets, only to weaken your security posture when using vendors. Harnessing underutilized aspects of your Master Services Agreement (MSA) to enhance its Data Protection Amendment (DPA) better manages the risk from vendors as an extension of your company.

It’s All About Trust, Right?

Engaging vendors for processing services or software is a matter of trust. Vendors often do not allow inspection of pre-packaged (ie COTS) software, sometimes citing illegal “reverse engineering” if a customer tries to use inspection tools to identify security vulnerabilities. Customer companies and their vendors have different security policies and standards that both are unwilling to share due to providing too much detail about security postures and potential weaknesses. As a customer is likely purchasing only a subset of a vendor’s offerings, even non-disclosure agreements may be too revealing and broad when it comes to internal security practices. Companies that assess vendors for security rely on security questionnaires that ask about security practices, any breaches, etc., and SOC2 reports to attest to the practices a vendor uses to protect customer data. However, questionnaires are not accurate with more sensitive security questions going unanswered and SOC2 reports (if a company does them) are only a snapshot in time.

Most vendors are genuinely concerned about security and understand the importance of secure interactions via products or services with their customers. But Information Security, like any other aspect of doing business, is a balance between cost, risk, and benefit. And even if a vendor invests significantly in security, their view of the what and how of doing it can differ with each client.

Trust but Verify With a Data Protection Agreement (DPA)

At its essence, the security requirements of clients are not unlike the ongoing expectations for other aspects of work done during a customer/vendor transaction. Enter the Master Service Agreement (MSA). The MSA typically addresses aspects such as intellectual property rights, limits of liability, warranties, standards of work, dispute resolution, termination activities, and confidentiality. The MSA forms the baseline of agreed understandings or actions that underlie the project-focused Statement of Work (SOW). With the MSA, its terms and conditions are agreed and ready to go with each new transaction or project. The MSA becomes the natural choice for extending privacy needs and including data protection requirements.

Simply lumping data protection under the privacy section of a MSA would be a tempting thing to do, but each focuses on different areas that often intersect. Privacy language deals with legal aspects of meeting the requirements of laws and regulations while data protection language should address the policies, standards, and security practices specifically around the data and any supporting systems. For instance, privacy language for HIPAA often identifies BA agreement requirements if vendors process patient data. Data protection language, on the other hand, might identify security controls within HITRUST or types of accepted encryption for securing HIPAA data. Information Security professionals may have knowledge of aspects of privacy, but are not qualified to act as corporate counsel in MSAs. Similarly, privacy attorneys are usually knowledgeable about aspects of information security, but do now know the ins and outs of corporate security policies and standards, data breach practices, or secure coding standards.

Increasingly, corporate privacy counsels include terms and conditions for ensuring HIPAA, GDPR, PCI, California’s CCPA, and other regulations are followed by vendors. In addition, corporate counsel may stipulate the purposes for processing data, conditions for disclosing data, data return or destruction, access by the vendor’s employees, and categories of data collection and use. Each aspect of data privacy language may have a follow-on MSA requirement for data protection.

General DPA Structure

Until the last few years, data protection requirements have been missing from MSAs or only touch on more business-focused aspects of data protection. When present, today’s DPAs often only identify the general methods for handling data, what type of data is handled, how a notifications are made in event of breach, and return/destruction of data at the end of a contract. What commonly is missing are detailed requirements for implementing and maintaining security practices and standards that can in some way be verified and periodically reviewed by the customer or an unbiased third party. These missing areas are basic components of security standards like NIST and ISO27K, and increasingly the basis for liability when companies suffer a breach.

The goal of defining useful and actionable DPA requirements is to be specific about what is expected in security areas without seemingly writing volumes of minute detail that recreate a publicly available security reference. Avoid making broad, sweeping, requirements that are up to interpretation (your corporate and the vendor’s counsel will stop you), such as “follow Microsoft’s Secure Lifecycle Development model” which is not definitively published nor managed by version control like a standard. As the expression goes, “The fine print giveth and taketh away”, you and the vendor will likely negotiate what the final version of the requirements will be.

The Security Devil is in the Details

The details and length of a Data Protection Agreement vary, but should cover the following areas at a minimum. In the end, the data protection requirements should correlate to established and well-defined security foundations like NIST, ISO-27K, OWASP, etc. The requirements should also be relevant to references in the MSA’s data privacy section, such as for GDPR, HIPAA, PCI, etc. Finally, when referencing a single technology or administrative requirement, the it should be as specific as possible:

Key Focus Areas

• Information Security Program – The vendor must define and follow a security program, based on a standard such as NIST 800 series or ISO-27K, including policies and procedures for processing, assessing, and storing the vendor’s software and customer data. In the case of vendor-developed software, follow a methodology that includes identifying vulnerabilities during the development lifecycle. Also require employee security awareness training.

• Risk Management – Establish and maintain practices based on generally recognized frameworks like NIST, ISO-27K, CIS, or COBIT. Execute actions to mitigate risk findings. The DPA might define agreed designations for risk levels (eg low, med, high).

• Data Protection Impact Assessments – The vendor performs assessments on the potential security impact to customer data or software when significant changes are made to vendor infrastructure or procedures (eg network reorganizations). The vendor must act on findings.

• Human Resources Security – Require background checks of vendor or contract employees with access to customer data or software used by the customer. A vendor will likely resist, but if possible, require periodic rechecks in case of status changes. Require HR to notify identity management and access groups to remove user accounts at user termination.

• Data Security Incidents – This requirement is not to micro manage every security incident but to be aware of significant issues that may affect vendor integrity. If language references “breach” instead of “incidents” you might miss a significant risk to customer data or the vendor’s infrastructure due to breaches having different definitions and required actions by locality. Be sure to specify the maximum time before the customer is informed of an incident, and to inform the customer of public communications due to a breach ahead of release (allowing the customer time to plan their own response). Require that information about the incident, similar to a summary provided to the vendor’s executives, be provided.

• Software Development and Test Environments – Require that any customer data be maintained separately and possibly removed from environments or deleted altogether when not in use after a specified period of time. Require separation of development, test, staging, and production environments. Require identity and role-based access to environments.

• Annual Security Assessment – This requirement assists in determining whether a vendor is following the above requirements for a security program. It can specify an annual SOC2 report, results from a vendor’s internal audit, or answering a customer’s security questionnaire.

• Audit and Security Testing – Language should be included, especially following a significant incident, that the customer can request a limited audit or penetration test to demonstrate that a vendor is executing security practices and programs. It is unlikely that a vendor will pay for these activities, unless an incident/breach or other question of their security stance happens. Instead of an audit, language could identify an agreed third party for a limited review.

The following additional requirements touch on other considerations and are often found in an MSA when a DPA is used. They are components that are part of an established program (mentioned above):

Additional Focus

• Asset Management – Specify how items like laptops or access to resources are used in relation to custom-affected data or software.

• Access Controls – Require that individuals and accounts be limited, monitored, routinely managed for sensitive data or software of the customer. This can include password complexity and rotation requirements.

• Operations Security – Require that resources used to provide services or products to the customer be regularly maintained with security patching, updates, and replacement/upgrades.

• Backup and Restoration of Customer Data – With industry stats of 60% of backups incomplete and an average of 50% failure rate for restores, specify that vendors processing your data not only backup and test recoveries regularly, but provide reports regarding success/failures.

Will a DPA Prevent Security Issues?

Whether the terms of a contract are executed, and to each parties satisfaction, depends on how well the requirements are defined and how much each side holds to the agreed contract. Some say that contracts cannot ensure anything, but are a recourse for settling disputes when not honored.

Where design requirements, or even Statements Of Work (SOW), are signed and agreed to as blueprints to deliverables, they are often not closely followed without substantial issues. However, the MSA, and the DPA within it, are different. If well written, their terms and their violation are clear, forming the basis for closely following them or risking liability due to breach of contract. A DPA won’t prevent issues, but is at least progress to make whatever security is specified binding.

What is Your Risk Appetite?

In the case of Information Security, there are not a lot of tools at a company’s disposal to ensure that a vendor will process their software safely or provide software tools that are secure. Companies, even partners, routinely do not share their internal documents, especially those that are security based. News of security issues or even breaches of vendors become lost when the next company makes the news. Leveraging the legally binding capabilities of a DPA for security assurance can be an important tool in security’s risk management toolbox.

And if a vendor doesn’t agree to security clauses increasingly seen in contracts and considered a security norm? They are shifting the “buyer beware” risk to you. At that point, what is your risk tolerance?