Voice Bot - Secure Data Variable

HI Team,

When using secure call flow along with bot flow, must we use secure variable in bot flow for sensitive data to meet compliance?

Before voice bot flow comes along, we have been using secure call flow to collect sensitive data to run data actions without additional encryption (which came out this year).

  1. Since recording do not happen within secure call, any "Flow." variables are not stored/saved/logged on the platform as long as we don't set them as participant data/external tag. Can you please confirm if this is accurate?

  2. Now that we have voice bot which is PCI-DSS compliant, does "Slot." behaves the same way as "Flow."? We are not going to use any intent (the main purpose of this bot flow is for 'Ask for Slot' action), so there is no "utterances history" displayed within the bot flow to expose the collect information via speech. However, we are not sure if "Slot." is exposed/logged on the backend of the platform, given that it's essentially speech utterances. Can you please confirm?

  3. With secure data variable in bot flow, we cannot do any advanced data validation other than without extracting the data variable into another variable. If we extract it then it seems to defeat the purpose of securing it in the first place. Is secure data variable is designed to 'mask' the utterances only? So if this is true, this leads back to question no.2 above - whether the utterances for 'Ask for Slot' without "Intent" setup are being captured in plain text on the platform.

Our current design is to send the call from inbound call flow > Secure call flow > Bot flow > back into Secure call flow. The bot flow is only to collect user's input via 'speech'. The output of the slot will be used for extensive logical checks using "Flow." before we submit it to third party.
This will not work if secured data variable must be used in bot flow as they can't be used as output, and we will not be able to do any data validation in bot flow like what we are doing in Secure call flow today.

Can someone please confirm if the approach in bold above still meet the PCI compliance?

Thanks,
MJ

@Mei_Jane_Lim1

I asked a similar question on the community forum recently, which was answered in the Q&A episode here:

Question, with follow up question also answered:

All slots are outputs, unless you actively remove them from being outputs, making them available in calling flows, so probably not secure unless you mark them as secure which removes them from being an output

Extracting Secure data (according to the answer I got) doesn't log the secure slot value if you are just creating a Boolean and using the secure slot in that check, as in my follow up question in the second link. Only if you actually save the slot as a string variable for example then it is logged.

When asking for slots you do have a built in validation in the ask for slot action which you can do with secure slots, and you can also of course use regex in the slot type to ensure you get the right format as well.
image

Hope that helps

Thanks Anton. Looks like copying the Boolean check from secure call flow into bot flow is the only way to make sure it is PCI compliant.

I do wonder though since Flow. is considered as 'secure' just by it being contained within the same secure call flow, does Slot. only be considered as "secure" by setting it individually within bot flow even though we are calling the bot flow from a secure call flow... Would be great if Genesys can be more specific on how Genesys native bot has been validated as PCI-compliant (eg. calling it from secure flow+ using secure variable, or just calling it from secure flow would suffice).

Hopefully the next video will be posted soon since they mentioned there will be some examples and best practices around this use case.

Cheers,
MJ

I've just confirmed that 'Ask for Slot' without using secure data variable will expose the details in utterances history in API even though the Intent & utterance history are not configured/used on the GUI. In case anyone needs to know.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.