Episode 43 — Build vendor due diligence questions that expose real privacy control maturity
In this episode, we’re going to focus on something that sounds simple but turns out to be one of the most powerful skills in privacy management: asking the right questions. Most vendor reviews fail for a predictable reason. The questions are either too generic, like asking if the vendor follows best practices, or too narrow, like asking for a policy document and assuming that means the practice exists. Real privacy risk lives in the messy space between what a vendor says on paper and what actually happens when people, systems, and deadlines collide. So the goal today is to learn how to build due diligence questions that expose real privacy control maturity, not just marketing confidence. You will learn how to write questions that force specificity, reveal how controls operate day to day, and make it harder for a vendor to hide behind vague statements. When you get good at this, you not only reduce risk, you also save time, because you stop chasing noise and start collecting evidence that actually predicts outcomes.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
To start, it helps to understand what control maturity means in plain language. A control is something that reduces risk, like access restrictions, incident response, deletion procedures, or training. Maturity is about how reliable that control is when tested by real life. A low-maturity control often exists as a statement, a policy, or a good intention, but it depends on luck and individual effort. A medium-maturity control is implemented in a consistent way, but it might not be measured, tested, or improved. A high-maturity control is designed into the process, monitored, tested, and adjusted when it fails. When you write due diligence questions, you want to identify which level you are dealing with, because that tells you how much you can trust the vendor to perform under pressure. Maturity is not a moral judgment, it is a reliability estimate, and privacy management is full of situations where reliability is the difference between a normal week and a reportable incident.
A great way to expose maturity is to avoid yes-or-no questions whenever possible. If you ask, do you encrypt data, the vendor can say yes and still be talking about only one part of the system. If you ask, do you have an incident response plan, they can say yes and still have never practiced it. Better questions demand context, scope, and proof. For example, instead of asking whether encryption exists, you can ask where encryption is used, what data is covered, and what happens when data moves between systems. Instead of asking whether they support deletion, you can ask how deletion works across primary storage, logs, analytics, and backups, and what evidence is produced when deletion is completed. When a vendor is mature, they can answer these questions clearly because they have operational clarity. When a vendor is immature, the answers tend to be vague, inconsistent, or dependent on manual effort that no one can guarantee.
One of the most useful patterns for writing questions is to anchor them to a lifecycle. Privacy risk is a lifecycle problem: data is collected, used, stored, shared, and disposed of, and each stage has different controls. So you can build question sets that follow the data through time. At intake, you ask what data fields are required and optional, and whether data minimization is enforced by design. During use, you ask how access is granted, reviewed, and revoked, and how the vendor prevents employees from viewing data unnecessarily. During storage, you ask about segregation, encryption, monitoring, and how they prevent test environments from becoming dumping grounds for production data. During sharing, you ask about subprocessors, onward transfers, and what controls are flowed down. During disposal, you ask how deletion is triggered, verified, and completed across all copies. This lifecycle approach prevents you from missing hidden processing, because the vendor has to explain what happens at each step rather than hiding behind general claims.
Another pattern that exposes maturity is asking questions that force the vendor to describe how they handle exceptions. Low-maturity programs often work only when everything is normal, but privacy incidents happen during weird moments: an outage, an urgent support request, a new feature release, or an employee leaving unexpectedly. So instead of only asking about the standard process, ask about the process when something goes wrong. How do they provide support without exposing live data, and what approvals are required for elevated access. What happens when an individual exercises a right and the vendor’s system cannot easily isolate their data. What happens when a subprocessor has an incident and the vendor needs to notify you. What happens when a customer demands deletion but there is a legal hold or a dispute. A mature vendor can describe exception handling because they have already encountered it, documented it, and improved their process. An immature vendor tends to answer with optimism rather than procedure, and optimism is not a control.
You should also design questions that separate documentation from evidence. Documentation is useful, but evidence is what proves the control works. A vendor can have a policy that says access is restricted, but evidence might be access logs, role definitions, quarterly access reviews, and records of revocation when people change roles. A vendor can have a breach response document, but evidence might be tabletop exercises, post-incident reviews, and a clear notification timeline with examples. A vendor can claim training exists, but evidence might be completion tracking, role-based training for higher-risk teams, and consequences for non-completion. Your questions should ask for the minimum evidence needed to trust the claim. You do not need to drown in paperwork, but you do need at least one artifact that indicates the control is operational, monitored, and enforced. The more sensitive the data and the higher the access level, the more evidence you should request.
A common mistake is asking vendors to answer complex questionnaires without making them specific to the relationship. If you ask a vendor about every possible privacy topic, you get generic answers that reveal nothing, and you exhaust both sides. Instead, build a question set that reflects the service type, access level, and processing activities, because those factors predict what matters most. If the vendor stores personal data at scale, focus questions on storage controls, retention, deletion, and incident response. If the vendor has privileged support access, focus questions on access governance, logging, monitoring, and how emergency access is controlled. If the vendor uses data for analytics or improvement, focus questions on purpose limitation, data segregation, de-identification, and prevention of secondary use. If the vendor uses subprocessors, focus questions on subprocessor approval, flow-down obligations, and how they monitor subprocessor performance. Tailoring questions is not being picky, it is being accurate.
It also helps to write questions that reveal whether privacy is integrated with security and operations, because privacy controls usually depend on those functions. For example, access control is often implemented through identity management, logging depends on security monitoring, and deletion depends on data architecture. So you can ask who owns key controls, how privacy requirements are communicated internally, and how changes are approved. Ask whether privacy reviews are part of product change management, and what triggers a privacy impact assessment. Ask how engineering, support, and legal coordinate when an incident happens. A mature vendor will describe a connected system of responsibilities, not a single privacy person trying to patch everything manually. When privacy is isolated, it becomes a paperwork function that cannot influence real behavior. When privacy is integrated, it becomes part of how work gets done, which is what maturity looks like.
Another maturity signal is how the vendor talks about metrics and monitoring. Immature programs often measure nothing, so they cannot detect drift or failures. Mature programs track things like how quickly access requests are processed, how often access is reviewed, how long logs are retained, how quickly incidents are escalated, and whether deletion requests are completed on time. You do not need the vendor to share every metric, but you can ask what they monitor and what thresholds trigger investigation. You can also ask how they validate that controls work, such as internal audits, penetration testing by independent parties, or periodic control testing. Be careful not to treat certifications or reports as magic proof, because they are snapshots and not guarantees. Still, a vendor that can explain how they test and improve controls is showing you that the program is alive. Privacy maturity is a moving target, and living programs behave differently than static ones.
Because cross-border access and transfer constraints matter so often, your questions should also expose geographic reality, not just corporate location. Ask where data is stored by default and what options exist to restrict hosting. Ask where support personnel are located and whether they can access production data from outside the desired region. Ask whether logs, backups, and analytics are processed in the same region as primary data, and what disaster recovery does to data location during an emergency. Ask how subprocessors affect data location and whether new subprocessors can be added without notice. Mature vendors usually have a clear data residency story, with defined regions and documented controls. Immature vendors often answer with vague statements like we use global infrastructure, which is a red flag when you have transfer constraints. The point is not to ban global operations, but to understand them well enough to choose lawful mechanisms and align expectations.
You should also include questions that reveal how the vendor supports your organization’s obligations to individuals, because that is where vendor relationships can quietly break compliance. Ask how the vendor helps you respond to access, correction, deletion, and restriction requests, including timelines and the format of responses. Ask whether the vendor can locate an individual’s data reliably and whether identifiers can be mapped across systems. Ask how the vendor handles requests when data is mixed with other customers’ data, which is common in multi-tenant services. Ask how the vendor avoids collecting more data than necessary during support interactions, such as when a user submits screenshots or free-text complaints. Ask whether the vendor has procedures for handling children’s data or other sensitive categories if that is relevant. A mature vendor has built capabilities for rights support into the service, rather than treating rights requests as unusual emergencies. Rights support is not just a legal feature, it is an operational capability, and your questions should test whether it is real.
At this point, you might be wondering how to keep your question set from becoming huge. The answer is to prioritize questions that create branching clarity. A good due diligence question is one where the answer tells you what to ask next, or tells you that no further questions are needed in that area. For example, if the vendor states they never access content because everything is encrypted with keys controlled by your organization, then many access questions become less urgent, but you must ask how support works without access. If the vendor states they retain backups for ninety days and cannot delete from backups earlier, then retention and deletion risk becomes clear, and you can decide if that is acceptable. If the vendor states they add subprocessors without customer approval, then you know you need stronger contract terms or a different vendor. These are revealing questions because they make tradeoffs visible. Privacy management is often about tradeoffs, but tradeoffs must be explicit to be managed.
To bring this together, strong vendor due diligence questions do three things at once: they demand specificity, they map to operational reality, and they produce evidence. They are designed around the data lifecycle, tested against exceptions, and tailored to the vendor’s service type, access level, and processing activities. They separate policy from practice by asking for artifacts that demonstrate controls are real, monitored, and enforced. They also surface the tricky areas that cause surprises later, like subprocessors, cross-border access, derived data, retention in backups, and support workflows that pull in unnecessary personal information. When you build questions this way, you are not trying to catch the vendor in a gotcha moment. You are trying to make the relationship predictable and safe for the people whose data is involved. That is what privacy control maturity really means: not perfection, but dependable behavior you can understand, verify, and hold accountable.
