5 Contract Requirements to Protect Product Design Data
This is part 4 of a 4-part series called Breaking the Barrier to SaaS Implementation. This blog series explores best practices in vetting SaaS vendors to ensure data protection and streamlined workflows throughout product design, manufacturing, and lifecycle support.
Even after understanding how to properly understand cloud risks and assess a potential software as a service (SaaS) provider, manufacturing organizations need to include certain requirements in their contracts with their provider. Contracts outline legally enforceable obligations between two parties and provide potential recourse if something goes wrong.
As you work through contracts, hopefully it’s obvious that your legal team will be involved. I am not in a position to provide legal advice and to try to provide a comprehensive list of security-related requirements would be both impossible and inaccurate since every organization has different requirements. All that said, the following list of contractual requirements should be fairly common across manufacturers.
1. DATA ENCRYPTION
Any reasonable SaaS provider should encrypt data in transit and at rest using current encryption specifications appropriate for your organization, including algorithm, methodology, and key length. Current standards and advice can be found on the NIST (US Department of Commerce National Institute of Standards and Technology) website.
In reality, your organization likely already has an encryption standard identified. That standard would be applied to any SaaS provider with your intellectual property. Encryption requirements also shouldn’t stop at the SaaS solution; any confidential organizational data stored or processed by the provider, whether it’s in the “solution” or in other provider systems, should be encrypted as well.
2. NEED-TO-KNOW AND SEGREGATION OF DUTIES
Reasonable SaaS providers provide a confidentiality provision within their agreement that follows a need-to-know (those of us in the security world like to say “least privilege” but let’s use need-to-know here) framework. Essentially, this model means that the disclosure of confidential information, including product design data, is limited to people within the organization that need access to the data to perform services. Even if an employee or contractor works on the software, platform, or infrastructure, data access should be extremely limited – and should be limited by agreement. Overall, this provides better system stability and security.
Organizations should also have built-in segregation of duties between different development teams. This means that no single employee at an organization can develop, test, or review updates; go through appropriate change management approval; and officially make the change. Both need-to-know and segregation of duties provides a strong layer of confidentiality and operational security within the SaaS organization.
3. THREAT AND VULNERABILITY MANAGEMENT
One of the basic tenets of information security is discovering and monitoring the threats and vulnerabilities that might impact you and ensuring that the resulting risks are understood, prioritized, and appropriately mitigated. SaaS providers have to do this to maintain a certain level of security for their solution. Ensuring via contract that a program is in place to mitigate risk to your data and organization by continuously updating the SaaS solution you’ve chosen is important for continued protection over time.
4. DATA RECOVERY AND PROTECTION
Another area to address within a contract is data recovery and protection, especially related to a force majeure event. A force majeure event is essentially something that happens by chance and is considered unavoidable. In the event of a catastrophe or other problem, SaaS providers should take advantage of the redundant capabilities of their underlying infrastructure or platform to maintain optimum data security and recovery. For the purposes of this blog, I will assume that the SaaS offering you’re looking at leverages a reputable and reliable cloud provider such as Amazon Web Services or Microsoft Azure. These solutions provide readily available features to ensure that data is available in the event of system issues or other major problems that can potentially cause a disruption in service.
It almost seems irrelevant to put here, because one of the main benefits related to SaaS solutions is the promise of system resiliency and reliability. It’s important to understand that capabilities such as resiliency and reliability are not automatic. SaaS providers have to build them into their solution. Hence, these are important elements to include in your agreement with your provider.
5. INCIDENT RESPONSE
I’ve mentioned in a previous blog that no organization can ever be 100 percent risk-free, but how an organization approaches incidents can separate a responsible response from disastrous results. Your SaaS provider should have a clearly defined incident response process that is exercised on a regular basis. Contractually requiring such a process helps to ensure that the provider has done the upfront work to plan for an incident. This is important because organizations that plan for incidents and test their plans generally respond to incidents faster and manage the event with less business impact. You should also ensure that the provider notifies you of incidents and includes you in the management of the event as appropriate.
THE CLOUD PROVIDES GREATER SECURITY BENEFITS
Data security within the right SaaS environment is indeed better than many organizations can provide for their self-hosted data, allowing manufacturers to take advantage of the other benefits of cloud-based computing. The positive impact on revenue, workflows, and data security is unmistakable.
The adoption of SaaS solutions for the majority of competitive manufacturers is underway. With security as one of the most visible advantages of SaaS to the customer, I hope to see more organizations take the leap in implementing SaaS solutions and recognizing the true value of cloud-based solutions.