How are you addressing Nth-party risks arising from AI adoption, especially given the extent to which AI providers depend on data subprocessors?
Sort by:
I wish I had a great answer for this. The challenge is that it’s difficult enough to track third-party risks, let alone the risks from their subprocessors—essentially, third, fourth, and Nth parties. The tool we use for tracking third parties doesn’t support adding their subprocessors, and there really aren’t any tools that do. Even if there were, I’m not sure how I would manage it. The only way I sleep at night is by ensuring our security requirements always roll down to our vendors’ third parties. Our hope is that those vendors treat the security requirements for their vendors as seriously as we do.
One thing I keep telling technology vendors is that security must be the default. You can’t just turn on AI in your tool by default; it should be a choice. AI should not be enabled automatically. I want the opportunity to understand and decide for myself if I want to enable it in a tool. That’s been my focus—making sure AI features are not turned on without explicit approval.
I completely agree with you. What we’re trying to do this year is to turn on fourth-party monitoring in BitSight. We’re not expecting total clarity from this, but at least it gives us some visibility into who our vendors are using. For example, if a vendor that’s supposed to be HIPAA-secure is suddenly sending data to a large language model in China, that’s a red flag. BitSight won’t be 100% accurate, but it allows us to have more proactive conversations with our vendors. <br><br>Being a Healthcare Provider, another control we had and improved was our Business Associate Agreement (BAA). We changed our BAA pre-COVID so that any vendor who receives our data must sign a transitive BAA. This means our vendors are responsible for ensuring their subcontractors comply as well. If they want our data, they must take on the risk for any subcontractors they share it with. This approach has helped keep vendors accountable.
For GDPR, we also rely on roll-down provisioning. We include language in our vendor agreements requiring that GDPR compliance and expectations are extended to any contractors accessing our data. If a vendor fails to do this, it constitutes a contract breach. However, depending on the size of the vendor, enforcing those provisions can be challenging.