Join Strike Graph CEO Justin Beals as he discusses the nuances and intricacies of SOC 2 audits, AICPA's guidance, and the direction in which that guidance might be moving with audit experts Sam Oberholtzer and Michelle Strickler. 

Please enjoy a transcription of the audio recording: 

Justin Beals: 00:04 Hi Sam. Welcome to episode six of our videocast that we're doing for Strike Graph. We now have a habit and a pattern and someone new with us today. We're really glad to welcome Michelle Strickler from the Strike Graph team that has joined us on our videocast today.

Sam Oberholzer: 00:24 Yay.

Justin Beals: 00:25 Yay.

Sam Oberholzer: 00:26 Excited to be here.

Justin Beals: 00:28 It's Thursday, it's the first week of February. We're all hammering through our quarter and it's been super busy. I just want to take a second I think to just make sure that for those folks that are watching one of these for the first time, Sam you just get a chance to introduce yourself and Michelle to introduce yourself. We have a little bit of a heavy topic today that's really interesting. So Sam, please say hello and just tell us a little bit about your background in this.

Sam Oberholzer: 00:56 Absolutely. Thanks, Justin. So joined Strike Graph 10 months ago, originally was part of the customer success team, really running with the audit readiness aspect package that we offer. And then I started supporting and leading the sales engineering, product demonstrations, technical conversations for the sales department. I bring to the table about 6 1/2 years experience in the CPA world, where I perform Sarbanes-Oxley for public companies and then also manage hundreds of SOC 2 and HIPAA reports.

Justin Beals: 01:34 Yeah. Critical for our discussion today that background, thanks Sam. And Michelle Strickler, we're so glad to have another participant on these calls. You're also a member of the Strike Graph team. Please give us a little background.

Michelle Strick...: 01:46 Yeah. Thanks, Justin. Happy to be here. I am a CX strategist with Strike Graph. I help on all the compliance, type frameworks and issues, backend, making sure that we're all set up at the right frame. I've got about 18 years experience in IT audit in the audit world. Everywhere from an IT auditor with public firms to being an IT governance coach. Joined Strike Graph a little over a year ago and excited about this topic today.

Justin Beals: 02:20 Excellent. The both of you are the people that I love talking about the arcane and weird niches of audit and audit practices. You're a wealth of experience in understanding who constructs these things, how they expect them to be measured, what some of the technical terms are that are to think of as technical terms. For instance, I think I've spent a lot of time learning what the technical definition of something like assurance is Michelle with you. And really both my knowledge of what's required for a company to be successful and some of the acquisition of these trust assets has grown as [inaudible 00:03:00] guidance.

Justin Beals: 03:01 Now, recently auditor in a information meeting I was having with them shared with me a document. And Michelle, you shared with me that document as well, which is I think a FAQ from the AICPA, the about SOC 2 and software. Is that right essentially a publication that we've gotten?

Michelle Strick...: 03:27 Yeah. So occasionally CPA firms will reach out to the AICPA with questions and requesting guidance. This FAQ goes through some of the questions that auditors have about how to handle engagements, where they're using a tool like Strike Graph tool, a SAS tool to help with their GRC or compliance needs.

Justin Beals: 03:51 Yeah. And we're aware that there are competitors in the marketplace, like any good marketplace. So Sam, would you say that... I guess build on that audience concept a little bit, right? They're going to auditors, but auditors are dealing with all this new technology, and that must be why the question is arising.

Sam Oberholzer: 04:12 Absolutely. Because as you can see with a lot of these SAS compliance tools out there, a lot of the times auditors may have access or auditors are taking evidence directly from these tools instead of the database themselves or the other systems directly. So I think this is fair that the AICPA is tackling some of these concern that auditors may have or even service organizations might have around either the ethical, the professionalism, independence even when it comes to actually performing an audit and then also preparing an audit or an audit.

Justin Beals: 04:56 Yeah. The context is the trust services criteria, the document that essentially lays out how to get a SOC 2 audit was authored by the AICPA. And in its authoring, it requires an assessment methodology of either I think, a certified public accounting firm or an independent certified public accountant. And that's why you're all way is involved with CPA in one of these audits, correct?

Sam Oberholzer: 05:25 Absolutely.

Justin Beals: 05:26 Yeah. Well, let's talk a little bit about motivation. I always find it intriguing. I'm not a certified public accountant, I'm not a member of the AICPA, but it is always interesting to me when a governing body is starting to explain something or clarify something. It means that there might be some issues in the land of audit and they're trying to resolve something. So is that the motivation we're getting beyond just the questions that auditors ask that Michelle mentioned?

Michelle Strick...: 05:58 Yeah. When I was reading through the FAQ the AICPA put out, it was pretty apparent that there were two major issues that CPA firms were concerned with. One was maintaining their independence, and we'll probably dive into that. And the other was that some of these tools skirt the boundary of performing a control on behalf of management. So there's some language in this FAQ about how do you treat these GRC tools in are they a sub-service organization?

Justin Beals: 06:32 Right.

Michelle Strick...: 06:33 Yeah.

Justin Beals: 06:34 That's a sticky situation, I think. We see that in all of our customers as they're preparing for any type of assessment; ISO or SOC 2. We rely on a massive cloud provider like many of the technologies that are similar to us to perform things like the controls around physical security for those servers and things. And I guess it's starting to blur the line a little bit and that would become a concern of are you managing a control? Are you operating a control? Where is the line of responsibility? Because I think as we all know, without a clear line of responsibility, that's where gaps start to break apart in a security system, whatever the posture is.

Sam Oberholzer: 07:27 Yeah. And so actually I wanted to break down the article because in my mindset, I think the AICPA was to the point tackling management's responsibility and how to operate when using this tool versus considerations and concerns that may appear for the service auditor when they're actually performing their testing. So before we go down the consideration route, I do want to talk about something that I find interesting that AICPA that brought up that made me start thinking further, like where's the landscape going honestly?

Sam Oberholzer: 08:06 So three of the main things that they brought up was just like, okay, the new tool that you're including in your processes may not function as intended. Meaning, the completeness and accuracy. So Michelle knows this, but this seems very heavy on what we have dealt with Sarbanes-Oxley and public companies. So I feel like they're putting a little bit more pressure on not only management to understand, but how to make sure that the processing integrity is there.

Sam Oberholzer: 08:39 So I feel like that was the most interesting part considering that this trust service criteria I barely see, and I feel like more and more companies are going to have to start thinking about including that in their scope, just based on using this tool if they're going to use that for the system of record. So I thought that was pretty interesting to see where the shift might go around completeness and accuracy of data from one system to the next.

Justin Beals: 09:08 I'd love an example of that. Like how's that play out from actual control perspective?

Sam Oberholzer: 09:16 Yeah. So one thing I can think about when I just break it down very simply to a very basic control. So say that we're collecting logs for logging from AWS S3 buckets, and that format changed a little bit. And so the auditor just decided to take the evidence that this tool or that we collected and that's actually it changed the format potentially of the way the data's actually situated. So one thing that AICPA is saying is like, "Okay, one, how is management understanding that it's actually complete and accurate? That everything that it's told to log or to actually put into the tools database is actually what matches what was in theirs."

Sam Oberholzer: 10:09 And I think it's interesting that they're basically saying like, "Just be my mindful." And the service auditor has to be mindful with maybe collecting parameters of what is being used or if there's a job scheduler or whatever it may be to actually confirm that's complete and accurate instead of just taking it for what it is. So I think that's what they're trying to go thinking about we still need to make sure that it's actually accurate data.

Justin Beals: 10:41 Yeah. I think this speaks to something that you and I have talked about, Michelle, about how a control might have multiple layers of evidence, right? It's not like a control gets one piece of evidence, correct?

Michelle Strick...: 10:53 Correct. Correct. So you could have a control where the evidence needs to be not only a list of what's shot out of the system, but the parameters used to create that list or what buttons were clipped, what script was used to get there. And the auditor wants to see that nothing was left out, that the data coming out is complete.

Justin Beals: 11:17 Okay. So if I net this recommendation with the AICPA I think there's a couple things that I'm seeing as a founder or an operator. One is is that assumptions that you make about the evidence required to validate a controlled designer operation could be changed by the auditor because they feel like the providence of the information isn't good enough to provide assurance. And therefore, they're going to say, "Hey, look, I see you got the logs, but I realize that you're getting these logs in some fashion that I need a secondary set of evidence to prove to me that that was complete. You completed all the logs that I wanted to see."

Sam Oberholzer: 12:00 Correct.

Justin Beals: 12:02 And so I think you could see situations where whichever auditor you're working with could ask for extra evidence and you need a solution that can deal with that dynamism. if it's very checklisty right, I could see how like, "Oh, I have this integration that collects this one piece of evidence, I feel fully fine about that." And then the AICPA comes with this guidance and the auditor now is reviewing. They don't want to come under scrutiny by the AICPA and so they're essentially saying, "Hey, look, I think that we need to prove that this is configured properly, and that there's a policy." And all of a sudden you got two or three other pieces of evidence on top of something you thought was solved.

Sam Oberholzer: 12:45 Yeah.

Michelle Strick...: 12:45 And to Sam's point, that's why we may see that some service auditors will ask that these tools, these GRC tools or compliance tools have their own SOC 2, but include processing integrity.

Justin Beals: 12:59 I got you.

Michelle Strick...: 13:01 Yeah.

Justin Beals: 13:01 Intriguing.

Sam Oberholzer: 13:02 And so also, so potentially, potentially it's more so for the service organization themselves to include processing integrity controls because now if we are deciding to shift the focus in collecting evidence, not necessarily maybe even creating more evidence or something around that nature, but maybe including that tool as a control itself. So in a control over the review of data. So as you can see, you're pushing not necessarily more systems in scope, but you're including a compensating control to that category.

Michelle Strick...: 13:46 Yeah.

Justin Beals: 13:46 Yeah. It's a tight squeeze, right? Because they say processing integrity is optional for a full SOC 2 audit, but they may ask for providence of information. It's interesting. And I do think it comes down to this technical term of assurance. Like a relativistic way to measure how sure I am that the analysis that I performed is done well. Yeah. Okay. So let's go into the next one, Sam. What's the next aspect of this guidance?

Sam Oberholzer: 14:18 Yeah. And this is something that may seem obvious, but a lot of people might not think about this. So it's around the nature that the SOC 2 tool or tool provider, whatever we want to call does not incorporate all of the systems and processes that should be in scope, and so it might exclude. So sometimes there's not enough customization within the tool that allows the customer or service organization to opt in or maybe the tool is more like a checklist where you can't actually appropriately scope. So if one of you guys want to talk about how we help this concern.

Justin Beals: 15:07 Yeah. I'll certainly lean in first, Michelle, and then I'd love to your thoughts on this, right? So I think one of the things that I'm coming to realize having read this document as well and thought about it a little bit is that it's really nice our perspective on how Strike Graph is a solution and valuable to our customers. And that actually ties into the way that AICPA seems to be wanting to drive these types of assurances.

Justin Beals: 15:33 Our perspective, being operators of companies, but needing to meet a compliance requirement is that we needed a tool that gave us the flexibility to design a security posture, because we were making very unique decisions about technology, based upon our products, who our customers are and what needs to be delivered. And that's incredibly dynamic. No two companies want to be the same, if they can at all help it so they're constantly trying to drive at their differences.

Justin Beals: 16:01 Then you need that ability to flex. And we designed our Strike Graph solution to be like, "Hey, I have the unique control. I have a unique risk. I have a unique piece of evidence. I can add them into the system." So it's like you certainly get a large set of compliance information that you can operate out of the box, but you also get this things are going to change over time and you need that freedom. That's different than some other solutions in the marketplace that we looked at as we were designing Strike Graph that felt more checklisty.

Justin Beals: 16:35 Also, there's a completeness to the way Strike Graph works, where we're like the entirety of the SOC 2 standard is in there. All the trust services criteria, processing integrity, things like that. Where if you go as simple control checklist, there's not the full coverage. And I think the net on the other side of the looking glass from the AICPA, is that we talked to customers that have an Excel spreadsheet outside of their GRC platform. Super painful, right, Michelle?

Michelle Strick...: 17:04 Yeah.

Justin Beals: 17:04 Yeah.

Michelle Strick...: 17:04 Yeah.

Justin Beals: 17:05 It's just so duplicative. And so I think we'll lined up well there when we think about our customer experience and the product to the AICPA's guidance here, do you think Michelle?

Michelle Strick...: 17:16 I do. The AICPA was pretty clear that they wanted to make sure the service auditor understands the risks with their auditee, the company they're auditing. But also the company they're auditing management needs to understand their unique risk profile. And that's where we can help out with some very high level risks and the ability to enter customer risks. Because as you said, Justin, every company is different. There's going to be a lot of similarities, but those differences are key.

Justin Beals: 17:49 I can tell you in a discussion with a certified public accountant recently, that was one of their first questions. And I'm not sure if they read this article, but they wanted to know about the ability to customize the risk profile. And I was like, "Yeah." And it just seems natural to me that as a solution, you would be like, "Hey, we're unique, and this is unique risk and we want to track it." And I love that the AICPA is going this direction on their guidance, right, Sam. Yeah.

Sam Oberholzer: 18:15 Absolutely. And I think not only in that we have a product that is able to right size not only the company's risk and mitigate that, but I think we do a really good job with just really, really having that first onboarding call with our customer success team where we that's what drives our recommendations to our customers is that we do have the initial scoping call to really make sure that we're guiding the customer through the product in an appropriate way.

Justin Beals: 18:51 Anything else in this FAQ, Sam that we need to reveal?

Sam Oberholzer: 18:57 Yeah. So this one I didn't necessarily think about, this is completely fair. Is the fact that the certain owners of the SOC 2 compliance, they may come and partner with a vendor or a compliance software and they don't have the skills or competencies to actually use the tool. So I think that one was interesting because I just didn't think about that just because of our process, how we operate. But I think that's completely fair because you could essentially mess up your initial security program if you solely rely on a SOC 2 tool that you might not really understand.

Justin Beals: 19:42 Michelle, you're right in the middle of this as our customer experience guru from the product side. how do we think about customers taking ownership of their security posture essentially?

Michelle Strick...: 19:59 Yeah. Well, it starts with our risk assessment for sure. Where we identify risk owners and then as risks are identified, finding control and the owners of those controls. And then taking it one level down the evidence owner, which might not necessarily be a control owner. Because different people play different roles in the execution of a control. Our CS team does a fantastic job of getting folks up to getting them trained on how to think about risk, how to think about controls, how to think about evidence. And that competence question, I don't think we've struggled with that much.

Justin Beals: 20:43 Yeah. Not too bad. Yeah.

Michelle Strick...: 20:45 Yeah. With our customers, we get them pretty well prepared. They own their control environment, we're just there to guide them and keep it organized.

Justin Beals: 20:54 Yeah. In a lot of ways I think about our customer success team like a managed security services provider, right? Like there's nothing wrong with expert guidance. I think the auditor would want that to happen. And there's even a part of the SOC 2 standard that asks if you have a deficiency in knowledge that you outsource that. At the same time if that expert guidance is the exact same for every company, it's not really guidance. And maybe this is what the AICPA is complaining about a little bit. Yeah. Okay. Sam, what's next?

Sam Oberholzer: 21:31 Okay. So for the first half around just thinking about management and actually the service organization, their responsibilities, I thought those three areas are actually good concerns but they do, they absolutely remind me of public accounting, again. The way you had to assess the skills and the credibility of process owners, control owners, and then making sure everything's complete and accurate and basically incorporating all systems and processes. So as you can see, this feels where is heading just because we're incorporating, I guess more softwares there are automating. But in my opinion that shouldn't be overwhelming at all.

Justin Beals: 22:21 No.

Sam Oberholzer: 22:21 So the next section is just considerations for the service audit. And one of the ones that really caught my eye is, and I know we talked about this a little bit earlier, but it's around checklist, making every customer fit in a box. And I guess, Michelle, I guess from your experience in your previous life in consulting, how do you think this is being met through our services and how we partner with our audit firms?

Michelle Strick...: 23:01 Yeah. So in past life, I was a SOC 2 coach guru. And I would say that about 60 to 80% of all controls are pretty similar across the board. It's that 20 to 40% that really are customized and really need thought for management. And that's where the risk assessment will push them to, "Oh wait, we have this really funky risk because we're in a high risk industry let's say, so we need a specific set of controls to address those." That checklist approach, it's a can of worms. So it's not going to do anybody any favors because again, that 20 to 40% of controls need to be your own.

Justin Beals: 23:47 I think there's a weird application of the old Silicon Valley style adage, which is the 80/20 rule. Like if it works for 80% of the customers and you're building a great business, but the problem with applying that rule in this situation is an 80% success SOC 2 audit is a complete failure. You got to do all the controls well designed. The auditor, if they find one issue it will be an issue, right? You'll have to explain it in every deal you try and share your SOC 2 report with if you're lucky.

Justin Beals: 24:26 And so the details are critical to getting that 100% to passing every control. But I also want to say that I've seen this from auditors on some level, I don't think there's only a reaction to just the software. Some audit firms have created checklists and treated this so much like a factory floor model that they've contributed to this perception as well. And so I think it's great across the board, right? Both to ask auditors to essentially be more consultative in their approach and really pay to the details a little bit per customer, as well as don't just adopt a checklist, even though a lot of the controls are the same, right, Michelle?

Michelle Strick...: 25:15 Yeah. And that checklist approach really feeds into the topic we're talking prior. Does management have the competence to be able to set up their own program? If they're just going off a checklist, they may not know what they're doing.

Justin Beals: 25:27 Yeah. Yeah. Okay. Sam, was there any other on the considerations? Yeah.

Sam Oberholzer: 25:35 Yeah. So I think the biggest one that we touched a little bit, but we can go into a little bit more of how we put in controls to suffice this, but it really is around the independence between a service auditor and the actual performance of controls. And so I think that's just a really good topic to discuss because as we're seeing, and especially in our industry, there's becoming more and more blurred lines between audit prep and the organizations that are actually assessing the security posture.

Justin Beals: 26:16 I think that this is a great opportunity for us to play vocabulary game. Independence I have learned is a technical term, right, in the practice of assurance auditors. But we throw it around all the time, and people believe they know exactly what it means and I'm not sure they always do. So maybe Michelle can help us define that technical term a little bit. How does independence and assurance or accounting practices, how do we boil that a little bit?

Michelle Strick...: 26:51 Sure. So I'm going to boil it by adding a couple more technical terms.

Justin Beals: 26:54 Good.

Michelle Strick...: 26:55 It's independence in fact and appearance. So I think the best way to explain that is with an example. If your auditor is also creating controls, performing controls, giving you guidance on how to set up a security program, that's not independent. They can't then go and say and test their own work basically. So it really boils down to the testing of their own work, and then that's in fact.

Michelle Strick...: 27:29 In appearance, we also want to make sure that the auditor maybe isn't being promoted on the website. Maybe there's no like you couldn't think there's some underlying agreement going on. So probably not the best examples, but auditors do need to be independent both in fact and appearance. And that can be that appearance bit can be a little tricky, and that came up in this FAQ as well.

Justin Beals: 27:58 Yeah. So appearance, right? Too close to a commercial partnership with a vendor, transactions for leads or introductions. I can see these being ethically issues for that appearance.

Michelle Strick...: 28:12 Correct. Yeah. If undisclosed, yes.

Justin Beals: 28:15 Okay. Undisclosed, that's a good way to put it, right.

Michelle Strick...: 28:18 Yeah.

Justin Beals: 28:18 Because in one of the accounting textbooks I read they did have this in a paragraph about how you do pay the auditor. There is some relationship there and so that's why the appearance of independence seemed so critical in this specification. Yeah.

Sam Oberholzer: 28:36 And I think that's a really good segue, Michelle, around discussion around the website. Because yes, that's a concern because sometimes you're promoting partners or whether it's discounts or referrals or gaining some monetary, they definitely discuss to make sure that you're keeping up with integrity and being objective. And then also just making sure that these types of companies or audit firms are not getting commissions necessarily. So I think that's really fair.

Justin Beals: 29:18 And when we just think about Strike Graph, right? There's zero financial transaction between us and any auditor other than the auditor we hire to do our own independent audits. Of course, yeah. We don't provides leads, but we certainly welcome recommendations back and forth when asked for an introduction. We also always provide optionality. Like if we get asked for introductions, we have a list that people can pick from that they would like an introduction to so that we stay out of the way, right?

Justin Beals: 29:56 Like when I pull back, the reason that we have this philosophy at Strike Graph specifically is that a SOC 2 is a trust asset. If I eat away at why that's trusted, I have reduced the value of us and our customers in the whole marketplace. And so we value that when using Strike Graph, the auditor is independent so that a lot of trust can be placed in the asset that you get. And that's my ethical rant about it.

Michelle Strick...: 30:32 Yeah.

Sam Oberholzer: 30:34 And I think we do a really good job with just like maintaining independence with our audit partners, because one, we don't let our audit partners have direct access to any customer data. We don't have direct access, but even their audit prep, we don't give them access. So they can't edit anything. And I think another good solution is that we act, our customer success team acts on behalf of our customers in certain scenarios where we will actually ship the controls evidence on behalf to the audit partners so that they don't essentially have their input and design of controls necessarily. So I think that's also very important I guess to just keep to top of mind.

Justin Beals: 31:26 I always thought it was valuable the way in which our customer success team, as a part of our solution for our customers acts like an advocate for the customer with the auditor. That's great. A lot of customer in not having the language or the understanding to navigate it and having an expert. Essentially, if you were a big enough company, you'd have a director of compliance, right, Michelle?

Sam Oberholzer: 31:52 Yeah.

Justin Beals: 31:53 But for some of our smaller companies, they're not there yet. And they lean on our expertise just to help navigate some of these questions. Yeah. Anything else that you want to touch on from the document? And if not, then Sam, maybe we'll sow it up a little bit. Yeah.

Sam Oberholzer: 32:13 Yeah. I just want to know from your guys' standpoint, did anything really catch your attention within the article? Do you have any opinions on where you see, I guess, the updates even to a SOC 2 to in the near future. I would be interested in seeing your standpoint.

Michelle Strick...: 32:32 Yeah. So from an end user standpoint, so from the auditee, the customer that's being audited. I can envision some savvy auditors maybe asking to see the tool provider SOC 2 report. I could see them asking for a little disclosure paragraph that we rely on X, Y, Z compliance tool, and it does these things for our compliance program, so for our control program. That could come up.

Justin Beals: 33:06 Yeah.

Michelle Strick...: 33:06 Yeah.

Justin Beals: 33:07 That's excellent. From my perspective, Sam, I think that what stands out to me probably is the checklist approach, pushing back on that from the AICPA. I think in service of a better design security for people that are using SOC 2 as a trust asset. I think that going forward, when I think about what the AICPA is going to be doing, I also think about the other governing bodies a little bit, and how each of these standards like ISO 27001 have some form of assessment methodology in them. And I'm just really curious about the innovations that they're going to allow in that ecosystem as things move forward.

Justin Beals: 33:55 And I think one thing they've done is maybe not mapped out the next innovation that the AICPA or trust services criteria might bring, but essentially definitely continue to carve out the space that they want. And also hopefully given the certified public accountants and audit firms of the world, some clearer guidance about how to think about customers using software to help be more secure. Yeah.

Justin Beals: 34:22 I think it's a win-win. I think there's going to be some shifts and I think that buyers beware as you look at products to manage your compliance, of course. And hopefully this video is just one of the many ways that Strike Graph helps those buyers be aware and make the best choice for them at the end of the day for acquiring [inaudible 00:34:44]. Yeah. Yeah.

Sam Oberholzer: 34:45 Absolutely. And again, I really liked this article, so thanks Michelle for keeping ahead of all these updates. And I do want to just make a note like overall, I don't think customers should shy way from compliance softwares because it will at the end of the day, make their life easier. Whether it's saving time or honestly, resources and budget in the long run, but it's just good for them to not only understand what's happening in the guidance, but where the guidance may go, especially as compliance softwares get more involved in performing actual controls, either through automation or even honestly just taking over some of those tasks. It's just important to understand where the concerns are going to be or how the responsibilities may change depending on when the technology gets more mature.

Justin Beals: 35:45 Yeah. Michelle, any last final thoughts before we wrap up?

Michelle Strick...: 35:50 No. This FAQ is really insightful, it spurred a lot of discussion in my household. So yeah.

Justin Beals: 36:02 I certainly am really glad to see the AICPA active. I want to kudos them, right. They have a difficult constituency, it's a very technical field what they do, it's fraught with concerns beyond just SOC 2, financial audits and assurances, things like that. And they leaned in quite quickly, I think to say something about this. And so I'm glad they're making us aware.

Justin Beals: 36:29 These are always so much fun to do. Yeah. I realize they can be very dry topics, but I find it so intriguing and also just glad to help share some of the things I'm learning with our customers and future customers and a broader marketplace about these types of challenges. Everyone have a great day, thanks for joining me.

Michelle Strick...: 36:51 Yeah. Thanks.

Sam Oberholzer: 36:53 Thanks, Justin. Thanks, Michelle.

Michelle Strick...: 36:54 Yeah, thanks.