Name: Ask an Auditor: SOC 2 – What Early Stage Companies Need to Know
Uploaded: 2026-04-08T17:30:07.186Z
Duration: 1 h 28 min 44 s
Description: Ask an Auditor: SOC 2 – What Early Stage Companies Need to Know

Transcript for "Ask an Auditor: SOC 2 – What Early Stage Companies Need to Know": Hi, everyone. Thanks for joining us today. I'm Monica Olmstead. I lead partner marketing here at Drata, and I'll be your moderator for this session in our ask an auditor series. So So this series is all about bringing you the auditor's perspective. So you're not just reading about SOC two in a blog post. You're hearing how it really works from the people who run these audits every single day. This series happens to be very close to my heart as I have been with Jurada for four years, and this was the first webinar series we ever had. And I am so delighted to bring it back. Today's theme is SOC two, what early stage companies need to know. We'll focus on what actually matters when you're getting ready for SOC two, especially if this is your first time going through the process. Let's get through a little bit of housekeeping. We're scheduled for forty five minutes. We've structured this conversation a bit and have built it directly from the questions. Please do drop your questions into the q and a panel at any time, though. We do have a ton of info to cover today, and so if we don't get to your question in the q and a, we will reach out to you after the session. We will share a recording with you afterwards, so don't worry if you have to drop early. And please take a moment to take the two minute poll at the end of the session and let us know what topics you would like to see covered in the future. Alright. So I am very excited to be joined by Dallas Baker from Sensibaugh. Dallas is a senior GRC analyst two, specializing in SOC two reporting and security compliance. Dallas, thanks so much for being here. Would you mind giving a quick introduction, your role, and how you typically work with companies on SOC two? Yes. Thank you, Monica. Hi, everyone. My name is Dallas Baker. I'm a senior GRC analyst at Sensible, and I've been working on SOC two audits for a little over five years now. I also worked as a SOC two secondurity consultant in the past, so I have a lot of work with getting readiness completed and also performing the testing for these audits. In my current role as an auditor, I do everything from assisting clients with readiness, testing evidence, creating final reports, and reviewing other auditors' work. I'm also an ISO 27,001 lead auditor and have a both bat both a bachelor's and master's focused in cybersecurity from the University of Tampa. It's great to be here today. Thank you so much for joining us, Dallas. As I mentioned, we have a ton of questions for you, so we really appreciate you, being so generous with your knowledge. To set context for this session, for a lot of growing companies, SOC two is the first major compliance milestone. What tends to trip teams up is less the framework itself and more understanding things like how auditors actually think about readiness, what evidence really matters, and where companies unintentionally slow themselves down. So today, we're gonna break that down into a few core areas based on those questions that we received from you. So those core areas are what auditors look at first when they begin a SOC two assessment, common mistakes and blind spots that first that derail first time audits, practical guidance on systems, processes, and timelines, and what to do when ultimately controls fail because, let's admit it, sometimes it happens. So let's dive into it. Dallas, question one. What do auditors evaluate first when beginning a SOC two assessment? Great. So for our SOC two assessment, when we first start to review evidence, the absolute first thing that we're gonna go through would be your policies. They help establish a baseline for our testing, and they act as a source of truth for the audit. So we wanna ensure that your actual processes match up with what your policy state you're doing. A good example of this would be if you have an SLA defined for vulnerability scanning. For example, let's say you want to remediate critical findings within thirty days. If that's what your policy states you're doing, you would need to be enacting that in practice as well. After reviewing your policies and kind of setting that baseline, that's when we would move into reviewing actual evidence and verifying that what your policy state you're doing are actually being done in practice. Excellent. That's super helpful. I see someone's asking if they'll get a copy of the presentation, and we will absolutely share the recording after the session. So no worries there. Thanks for that, Dallas. So just to replay that for everyone, your policies set the rule of the game, and your evidence shows whether you're actually playing by those rules. Is that accurate, Dallas? Completely. Absolutely. Awesome. So next question. We hear a lot about readiness when it comes to SOC two. So, Dallas, from your perspective, what does SOC two readiness actually mean? For sure. So SOC two readiness to me would mean defining the scope of your system and controls and then ensuring that your controls are properly designed and operating effectively throughout your audit period. So begin getting the scope and then setting up your controls that are hookable to your environment is definitely the first step in readiness and one of the biggest areas that I like to focus on. With that process, it typically begins with creating a system description document. And this is a document where you would outline key details about your in scope system including infrastructure information, processes, and different boundaries of the system. And then we as auditors will take that document to guide us in scoping, aligning on applicable controls to your environment, and then identifying which controls are required for your compliance. Once we define the scope, the next step of readiness would be moving into ensuring that your organization has implemented and then is consistently enforcing the in scope controls. It's essential to demonstrate that the controls have been operating consistently over the full audit period rather than only a single point in time. The first step in readiness would be to conduct a gap assessment to identify and remediate any control gaps before the audit period begins rather than trying to address any issues after the audit period has ended or during the period itself. Specifically for us at Sensaba, our CSMs are very supportive during the readiness assessment and will assist with a gap assessment as well and can help you figure out which controls are in scope, how to best implement them, and make sure that everything is completed efficiently. Drata also helps immensely with readiness because you can go through and assign control owners, set renewal dates for your evidence, and you're able to see what controls are in scope and if they're currently in a passing state. And if they're not in a passing state, you can see exactly what's causing them to fail, which is extremely helpful with readiness because then you can remediate based on what the exact failure is without having to do a ton of research into it. Lastly, it's essential to keep track of your readiness as you progress through it to ensure that nothing is missed. And JAD is also a great place to track this because it will show you everything at that moment in time. What's passing, what's not, what needs to be fixed, all that good stuff. Awesome. So a few key pieces that I'm hearing are you've defined what's in scope, your systems, your boundaries, and your controls. You have named owners for those controls, and you can show those controls have actually been operating over a real period of time, not just on paper. And lastly, that you've done a gap assessment ahead of the audit instead of discovering everything in the middle of it. So that's a much clearer definition than just, you know, we have some policies written. Right? So, thank you for that, Dallas. Let's build on that with evidence because this was one of the top question themes that we saw in registration. So let me share this here. What types of evidence do you expect to see, and what distinguishes sufficient evidence from what raises concern? Absolutely. This is a big one that we get asked a lot. So as we mentioned above, the first step for us is to review your policies in place. From there, we evaluate evidence demonstrating that controls are not only properly designed, but then in policy and operating consistently throughout your audit period. This evidence that we request may include items such as screenshots of system configurations, personnel records, for example, policy acknowledgments, security training completion status, background checks, and device compliance data such as encryption and antivirus status on employee devices and any sensitive systems. A key requirement for evidence to be sufficient would be demonstrating that the control operated throughout the entire audit period. You'll hear me come back to this a few times today because being able to show that the control operated for the whole period is the biggest area to focus on. If it cannot be shown that it was operating for the period then the evidence would not be sufficient in that case. One of the biggest issues that I see arise is when evidence is either dated more than a year before the audit period begins or after the period has ended which would make it unusable for us as auditors since it falls outside that defined audit period that we agreed upon at the beginning of the audit. It's also important that the evidence clearly shows adherence to defined SLA's. So for example, if a policy states that a terminated employee's access must be removed within one business day, it's critical to show that the access was actually removed within that time frame rather than attempting to reconstruct the evidence after the period ends. Another example would be vulnerability scanning like we talked about before. If you state that. specific levels of findings need to be remediated within a certain amount of time, this is the SLA that we would test against. So that's why it's really important to define and update your SLAs within your policy to be as accurate as possible. You're also allowed to update your SLA and your policies as you go along. So as you're working through things, if you find, hey, we actually can't remediate this within a certain amount of time, you can always update your policy to reflect what you're actually able to do with your team. Frequency is another really important consideration because, for example, if a policy states that quarterly access reviews are performed, but during testing we find there was only an annual access review, this would show misalignment between your policy and what's actually being done. And in that case, evidence would not be sufficient. Lastly, inconsistent or conflicting evidence would be another concern. Different sources telling different stories is kind of a big piece of this. For example, if an access removal ticket shows one date stamp, but then the system access removal actually shows a different date stamp, that can raise questions about reliability of evidence and if the control is actually operating effectively. I love the way you're framing this because it's not just, like, do we have a screenshot? It's, is it within the audit period? Does it actually show that we met our own SLAs? And to your last point, do all the data points tell the same story? So I would say one practical takeaway that I'm hearing here is to start capturing evidence with dates and context now even if you're early because it's a lot easier to do that than to try to reconstruct it after the fact. Absolutely. Always better to get the evidence documented as early on as you can and as you go through the process rather than trying to collect it all at the end. Mhmm. Okay. Thank you. So we talked about what good looks like now, but I wanna shift into where things don't go smoothly because that's where a lot of learning happens. Dallas, we had a ton of questions from teams who either haven't done this before or who have had a rough first pass. So, on that note, what are the most common mistakes you see before a company begins its first SOC two audit? Absolutely. And that's a big point to hit on here, because if you can try to avoid some of these mistakes, it can make the process a lot smoother for you. So one of the most common mistakes that I see day to day is companies using policy templates without actually updating them to reflect how the business operates. So it can take a good amount of time to update the policies to reflect your actual business practices, but it's really important that you do that at the beginning of the audit prior to the period starting so that when we start to review, everything's aligned with each other. If they aren't aligned, it can create a situation where we're testing against policies that don't match what's actually happening, which can cause some issues during the audit. Another gap that we see is if you start to treat SOC two as a documentation exercise rather than being an operational exercise. So in these cases, we see a lot of people where they design their controls on paper and in their policies, but then they're unable to provide consistent evidence of what they've been performing over time. This becomes really apparent when we start to perform sampling. For example, we request code change tickets and personal onboarding and offboarding tickets for a random sampling during the audit. And if the evidence isn't able to be provided aligning with your policy, that can cause a big issue. I wanna dive into those examples of code change tickets and access management. So first, access management. So for example, if you define your onboarding and offboarding procedures in your policy and state that access reviews are being performed for all key applications. But in practice, when we review evidence, we see a delay in removing access, maybe missing access request tickets that are unable to be provided, or a lack of permission reviews, maybe only one or two systems rather than all key systems. This can create discrepancies between policies and what's actually being done at your company. Gaps also appear in change management quite frequently, particularly within any smaller engineering teams. So for example, changes may be deployed frequently without being consistently tied to tickets, approvals, or documented testing. This can make it difficult to demonstrate that the controlled processes were working throughout the entire audit period when we go ahead and request code changes for a random sampling of changes. So with the sampling, it really brings in an area where you wanna make sure you have evidence that matches to your policies because we take an entire population of things such as code changes that happened during your period and request evidence for just a sample of them. So it's really important to make sure that your processes are functioning for all changes where they can to make sure that when we request that evidence for the samples it's able to be provided. Also related to this, companies often underestimate the importance of collecting evidence from the beginning of the period, kinda like we mentioned before, rather than trying to gather it at the end of the period. This becomes a problem because even if the control was functioning at the beginning of the period, but it's not consistently logged or tracked, it can be difficult or almost impossible to validate during our testing that it operated for the whole period. This is another area where Drata's automations can be extremely helpful because the automated controls will provide provide us as auditors with daily evidence for the entire audit period showing if the controls were operating as effective or if there were any failures, and it will also show us what caused those failures, which gives us space to evaluate if this was a true control failure or something else happened, for example, if an asset wasn't scoped properly. So overall, those are the most common mistakes that I see begin before begin before beginning the SOC two audit. That's super helpful, and I hear the same sort of theme throughout, which is applying the concept of compliance and SOC two operationally as opposed to a check the box moment. Right? Because your your audit doesn't just happen once. You you have to continue to remain, compliant between the audits as well. So that idea of continuous compliance becomes really important here too. So, if I were to translate what you were talking about into, like, a checklist of things to avoid, I would say copy paste policies that don't really reflect reality. Right? Treating SOC two as a paper exercise, as I mentioned, instead of an operational one. Waiting to think about evidence until the audit period is over as opposed to continually thinking about capturing that evidence and then letting access and change management run informally but in the background. So I guess I would say for those tuning in, if you're listening and thinking we might be doing one or two of those, that's actually probably a great signal of where to start focusing this quarter. Next question. So we also saw a lot of questions from teams who feel like they've done a lot of what I would say is, like, the big lift or the big stuff, but they still aren't really confident about what might be what gaps might be lurking under the surface. So, Dallas, what are areas that companies frequently overlook or tend to underestimate during preparation? Absolutely. So to start off, one of the most commonly overlooked or underestimated areas is gonna be the personnel related controls, which I've talked about a little bit before, but I wanna dive into here. So this area in particular can become challenging because you may have many employees across multiple departments, possibly even multiple locations, possibly even multiple countries. So ensuring that completion of required tasks can take a significant amount of time as you rely on personnel to complete them. Some examples of tasks that would need to be completed by your personnel would be policy acknowledgments, security awareness training, and employee device compliance. A lot of the time companies can get stuck at this point because there are lingering and complete tasks that rely on individual employees to complete on their own time. Going back to Drata, this can help a lot with this because it keeps track of which employees are missing which specific areas of compliance and also allows you to send reminders on any incomplete compliance tasks. With personnel tasks again they can start to take up a lot of time if you're waiting on individual employees almost having to incentivize them to complete these compliance tasks so that's an area where I do see companies getting caught up a lot of the time. Another major area where gaps will frequently occur would be in vendor and third party risk management. So a lot of the times I'll see companies that maintain a list of their vendors but then that's all they have is just the list And they aren't consistently. keeping up to date security reviews, contract documentation, vendor compliance reports, or evidence of due diligence for those vendors. This becomes really difficult when vendors are being added quickly without a standardized onboarding process, and it's really important to define the third party risk management process within your vendor management policy and then ensure that it's being properly followed as new vendors arise. And then you also wanna go back and make sure that this process is also applied to all of your existing vendors as well. Moving to another area would be logging and monitoring in your environment. That can also be really underestimated because a lot of the times we'll see teams that have logging and monitoring enabled in their environment, but they're not defining retention periods, they're not regularly reviewing the logs, and they are unable to demonstrate that alerts are being sent and acted upon. So we are gonna always evaluate the configuration of the system, but then we'll also evaluate the operational execution of controls such as logging and monitoring for the entire period. It can be time consuming to ensure that logging and monitoring are actually configured properly in your environment and that alerts are being reviewed and actioned on effectively. Also, there can be a lot of false positives and noise coming in from these systems as well. Going to an overall view, one of the biggest things that companies often underestimate is the effort to maintain the audit ready status throughout the entire audit period rather than attempting to pull together all the evidence at the end of the period. Controls. that controls that are technically in place but not consistently evidenced over time tend to be a recurring pain point when it comes time to produce evidence for the whole period. This is another area where the Drata automations can be extremely helpful as they will alert on any control failures in real time. They'll allow your team and control owners to act quickly rather than having to manually sift through and investigate your infrastructure to identify what's causing the issue. Drata will tell you exactly what's not in a passing state, what's causing it, whether it be a specific asset or document that's Can I. just say, for our our viewers and listeners tuning in, I did not ask Dallas to shout out Drata? So I really appreciate the shout outs, Dallas. I know that, Drata, we work really hard on this continuous compliance motion that you're talking about. And, we did just have a a really, upgraded, excellent new TPRM product release because TPRM, that third party risk management really is a huge pain point for a lot of our customers that we have been working really diligently to solve, as part of their compliance journey. But, I do I do appreciate it. But I must say, that was that was on your your accord, and I didn't I didn't ask you to to call us out, but thank you so much. So, like, I'm glad that, I'm I'm glad that we are, valuable for the audit experience as well. Right? So what we do, and what we have always done since the beginning is we've had auditors weigh in on our product offering because, ultimately, the auditor is the, you know, we we need we need the auditor's buy in for what we're doing to ensure that we're doing it right. So we've always really held the the auditor in high esteem and have always wanted the auditor's, input into our product and how to do it the right way. So I'm it it makes it fills me with delight to know that, you know, that we are making the audit experience, hopefully, a little a little easier, a little more seamless. Absolutely. Moving on. Oh, good. Good to hear. So those those people related controls that you were talking about, Dallas, the vendor risk management, the logging and monitoring pieces, that those are such good callouts because they are easy to assume that they're handled, but they are often the places where gaps really show up during testing. We've received several questions from smaller teams as well, so those folks who don't have a dedicated compliance function yet, and they're feeling a bit overwhelmed by SOC two. So, a question for those folks that came up was how should companies approach SOC two if they don't have a if they don't have those dedicated compliance resources, if they're working with a lean team? Absolutely. For sure. So I've even worked with companies that have a small total of three people in the entire company before. So this is a really important point to hit on. A key starting point for companies without dedicated compliance resources would be to clearly assign control ownership across the business. So even in small teams, each individual control should have a named individual that's responsible for ensuring that the control is executed and also ensuring that there's proper evidence for that control. Without clear ownership, these control responsibilities tend to become everyone's responsibility or the thought of someone's doing it, but it's not my responsibility, which often results in an inconsistent execution and incomplete evidence at the end of the audit. Having specific individuals responsible for their specific controls can help create clear guidelines on who's responsible for exactly what. It's also really important to invest time early on in clearly understanding your audit scope. Many first time SOC two companies tend to underestimate how much effort is driven by an unclear scope or overall broad system boundaries. Narrowing the scope to be specific to your environment at the beginning of the audit can significantly reduce future workload. By properly defining scope at the beginning of the audit, it's gonna allow your team to only focus on the controls that are applicable to your environment rather than trying to hit every single control that's referenced in SOC two. Using a GRC platform is also a strong step for smaller teams because these platforms, for example, Drata, will provide you with policy templates, which can save significant time by allowing you to tailor your policies with your with their existing language to reflect your actual business practices. These policy templates will help significantly reduce how long it takes for you to write your policies as well. Policies, also keep in mind, can be updated as processes change. So Drata also maintains versioning and date history, which would remove the need for manual tracking of this documentation. But key area there is just gonna be your policies can be updated as you go along. If you find a new process, if you find something's not working, they can be changed as you're working through it. The automation capabilities in Drata are also a major advantage for teams without a dedicated compliance resource because with integrations and automated testing, it reduces time significantly for individuals because these tests can demonstrate to us if the controls operated throughout the period. This also makes it faster and easier for us to identify and remediate issues as they may come up. Companies also will really benefit from establishing a consistent cadence for control execution and review. So instead of trying to play catch up before the audit begins, setting monthly or quarterly checkpoints with your team for controls helps you ensure that evidence is generated and properly documented over time. This will allow you to review if there are any gaps before the period begins and allow you to address them before the period begins as well. So those recurring reviews are a really big piece of this to make sure that you're checking in with yourself throughout the process to see if things are actually being completed. This is super helpful. I really appreciate the granularity of practical advice you're giving to companies that especially are just starting out and just don't don't know how to where to put their efforts first with with, you know, limited resources. So thank you for that. And, you know, I wanna talk, now we've I wanna even get more practical here. So we've talked about common mistakes and blind spots, But a lot of registrants also asked, what do we actually need in place before we start an audit? So, to that question, what what systems and processes should be in place before a company is truly ready to begin a SOC two audit? Like, what has to be there before they begin? Definitely. So I'll begin on the system side. So a key requirement on the system side would be to have a centralized identity management system in place. Ideally, we'll. sign on enforced where applicable and enforced authentication standards such as MFA, across the all in scope tools. This helps ensure that access is gonna be consistently controlled and can be evidenced during your audit. A lot of the time And, oops. Sorry, Beth. yeah, and then I was wondering about, like, asset management as well. Absolutely. So when it goes into asset management, a lot of the times, you will need to have a reliable asset management or endpoint management tool or approach to make sure that you're tracking devices, that access either production data or sensitive systems as well as their ongoing compliance status. Mhmm. Another important system related item to focus on would be centralized logging and monitoring, and you wanna make sure that you have clearly defined alerting and retention configurations. So we need to make sure that it's defined where the logs are stored, how long they're retained, who's responsible for reviewing and responding to alerts, and any SLAs that need to be defined through that process as well. If you're missing the structure in your logging and monitoring system, it can become really difficult to demonstrate effective controls throughout the entire audit period when we request evidence for that. And then if you're using a GRC platform, what do you need to be ensuring from that perspective? Absolutely. So moving over onto the system side. If you're using a GRC platform, it's really important to ensure that your identity provider, cloud infrastructure, code repositories, ticketing system, HR system, and logging monitoring tools are fully connected and integrated with your platform. This really helps produce reliable audit evidence throughout the period, and it will help you view what may cause failures if it's something in scope, out of scope, actually give you the full picture view of what's happening. For example, in Drata, a lot of the time, we'll see asset specific failures flagged or specific documentation failures flagged, and that can really help your team with adjusting scope prior to the period beginning or remediating those items if they are true items that need to be remediated. Mhmm. That's great. What about vulnerability management? What kind of process needs to be in place there? For sure. So looking into vulnerability management, we wanna see that you are doing routine scanning, whatever is defined in your policy, whether that's monthly, quarterly, or, weekly, we've even seen in the past. We wanna make sure that you can show evidence of triage and then also remediation tracking. So the focus for vulnerability scanning is not only on identifying issues, but we also need you to demonstrate that you have a specific workflow for how findings are remediated and ensuring that your policy defined SLAs are also met when it comes to those remediations. Got it. What other what other factors need to be considered? Another big factor would be maintaining formal backup and data recovery processes. That's a big one because we always wanna see that databases are being backed up at least daily, and then we also would wanna see that you've tested your backup and data restore processes. So with that, Yeah. it helps us see that it's actually functioning as intended, your plan and policy, rather than just being written out and hoping that it works. So these tabletop testing exercise of your data recovery processes can really help you review and evaluate if anything in your policy needs to be changed as it relates to those processes. Got it. Got it. Also then there any yeah. What what are some things that some folks wouldn't maybe consider, like, the soft with regard to software development. For sure. So then moving into software development and specifically code change procedures, they need to be specifically defined in your policy with your processes truly following what your policy states. So it's critical that the processes operate consistently across the organization for the entire period so that sample changes can be supported with proper evidence like those samples we were talking about earlier. As we do select those samples randomly, you wanna be able to provide that evidence wherever it may need to be provided. Lastly, you really need to maintain a basic internal governance cadence, such as a regular security or engineering risk review. This really gives you a space where changes and operational issues can be discussed and tracked and any failures can be discussed prior to the period starting. This also demonstrates to us as auditors that security is being actively managed rather than handled in an ad hoc manner throughout the period. That's great. So this is, like, a really clear checklist across, systems. So identity endpoints, logging, and integrations, as well as processes. Right? So vulnerability management, backup and recovery, you mentioned change management, internal governance. And so once those foundations are in place, I think the next big question would be around timelines. Right? So how long does this all really take, and what are the things that tend to stretch it out? So on that note, Dallas and we, you know, I'm really sort of putting you through your paces here with, covering all of this information, in such a short time, so I do appreciate it. But that being said, how long does the SOT two process typically take, and what are those factors that most commonly extend timelines? Absolutely. So preparing for the SOC two audit is honestly probably the most time intensive phase, and the timeline for that can vary greatly. We've seen companies go through a few months to up to a year of needing to get ready for the audit. This part of readiness is usually driven by how quickly gaps can be identified and remediated and then also how quickly you can put those controls into your day to day operations. You also wanna be sure that consistent evidence is being generated and collected across the organization to show that you're doing these things and show evidence that they're actually being done. Another area that can be really time consuming is gonna be that system description document that I talked about at the beginning of this. It outlines. the scope, boundaries, key components, and how they operate. So this can really take up some time because it needs to be very detailed and accurate, and it has to include both the technical and operational sides of your business, and it needs to align with actual behavior in your environment. So pulling all that information together and putting it into that document can take a good amount of time, at the beginning of the audit for sure. So when folks are, you know, oftentimes, you hear about folks, companies wanting to get, you know, their SOC two assessment for a deal, so they're trying to rush toward it. But what I'm hearing from you and what I've seen is that that's not that's not best practices. Right? Best practices is doing it the right way, and the right way ultimately takes takes some some more time than folks necessarily are prepared for. Would you agree? Absolutely. For sure. And that's kind of just that beginning getting ready stage. That probably is the most time consuming. Once you are able to see that your policies are aligned with your controls and you're starting to collect proper evidence, at that point, it really does become a little bit of a weight off the shoulders at that point. But then after that, once you are prepared for the audit and you consider yourself to be audit ready and begin your engagement, this is when you have to set your observation period. So when we look at an observation period for a SOC two type two audit, has to be a minimum of three months and can go up to a year depending on your requirements, your customer's requirements, etcetera. The key requirement for this is to show that your. controls are operating through the whole period. So the window is intentionally set after you go through readiness to make sure that everything is implemented and set up correctly before you actually move into your audit period. So waiting on this audit. period, once you set it, let's say it was three months, we would have to wait three months before us as auditors can begin our testing. So this is an area that some people don't anticipate but you just wanna make sure that you know once you get to a ready state, you set the period and then you wait the period before we actually begin our testing on our side. So some people are surprised by that, I guess. Right? That's not what they put in the the timeline? For. sure. For sure. So just staying in communication with your auditor and the team can also help a lot because let's say you're ready earlier than expected. We can start your period whenever you're ready for us to. Or if you need some more time as well, it's something that we can work with you on and you wanna make sure that you set up properly for your organization. Got it. Okay. We are quickly running out of time, and I wanna get to, I'm gonna skip the this next question that we have and get to the one following. I think that you know, I have to be honest. We've had so much demand for this, webinar. It makes me think that we should do a SOC two focused ask an auditor, like, on a monthly basis. So just putting it out there. Maybe that's something that we should do. But, I wanna address something that came up multiple times in the questions that were submitted, which is more about how what to do when things don't go perfectly. So how let's see. How oops. Sorry. Here we go. Here we go. How should companies handle situations where a process is not followed during the audit period? I'm gonna skip ahead a little bit, Dallas. I hope you don't mind. Absolutely. Yeah. Perfect. So when we are reviewing evidence, we do see that control failures can happen. It does that that does not automatically mean that it's a deal breaker when it comes to SOC two. What matters most with the finding is how you respond. So if you notice a control failing or a process not being followed during the audit period, the first thing you should do is formally document that in your risk assessment. This should be recorded as a risk and you should also have a defined plan on how you're gonna remediate this going forward. This paints the picture for us as an auditor that you've recognized the control failure, you have a plan to remediate it, and that the failure was not overlooked or fully unrecognized by your team. It also shows that your organization is actively working to remediate the gap that was found and helps ensure that the control will operate effectively moving forward for the rest of the audit period and hopefully then going forward after that as well. Once you assess the risk for your control failure, it's also important to review your policies and procedures and make sure you update them to reflect any new processes or procedures that need to be put into place going forward. In a lot of cases, if it's an isolated issue and you can show that it was addressed properly, it may not raise an exception in the final report. But if it's a part of a broader pattern that we see going on time and time again going unaddressed, that's when it does become a more significant issue. Okay. So I'm hearing that what matters most is how you respond. So documenting the issue in your risk assessment, showing a clear mitigation plan, and updating our policies and procedures so the failure turns into a learning moment rather than a pattern. I know that this is an area that a lot of folks have a lot of anxiety about. So I think, framing it in that way is is helpful for sure. I'm gonna skip ahead because we're just at the end here, but I wanted to ask you, because we're getting close to time, I'd love to consolidate everything we've talked about into a single piece of advice. So, for those who are still here, let's see. Oh, sorry about that. If you had to leave this group with one recommendation for approaching SOC two effectively, what would that recommendation be? For sure. So my most important recommendation, and I've hit on this a couple times, is to focus on operational consistency with your documentation and not just your documents and policies alone. SOC two really depends on the controls being performed the same way every time over and over again in a repeatable process, not just how they're written in your policies. Consistently and how consistency and how your controls are operating day to day is what really drives audit readiness and a successful outcome. My other suggestion. would really to be be to ask questions throughout the audit process. So please don't hesitate to engage your audit team during readiness or during the audit period as we're here to help guide you through it. At a minimum, if we can't give you an exact answer, we can always point you in the right direction or help provide clarity on any questions when needed. That's great. That's again, that's a great reminder that, again, right, operational consistency seems to be the theme of this session, not just documentation. Operational consistency really drives SOC two success and that it's okay and encouraged to ask questions along the way and use your audit team as a partner. On that note, do you recommend, organizations enlist an auditor early in the process? I think that that's what I've heard, but I wanted to get your take on that. When should they enlist an auditor? Absolutely. Yes. I would definitely say early on in the process because not only can we help you with readiness, but then we can help you discuss that audit period and kinda get those discussions rolling rather than waiting and then having to set it later and then wait even longer. It's always good to get engaged with us as early as possible. Awesome. Okay. So we are a a minute over time, but I did I actually submitted one question for Dallas, and I would like Dallas, if you don't mind answering for me. What is, one thing about being an auditor that most people would be surprised to learn? For sure. So I think one big thing is that we are not in the business of trying to catch you doing something wrong. We're very much rooting for you to succeed. So a big part of our job is understanding how your business operates day to day and how to set controls in a place that makes sense and are sustainable for you and your team. Also, because every company's environment is a little different, we're constantly learning new systems, processes, and ways of doing things, which keeps our work very dynamic with clients. Lastly, I would say the best audits feel like a collaboration rather than a test test where we're working back and forth together rather than just us testing everything and coming back to you with any questions. So yeah, overall, that's what I think you'd be surprised to learn. I love it. That's such a good note to end on. I love the idea that the best audits feel like a collaboration and not a test, and that auditors are actually rooting for you to succeed. So thank you, Dallas, so much for the generosity of your insight today. And thank you, to everyone who joined us. We will share the recording following the session. I see a lot of notes about that. We will absolutely share it. There are a lot of questions that we weren't able to get to. We will follow-up after the webinar. If SOC two is on your road map and you're looking for support around readiness, automation, or continuous compliance, both Drata and Sensibar are here as resources for you. Our next ask an auditor will focus on SOC two versus ISO 27,001. It should be up on the Drata site in the next couple of days. It's on April 29, so please watch for it. And then make sure and let us know if you found this useful and what topics you'd like to see covered by taking the two minute poll, just two minutes when you log out. Thanks again, Dallas, for joining us, Thank you. and have a great rest of the day, everybody.