As a cloud service provider, it's important to be transparent about any third-parties that may have access to customers' personal or sensitive data. The Disclosure of Data Sub-processors control from the CSA Cloud Controls Matrix outlines the need to notify data owners about sub-processors that will access their data, prior to that access occurring. By implementing proper processes and controls around sub-processor data access, CSPs can build trust with their customers.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full CCM here: https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4

The CCM provides a comprehensive set of cloud-specific security controls, mapped to leading standards, best practices, and regulations. It's considered an essential resource for organizations assessing cloud security.

Who should care?

This control is particularly relevant for:

• CSP compliance officers responsible for adhering to data privacy regulations
• CSP vendor managers who oversee relationships with sub-processors
• Enterprise security leads evaluating potential CSPs and their data handling practices
• Data protection officers (DPOs) ensuring proper governance of personal data

What is the risk?

The main risk that the Disclosure of Data Sub-processors control addresses is unauthorized access to sensitive data by third-parties. Without proper notification and controls, sub-processors could potentially access customer data without the data owner's knowledge or consent. This could lead to:

• Compliance violations with regulations like GDPR
• Reputational damage if a data breach were to occur
• Loss of customer trust

While the likelihood of unauthorized sub-processor access may be low, the consequences could be severe - making this an important area to address.

What's the care factor?

For organizations dealing with personal data or operating in heavily regulated industries, the care factor for this control should be high. Customers are increasingly aware of how their data is being handled, and expect transparency from their CSPs.

Failure to disclose and control sub-processor access could result in damaged customer relationships and potential regulatory fines. CSPs targeting enterprise and government sectors will likely face strict third-party risk management requirements.

However, for CSPs dealing primarily with non-sensitive data and operating in less-regulated spaces, the care factor may be lower. The effort of implementing this control needs to be balanced against the realistic risk profile.

When is it relevant?

The Disclosure of Data Sub-processors control is relevant any time a CSP engages third-parties that may have access to customer data. Common examples would be:

• Using an outsourced customer support provider who can view customer records
• Leveraging a third-party data center for infrastructure hosting
• Engaging an external security monitoring service

This control is less relevant for CSPs that fully manage all aspects of their service in-house, without engaging sub-processors. Although, this is increasingly rare in today's specialized cloud supply chain.

What are the trade offs?

Implementing proper sub-processor disclosure and controls does come with some costs and trade-offs:

• Developing processes, documentation, and technical measures takes time and effort
• Pushing notification and control requirements to sub-processors may limit selection or increase costs
• Customers may be uncomfortable with sub-processor arrangements, requiring additional reassurance
• Over-notification could desensitize customers to important sub-processor communications

CSPs need to strike the right balance - instituting proper third-party governance without excessively burdening their business. Scoping controls to the risk profile is key.

How to make it happen?

Here's a step-by-step guide for implementing the Disclosure of Data Sub-processors control:

1. Identify all sub-processors across the organization and catalog key details:
   • Company name and location
   • Services provided and data accessed
   • Contract terms and SLAs
2. Develop a customer-facing sub-processor disclosure:
   • List of active sub-processors with company details
   • Categories of data accessed and processing performed
   • Mechanism for customers to subscribe to change notifications
3. Integrate the disclosure into key customer touch points:
   • Product documentation / trust portal
   • Pre-sales materials and contracts
   • Ongoing customer communications
4. Develop an internal process for sub-processor onboarding and offboarding:
   • Security and privacy review criteria
   • Contract language requiring disclosure and control support
   • SLAs for notification of changes to sub-processors
5. Implement change management workflows:
   • Track changes to sub-processor arrangements
   • Notify relevant internal stakeholders
   • Notify impacted customers per agreed SLAs
6. Institute ongoing vendor management:
   • Review sub-processor performance to contract and SLAs
   • Assess evolving risk profile and institute new controls as needed
   • Regularly re-evaluate disclosure and control processes

With these processes, documentation, and technical measures in place - a CSP can more easily meet the Disclosure of Data Sub-processors control expectations.

What are some gotchas?

A few potential challenges to watch out for when implementing this control:

• Lack of centralized procurement leading to "shadow" sub-processors without proper vetting
• Sub-processor contracts that don't include provisions to support disclosure and control requirements
• Immature change management processes leading to breakdowns in customer notifications
• Pushback from sub-processors on flow-down disclosure and control obligations
• Customers requesting bespoke agreements for sub-processor disclosure exceeding the baseline

There aren't many specific permissions or access rights implicated in implementing this control. It's more about instituting proper policies, processes, and contractual arrangements. However, to support some of the technical change tracking and notification mechanisms, relevant staff may need access to:

• Contract management systems with admin-level rights
• Procurement systems to view / modify sub-processor details
• Customer communications systems like CRM to issue notifications
• Vendor risk assessment results to make informed sub-processor decisions

What are the alternatives?

The Disclosure of Data Sub-processors control is fairly unique in its focus on transparency, SLAs, and customer notifications specific to sub-processor data access. However, there are some related controls and processes that support similar risk mitigation:

• Third-party risk management (TPRM) - Assessing and controlling risks from external entities
• Data processing agreements (DPAs) - Contractual terms governing third-party data handling
• Privacy impact assessments (PIAs) - Analyzing projects for privacy risks, including third-party access

While these other processes support the spirit of the control, they don't replace the need for formal disclosure and notification measures to keep customers informed about sub-processors.

Explore further

For more information and guidance on implementing the Disclosure of Data Sub-processors control, check out:

• CSA Cloud Controls Matrix (CCM) - https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4/
• GDPR Subprocessor guidance - https://gdpr.eu/data-processing-agreement/
• CIS Controls V8 #15 Service Provider Management - https://www.cisecurity.org/controls/service-provider-management

This control maps closely to the CIS Controls V8 "Service Provider Management" controls, focused on implementing processes, procedures, and technical measures to ensure security and privacy requirements are met by third-parties.

‍