Salesforce, Inc. (CRM) Earnings Call Transcript & Summary

Welcome to our webinar today, Navigating Australia's Privacy Laws, covering how organizations can navigate a changing regulatory landscape. My name is Belinda Burgess, and I'm the Area Vice President for Platform and Security here at Salesforce in Australia. Before we start today, this presentation contains general information only and should be taken -- not be taken as providing legal advice. All organizations should seek independent legal advice about their own privacy obligations before making any purchasing decisions. Also, a reminder that Salesforce is a publicly traded company and customers should base their purchasing decisions on products and services that are currently available. Before we kick off though, a very big thank you. We know your time is valuable, and we appreciate you taking the time to join us today. Thank you. All right. So let's get started on today's agenda. Today, we will be going through setting the scene with an overview of the global privacy environment, highlighting some of the proposed reforms for the Australian Privacy Act, offering suggestions around what organizations might consider and then, of course, detailing how Salesforce can help. [Operator Instructions] If we don't get to your questions, don't stress. We will make sure that we will get back to you after the webinar. Joining us today will also be Rachel Baker, Corporate Counsel, Privacy. Rachel advises Salesforce on privacy laws in Asia Pacific and is responsible for many global privacy policies and procedures. Also joining us will be distinguished technical architect Mike Burnside. Mike has many years' experience as an architect, adviser and consultant in the IP ecosystem and is a trusted partner to many of our Salesforce Australian and global customers. So to introduce today's topic on privacy in Australia, we have seen that customer attitudes towards privacy are changing. Individuals are becoming more aware of their rights and more interested in protecting their personal information. This has been coupled with a number of high-profile data breaches in Australia. Businesses are also becoming increasingly concerned about their privacy program. They are wanting to minimize the legal and reputational risk of being responsible for a serious breach of privacy. Being seen as pro privacy is also becoming an important way for companies to set themselves apart from their competition. An Australian Community Attitudes to Privacy Survey revealed that almost 1/2 of the respondents suggested that they have been advised by an organization that their personal information has been breached. 3/4 of them had experienced harm as a result, and over 90% of them expected businesses and governments to do more to protect their data. I'm now going to hand over to Rachel Baker, Salesforce's Corporate Counsel for Privacy.

Thanks, Belinda. Hi, everyone. Thanks for being with us. So I'm going to take you through Salesforce's approach to privacy compliance and also our perspective on some of the reforms to the Privacy Act. And then I'll also do a bit of a deep dive and unpack some of the key provisions that are set or proposed to be changed. So Salesforce has really always seen privacy as an opportunity for innovation and growth, and as Belinda pointed out, a chance for us to differentiate ourselves. Because as one of the very early cloud software providers, it's always been important for us to demonstrate to our customers that we can keep their data secure and safe and within their control. In terms of regulation, one of the -- the sort of revolution in privacy law reforms started in Europe in 2018 when the General Data Protection Regulation was passed. And Salesforce just took the decision to build our global systems around that GDPR baseline. So that means that we provide really robust privacy protections for customers and users all over the world, even where local laws don't require them because it's actually -- there are scalability benefits to providing high standards on a global basis rather than on a piecemeal basis. And as we've seen, law reform really spread around the world. And this slide shows some of the key privacy law changes that we've seen in our region. So some of you might have been dealing with now additional obligations required under these laws. And once we had set our systems based on GDPR compliance, for the most part, we're really ready and able to comply with new laws as they're passed. It only requires minor, if any, adjustment. So in terms of how Salesforce has built its privacy program, we really see privacy as a human right. And by foregrounding privacy rights for our customers and our customers' customers, that's part of our philosophy of businesses being a force for good in the world. And so we build privacy protections at the cornerstone of our products and systems rather than as optional add-ons. We encourage stricter privacy laws around the world. We think it's in the best interests of individuals and the community, and we have close relationships with regulators and convey that view to them as well. So in terms of setting up our internal privacy program, it's broken up into 3 functions. So Privacy Compliance is where we look at the obligations required under various privacy laws globally. And then we map those obligations against the use cases that our business wants to participate in. And then we set up global standards and procedures. And this is an important point in terms of scalability. So rather than a business unit or a team coming to Compliance or Legal and asking if a certain function can be lawfully conducted, we kind of set the rules on a broadcast basis, and then only escalations or exceptions to those standards require individual manual review. Strategy and comms study is where we communicate internally with our teams so that they understand what the processes, what the rules are, where they can find the information that they need. And privacy program delivery is where we look for opportunities to develop technological solutions to these privacy challenges. So that involves partnering with Engineering and Technology. So just turning to the Privacy Act. So this legislation was passed in 1988, so it's nearly 40 years old. There are some concerns that the Privacy Act hasn't kept up with changes in the way personal data is collected and processed. I'm sure all of you have experienced, for example, going on to a search engine, searching for a particular product or service and then you see those ads pop up as you move around the Internet. You might see ads popping up in your e-mail service. Similarly, as you travel around using an Internet map service, there's data being collected about where you've been, where you're likely to be going on a certain day at a certain time. So there's a massive proliferation in the collection and processing of data. And this just wasn't the case back in 1988 when the Privacy Act was passed. So certainly, there is an opportunity to bring this legislation up to date. So Salesforce has been closely involved with this reform process. There was an Issues Paper released and a discussion paper and then the government's response to these reforms. So all off, there's about 100 proposed changes to the Privacy Act. In the government's response, it indicated that it agreed with a number of these changes. And then it agreed in principle with the majority of them, about 70. So agreed in principle means that the government thinks it's a good idea but wants to carry out still further consultation before it passes those changes into law. And then there's another set of changes where the government noted them, which means that it doesn't plan to proceed with the changes at this point. The first tranche of reforms we were expecting in August, that's last month, in the form of draft legislation. That's now been postponed to September. So we are very much looking forward to seeing that draft legislation later on this month. In terms of Salesforce's view on these changes, we have made submissions throughout the reform process. Generally speaking, we're supportive of the reforms. I'll just run through some of the changes that we believe would be most beneficial. Firstly, the introduction of the distinction between controller and processor. So just to explain what that distinction means. So a controller is the organization that decides what data is processed and for what reason. And then a processor is the party that carries out that processing, only as instructed by the controller. We think this distinction is important because it really reflects the reality of how data is processed in the modern economy, and it allows for more appropriate risk allocation for each party. We support the removal of the small business exemption. So currently, businesses with turnover of less than $3 million are exempt from large sections of the Privacy Act. So our view is that the rights of individuals should be protected regardless of the nature of the organization they are engaging with. And we think that there are steps that can be taken to ease the burden on small business and make it achievable and efficient for them to achieve compliance. We support harmonization between federal and state privacy laws. So as I'm sure many of you are aware, I'm seeing the emoji reactions there, as well as the Privacy Act, there are other pieces of legislation that operate at a state level and also that regulate specific industries. And finally, we really support interoperability with major privacy regimes around the world. There's been a lot of really good work done to reform laws around the world, and we think it makes sense for Australia to have regard to that reform. And to the extent that there are changes that have been working well in other parts of the world that really makes sense for Australia to not go -- not to do things too drastically different from those well-established sensible reforms. So now we're just going to unpack some of the terminology that you might have heard in terms of reform of the Privacy Act. And I'll just try to explain in everyday language what these would mean in practice. So just some color coding. Light blue means agreed full stop, and the darker blue means agreed in principle. So we -- when the draft legislation comes out this month, we're expecting most of the -- most or all of the agreed changes plus, hopefully, most or all of the agreed in principle changes. But we don't know exactly what that legislation is going to contain. Okay. So first box in the top left, retention and destruction requirements. So that means that when an organization collects data for a specific purpose, it needs to have a clear idea of when the purpose is exhausted and when the data should be deleted once that purpose is exhausted. So the idea is that organizations aren't hanging on to data indefinitely, and they are deleting it at the appropriate time. Expanded disclosure requirements for automated decision-making. So this is an agreed reform. So that means we probably will be expecting to see it in the first tranche of draft legislation. So to the extent that any organization is conducting substantially automated decision-making. So substantially, that's the sort of new Australian word that's being put into this obligation. It's not in the GDPR equivalent provision. So to the extent an organization is conducting substantially automated decision-making, they need to put in their privacy statement the types of data that they're using for that substantially automated decision-making. And then if individuals make a request for information about substantially automated decision-making, then you have to provide that to data subjects as they're requested. Moving on to expanded definition of personal information. So at the moment, the Privacy Act regulates information about an individual, and that's going to change to information in relation to an individual. And that probably sounds like a very technical trivial distinction, but what it means is it's going to capture a broader set of information. So things like device IDs and IP addresses which could conceivably be argued to be about a household or about a location, not about an individual. If they can be related to an individual, they're going to be captured. Also information that is inferred or generated. So if, say, a company is running a loyalty program and collecting information about purchasing behavior. To the extent that you then draw conclusions about the nature of an individual based on their purchasing decisions, those inferences will be captured within this new broader definition of personal information. Strengthened consent requirements. So that's really spelling out in the legislation that consent has to be informed. That means people have to know what they're agreeing to. Consent has to be specific. So that means it can't be bundled. You can't sort of have a link where people tick a box and they're agreeing to all these separate things at once. Consent has to be current, which means it probably doesn't last forever; it would need to be refreshed at certain points. Consent has to be free, given voluntary, which means it can't be conditional on receiving a service, for example. Individual data subject rights. So this will give individuals an exclusive right to have their processing restricted. For example, if someone says, "I don't want my personal information used for direct marketing purposes", there's a clear obligation to cease that processing and a deletion right. So again, this ties into that broader definition of personal information. Once this broader definition, including inferences and generated information, is captured and an individual requests deletion of all of that data, it's important to be able to capture, put your hands on where all that data is and then comply with the deletion request. Clarifying obligations in relation to de-identification. That's really just to make sure that it's not possible for de-identified data to be re-identified. Stricter obligations around data breach reporting. So in the event that your organization was subject to a data breach, there are stricter obligations around reporting and timely reporting on that. Additional protections for offshore disclosures. So key there is that if your organization proposes to transfer data to a country outside Australia that doesn't have protections as robust as Australia's, you need to spell out to data subjects what the risks are at the point of seeking their consent. And finally, additional protections for employee data. There's currently an exemption in the Privacy Act for employee records. And there are proposed to be additional protections so that employees in the private sector have greater protections, greater data subject rights in relation to the data that their employer processes in relation to them. And finally, I just wanted to touch on as well as this set of reforms that are coming up in the future, a couple of years ago, the government did introduce some changes in the Privacy Act to really increase the penalty. So you can see here really significantly higher penalties in the event of serious or repeat breaches. So up to $50 million, 30% of adjusted turnover or 3x the value of the benefit obtained. So really, this begs the question what is a serious or repeated breach? These terms aren't defined in the act. So that means that if there was an allegation that an organization had committed a serious or repeated breach, then a court would decide what that means based on the ordinary meaning of these words and given the particular circumstances. Also, as part of the reforms to the Privacy Act, there's a proposal to introduce 2 more tiers of offenses with more targeted penalties. So a mid-tier and then a lower administrative tier. So that's it for me. And now I'm going to hand over to Mike.

Okay. Thank you, Rachel. That was super informative. Thank you. I always learn something when I listen to you, Rachel. Can I just maybe review what I think I heard in my layman's understanding? First of all, I think it's pretty obvious that privacy is changing around the world. That's a given. It's also top of mind for most companies. Not the least reason being that their customers are so concerned about the potential of harm for them and the reality of some of the extent of the breaches. So -- and thank you for telling the audience how Salesforce is approaching our own privacy, I guess, challenges. I mean we're a multinational company as well. We use GDPR as the gold standard, as you said. And the renewed, I guess, focus on enforcement, it's really important. So with that in mind, let me move towards what we might consider. And in consultation with Rachel and our team, we think we've put together a brief checklist of the themes that we think might be the practical response to what's happening. I mean the problem space is complicated, as we've seen. It's multidimensional. So let's go through some of the 8 things that we think together that might be useful to get started on. The first thing I would say is you're going to need to take advice. And that's not necessarily legal advice, but does include legal advice. So -- but you need to be, I guess, informed about what these changes are going to mean for your organization. So that's what obligations might be involved. You might have cyber teams or compliance teams already. And I'm assuming that you're possibly mostly interested in the Salesforce side of things. So I would then suggest that some basic data mapping would be really helpful because knowing what data you hold and where it's living is a basic requirement for the response you're going to need to have to the privacy laws. And then I think as we noticed, the reviewing of the internal and public-facing privacy policies. So Rachel mentioned the currency requirement for privacy and the nonconditional nature of privacy policies. I'm guessing you all have privacy policies, some of them public, some of them internal. We'd strongly recommend that you take a look at those. Data subject requests are really giving to your customers the agency to decide what you're doing with their data. We call those data subject requests. So for example, customer asks you to supply all of the data that you've stored about them and asks you what you're doing with them or potentially requests you to forget their data. Number five, a data breach response plan is absolutely mandatory, of course. So that needs to be sketched out. That will typically be -- that will span multiple teams. It's not just a technical sales force-, admin-type responsibility. It will include broadly across the business, many interested parties. Machine learning and generative AI. I guess it contributed to some substantial changes to the level of automation that might be brought to decision-making about the actual customers. So that's a very -- it's an emerging area, but of course, really important to your response to the privacy changes that we're experiencing. As a technical architect, I spent a lot of my time lately discussing with customers and I guess helping them navigate the big 3 parts of this topic, which are security, privacy and consent. And so the security, of course, is a major aspect. So we recommend you take a really good look at how the data is secured in your Salesforce orgs but also beyond Salesforce, of course. And number eight, I think, Rachel, you mentioned a scenario where a customer database is perhaps separate to another system that records purchasing history and so forth. I think it's really -- and this is common that your processes span multiple systems. But we feel that it's important to really start to document what you're actually doing with customers' data. So not only where it is but what's happening to it in terms of processes. So of course, responding to the privacy and consent and security challenges is going to take people, process and technology. And so what I'd like to do is perhaps present our response, if you like, to how Salesforce can help you in terms of the technology that we're providing. So the first thing I would say is that just about every requirement that we'll talk about today starts with understanding how and where and what you're doing with your customers' data. So the response would be, in our opinion, to get started on the process of auditing, cleaning and preparing. So on the righthand column, you'll see some of the technology that we can help you bring to bear. Understanding your users' behavior, for example, will tell you what they're doing with the data and provide insights to inform the other aspects of the process. So Event Monitoring and Data Detect as part of Shield, allow you -- give you a really good understanding and insight into what's happening in your org. Event Monitoring, for example, stores 80-plus events. It will record every page, every activity that your user base is embarking upon. Data Detect will find perhaps that embedded hidden PII. Perhaps in a case note someone's embedded a credit card number, for example. So Data Detect is a way to find embedded PII. Field classification is something that we provide out of the box actually at no extra charge. And if it's done properly, it allows you to classify fields according to their data sensitivity and compliance metadata. So we think that's really important. So classifying a field as relevant to Australian privacy principles and classifying it as confidential, for example, provides benefits further down the value chain, if you like. So that can inform your policies. It can also inform your obligations about reporting a potential breach, for example. So that's a service we'd highly recommend that people get started upon. Moving on to -- so understanding sets the scene. Now, of course, understanding without security is a bit of an empty vessel. So we would strongly recommend that you take all steps practical to make sure that not just PII, but all of your customer data is secured according to best practice. And again, moving down that righthand column, authentication, in other words, that's the gate that's allowing qualified credential users into your organization. But you'll notice the big sign on the left there that says, very interesting, that 37% of breaches are occurring from inside. And so they are typically people that have been through the authentication process. So authentication is not the totality of the solution that you'll be offering. So beyond authenticating, we need to consider things like access control; which data can somebody access once they're credentialed? And there are principles such as the least privilege principle you can bring to bear so that in order to perform someone's role, they really only have access to the data that enables them to do their role. The Health Check is a soft service and free capability that compares the state of your org to what we consider best practice. It's expressed as a number out of 100. It's a percent. So we would recommend that you run that. It only takes a few minutes, and it will respond with, I guess, a summary of the status of the health of your org. And not only that, it will provide some links to the remediation processes that you can bring to bear. An example would be it detects a weak password policy, for example. So the Health Check would tell you and provide a link where you can go and fix those sorts of things. Privacy Center, it's a composite product that is aimed at providing all of the pieces that you will need to comply with your obligations against -- we'll talk about that shortly. But specifically, in terms of securing your data, we're looking at minimizing the opportunity that people have to breach data. And that's -- if you think of it, then it makes sense to take the data that's not used and not critical and either move it out of the org or obfuscate the PII. Privacy Center can do that. Data masking is a facility for masking PII in the nonproduction environments. So we know, for example, that -- and we call them sandboxes. Most sand -- not all, but many sandboxes receive lesser retention when it comes to their security posture than production environments. So -- and sandboxes are commonly used by third-party contractors and so forth. So masking PII in sandboxes is just really considered a best practice. We've spoken about Event Monitoring and how it can track what people are doing. But another aspect of Event Monitoring is the real-time policies you can enable to actively prevent, for example, data exfiltration, an example. So a policy might detect somebody trying to export a CSV file that contains PII data, would be a classic use case for Event Monitoring. And then in some industries, under the auspices of some regulators, additional encryption at the data level is required. And we suggest that you check whatever your circumstances are with regard to the requirement for encryption. We offer a platform encryption capability where you control the keys essentially. Moving on to the third aspect, which is the active provision of the agency you need to give your customers, okay, with respect to responding to their requests to be forgotten. For example, right to be forgotten, RTBF, and the data subject access requests. So in GDPR, for example, these are very much at the forefront of people's consciousness when it comes to providing privacy laws. And as Rachel described, and without going -- I'm not a lawyer, obviously. But it's very likely that Australia will adopt similar type of obligations, if you like. So the customers can be forgotten and that you -- and can be provided access to their data. Privacy Center does that. It's an ensemble product that contains all the capabilities. I briefly talked about consent. We talked about the granting or the withdrawal of permission from your customers to the way you're processing or using their data. So Salesforce has a built-in consent data model. And we've got some facilities over and above that to help you build the user interfaces that you would need to put in front of customers so that they could elect which aspects of permission they're going to give or withdraw. That's all part of Privacy Center, actually. Again, and I think finally, we talk about monitoring because the threat landscape is evolving. And so it's not the situation where you fix the security, audit the users, build some policies and then walk away. In fact, far from it. Monitoring activity is part of the proper way to mitigate threats, okay? You need to be active about knowing what's happening in your org. So an example is at the top, log user activity and data access and retain it, okay? That's useful in the situation where you perhaps suspect something happened and you need to retain it for auditing purposes to go back and see exactly what happened, okay? PII, we talked about, and we consider that it's really essential that you start to label the PII in your orgs. And the Field Audit Trail can log changes automatically and permanently to those changes to PII and other data as required. Event Monitoring. I know I keep talking about Event Monitoring, but it's got a facility that uses machine learning actually and detects what might be considered anomalous behavior. So a user potentially who never runs a report suddenly is detected to be running a report from a cafe in Eastern Europe, for example. That would be considered an anomaly, and Event Monitoring can really help you deal with those types of situation. I guess -- I mean I guess by definition, it's anomalous. You didn't anticipate it. So that's where machine learning can really help you out. And Security Center. Many of you have multiple orgs. And in fact, if you think about it, even with 1 production org and a couple of sandboxes, that's 3 orgs. You probably all have multiple orgs. And then in addition, some of you have literally multiple production orgs. So monitoring the posture of those individual orgs not only now but in kind of a time series way is a really critical part of monitoring the posture across your landscape, the fleet, you could say the sales force fleet if you like. So look, with that, I'm going to hand back to Bel. Thank you very much.

All right. Thanks so much, Mike. Can you hear me?

Yes.

Good? Excellent. Thanks, Mike, for the overview on how Salesforce can help. Really appreciate your insights there. And thank you, Rachel, for all your insights on the proposed reforms of the Australian Privacy Act and sharing how Salesforce manages its privacy fundamentals. So from our conversation today, I think it's pretty clear that privacies are fundamental to all businesses and to the trust our customers place in all of our organizations. At Salesforce, we're committed to upholding trust, ensuring that we uphold our #1 value of trust while protecting our customers' data and helping them deliver privacy to their own customers, encouraging best practices, supporting regulations that standardize best practice for privacy and then, of course, leading by example, demonstrating our commitment to privacy compliance. Okay. So on that note, we are going to move into Q&A.

So Rachel, could you turn your camera on as well? That would be great. Just as Rachel is coming back online as well, I just wanted to call out from [ Josephine ]. I loved your comment. "This session is awesome and value packed. I need to listen to it over again. And all of the caps is deliberate." That's a wonderful note to send through to us. Thank you. We really do appreciate it. Okay. Just before we get started on the questions, unfortunately, we can't give any specific details about high-profile data breaches or particular legal advice about specific circumstances. But we can add -- so what we can -- some of the other ones there. So I'm happy to start off with, do you think Australia will become the gold standard going further than GDPR?

Bel, thanks. Can you say everyone see me and hear me?

Yes.

Yes. Great. Good. So in terms of the proposed changes to the Privacy Act as they are at the moment, in most cases, they don't go beyond GDPR. In most cases, they are a kind of less onerous version, like a less strict version of GDPR. But they're covering a lot of the same ground. For example, a more complete set of data subject rights, a stricter definition of consent. So things like automated decision-making, under GDPR, there's a right to opt out of that in certain circumstances. So the Australian version is not a right to opt out of it but just a right to understand it better and get more information about it. GDPR has a requirement for a legal basis, which is a bit different to the way the Australian Privacy Act works. So what that means is in order to do any kind of data processing, you need to have some kind of reason that is recognized by law. So there are reasons that recognize functions of government and law enforcement, for example. And there are reasons that companies can rely on to fulfill a contract. So if someone gives you their credit card information to purchase something, if you're an e-commerce provider, you don't need to separately ask their consent to process their credit card information to fulfill the purchase because fulfilling the contract is the legal basis for the reason that you're using their data. So the Australian Privacy Act doesn't operate on that basis exactly. It's a slightly different setup, which relies on reasonable expectation of an individual. So you can conduct data processing if the individual would reasonably expect that processing to be carried out. One of the proposed reforms is an additional requirement that all processing be fair and reasonable in the circumstances. So we don't know exactly what that's going to mean in practice. That's -- they're words that don't have further definition at this point. But as time goes on, if that requirement passes into law, we would expect to get guidance from the regulators what does term reasonable will mean, perhaps some examples for companies to work with. And then as courts decide outcomes of cases in relation to breaches of the Privacy Act, we would get more descriptions from courts about what is fair and reasonable in the circumstances. So that's a really long way of saying in short, the proposed reforms for Australia are to move a little bit closer to GDPR, to start covering some of the same ground that GDPR covers. Doing it generally speaking in a less onerous way and also, in some cases, approaching risk in a slightly different way.

Thank you for that answer. Very comprehensive. So in terms of though -- there's another question here. Will using data for AI training be also part of the legislation?

So there is that proposed provision I mentioned before where organizations would need to disclose the data that they're using for automated decision-making. But apart from that, to the extent that personal information, so information about an individual or in relation to an individual, is used in AI or automated decision-making, it would be regulated in the same way as other personal data processing is. So to the extent that you can use data that's no longer personal information, so if you've stripped out all the identifying detail and it can't be re-identified, then it would fall outside the Privacy Act. It doesn't mean it wouldn't be subject to other legislation and other regulations. But to the extent you are using information about individuals or in relation to individuals, then you're going to be subject to the requirements of the Privacy Act, which means reasonable expectation of the individual. You might need consent in some circumstances. You're going to have to think about when you delete that data. You'd have to provide access if individuals ask for information about what you've been doing with their personal information.

Great. Thank you. Mike, here's a question for you. Does field classification impact reporting and queries?

Field classification does not impact reporting and queries. It's an additional metadata that you would put on to a field. For example, if you're recording a passport number, then you could simply classify it as confidential and perhaps relate it to Australian Privacy laws. In fact, where it touches reporting is that you can report on which fields in your org have been classified, if that makes sense.

So that leads into maybe the next question here. Can we run reports on Field History Tracking and Field Audit Trails?

Okay. So the Field Audit Trail is -- I can combine that with another question, actually. Someone asked whether Field Audit Trail can be limited to PII data. In fact, Field Audit Trail information can be attached to whatever fields you want to track, but we recommend that specifically you do include PII data, okay? There was another question about the storage requirements for Field Audit Trail. It doesn't impact your storage. The storage is separate for Field Audit Trail. It's part of the license. The retention is permanent, and there is no additional charge for the storage. Great questions, by the way. Rachel, people are so engaged. And maybe back to Rachel because I think on balance, she's really got some great questions here. I'll scan for some tech guy ones at the top here if you like.

Yes. Excellent. So Rachel, just to clarify again, there's a question here that I missed, what the layman's definition of automated decision-making was. Could you explain that?

Sure. So there's a proposed reform to the Australian Privacy Act, which would cover substantially automated decision-making. So these words haven't been defined in the act. So it's kind of a bit of a gray area as to how much -- what does substantially automated mean in the circumstances. So this is one of those areas that we would be looking to get guidance from regulators and really relying on ongoing decision-making from courts about where is the threshold between substantially automated and not substantially automated, what degree of human involvement would you need to take [ out of ] substantially automated. But in terms of managing the risk, it would really most likely be prudent to really err on the side of caution and look at all your automated decision-making and really sort of generously categorize what's substantially automated and then make the necessary disclosures in your Privacy Act in relation to what could conceivably be regarded as substantially automated.

Understood. There's another question here to you as well. It says, you mentioned about making consent through tick boxes more explicit. Could you elaborate?

Yes, sure. So there's another proposal in the Privacy Act to really spell out what consent has to be. So it has to be voluntary, current, specific. So that means that -- specific means that you couldn't, for example, have a tick box requiring people to consent to all sorts of processing. So tick here to consent to, for example, direct marketing, targeted advertising, sharing your data with a whole number of organizations, transferring your data to a number of different countries. Each of those different purposes of processing would have to be requested separately.

Excellent. Thank you. Mike, is there any questions there that you are just having a quick look at that you want to answer as well, maybe read out?

Maybe I'll combine a couple. I have a question, gentleman asking, when you classify data, is it permitted as part of the field creation process at this time, or you have to go back and do it after the field is created? I believe that's still the case. So I'm just calling out -- thank you for the question. I'm just conceding I don't know the exact answer. It's a great question, an indication that you're actually interested in that field classification. At the moment, it's -- you do that manually. Is Field Encryption and Event Monitoring an add-on product? Yes, they are add-on products. Is Data Detect paid? It's free as part of Shield. So I guess it's in -- Shield is an add-on. Data Detect comes with it as an offering on top. Sorry, Rachel, I'm -- Bel, I'm just scanning here to -- the majority of questions...

That's all right. While you're doing that, Mike, I can just come back on the usual consent -- yes. So I've just pulled up the proposed reform in front of me. So the proposal is that consent must be voluntary. That means freely given. It can't be conditional in order to receive a service. Informed, so that means you have to understand what you're consenting to. That means you have to use clear language when you're seeking consent. Current, that means it probably won't last forever. I think someone asked how long does current mean. It's going to depend on the circumstances. So we would be expecting to get potentially some guidance from the information commissioner about the different ways you can measure whether your consent is current, but there wouldn't be a kind of one size fits all for that. It's going to depend on the nature of the information, the nature of the processing. Specific, that's what I mentioned before, about can't be bundled. You've got to ask for the different types of consent separately. And unambiguous, so that just means it has to be clear. You have to spell out in clear language exactly the type of consent you're asking for.

Excellent. Thank you. Mike, any other ones there from you?

No, I think I've answered -- there's a bit of repetition. Let me just -- I'm scanning now. Bear with me. There are a lot. I'm going to say -- will Salesforce increase the field tracking from 20 on an individual object to support these changes? Okay. So the field -- it's a great question. Let me just -- because it's characteristic of some of the other product offerings. Field Audit Trail is an out-of-the-box facility at the moment. Most of your -- people on this call already have it. It limits 20 fields per object and stores the Field Audit Trail for 18 months. The paid option, Field Audit Trail, extends the 20 fields to 60 and removes the 18-month retention policy. They become permanently stored. So I think I've answered that one. Will the Right to Be Forgotten requirement -- sorry, the Right to Be Forgotten requirement, does this include backups? That is an excellent question because to do a Right to Be Forgotten properly, and we believe we do it properly, you really need to do a deep delete. To truly forget a record, you need to delete not just production but also the occurrences of that record deeply into the systems that are attached to it. We can do that in 2 ways. One of them is out of the box. So one of them is our delete -- Right to Be Forgotten will penetrate into the backup side of things. And secondly, facilities like the platform Event Bus can notify downstream systems of the process -- the Right to Be Forgotten process that had been embarked upon and approved and can kick off downstream systems. So that's a really good question. And one other caveat -- well, not caveat, an extra feature, if you like, we released quite recently. Sometimes you don't want to forget a customer even if they request to be forgotten. And I'm going to look at Rachel here for some backup here. But the example would be what we call a legal hold. So there's a circumstance where there's something going on legally where you really shouldn't be exercising Right to Be Forgotten, then Privacy Center will be -- will take account of that. Rachel, I'm looking at you pleadingly for a bit of help, but...

Yes. Look, I mean it's -- until we have legislation on exactly what the deletion obligations in Australia would be, all we can do is look at examples in other jurisdictions. And generally speaking, yes, there are exceptions to the obligation to delete data. If, for example, you have a legal obligation to retain data or an important legal justification to retain the data, then you wouldn't necessarily need to comply with the deletion request.

Thank you. Thanks, Rachel. So where that is kind of surfaced in the Privacy Center is that fair value -- records can be flagged as legal harm. It's a Boolean value. You can click it and the Privacy Center will take account of it, wherever it's relevant. I think that's probably it, Bel.

Cool. Thank you so much, Mike. Just one quick last question for you, Rachel, before we wrap up today. If these are proposed changes, is there a possibility that some of these changes might not go through or may be stricter? Not that you have a crystal ball, but what's your thoughts on that?

Yes, that's fine. So I don't have a crystal ball. I can sort of say what most people are expecting to happen. So of the sort of more than 100 recommended changes, there's roughly 30 of them were agreed. So we'd most likely expect that -- common wisdom is that all of those agreed changes will go in the legislation. And then the agreed in principle, to the extent that the government has been able to secure support for those changes through consultation with the business community, most people are expecting those changes to also be in the first tranche of reforms in the draft legislation in September. But of course, it really remains to be seen. We haven't seen a draft legislation yet. And then it will be draft legislation. So it's possible that it could be further amended before it's introduced into Parliament. And then in the process of going through Parliament, there could be still further changes made as part of that process. So really, it's not clear. We don't know exactly what we're going to see until we see it.

Great. All right. Thank you so much, Rachel. Thank you, Mike, as well. We're just going to wrap up now, folks. A big thank you for joining us today. If you're curious to dive deeper in today's conversation, please reach out to your Salesforce account executive. We're very happy to do a deeper dive on the topic. Also, folks, be on the lookout. We are about to launch a new e-book that we've written here in Australia. That's called 5 Steps to Strengthen Privacy and Compliance in your Organization. This will be launched soon. And we'd also like to invite you to attend World Tour in Sydney on the 15th of October. We're going to be bringing the best of Dreamforce to you in Sydney. It's a free event and it's also a chance to get hands on with some of our tools, so you can scan the QR code there to sign up. Many thanks, and please reach out if you have any other questions, and we will endeavor to get to all those questions individually for those folks that have put them into the Q&A. Appreciate your time today. Thank you.