Defining "material" around encryption, access, and storage location is the correct starting point, but it requires further scoping to be enforceable. I'd add a clause specifying the *state* of the data in question. For instance, "any change affecting the encryption, access, or geographic storage location of customer data **at rest or in transit**." This prevents them from arguing that a change to transient processing buffers is exempt.
You also need to tie the definition directly to the notification timeline. A statement like "notification of any material change shall be provided no less than 30 days prior to implementation, with an option for Customer to terminate without penalty" is useless if they can claim the change isn't material. Your proposed definition helps, but I'd explicitly exclude changes that demonstrably *increase* security, like upgrading from AES-256-GCM to AES-256-GCM-SIV, to avoid unnecessary friction over genuine improvements.
— Harper
Good on you for hitting pause. The SSO gating is a red flag for sure. Been down this road with other sales engagement tools.
When you get their questionnaire, push beyond just the subprocessor names. You need to know exactly *what* data classification (e.g., raw text vs. processed audio) each subprocessor touches. I've seen vendors route metadata through one service and the actual content through another, which changes the risk profile completely.
For retention, ask for the specific automated enforcement mechanism, like an S3 lifecycle rule. A policy statement isn't the same as a CloudTrail log proving the deletions actually happen.
spreadsheet ninja
You're spot on about demanding the actual automation proof over policy statements. I've found that asking to see a recent, anonymized CloudTrail event for a lifecycle rule execution can be even more revealing than the rule itself. It confirms the automation is both configured and functional.
That said, pushing for this level of evidence can sometimes stall the process with vendors who are less mature. In those cases, accepting a screen share where they demo the live policy in their cloud console can be a workable compromise to keep things moving, as long as you document the gap.
—HR
Great questions. I'm also trying to figure out vendor security stuff for my team, so I'm learning from this thread too.
Your point about SSO being on the highest plan really stood out to me. It feels like a basic security need, not a luxury add-on. Have you asked them directly if their support or engineering staff can access the raw text? Sometimes the sales team gives a clearer (or scarier) answer than the docs.
When you request that questionnaire, could you share how it goes? I'm curious what kind of evidence they'll actually provide.