3 steps to understand vendor data protection and retention measures
Your supply chain data governance toolkit.
How are you protecting my data?
This is a key question for anyone you are (considering) giving it to. Which is why I previously put out a guide to evaluating AI processing and training in your supply chain.
When I posted it on LinkedIn, folks had some great suggestions for what to add, but most of them were not AI-specific. That’s why I put together this document. It goes hand-in-hand with the AI processing checklist to give you a deeper view of data protection and retention by your vendors.
This is not by itself a security questionnaire, which I generally loathe. But it can form part of one, if you absolutely must send one. And it is narrowly scoped:
This document is focused primarily on data confidentiality measures. Incorporating integrity and availability considerations would make this basically the description of an entire third-party risk management program.
It doesn’t cover:
attestations or certifications
regulatory compliance
security awareness
background checks
or anything not directly tied to technical data protection measures.
1. (Internal question) What types and classifications of data does this vendor process?
If only Public data:
Are we sure?
If so, then stop here, but this is rare considering third parties almost always retain and process email addresses, employe names, etc. These constitute Personal Data according to the European Union (EU) General Data Protection Regulation (GDPR).
If anything other than Public data:
Proceed to step 2.
2. For each type of data we give you, provide:
Encryption methods protecting it:
In transit
At rest
In use (i.e. via homomorphic encryption)
Instructions for how we can encrypt the data with our own keys, if applicable.
All situations when data is not encrypted, for example:
When an employee is viewing it on his/her workstation, and which types, e.g.:
customer support personnel assigned to our account
any full-time employee
summer interns
When our S3 bucket containing it is accidentally exposed to the open internet (kind of kidding…but not really).
For all third and greater parties with access to our unencrypted data, the text of all agreements with these parties concerning:
Confidentiality
Data processing/protection
Intellectual property assignment
Your data retention practices, including:
Length of time you retain data.
Whether we can request shorter retention periods globally or specifically in certain situations, and what the consequences of shorter retention periods will be.
How the data is deleted, for example:
Manually
Via a custom-built Google Apps Script
Using a built-in feature of Microsoft OneDrive
Confirmation that deletion includes all backup and archiving tools, and any exceptions, such as emails.
Methods by which we can verify data deletion, such as audit trails.
All legal jurisdictions where you store our data, in any form.
Your process for notifying us of non-conformance with the above, including:
Timelines for notification
Criteria for notifying customers
Remedial actions and incident response
Confirmation you will inform us within 10 days of any changes to these data security practices.
3. How is this information provided?
The process of getting this information alone will tell you a lot about a company’s security posture. You can evaluate their transparency and seriousness when it comes to data security using the below rough heuristics:
Terrible
“We don’t disclose our security practices in order to protect our customers.”
Security through obscurity has extremely limited value, and any indication your counterparty is relying on it should be a major red flag.
Okay
“Request details through a support ticket or via a security questionnaire.”
If they need to manually dig through a lot of internal documentation to get this data, it suggests they aren’t very well organized. Additionally, if this information isn’t easily available, that suggests employee awareness of these practices will be low.
Compliance with them will also likely to be spotty.
Good
“Check our trust center! Additionally, our contractual language refers to and binds us to these measures.”
It’s difficult to see a good reason why most of the above (and a lot more) information needs to be kept private. That’s why proactively publishing it is generally good for everyone. StackAware partners with SafeBase to power its trust and security center.
Amazing
“All of this information is available in a machine-readable format through our SBOM.”
In addition to publishing information about data security measures, doing it via a standardized format like the CycloneDX Software Bill of Material (SBOM) would represent the gold standard. Unfortunately, even CycloneDX doesn’t have dedicated fields for representing all of the things mentioned, so you would need to use custom properties
to depict some of them. Thus, StackAware doesn’t yet do all of this in our SBOM.
We will work with the CycloneDX team to get as many as possible integrated into version 1.7 of the standard.
Managing data security risk in your supply chain
As companies accelerate their rollout of new AI tools and technologies, tracking and securing all of the relevant data flows will be vital. Combined with the StackAware AI training checklist, this guide can help illuminate them and any relevant risks.
Need help building your AI and data governance program?