Name: Office Hours | Forcepoint DLP: Supercharged (EMEA/APAC)
Uploaded: 2026-03-19T11:16:11.312Z
Duration: 50 min 4 s
Description: Office Hours | Forcepoint DLP: Supercharged (EMEA/APAC)

Transcript for "Office Hours | Forcepoint DLP: Supercharged (EMEA/APAC)": Hello there, everybody. Thank you for joining session number two of our DLP, setup for success office hours session or series. The first series, we focused on, you know, day one getting yourself up and running. Today's session is going to go beyond that. There'll be a little bit of crossover from the previous session because it's really good info. We we want to make sure we give the context of transitioning from early to late stages, but we will be focusing more heavily on things like advanced tuning, etcetera, in this session. So thank you very much for joining. Okay. If And you wanna go to the next slide, I can just do a bit of housekeeping. So before we get started, you'll see there's a q and a box up in the top right there. Please go ahead and enter any questions you have during the session. I'll be sending out a poll at the start and the end, plus a survey at the end. So please do go ahead and fill them out. It it's really helpful to us and helps us improve our future sessions. And then you will receive an email tomorrow to watch the playback of the session. Okay. Where's the next slide there? So who are we? So I'm your host. My name is Nell Connell. I'm the manager of our strategic programs team in the customer success org. Emesh is gonna be your presenter today. He's a senior manager in project man in product management over at DLP. And then we have got Senthil and Dinesh who are senior members of our tech support team who are going to be on hand to answer your questions in the q and a section. And if we see any good questions, anything notable, anything we wanna share with the group, they they'll jump in ad hoc throughout the meeting to let us know so that everybody knows what's going on in the q and a session. Please do ask questions because, as a product manager here in Forest Point, the questions that you ask are the things that help me validate my road map and validate what the product does or tell me how to improve it. So please feel free to ask as many questions as you can. Sorry, Niall. No. Absolutely. I I I second that. The more questions people ask, the the better we can do our job and hone the product to serve to serve you. So, yeah, I I I second that thoroughly. Okay. Okay. So moving on. So we have a pretty packed agenda for today. I won't I won't go through everything. But as I said, the goal of this call is to kinda set us where did we where did we leave off from last time, and then how do we advance through the implementation of DLP to where we feel like we we understand how to use this product from an advanced point of view. So before I hand over to Emmett, I'm just gonna pop a poll up here. Let me click it. There we go. Yeah. That's popped up. So I'm gonna give everybody give you about thirty seconds, a minute to start filling out that poll. So please do. The goal of it really is to understand how do you how comfortable are you with the DLP concepts right now. And we'll run the exact same poll at the end and see once again, as we said, feedback is super important, so we'll see if you are more comfortable with DLP concepts by the time we end this meeting. And as I said, I'll also run a a survey near the end, so we can get feedback generally on our office hours to let us know. Let us know how let us know how we're doing. So I can see people are I can see the numbers going up. That's super. Thank you very much. Keep on going. Don't don't hesitate. Once I see it start to taper off a little bit, we can go ahead and continue with the presentation. I think we've hit maximum capacity. Yeah. Okay. I'll close that off. And and I'll hand you hand you over to Emmett. Go ahead, Emmett. Okay. Thanks Niall. So I'm going to start with just a quick, summary of what we talked about in the last session. We talked about the process of setting up a DLP project, always starting with the permissive monitoring phase. That means audit only. Then moving to incident analysis and refinement. Set up your policy. Look at your incidents coming in and see how many you're getting. Tune the classifiers. Then gradually move those from an audit or a monitoring phase to blocking. Move them one by one And then keep repeating that step. Keep tuning your policy, as you go along. The thing about DLP is there's a lot of work to do at the start, but it doesn't just finish then. Data is changing. Organizations are changing. And quite often you'll find that there's new regulations coming in, your organization might be collecting more data, and you have to keep looking at your policies. So it is an inspect adapt relationship. You have to keep looking at it, keep updating it. Moving forward, let's talk about where we start in a bit more detail. The key thing here is don't boil the ocean. So when you come to your policy for the first time, you'll see lots and lots of predefined policies, lots of classifiers. A classifier for us is something that identifies a particular type of data, like a credit card number. So you'll see lots there. We have 2,000 classifiers, and you're not going to need all of them. No way. These are geo specific, particular to countries. They are use case specific, and they could be industry specific also. So you're probably not going to need all of them. When you get started, look at your data protection policy that you have within your organization. Select what data you're really interested in, something like PII or GDPR and start with that. Normally the first five or 10 policies and use our predefined policies. Our predefined policies are set up so that you get started in your region, in your industry, with your use case really quickly. But remember, we cover much more than that. We do compliance frameworks. We have data theft indicators. We have things like acceptable use policies. So because we're scanning all the data in motion going out of your organization, we can check things like acceptable use. So what language? Is the language appropriate? Should you be using that language with an external party? We can check all this. Now the thing about it is, as we said last week or two weeks ago, always start with audit only. You never block on day one. So you have the choice whether to audit or enforce. And we have a lot of organizations, a lot of customers that just do audit only. And the advantage of audit only is that the users are never interrupted. They're never blocked so that when they want to send the email, the email always gets sent. We will always record if there's sensitive data in that email and create an incident. But quite often, organizations want to allow the organization to move freely. Other organizations are the opposite. They want full prevention from exfiltration. Any sign of sensitive data being exfiltrated, block. So you have to decide where your organization is. And you can mix the approaches. So you can audit on lower risk policies and you can enforce on the really sensitive data. So there's no right answer here. You have to look at your organization and decide whether you want to audit or enforce or a mixture of both. But to begin with, always audit. When you're setting up your policies, you have to look for the right classifiers and the right policies. So for example and we have ways of doing this. We have knowledge based articles. We have our smart search, and and just a search. So looking at some of these. For example, GDPR. If you come in the other policy library, you can type in GDPR and you will get this set of policies. This set of policies is specifically for GDPR. You can turn things on and off within this policy as you see fit. If you're not interested in CV and resume, you can leave it off. Again, within GDPR there's priorities of data. And you can decide what your organisation is interested in. We have an AI smart search. So you'll see in the top right hand corner, there's a button called smart search. And this is really good because what we've done is we've taken all our knowledge based articles, all our documentation, all our admin guides, a lot of internal documentation also, And we've put it into an AI model, and you can query that model. For example, if you're in the energy industry, you want to get started fast, list the classifiers for the energy industry, and that will reply with these classifiers. Once you have the name of the classifier, you can go into our patterns and phrases, our list of classifiers, and you can select the filter button. You can find these classifiers very, very quickly. This is a really good search capability. It's a small menu and some customers tell me it's hard to find, but it's really powerful. If you're looking for credit card classifiers, if you're looking for base 64 classifiers, hexadecimal class, All these things, just type it into the search, you can use wildcards, and you'll be able to find the classifier that you're looking for. So when it comes to setting up your policies, this is the best place to start. What happens in your organization if you have a specific type of data or a data type that we haven't covered? We have 2,000 classifiers. We have more classifiers than any other vendor out there. But a lot of organizations have classifiers that are just particular to them. And in that case, there's two things you can use. First is our custom classifier. So I'll come back to the screen. If you type into that search dialogue, here, custom ID, you will find our custom classifier. And what that does is you give it a regular expression, and it will go and, it'll do a search on, for that regular expression. But there's a lot of parameters additional to that, things like a preceding pattern or a consecutive pattern, a concatenate pattern, a check that digit algorithm. So you can say there's an IBAN or a LUN validation, modular validation. There's lots of check digits that we've built in that you can use. We have modulo ten and eleven weights or a calculation constant. So you can this classifier an algorithm to check a digit in your ID. Hidden prefixes, numerical conversions, statistical validation only fire if you get this number of matches. Substring analysis, support terms, and support term max proximity. How close is that term to the regular expression? There's even more, but this is just a high level view. And you can see from this how complex our classifiers are. It's not just a regular expression. It's not just a dictionary lookup. So if you want to create your own custom classifier, this is the classifier that you use. The second thing, if you've got your own type of data, not even your own type of data, we have machine learning classifiers. What you can do is if you have a document and the easy example here is a resume or a CV, you give our classifier 50 CVs. It scans them and it now knows what a CV or a resume is. It can identify that if it's being transferred. It's particularly good for detecting code. So Rust, C plus plus Java, doesn't matter what code it is. The machine learning classifier is a sort of one stop classifier for all programming languages. You're up your policy levels sorry, when you're setting up your policy, what's really important is policy level. Policy levels, they set the execution order of checks and it ensures that you hit the most critical protections first. You want to structure your policy levels, where you're assigning the execution order. You can create as many levels as your organization needs. And you normally group them into tiers, so high, medium, and low. And that can be based on sensitivity. It can be based on the use case or based it's up to you what you base that on. Most of our customers would think in terms of risk. The severity is the cost of the data being exfiltrated. You have your most sensitive data, the first check we do. When data is being moved, we look at the data and we say, Is this data the most sensitive, the most confidential data in your organization? That's the first check we employ. Then we move to the second level, the third level, the fourth level. We move down the list. Obviously, higher the impact, the higher the level. This is a number of benefits. The first benefit is from a performance point of view. We will stop processing once we trigger a rule. The advantage here is the action will never change lower down. So if we find really sensitive data, we don't need to check anything else because the action is always gonna be blocked. But there's a couple of things you have to remember. If a rule is triggered but no incident is raised because you've got an exception. So for example, if you had sensitive piece of data and the exception was that the CEO was allowed to send that data, then we would stop processing here. We wouldn't continue. The exception would allow it to be sent and we wouldn't keep processing. So just keep that in mind when you're using policy levels. The other good thing about policy levels is from a timeout point of view, every vendor in the market has a timeout. And the reason for that is when you have really, really large documents, we don't want to interrupt the user's flow. So they're transferring documents. They're sending emails. We don't want to, hold process and time while we scan the full document. So what we do is we always check for the most sensitive data first. If we find it we break out. When a timeout occurs we will stop processing but at least we've checked for the most sensitive data. We have a number of features around large file analysis. Things like checking random sections of a really large file to make sure that we get coverage across it. And we have new large file analysis coming out later this year where we will just continue to check. It doesn't matter what size the file is, we will check all of it. The next thing I want to talk about is rules. So data guardians. Data guardians are really important. So when you've got a large organization, actually any size of organisation there's rarely one single person that knows everything about the data. Best practice is to identify the people that know the data. Normally you have a legal department, a HR department, a finance department, an engineering department and each one of these departments has its own sensitive data. The other department heads probably don't know. The finance people don't know about the engineering data. Engineering people don't know about HR data. So you have to identify the data guardians. And the problem that they solve is that the DLP admin, the data admin, doesn't know everything about all data. And the context has to come from somewhere. The data guardian, they know what data is critical to their business, their department or their business unit. They know how this data is used day to day. They know who should have access to it and who it should be sent to. So most of the time when a data guardian gets involved is when an incident comes in, the admin might look at the data, they might be unsure whether this source, the sender, can send it to this destination. In that case, they will go to the data guardian, notify the data guardian. The data guardian would make a decision. While we're on the subject of roles within DLP, we have a full RBAC, and it's fully customizable. And it's sort of we have sort of two sets of customers, small organizations, large organizations. When you're a small organization, we find that the admins typically play multiple roles, whereas the larger organizations have more specialized DLP team members. And those roles are mapped to function, things like an auditor role, an incident manager, a policy manager. But we have fully customizable roles. You can create your own roles depending on what your organization needs. You come into So you create your admins or your admins can come in from Entra ID or Active Directory. And when you have an admin, you assign that admin a role. And we have a default role. We have an incident manager role. We have the super admin role. Each one of these roles you can change. So they have permissions. There's some here. But you can create your own roles. For example, an auditor role. Auditor roles don't have access. They can't make any changes. It's read only. They normally don't have access to forensics. So you would uncheck this. You could look at the violation triggers but they couldn't look at the forensics. So we have a very detailed level, very granular level of permissions for what each admin is allowed to look at or access or change. When it comes to the policy management, we've got three levels. We've got restricted read only and edit. And even below this, it's a small screenshot, but there's more permissions even below this for system settings, etcetera. Think about your admins. Think about what you want your admins to see. Think about what your admins are allowed to edit and set the rules up accordingly. Next thing I want to talk about is administrator workflow and notifications. So when you create your admins, you assign them rules. These admins have a job to do. And the main part of the job, updating the policy for sure, the sysadmin on the various protectors or infrastructure. But the biggest part of the job for a data admin is looking at an incident, triage, and escalation. You want to set up the workflow depending on the incident that comes in. So if it's a low severity incident, you want to coach the user or educate the user. So at this point, the incident has been created and the admin has taken action on it. And that might be send an email, for example, card numbers or maybe acceptable use. If there's inappropriate language being used, the first thing is coach the user. Send an email saying you're not allowed that's not appropriate to use that in external communication or an internal communication maybe. So coach the user and define who should be notified at each security level. This is important because if it's low severity just educate the sender or the user. If it's a higher severity you might want to escalate to a manager, escalate to HR, whatever. For each one of your incidents you want to establish a clear escalation path before you go live. Policy owner notifications. Policy owners is a really important concept. When you create a policy, you can assign a policy owner. That means that that policy owner is responsible for incidents coming in, triggering from that policy. So the policy owner would get a notification. When they log into FSM, they won't be able to see any other incidents. They're only allowed to see the incidents that they're in charge of. You define notification templates for policy owners. Sometimes your policy owner and your data guardian have a very close relationship or are the same person, so they would get a notification if a particular type of policy is triggered that they have to act upon. I would just say one thing here is when you set up your policy owner notifications, be very careful about be very careful with the wording. You can include the the trigger details. You can include the source, the destination. There's lots of it's very configurable, that notification. Just be careful with the wording. The next thing I want to mention is tracking and reporting. So your workflow is sort of defined in stages or phases using statuses. There's five predefined statuses. The first status is always new. When an incident arrives in status new. Then it can move to handled or acknowledged. Then possibly it could be marked as a false positive. It could be quarantined. It could be released from quarantine. There's five predefined statuses. You can add as many as you want and statuses can be dependent on your workflow. So when you define your workflow up here think of it in terms of status and status can be particular to a channel. For example, email, there's a status quarantine where an email can be quarantined and it can be released. So those are particular to the email channel. You don't get quarantined and released on the endpoint channel or the CASB channel. Define your statuses. Think about the channel, and you can define as many as you want. The other thing you can do with incidents is tag them. You can tag an incident with just give it a user defined tag. And what this is good for is when you escalate. Maybe you collect together a number of incidents particular to a case. It could be an individual in the organization that has multiple incidents or it could be a department that have multiple incidents. But you can tag these. You can send them. The admin can send them to the CSO or the admin's manager and say there's something strange going on here. Have a look at these incidents. Filter on this tag. It's also useful. You can tag as ignore, so there's a special ignore tag. This is for every time when you set up your DLP policy, you'll always do testing on it. The thing about incidents is in general you don't delete incidents because you want to keep a record of what happened. Even false positives quite often you want to keep them. But you can mark them as ignore, in which case they won't appear in the view. Now the thing about tracking and reporting and about statuses is it really comes into play from a reporting point of view. When you can see the status it tells you how long an incident remained in that status. This is really good when you're reporting up to the CSO level and we have a CSO dashboard that works off this principle. The CSO dashboard will report how long or what's the average time an incident will be in the new state. Actually a critical incident would be in the new state and that's really important because it tells how fast you're addressing these incidents, how fast you're getting through them. It'll also tell how fast an incident went from new to false positive or it went from new to release from quarantine or quarantined. So it's really important when you're defining your workflow, define it with statuses because that drives your reporting. So what we talked about there, that was admin workflow and notifications. What I want to talk about now is user workflow. So this is the end user. This is a user that's sitting on the laptop and they're copying data to a USB stick. They're sending maybe they're attaching an email putting an attachment on an email. What we find is end users need to be educated. And the employee coaching dialogue is really good for that. It's good when you're moving from audit mode to block mode. You can use the confirmation mode. So what happens is instead of doing a block, a dialogue pops up in the bottom right hand corner. And it's a small dialogue, so we're sort of limited to how much space is available. But it will it is a thirty second timer. If you don't do anything, it will block at the end of the thirty seconds. But as we say, there's a policy violation here. In this example, it's 16 credit card numbers. But it says if you feel this is justified then select a reason from one of the predefined reasons. Otherwise enter justification and press allow. This has two benefits. One, it reduces the severity of the incident because the user is actually taking responsibility for the alloy. You've explained what the problem is and they're saying no, this is okay. So it takes away work from the admin, but an incident will still be created. The second thing is it helps the admin learn what's the exceptions to the use cases. What's exceptions? Then the policy can be adjusted to suit this. Two important things here. One, the company can put their own logo here. It doesn't have to be the Forcepoint logo. They can add their own logo and that's good because it means that if you put your own logo here, it means that the message is coming from your company. This is our sensitive data. You shouldn't do this. It's not a third party company. It's the user's company that's telling them, are you sure you want to do this? The second thing is because we're limited to space, you can add a URL. That URL could link to an internet site where you can explain why you're not allowed to send credit card numbers outside the company. One other point I want to make very quickly is when it comes to planning resources, no. There's the policy, and then there's resources around the policy, things like business units, domain names, IP addresses. When you're looking at resources, when you're looking at those things, save them as lists in the resources so so that they are reusable. But there's other things and that takes a bit of planning upfront. There's other things where you need to get permissions and credentials. And these credentials are not they're not probably known by the data admin. They're known by the system admin. So what you want to do is things like if you've got if you're using Microsoft MIP or Purview or if you're going to use our fingerprinting feature or discovery feature, these are features where you need to provide credentials so that we can access that data. It might be in a repository, which as you would expect, that repository should be locked down for fingerprinting. That's your most sensitive data. So you have to provide us with the credentials to access that area. With MIP, we work very closely with Microsoft. They provide us with an SDK and they say, Get the user to enter the tenant ID, the client ID, the client secret. In that way, you can use our SDK to read MIP labels, to decrypt files. If someone encrypts a document and then sends that document over email, we can read the label on it. Even though it's encrypted, we can read the MIP label. If it's confidential, we can block it. But we can also decrypt that attachment, scan the content, and if it's sensitive, we can block it or we can alloy it according to your policy. So, the point here is if you're using MIP, if you're using fingerprinting, if you're using discovery, there's things like this. Plan for these upfront and make sure you've got the credentials so that when you're setting it up, the system admin is there and they can enter the credentials because you don't want to delay your setup because of this. So we've talked quite a bit about policies, setting up policies, best practice for policies. Once you deploy it and it starts running and you're going be in audit mode, for sure you're going to hit false positives. So how do you handle them? Just an example of a false positive. This is a classic example. Sydney Kimmel Comprehensive Cancer Center at Johns Hopkins. For a lot of medical companies in the medical industry, we have policies that would look for a name and a disease because that's very sensitive data that you want to protect. You don't want that sent out. So this is textbook false positive here. It's matching the name Sydney Kimmel or the name John Hopkins. And it's also detecting the word cancer. So there's a proximity link between these two. In our classifiers, you can define, you can add classifiers together, you can put a condition. If this and this or if this or this, you can pull up conditions. So that's what's happening here. A name close to a disease. Now if this happens don't remove the rule. You can tune it. The first step in tuning, especially if you're using a predefined policies and rules, is when we have lots of classifiers, but when we release a classifier, we release it in three versions normally. And it's three versions of accuracy depending on what your organization wants. So there's narrow. Narrow matches only high confidence, tightly validated patterns. And if you select narrow classifiers you get a lower false positive rate. On the other side we've got wide and that's a broader set of patterns, relaxed rules, it's higher recall but potentially more false positives. The example here you can see credit cards, default R1 wide. We have many, many credit card classifiers because it's so important beyond this. Have specific ones for American Express, for Visa, for MasterCard. We actually have an extra narrow and an extra wide. But most classifiers would have three levels. Just to look at how the narrow differs from the wide or the narrow and the default can differ from the wide. There's lots of checks, and you saw that in the custom classifier. But just a few examples. Supporting terms. With supporting terms, if you use the basic wide credit card classifier, 16 digit numbers with a space either side will generate an incident. In narrow mode, that has to be preceded or it has to be in the proximity of a supporting term. That term could be Visa, MasterCard, American Express, credit card, CC, multiple supporting terms coming from a supporting term dictionary. So it wouldn't fire on this. It would only fire if it had Visa and that 16 digit number. We also use delimiters. So delimiters are, again, for the format of a credit card number, it's four digits. Delimiter, four digits. Delimiter, four digits. And wide will always fire on the 16 digits. Default will fire on, the separation using the delimiter. And it could be a dash, it could be a space, multiple delimiters. And also the number of matches. So it won't fire on one, but if it finds five, ten, it will it will trigger. And these are just three examples. There's many, many more examples for a credit card, things like the numbers and check digits, etcetera. This is just to show the difference between the narrow and the wide. Default is in the middle and it's a good place to start. When you're tuning your policies, if we're getting way too many incidents on a particular policy or a particular rule, move it to default, then move it to narrow. Other ways of tuning. Supporting terms, we've talked about that. Dictionaries, we have our own built in dictionaries. You can add weights to terms in dictionaries. Regular expressions, you can add your own regular expressions. My advice is use AI to generate really accurate and really efficient regular expressions. We have incident analytics. Our analytics engine is a specific separate tool that will use AI and Bayesian networks to collect related incidents together. So it could be a person. Here's the incidents on this person. Here's on a department. Here's related type of incidents that are probably false positives. Use our analytics engine to help you if you've got a lot of incidents. We talked about the wide narrow and default settings. Exceptions and exclusions, really important. And in the John Hopkins example, this is where you would use an exception. You don't delete the rule. You just say if it says John Hopkins, that's an exception. The last thing is threshold in Drip DLP. You can set a threshold. Don't fire on a single credit card number. Fire on 10 in a single transaction. Drip DLP is what a lot of happens with people who if they want to exfiltrate data, they might set up a cron job that sends out one or two credit card numbers in an email every second, every minute. So they can transfer hundreds in a day. We can use a feature called DLP, which will accumulate, for a for a particular user. It will count the number of individual transactions and then fire trigger on that. Now we've gone through a lot of policy. Once you've tuned your policy, it's time to move from audit mode to either confirm mode or block mode. Confirm mode's a good stepping stone in between block mode, and it depends it depends on your organization. If you or you can mix it up. A lot of organizations, as I said earlier, they don't want to interrupt the user. They don't want an incident a user being blocked and having to wait half a day or a day for an admin to handle that incident. But there's always a record of what happened, so they can be held accountable if there's data exfiltrated. Confirm mode, we talked about that. It's a nice halfway between block mode and audit mode. And block mode is full enforcement. An incident gets generated, and the data never leaves your organization. It's up to your organization what they want to do. Looking at the long term, things that you want to think about retention. We collect a lot of data and we collect a lot of sensitive data, PII, GDPR. Lots of sensitive data. How long does your organization want to retain that data? This is your choice. We will keep it as long as you want it. Some organizations need to keep three years of data. Some organizations only want to keep it for thirty days. The choice is yours. Define the retention period at the start of your project, plan your storage capacity, and schedule when you're going to back that up. Staying current is really important. We are releasing we have a major release every nine, ten months, and we have incremental releases in between that. So maybe four releases a year. You want to stay within one release of a current version. If you see the maintenance releases when they come out, if it's a feature you want, install it. If not, wait until the major release version. Lots of our customers would have a development environment or a staging environment as well as a production environment. Staging and dev environments are good for testing and for building up your policies. And have a clean house. What you find or what we find with customers is they try out a lot of policies. Some they need, a lot they find out they don't need. If you have a policy that's generating incidents, you don't you're not interested in them, you're not looking at those incidents, just delete the policy. It makes, managing it much easier. Hey, Yep. Emmett. Just letting you know, gonna launch the survey now. And then when you get to the last slide, I'm going to launch. the poll. So shout out to everybody out there. Please, the more you respond, the more we can help. Thanks. a lot. two more slides. Discovery. Look at our Discovery product. The thing about Discovery is it looks at your data and classifies it, labels it. The good thing about that is if you have good data hygiene inside your organization, you have much less false positives and much less true positives. Good data hygiene within your organization reduces the workload for DLP admins. Fingerprinting, really, really important. Quick example. We look. We work with a lot of retail customers. They do block Black Friday deals. They're working on those ten months in advance. That's extremely secret data. They don't want it leaked. What they do is they store it in the directory and we fingerprint that. And even if someone looks at one of those documents and copies one sentence out of it, we can detect that. Copy and paste that sentence into an email. We will detect and block that email. Fingerprint your most important data. And lastly, APIs. We have a semi export. If you want to go to QRadar, Sentinel, etcetera, we have a semi export. We have an incident API. This incident API is two ways. So for example, if you have an employee that leaves a leaves the company, so in Workday, they're marked as a lever or they've resigned. You can have a policy or you can have a a you can from Workday, you can use our API to go in and find all the incidents and provide a report of the incidents for that employee over the last three months. You can also update incidents externally. So you can move the status, can change the status, the severity, etcetera. Policy API. Again, when you're looking at incidents, maybe you might have an external product that looks at incidents like a Sword product and would say we need to change the policy to address this. We have a policy API to do exactly that. And we have a protector API. The protector API is when you have your own custom applications in house and you want maybe they're communicating within the organization, maybe outside the organization. But if you want the data that they're transferring to be DLP checked, you can use our API to do that. An example is Confluence. If you're using Confluence, someone can take any data, paste it in their Confluence page, and everybody has access to that if they have access to the page. What we can do is pass it in the protector. We'll apply policy to it. We can then say don't submit this page to Confluence. So that's everything. If there's any questions, anybody wants to talk about any questions? Niall, if you have any comments? So now are you on mute? I am on mute. Thank you. I unmuted myself on the UI, but not on the hardware here. Thanks so much, Amit. So yeah. I saw a few people were asking about can we get the recording? Can we get the presentation? So yeah. The the link to the recording will be sent out to you tomorrow. Usually, there would be a doc section up there beside q and a where you could download the presentation in PDF format. Unfortunately, that's not functioning correctly today. So but we will send it out to you. I think it's a great presentation and it's got so much detail in there. I think it's definitely something you can keep handy. So I'm on to our team at the moment with regards to getting that sent out to you in a very timely fashion. Dinesh, Senthil, any notable questions there that you think could be brought up? Anything anything that jumped out to you? I think we covered all the questions. Yeah. Yeah. So all questions has been answered. Folvia, do you see any teams or anything like that in the in the chat, or was it, you know, was there, a good spread of questions? I'll take that as no theme no notable themes coming through from the chat. There was plenty of unique questions. And I sent out that survey, which I've closed, and I just popped up the poll. So if you can if you complete that poll as well. The survey, as I said, that gives us an idea of how the office hours is run-in general and how we can improve our office hours in general moving forward. And then the poll gives us an understanding of, well, how well have we done with regards to transferring information across you during this session. And I'm seeing the info I'm seeing the it come in, and I can see that we have a lot of high we're we're high and very comfortable and somewhat comfortable. So that's that's great. And yeah. So I suppose that's it. I'd like to thank I'd like to thank Emmett very much for for presenting today. Thanks to Dinesh and Santil for being so active in the q and a session. I look forward to seeing your survey responses. And thank you very much everybody everybody for joining. Thank you. Thank you, everybody. Really appreciate it. Cheers. Cheers. Bye now. Yep. Thanks, sir.