ISACA Now Blog

Knowledge & Insights > ISACA Now > Posts > Clouds, Codebases and Contracts – How the New Era of Privacy is Changing Third-Party Risk

Clouds, Codebases and Contracts – How the New Era of Privacy is Changing Third-Party Risk

Alex Bermudez | CIPP/E, CIPM, Privacy Solutions Consulting Manager, Atlanta, GA, USA
| Posted at 3:08 PM by ISACA News | Category: Privacy | Permalink | Email this Post | Comments (2)

Alex BermudezThe last two years have taught us that conventional wisdom and knowledge around privacy and security needs a makeover, in particular as it relates to the EU’s GDPR and the California Consumer Privacy Act. Data controllers and businesses, the entities responsible for what happens to personal data under GDPR and CCPA, respectively, are subject to new obligations that place significant organizational risk squarely on their shoulders. Though compliance issues can come from many places, one often-overlooked impact is managing processor/third-party risk.

Third parties (aka processors in the GDPR or information recipients in California law) are critical to organizational operations, from cloud hosting to payroll administration and processing. They hold customer, partner, employee, and confidential data that is the lifeblood of organizations, and we can’t run without them. While many third parties strive to be good stewards of their customers’ data, we find ourselves in a time where trust and good-faith efforts aren’t going to pass muster anymore.

Under the GDPR, CCPA, and other regulations, controllers need to hold their vendors contractually responsible in regards to specific obligations for how data is handled through data processing agreements and other measures, and as always, “trust but verify” that the vendor is acting accordingly. By extension, this includes our vendors’ partners as well, when fourth parties are involved.

Along with contractual measures, controllers need to assess, test and review a vendor’s ability to adequately safeguard the data they are transferring through product, personnel, and organizational protection mechanisms. This also requires that they pass the same data protection expectations downstream.

All of this due diligence should, at all times, be centrally documented and maintained. In the event of an incident or breach, controllers must be able to demonstrate a reasonable and defensible process for vetting third parties, including providing results of their assessments of vendors' practices and commitments to data protection, to help mitigate risks of liability. This also includes identifying potential risks of doing business with a particular vendor, taking actions to mitigate those risks, and continually managing vendors based on the scope and sensitivity of the data they process.

Now, chances are your organization has already taken steps to ensure proper actions are taken. For organizations looking for continual process improvement (CPI) and formal action plans, here’s a sample Vendor Risk Management lifecycle to consider:

This lifecycle is a roadmap to operational Vendor Risk Management that includes:

  1. Establishing a baseline for new vendors to benchmark associated risks (done during the evaluation and procurement process);
  2. Mitigating risk down to the lowest possible level and using that analysis to set a cadence for vendor review frequency;
  3. Documenting all aspects of vendor due diligence, including services agreements, privacy and security risk analysis, data processing agreements, vendor contacts, and internal owners; and
  4. Reviewing all vendors periodically to ensure agreements and relationships are maintained with appropriate controls in place, including based on regulatory guidance, as renewals or new services may be rendered.

Organizations should also incorporate privacy/security by design into vendor onboarding practices by integrating with procurements processes to take advantage of work being done today. This could include an early screening to determine if further privacy and security due diligence will be required – based on what services are being rendered – and how they’re delivered.

Editor’s note: For more resources related to GDPR, visit www.isaca.org/gdpr.

Comments

Establishing a baseline

Hi Alex,

Thanks for your views and experience. To establish a baseline  for adequately safeguarding data I have seen companies use ISO27001 and I have seen COBIT 4.1 being used. Perhaps the strongest solution would be to combine both. Do you know of a source that integrates the ISO27001 framework and COBIT?

Kind regards,

Michael
Michael at 10/12/2018 2:11 AM

Estabishing a baseline

Hi everybody,
Establishing a baseline is not easy. Moreover when, according to GDOR, the security level should be aligned with the risk analysis done by the data owner (i.e., each dataset have a different baseline).
What I start seeing is companies defining different baselines for different levels of risk (low, medium, high) and then ask processors for showing compliance with those different baselines. As this is a one-to-one approach, to make it more efficient, I think that security rating is the only way to solve this issue (understanding rating as the evaluation of the maturity and robustness of security controls implemented by the proccesor).
More detailed information can be found at: http://www.leetsecurity.com/gdpr/ 
(Disclaimer: I am the founder of that company)
Antonio Ramos at 10/14/2018 12:31 PM
You must be logged in and a member to post a comment to this blog.
Email