Steven Nguyen, Director of GRC at Segment, on the sea change brewing in the compliance industry around Security Sales Enablement and automation tooling.
Data security and compliance is vital to building trust between vendors and clients in SaaS, but it’s also a highly complex and time-consuming process. This expense of time is especially evident in the sales process; compliance verification often happens during the due diligence phase, where long surveys, NDAs, and watermarked certifications introduce friction and delay deal closing.
As a result, many operators are coming up with creative solutions to ease and expedite compliance requests. Steven Nguyen is Director of GRC at customer data platform Segment, where his department has devoted time to anticipating those requests and building innovative technologies to reduce costly delays. But most of all, Nguyen is pioneering a new way of thinking about GRC—and how compliance must adapt to an increasingly automated and faster world.
Aptible: What does the Segment security governance, risk, and compliance (GRC) team look like and what are their responsibilities?
Steven: The security and compliance team at Segment is small but scrappy. We have three people, including myself on the GRC. We have someone who is quite seasoned in this industry as our senior solutions lead, who leads our day-to-day operations—handling audits, handling many of our vendor requests, handling things like training updates.
But the most unique role on our GRC team is actually a dedicated engineer. “Engineer” is sometimes used pretty loosely in the GRC world—folks often dive into some level of technical detail—but ours is an engineer at the truest form: her role is to build tools and automation.
At Segment, GRC is broken up into five domains and our team supports all of them. Governance can be a pretty broad bucket, but it includes policies, training and awareness, and management reporting. Then there is Risk, the internal and external risks to Segment that need to be managed, such as third party vendors or partners. And then there are regulatory compliance and framework compliance such as ISO 27001 and SOC 2, and contractual compliance, which isn’t just meeting different laws and standards but meeting very specific customer requirements.
But there are two other pieces that are more unique to the GRC team at Segment. One is Privacy, which we partner with our legal team on. And then the last function is Security Sales Enablement, which means we are representatives of the entire security function at Segment and we help our sales org as part of their conversations with our prospective and current customers on how Segment protects their data. It’s a very big piece for us.
I would say our overarching objective in each of those five areas is maturing those processes: making sure that we can scale at the rate in which Segment is growing. And an even more specific lens within our team is scaling GRC activities through tooling and automation. It’s a big push within our organization to figure out how we do that.
A: What have been some of the challenges you’ve experienced at Segment as a vendor responding to security requests?
S: We have a really broad range of customers, from one-person stealth startups to some of the most recognizable brands in the world; we see the entire spectrum of the security due diligence process. And the challenges we see are not unique to Segment—they’re things that every company in this industry dealing with customer data will have to address. It’s the 500-question surveys. It’s “We need to come onsite to talk with you and spend a week with you.” We want to be transparent, but these things are time intensive and they allocate resources away from actually maturing the program.
A part of our time is also spent educating prospective or current customers in terms of what it actually means to use a SaaS solution and how a company like Segment protects your data. We have situations where questionnaires are written assuming we operate in a more traditional hosting environment, as if Segment runs a data center and we're physically in the server room with the rack and servers. Some customers don't have a concept of virtualization. Or they might refer to technology that's been deprecated or that Segment doesn't use. A huge challenge is that before we can get into the security conversation, we have to establish a baseline of what a SaaS solution is, what are our dependencies on cloud service providers, and how that co-ownership of security works. Those are the themes we see most often.
A: If we know that these are not unique problems, what is the solution? You’ve used “moving left” to describe a way to mitigate some of the delays of the compliance process. What does that look like?
S: If you think about the sales process as a linear process from start to end, from generating a lead to closing a deal or doing referrals, moving left means that security should not wait until the end of the deal-closing process to enter the conversation. It belongs earlier in that linear process.
Moving left means that security should not wait until the end of the deal-closing process to enter the conversation.
One way we’ve done that is by highlighting the security page on our website. When we created the page, the idea was to answer the table stakes security questions. Do you have security certifications? Do you have the basic things like encryption and access controls? And we actually measure the page’s effectiveness by the questions we get subsequent to that process.
For example, in the last few months we added a logo for our SOC 2 report onto that web page—we didn’t announce it, but we did know that our sales team was showing this page to prospects. This quarter we've seen a significant uptick in requests for our SOC 2 report. We also get questions around pen tests and other reports that would require an NDA. It is definitely useful and we’ve been able to reduce the kinds of questions that can be answered by that page and focus on these types of requests instead.
Another way we’re moving left is in providing our account executives and sales team with as much security collateral as possible. The scenario we're trying to avoid is a prospective customer’s due diligence team coming in very late in the sales cycle and saying, “Hey, we have 55 questions that need to be answered,” or “We need to have a meeting with X, Y and Z before we let the buyer sign off on this.” It's really getting in front of the security conversation early, because we know it's coming.
A: How do you empower the Segment sales team to handle security questions?
S: We’ve developed a process for our sales team that allows them to respond to questionnaires pretty quickly by leveraging tooling to assist in taking a first pass at completing security assessments. The tool allows them to answer common questions—and a dedicated folder we keep up to date with sales collateral, such as our recent pen tests, policies and standards, and diagrams. These are things we know customers are going to ask for.
We’ve also built escalation mechanisms into this process. There are certainly varying degrees to how technical some of these conversations get, and that’s when the security team will get involved. But having content and collateral available to the sales team is what we think of in terms of moving left. If they feel like the timing is right or if the customer brings it up, they can have those conversations earlier on and not have to wait to coordinate with the security team.
This is where the engineering piece can really make an impact. With sales enablement, you know the vast majority of the questions that you're going to be asked. You generally know what security documents that customers are going to ask for. So our engineer is focused on developing solutions and getting us these quick wins that allow us to get back to the customer much quicker. We’ve also been able to get security collateral like SOC 2 reports and ISO certificates in front of our customers by developing an automated process that will watermark them so that within minutes, the sales rep will have the report watermark ready to go. It is a pleasant surprise for our customers, and with the power of engineering we have the ability to enhance that process even further and make it even more seamless.
These are the things we are thinking about right now. We’re not trying to figure how to track things in a spreadsheet or keep tabs on whom we’ve sent a report. It’s already automated on our end.
A: What are the challenges you’ve faced in adopting this process? Is there a shift that is taking place or that needs to take place in order for GRC to become more automated?
S: For GRC, a lot of organizations are still very adamant about us completing their questionnaire or going through their process. And when you take a step back and you look at what they've asked and what we already have—for example, a security assessment that's based off ISO—well, we’re ISO certified. But they still want us to complete their security due diligence process.
It's important to understand that for the security practitioners in this conversation, we have the same interests and the same goal: to protect the customer’s data. We take security very seriously. We sign up for multiple rigorous audits and do multiple pen tests a year externally. We do this so our customers can get the assurances that they need, and the assurance comes via third parties who are assessing our application and reviewing our documentation.
It's important to understand that for the security practitioners in this conversation, we have the same interests and the same goal: to protect the customer’s data.
The challenge is GRC is somewhat stuck in its old ways, saying, “We must follow this process” when the question really should be, “Where should I focus my attention from a security compliance standpoint that goes above and beyond what the standard security assessments are asking?” Everybody has their own questionnaire. Everybody wants it completed, and yet these questions are very repetitive. We see security assessments that will ask for change control backups, access management… but these things are already covered in multiple audits. Instead these teams should be focusing on how their company specifically uses a SaaS solution and diving much deeper into those pointed questions.
A: What is your assessment process for evaluating a vendor? How do you think about what’s required from them?
S: We are in the midst of recalibrating our program, but what we do now is ask companies to rate their maturity in certain areas. We have different types of security assessments for different types of companies. For example, for a SaaS solution we will ask what you think your maturity is around the development lifecycle, or we will ask questions about your breach notification process. Can you respond within a week, a day, 72 hours? We ask folks to think about it a little bit more. The questionnaire maxes out at around 54 questions, and we do ask for certifications.
But we’re in the process of shifting that program to where we’re defaulting first to certifications. We want to be a part of the change toward leveraging the work of others as opposed to just relying on a self assessment. Then we’ll supplement certifications with even more specific, poignant questions. So we’ll get a SOC 2, which isn’t universal. It doesn’t contain every security control. If you’re a solution in AWS, we may have five to seven additional questions that are a little bit more poignant and that reflect your cloud security maturity. We need to really rely on these third party audits, but we will probably have 15 followup questions at most that we’ll ask that are not covered as part of the certification or pen test report.
In the event there is no third-party audit, we will likely revert back to our 50-question assessment or ask more questions. We will also note that as an exception to our process because we are trying to be a lot better about using these third parties that have been independently security audited in some capacity.
A: What does the certification landscape look like right now if so many companies are adding their own questionnaires to the compliance process?
S: The feedback that I hear from time to time is, “This certification doesn't cover XYZ.” And I don't disagree with that sentiment, but I feel like folks in this industry have been somewhat complacent in terms of the certifications that are available. That energy and feedback needs to be harbored and pushed back toward the certifying bodies that are creating these frameworks. As a company, we are complying to whatever standard is out there, but if we collectively think the standards aren't high enough for security today, let's collectively push back on that. It's really difficult for us to have a conversation with a customer if they're saying my SOC 2 wasn't good enough but their security assessment is. There needs to be a paradigm shift if everybody thinks their certification is better than the one that is more widely accepted.
There needs to be a paradigm shift if everybody thinks their certification is better than the one that is more widely accepted.
There are probably 10 to 15 questions that, if you get them from a customer, they’re going to make you a little bit uncomfortable. Nobody is at full maturity across the security spectrum. So there are questions that we can ask that will reflect how mature an organization really is. We might ask about how frequently admin accounts are reviewed. It doesn’t just allude to a specific process but it’s an indicator of maturity of security. But you look at how frequently these standards are updated by certifying bodies, and it’s not that frequently. Technology completely outpaces standards. So sure, you can ask a company to complete all these audits, but we should really direct that energy towards getting to certification standards that we can at least somewhat agree to for the next few years.
A: What is the future that GRC is moving toward?
S: At Segment we have only scratched the surface in terms of moving left. We need to even better anticipate what our customers are asking, and there is both a technical and a non-technical component to that. The non-technical part is being plugged into the industries and sectors that Segment wants to sell to and understanding the regulatory and contractual compliance considerations for those industries as we mature those processes internally.
GRC functions need to realize that compared to other core security functions, we are probably the least mature in terms of tooling and automation.
I think the first step is acknowledging where we are as a function and how well we have or haven’t incorporated some of the aforementioned technology. That's really why we decided to hire an engineer. We absolutely could have hired somebody who was very well versed in GRC, but the reality is we needed somebody to build automation into existing workflows.
There are a lot of opportunities. I think about a world where we have the tooling in place. Maybe we have an additional layer that allows for customers to be a lot more self sufficient. Assuming we have the NDA in place, they can look at the SOC 2 on demand. They can request it or the pen tests on their own through a customer-facing version of that same repository. If they want to know how frequently we do audits, why can’t they look that up on their own? Certainly there is a level of white-glove service related to security sales enablement, but when the customer is ready to view the content, wherever they are in the sales cycle, it’s all there and packaged up for them—thoroughly addressing their major security compliance and privacy questions. At the end of the day, what we provide at the end of the cycle today is not very different from what we would provide very early in the cycle. The collateral is there—let's just make it more useful.
Can’t dedicate an engineer to focus on moving left, automation, or other compliance improvements? Conveyor Rooms is a free security sales enablement tool to help any company move left so you can turn compliance into customer trust.
Move forward by moving left.