Name: Cybersecurity Essentials for Effective Compliance Oversight
Uploaded: 2026-02-10T17:16:07.223Z
Duration: 1 h 12 s
Description: Cybersecurity Essentials for Effective Compliance Oversight

Transcript for "Cybersecurity Essentials for Effective Compliance Oversight": Hi, everyone, and thanks for joining today's session on cybersecurity. I'm Trent Lanning, product marketing manager here at Comply, and I'm joined by Jeremy Trinka and Rob Nady. Jeremy, Rob, would you like to introduce yourselves? Sure. Hi, everyone. I'm Jeremy Trinka. I'm the CISO here at Comply. I've been working in the industry for about fifteen years. I got a variety of of experience across a number of different sectors to include federal government, financial sector, healthcare, you name it. Go ahead, Rob. Morning all, welcome and thank you for joining us here today. My name is Robert Mahdi. I'm the Director of Enablement for COMPLY. I work with our go to market teams, them on industry trends, regulatory guidelines, and really everything it takes to become a strong partner in financial services. I personally spent about two decades working in financial services or serving financial services, and the vast majority of that was as an IT infrastructure and cybersecurity expert working with RIAs exclusively. So certainly have quite a bit of experience working from a cybersecurity lens and guiding RIAs and excited to share this content with you today. Awesome. Looking forward to it. Thanks both. Some quick housekeeping for everyone in attendance. If you have any questions today, please feel free to just drop them in the chat. We'll follow-up on questions after today's session. Now before we get into today's session, here's a quick overview of comply. We give firms a complete view of compliance from daily employee oversight to firm wide governance. We bring compliance technology, consulting services, and education together in one place with the goal of helping you build a stronger compliance program. Today's agenda will go as follows. Jeremy will cover the intersection of compliance and cybersecurity and discuss some key topics including incident response, third party risk management, and business continuity planning. Then Rob and I will cover relevant regulatory context from the likes of the SEC and FINRA. Jeremy, I'm gonna kick it off to you. Alright. Thanks, Trent. So today, we're gonna talk a bit about cybersecurity essentials, but we're also gonna be covering why cybersecurity is now a compliance obligation and not just a technical one. So, this isn't gonna be a deep tech talk. I'm not gonna talk about things like encryption, firewalls. There won't be any technical jargon for today's discussion. We're mostly gonna be focusing in on what the regulators are gonna be expecting. So let's go back to why this matters. So the SEC and FINRA are now treating, protecting client data and responding to cyber incidents as a regulatory duty now. So this is no longer optional. This is no longer just an IT concern. I would argue that it's never been just an IT concern, to be totally honest with you. Trent, Rob and I, as we walk through, we're gonna talk about the expectations as they relate back to primarily RegSP, but also some of the new cyber rules and exam focus areas for smaller firms. So when you think about the reality of cyber risk, they create regulatory, operational and reputational risk all at the same time. They don't respect things like your org charts. To be totally honest, this is why cybersecurity responsibilities lie within the compliance realm. You as compliance officer are gonna be expected to be a bit of a liaison as it relates to cybersecurity events and functions. But taking it back to RegSP and what you need to know, the safeguards rule now is gonna be requiring written policies, procedures and controls to protect customer data. So looking at the 2024 amendment in particular, you're now required to have a formal incident response program with a plan, right? We could never not document things when the regulators come asking. Customer notification process, when data is accessed without authorization, and a number of other things. So we'll talk about that as we go throughout the slides. And let's carry on, let's go to the next one. So the compliance officer's role. So from a compliance standpoint, first job is alignment. Your policies should be reflecting what actually happens in the day to day and what your teams actually do from the day to day. You know, there may be an urge to go out to Google and find something like an incident response plan template and say, this is our plan. But I would strongly urge you not to do that. Regulators are gonna expect you to have written policies that reflect your actual incident management process and your risk assessment approach, right? They're gonna wanna see how it's handled in practice and not just what you've written down on a piece of paper or what somebody else wrote for you. So under RegSP, in particular, the firms must create and maintain documentation of the safeguards and incident response decisions. And if it's not documented or written down, regulators are gonna assume that it didn't happen. So a couple things that need to be crystal clear. Who owns decision making in your org? Who leads incident response in your org? How escalation happens? What does reporting look like? All of these are big considerations. And I would argue one of the biggest consideration is that cross functional coordination piece. Because cyber incidents don't, like I said before, they don't respect your org charts. Very often when an incident happens, it's gonna involve compliance, IT, operations, legal, right? But also your vendors. And that's kind of a key piece that we'll key it on a little bit later. All of these groups should be coordinating and communicating with each other under the lens of if an incident were to occur. And then finally, regulators want to see ongoing risk assessments. And that topic I'm not gonna totally cover during this call. That could be its own call, maybe we'll have a follow-up. But policies related to risk assessments and risk management can't just be policies on paper. So you actually have to be practicing it and proving that you're practicing it as well. So we'll go to the next slide and talk a bit about incident response and why it matters. So think of your incident response plan as your playbook for what happens when things go wrong. So picture this. Someone clicks on a phishing link in your org. Ransomware is downloaded and it locks up the whole machine. You may have things like your QuickBooks or your customer data is on the machine. Maybe there's a number of forms that are now locked up, right? These are the type of moments that your playbook needs to be accounting for. That particular scenario brings in a lot of different issues that cross into a lot of different realms of your organization to include the availability of data, which we'll talk about a little bit more later. But the latest updates from RegSP now tie your incident response approach directly to customer notifications. And I think we all know this by now, that the timing really matters. So firms have to notify affected individuals when it is practical, but no later than thirty days after determining unauthorized access occurred. That determining piece needs to be a part of your incident response plan. So when you think about what your internal steps are gonna be, you need to figure out how you're gonna classify events such as that. Who gets escalated to when those events happen? Are you working with third parties to help you? Is it managed internally? Do you have a managed security provider? All of those things matter here. But then also, how do you report and document your decisions? Because all of those tie back to and impact your obligations. So some good news, right? Regulators aren't gonna expect perfection. What they are gonna be expecting is a clear record to show that you made timely decisions, that you escalated appropriately, and that you're keeping documentation throughout the process. We'll go to the next slide and talk about one of those examples, which is tabletop exercises. So this is a favorite here. So one of the most effective ways that you can demonstrate your readiness for incident response is by holding a tabletop exercise. What they are is a scenario based walkthrough. You take a realistic cyber incident, You test your decision making skills. You play it out kind of like a devil's advocate style, worst case scenario type of discussion with the right people in the room. So from a RegSP standpoint, tabletops show that your incident response program has been tested and that it actually works. Your team is is gonna hopefully walk out of there with an understanding of how things are escalated and what your notification thresholds are. But they also produce the things that regulators are gonna be looking for in the event that there's an exam or an audit, which would be your decision logs, escalation timelines, that you've talked about it, you've tested it, gamed it a little bit. But then also that you are identifying gaps that are impacting your incident response capabilities and that you're planning remediation for those gaps. So for small firms, I'll leave it at this, a well run tabletop, I would argue, is one of the strongest indicators of your readiness for incident response type scenarios, especially if you're in an exam. But also, if you could show that you brought the right people into the room to talk about what would happen in these scenarios, it goes a long way. Not even just for regulators, but just for general operational hygiene purposes. Go ahead to the next slide. Talk briefly about third party risk management. So for most RIAs, vendors are probably the biggest source of cyber risk. The issue usually starts because firms don't fully assess or understand how vendors secure their data. In some instances, they may not even understand what data is going to their vendors. But under RegSP, you're required to oversee this aspect of aspects of your service providers and their level of access to customer information that you're responsible for, right? So a vendor breach could very quickly become a big compliance problem. So the amended rule makes it explicit. So firms, not vendors, are responsible for meeting customer notification requirements. And regulators will consistently flag vendor risk management as a priority for that reason. So especially when it comes to vendors that support critical systems or handle sensitive data, the expectation is that you understand what data's going to them, how they're processing it, what they're doing with it, how they're securing it. So talking about best practices from here. Effective third party risk management starts by simply knowing who your vendors are and what they're accessing. I would argue that visibility and understanding is probably the 80% of the cybersecurity job and then the 20% is actually executing on protecting it, right? So start with understanding. A best practice would be to create a central vendor inventory. Classify those vendors as high, medium, low risk. And then perform ongoing due diligence on those vendors as the business evolves, right? So that could be an annual turn. It could be upon a major change to your organization. But tying this back to Regis P again, they're gonna expect firms to ensure that vendors notify you when something goes wrong. Generally within seventy two hours. That way you can meet your own compliance obligations, which is that thirty day timeline. So just a closing thought. Key vendors should be part of your incident response planning. When you think about what your plan is gonna be, you think about how you'll do things like tabletops or demonstrate your plan. Account for vendors while you're doing so. And then if you want to go to the next slide, this will be the last one that I discuss and I'll turn it over to Trent and Rob. Business Continuity Planning Disaster Recovery. So this topic, it's probably one of the simplest in concepts, but it's probably also one of the most heavily scrutinized. Most cyber incidents today involve some level of loss. And that loss could be system availability. It could be loss of data, right? Using the ransomware scenario that I was explaining before and how that touches into different areas, right? So if a system is owned by ransomware, it is encrypted and it is generally not accessible. So that generates a system availability problem. So your ability to restore critical data becomes key. It becomes critical. You definitely can't bank on threat actors to unlock your data if you pay them. You need to be ready with a backup plan to restore that data. So if the systems can't be recovered and you can't prove that they can be recovered, regulators are gonna see that as a safeguards failure. FINRA in particular views this through operational resilience under rule 4,370. It requires business continuity plans that address disruptions like major cyber incidents. Regulators aren't, again, they're not gonna look for something fancy. They're not gonna look for something expensive. What they're gonna be looking for is just that critical systems are backed up, backups are protected from compromise and that recovery has actually been tested. Those three pieces. So common exam finding, firms have backups but they haven't been tested. Or they haven't been tested for years and they have been failing. Horrible scenario to run into. So be ready to demonstrate that you're prepared to restore if you needed to. And just remember, backups aren't just an IT issue. I would argue, if your business runs on technology, which just about every business does today, the control really does matter to you. So with that said, I'm gonna turn it back to Trent and Rob. We're gonna talk a bit about the context from regulators. Awesome. Really insightful stuff, Jeremy. We've heard a number of best practices today and insights into cybersecurity. Now we'll loop in some more regulatory context. First and foremost, cybersecurity is very much top of mind for the SEC. Just recently in its 2026 exam priorities, the SEC name dropped cybersecurity. They want to know that firms are adequately addressing governance, data loss prevention, and responses to cyber related incidents in their policies and procedures. This is a good time to reflect. Are your cybersecurity practices baked into your policies and procedures right now? And how regular is that process? Rob, do you want to chime in here? Yeah, absolutely, Trent. And I think when we look at how the SEC is approaching cybersecurity and exams and cybersecurity in general, the theme is consistency and resilience, and as Jeremy mentioned earlier, not perfection. First, there's a continued focus on preventing disruptions to mission critical services. That's extremely important. Examiners understand that incidents happen, but what they want is confidence that firms can continue operating, protect their clients, and recover without too much chaos. Downtime is a compliance issue when it impacts clients. Secondly, the SEC remains very clear on expectations around safeguarding client information, records, assets, cybersecurity, as Jeremy also mentioned, for quite some time has not been viewed as purely a technical function, but over the recent years from a regulatory perspective, it's a core protection and obligation for financial services organizations. If customer data is compromised, regulators see that as a breakdown in controls, it's no longer just a bad day for the IT team. This scrutiny is only increasing because of the fact that cyber attacks are increasing, they're increasing in volume, they're increasing in sophistication, and the impact is becoming more significant. Gone are the days of I'm too small, there is no reason a bad hacker or malicious person is going to target my firm. Everyone is a target, no matter how big or how small your organization is, no matter how robust or if you are just beginning to implement certain controls, this is a crucial topic and a crucial strategy that needs to be part of your business. The SEC isn't reacting to hypotheticals anymore. They respond to real repeatable patterns that they are seeing across firms. There guidelines that have been put out there. I can think back to the cybersecurity sweeps that were done around 2015 or 2016 and then the OCIE cybersecurity alerts, but over the recent years, examiners have been providing a little more context on what they're actually paying attention to. They're looking at governance and oversight and what does this mean. Jeremy alluded to a bit of this earlier, but who owns the cyber risk? How often is leadership briefed? Whether cybersecurity is treated as risk strategy within the business as opposed to an IT project? And how do teams react if an incident is occurring. They look closely at data loss prevention and access controls. Essentially what this means is who has access to what, why do they have that access, how is that access monitored, how is it granted for new hires, how is it revoked when employees are no longer part of the firm, a lack of defined permissions or over permissioning and being too loose with how data permissioning is done, that's typically an indicator of weak protocols or poor cybersecurity hygiene. Account management practices matter too. Things like credential protocols, what are the password policies that you have internally, obviously vendors have their own processes, but anything that you maintain in house or any passwords on things like your computers to start there or whatnot are extremely important. Multi factor authentication enforcement, how you manage privileged accounts, not everybody at your firm needs to have access to everything. There's certain data that only specific groups of people or individuals need access to. These are pretty basic controls in concept, but there's still frequent findings and they're the start of a lot of potential risks that may happen within your organization. Finally, incident response and recovery. This includes events such as ransomware scenarios that Jeremy touched on, but examiners want to see that you have planned for the hard days, not just have a plan put on paper, but that you actually tested your plan. They don't want to see that you just have a way to detect something has happened, but how do you contain it? How do you communicate that internally and how do you recover? One of the biggest pieces of advice that I could share and one of the ways that most incidents are reacted to in the most efficient way is encouraging a culture of if you see something, say something. Your team can be your strongest defense against cybersecurity incidents or they can be your weakest link. So encouraging them to, if something doesn't look right, if you feel like you get a pop up that shows up in a system, or if you're getting asked for information, or if you accidentally do put some information somewhere that maybe you shouldn't have, encourage your team to speak up and say something so that you can then kick your plan into place and analyze the situation and figure out what you need to do to react from that event. The biggest takeaway is this: the SEC isn't asking firms to eliminate cyber risk, they're asking firms to govern it, control it, demonstrate readiness, and that's where compliance and cybersecurity fully converge. This has been a theme throughout the conversation today, but for compliance professionals, cybersecurity is not just an idea that lives within your operations or IT teams or within your general business practices. It is a function of compliance and it's something that you need to incorporate into your compliance management program. Excellent, excellent insight, Rob. Appreciate it. We're gonna continue to discuss SEC and particularly RegSP in just a second. I did wanna take a quick pivot and look at a little bit from FINRA as well. Because they have cybersecurity top of mind. Here's a quote straight from their annual regulatory oversight report that connects compliance to cybersecurity. The failure to have a well designed cybersecurity program could result in compliance with shortfalls. So there is clearly a direct connection between inadequate cybersecurity practices and potential shortfalls. So what's really great about FINRA's annual regulatory oversight report is that they get really granular. What you'll see on the screen here is just some of the effective practices they've outlined in their report. Beyond just outlining what they expect from firms, FINRA really does try to provide guidance. If you don't have this report handy, definitely recommend downloading it from FINRA's website. What they're really doing here is translating cyber risk into observable behaviors and controls. For example, they call out monitoring for customer account takeovers. That means firms should have the ability to identify unusual activity, things like wire requests to previously unused third parties or logins from unfamiliar devices or locations, and then take appropriate action. From a compliance perspective, this is about escalation, documentation, and knowing when trading or fund restrictions actually make sense. They also emphasize multi factor authentication. Obviously, Jeremy in the room, this is pretty table stakes, but FINRA is explicit about scope here. MFA should protect access across email, operational systems, and platforms used by associated persons, contractors, and customers. Another area FINRA highlights is impostor domains and accounts. Firms should actively monitor for lookalike domains and fake social media profiles that impersonate the firm or its representatives and have written procedures for how those threats are identified and escalated. FINRA also points to outbound email monitoring, scanning outbound messages and attachments. This helps mitigate the risk of sensitive customer or firm information leaving the organization without detection. And then they address BYOD programs. The expectation is reasonable supervision, clear policies, and documented procedures around how personal devices are used for firm business. This is another area where compliance plays a key role in ensuring the policy matches how people actually work. Jumping to the second portion of this guidance here. So Jeremy has already touched on several of these earlier from a security perspective, so I won't rehash the mechanics here. What I do want to enforce is how FINRA is thinking about these controls through a compliance and supervision lens. So training and security awareness, one of them. FINRA continues to emphasize regular role appropriate training so employees can identify and report things like phishing and social engineering attempts. From a compliance standpoint, this is about consistency and evidence, making sure training is happening, that is documented, and that it evolves as the threats evolve. They also call out identity verification. So when funds are requested to move to or from outside accounts, FINRA expects firms to take extra steps to validate those sorts of requests. FINRA also explicitly highlights tabletop exercises, which Jeremy discussed in detail earlier. What's important here is that regulators view these as a practical way to test coordination, decision making, and communication across teams. Participation, follow-up, and takeaways are what turn these exercises into something defensible. There's also a focus on network segmentation. While this is implemented typically by security teams, compliance leaders should understand the intent behind it, limiting lateral movement if a threat actor gains access and reducing the blast radius of a potential incident. FINRA also emphasizes cross team communication. Cyber events, they often surface as potential fraud or suspicious activity. So clear communication channels are and escalation paths are critical. And finally, third party vendor risk shows up again here. FINRA continues to stress monitoring risk that arises from vendor relationships, especially where vendors support key systems or handle sensitive data. And if I can just add a couple of thoughts here. Obviously, we get to REGSP, we've talked a little bit about SEC guidelines and FINRA guidelines. And from a regulatory perspective, it's certainly important to be aware of what the governing bodies are looking for, what they're expecting you to do. But at the end of the day, it's about doing the right thing to protect your clients, to protect your employees, and to protect your business. And Jeremy had mentioned this earlier, as the regulatory guidelines have adopted and incorporated some of these best practices, from an IT perspective, a lot of this has been best practice and recommendations for a very long time. And look, we're aware as we're sharing these guidelines that incorporating some of these strategies into your business to have strong security hygiene, it can take away from the convenience that your team has and how they operate. It could change how your team is engaging with technology. So cybersecurity is going to come at the expense of convenience at times, and it's going to change the way your team does things. But that's where it's extremely important to have the buy in from the leadership. It starts from the top, and that culture then becomes a culture of cybersecurity protection and allows you to incorporate and get a little bit more buy in from your team when it compromises some of the convenience that they have or it sacrifices some of the convenience that they have on their day to day. It's for a good cause, not only from a compliance perspective, but at the end of the day, it's the right thing to do as a business. Yeah, and I just wanted to chime in here as well, because what you're saying, Rob, really resonates is the fact that it may change some behaviors. There may be some minor inconveniences as a result of doing some of these things. That's understood. You know, that's just kinda like par for the course with cybersecurity. And segmenting networks, I think, is a great example to kinda key in a little bit more on like a down to earth example here. Using the term segmenting networks can be border on jargon, technical jargon. But to make it a little bit more simple. You think about you have guests come to your office. And they're gonna wanna connect their laptops, work off a wireless network. Are you gonna put them on the same network as your production machines? You gonna put them on the same network that your employees are on? Or where you have printers or access to your servers, right? I would hope the answer would be no, right? And you've taken a little bit of time and made a little bit of investment to say create a guest network. I would argue that that is more of a time investment more so than a technology investment. Because at this point, just about every wireless router in existence will provide a guest network for you. But I just wanna, you know, provide this as kind of like a down to earth example of simple changes that require relatively minimal investment but make massive impacts relative to your security posture. So go ahead, Trent. No. I really like that example, by the way, Jeremy. You're welcome. Now, Jeremy, I know you mentioned RegSP a number of times earlier. This is a really, really critical area that we're gonna touch on a bit more as we close out today's session. So for firms within our AU and below $1,500,000,000 the compliance deadline is June 3. That means brand new requirements for things like incident response programs and client notifications, which we'll cover in more detail in just a second. But Rob, I know you've worked in IT space for a number of years with a lot of smaller firms. Curious to hear your thoughts on this. Absolutely. And over the past several years, regulators have heightened their focus on cybersecurity. We've shared this theme consistently throughout the conversation, but I'll mention it again. Cybersecurity is no longer just a function of IT. And REGSP is one of the clearest examples of how cybersecurity and compliance are now inseparable. At its core, Reg SP is about one main thing, in my opinion, and it's protecting customer information. What has changed, especially with the safeguards rule and incident response amendments, is that regulators now expect firms to prove that they're doing this in a structured, repeatable way. From an incident response perspective, compliance sets the expectation that you don't improvise in the event of an incident or a crisis. Firms need a documented incident response plan, including clear roles, a decision making authority, escalation paths. When something happens, regulators want to know that you followed a plan, not just reacted quickly and spontaneously. That flows directly into client notifications. REGSP isn't about isn't just about if you notify clients, but when you notify them and why you notify them. So you need a defensible process to assess material impact, determine risk or harm, and communicate clearly and consistently. Silence or delay in communicating is usually more damaging than the incident itself. This goes back to the idea that I had shared earlier. If you see something, say something. It allows you to enact your plan and assess the situation quickly and then notify your clients, if needed, to address the incident response, as well as the client notification piece here. Vendor due diligence is another major pillar, as Jeremy mentioned, in today's world. Data is everywhere. Any sort of cloud based tool, whether it's your email, your CRM, your portfolio management tool, whatever it is, it's more than likely that you have data out in the cloud rather than sitting in a server closet like traditional technology, but in doing so, you've now incorporated a ton of vendors into your business operations and that also introduces the concept of needing a very strong vendor due diligence program. Regulators recognize that many breaches don't start from within your business. The compliance expectations now extend to how you select your vendors, how you assess your vendors, how you contract with them, how you monitor third parties, especially those that maintain customer data. If a vendor has weak controls, the regulators view that as your risk. Finally, on proving compliance, firms need evidence, not just policies. That means that documented risk assessments are required, employee training records, vendor reviews, testing results, governance oversight, the question from regulators and also your clients. If you haven't started receiving questions from your clients, I assure you, you will, as I've seen in many interactions with clients that I've served over the years, but it's no longer do you care about security, it's show me how you care about security and what are your policies. The takeaway is this REGSP doesn't turn firms into cybersecurity experts, but it does require leadership. It requires accountability and action that you can demonstrate in terms of how you're safeguarding your client data. Thanks, Rob. I know there are probably some people wondering just like these new requirements versus what was currently existing. So I've included this just to give people a high level view of the meaningful shifts that are worth calling out. So first, incident response is now explicit. Firms are expected to have written incident response procedures designed to detect, assess, and address unauthorized access to customer information. This aligns with the incident response frameworks and tabletop exercises Jeremy walked through earlier. Second, client notification is now defined. So if sensitive customer information may have been accessed, firms generally have a thirty day window to notify affected individuals unless an exception applies. From a compliance standpoint, this elevates the importance of escalation paths, decision making authority, and documentation during an incident. Third, third party vendor oversight is no longer implied. The amended rule requires written policies for monitoring service providers with access to customer information. So this reinforces what we've seen from both the SEC and FINRA. Vendor risk is part of your cybersecurity program, not just adjacent to it. There's also a broader definition of protected information, expanded coverage under the safeguards rule, and new record keeping expectations. So firms need to maintain written records demonstrating compliance with both the safeguards rule and disposal rules. And finally, while the annual privacy notice requirement still exists, the rule does allow for limited exceptions when certain conditions are met which gives firms some operational flexibility. Pausing and zooming out a bit, it can feel like a lot. But these sorts of requirements coming from the SEC really do show its sustained interest in information security, especially pertaining to the data of clients, Rob, as you alluded to. I will note that Complia's consulting team does have a dedicated Reg SP service offering. It includes things like conducting a risk assessment, helping create the policies and procedures we've been referring to during this session, and creating a customized incident response plan among other things. So if you're interested in that, please do reach out. We're definitely happy to help. If you have any questions about today's session, feel free to come to me personally. My email is tlanningcomply dot com. That's t l a n n I n gcomply dot com. And if you've asked questions in the chat today, we'll make sure to provide responses as soon as possible. Jeremy, Rob, any last word from you guys before we close this thing? In relation to the chart that Trent was just talking us through. I think as you're going back to your organization and figuring out what do we need to evaluate, what do we need to assess, there's two key pieces here. There's the policy portion and what do you have documented, what's within your policy, and then there's the execution and practice. And as you're incorporating enhancements to one or the other, it's important to make sure things align. You can't have something written in your policy that is not supported by your practice. And if you have something in practice, it needs to be captured in your policy. If there are inconsistencies, that becomes very difficult to explain what's actually happening. It becomes very difficult for your teams to be aware of what they should be doing. So if you work with compliance professionals, hopefully you're working with Comply, but if there's another resource you're working with, have this conversation with them. If you manage IT in house, have this conversation with your IT resources internally. If you outsource your IT function to a third party, have this conversation with them. It's important for them not to incorporate only general best practices, although a lot of those are part of what the regulators are looking at. And it's important to have this conversation around Reg SP and what the regulatory body that your business is subject to is requiring so that you can address these items and best be prepared for a regulatory event when it happens. And more importantly, be prepared for your day in and day out protection that's required to secure your business and your clients. Yeah, I think that was great. I think parting wisdom wise, I'll probably jump back to that age old acronym of KISS, the keep it simple silly. You know, at the end of the day, I think there's a of terminology and jargon that gets thrown around in the cybersecurity realm. Really, honestly, at the end of the day, you know, when you think security as a people process technology problem, a lot of people hone in on the technology problem. When really 90% of the work is people in process. Rob said it multiple times, just foundational user awareness, it does so much. That's the min max here is how you handle your people and process far outweighs any technology that you can buy. So when it comes to putting things down to paper and making sure that you're doing what you say you're gonna do, spend that time focused in on executing a real process and having the right discussions with people so that you know when to escalate. When something hits the fan, you know exactly what to do rather than having to ideate around, well, maybe I should have done this, I should have prepared that. When you're ready to go, you're ready to go and it becomes a reference book rather than something that should have been thought about ages ago. So I'll just leave it at that. Awesome. Thank you, Jeremy. Thank you, Rob. And thank you everybody for attending today. We'll see you in the next session. Bye.