ISO 27001 Compliance for SaaS | SOC2 vs ISO | Girish Redekar (CEO & Co-Founder, Sprinto)

I’m Girish, one of the co-founders and the CEO of Sprinto. Sprinto is a platform that helps companies automate their journey to security and privacy compliances like SOC2, ISO 27001, HIPAA, and GDPR.

You need these certifications as a company to prove that you follow adequate security practices. Typically, obtaining these compliances takes hundreds of hours of manual effort and expertise, and Sprinto helps you to automate this journey and get that 10x faster.  

I’m an engineer first. Sprinto isn’t my first SaaS company; I co-founded and exited another SaaS company before this called Recruiter Box and grew it to a reasonable scale before I started working with Sprinto.  

As you can imagine, this is like a boring space, so you don’t come across it unless you have had some prior experience. And that’s what happened with me and my co-founder. When we were running a SaaS company and as we were trying to build larger and larger teams, there were many security reviews involved. And this is when we got asked about the company’s security posture and compliance like SOC2 and ISO.  

We tried to do it the traditional way, like talking to a bunch of consultants and trying to put all these things in place manually  

It took a lot of time, effort, energy, and money. There was the germination of the idea that “Hey, this can be a lot easier, it doesn’t have to be as hard, and there should be a way to do this much more painlessly”. So that was my initiation.  

We learned whatever we did in the process by actually doing it. When we were first developing Sprinto, during the first few months, we thought the best way to learn the ropes of anything like compliance was to go through the process ourselves. And believe it or not, we used to get ourselves audited multiple times. Sometimes SOC 2, sometimes ISO, and so forth.  

We learned a lot through that process. What exactly ISO 27001 is it’s one thing to read about theoretically, and there is much online content about what ISO 27001 means. But do it yourself to understand :  

• How do auditors look at it?
• What do they expect from you when they’re going through this?
• How different auditors might have different ways of looking at something? What variations happened between them, what do they expect of you, etc?

These are all the things we learned on the ground, but in a sense, we didn’t believe we could learn by second-hand information, and we did that ourselves too. There was a first wave where we gathered much expertise in what that process means and what the certification means after that.

These are all the things we learned on the ground, but in a sense, we didn’t believe we could learn by second-hand information, and we did that ourselves too. There was a first wave where we gathered much expertise in what that process means and what the certification means after that.

ISO 27001 is a series of specifications for running the Information Security Management System (ISMS). It is designed to help you design an information security program, which is a program that will help you keep whatever sensitive data that you handle as a company safe and secure. It is designed not just to be a series of checklists that you should follow but to help you design a system that comes up with a security program. It’s not a security program. It’s about a system that can give you a security program.  

That’s a very small but important distinction. It will not only help you create a program, to begin with, but it’ll also help you understand how to maintain it, improve it, and make sure it gets audited by a third-party board.  

It has all these components baked into it. It’s designed to be a way to help you implement the program, maintain it, to improve it, and get itself audited.  

It’s a way for you to sort of make sure that you, as an organization, follow the right security practices and come up with the correct security practices for you; each organization is different, and then continuing to improve on them will work overtime as well.  

For example, if I talked about Stream, they already added security. We were already SOC2 compliant. We have GDPR endpoints that we provide to our customers so that they can delete content if needed. All those things were already in place, and we are talking about this because the company is this type of series A.  

They talk about the ABC to create a system that will tell you your security program. Because every company is different, you cannot apply the same program across different kinds of companies in various industries, geographies, etc. It’s written in a manner that you can evolve the program to meet your specific requirements.  

The requirements are on the program’s structure, not the program’s specifics.

Fundamentally a company that gets an ISO 27001 is a company that needs to demonstrate its commitment to security to somebody externally or to an external stakeholder. That stakeholder could be a customer, a prospect, a partner, a cybersecurity insurer, or your board of directors. But it is someone outside of the company who needs some assurance that you follow the right security practices.

That’s the program’s main goal because that is where you depend on a certified third party to give you the certification. “Okay, these folks follow the right security practices.”

That’s the common thread about who should consider getting it or who are the first people who tend to do this.

In reality, you will see ISO 27001 used mainly by tech-first or tech-forward companies.

There are some geographical factors as well. ISO 27001 is extremely popular in Europe and Asia-Pacific, whereas it has a sister standard called SOC2, which is much more popular in North America.

If you’re a Tech-first or a tech-forward company, you have a lot of data that you process as a company, which means the data’s security becomes paramount. And then anybody who is working with you needs to start having some assurance that you keep this data safe and secure. And that’s typically the trigger for companies to start becoming the ISO 27001 company.

Then you have your usual suspects like your SaaS companies, technology companies, and startups to larger companies with a large digital footprint, even though they may not be directly technology companies themselves, but the tech-enabled largely, etc., that is what starts falling into the gamut.

The two are different standards, with large amounts of overlap in terms of the security practices you implement on the ground if you do either. But the two have different governing bodies. They have different ways of talking about things. But the outcomes and the things intents are very similar.  

There’s a fair degree of overlap if you as a company find yourself in a position where, let’s say, your customers, both in North America and Europe, would likely end up doing both SOC2 and ISO 27001. You would see a fair degree of overlap between the two; even though they will have different things, in terms of the actual practices you’ve followed as a company, there’ll be a fair degree of overlap.  

It depends on actually how you go about both of these programs.

I’m biased at Sprinto, but this is one of the main values that Sprinto brings to the table; we run these programs so that you can reuse the security practices and the evidence collected around security practices for both an ISO and a SOC2 audit. And that’s where you get a large reuse of overlapped.

But having said that, I’ve seen many companies run these two as independent things, and they get so lost in all the documentary work and all the nuances of this.

So it can happen if you think about this in terms of working backward from what the auditors say they do look like; there are many different things you need.

But in a sense, really at its core. You should be able to run both programs from a common security program. It depends on how you do it. It’s not natural, but if you work towards it, you can benefit from it.

It depends on the path you take.

To paint a picture of how long it would typically take outside of a platform, I’ve seen companies, let’s say, about 50 to 200 people in size, it can easily take you something anywhere between 3 to 9 months just to make sure that you’re working hard towards it and you want to ensure everything falls in place; I’ve typically seen companies take anywhere between, on average, at least six months or more.

And in this, if you add unknowns like something else started getting priority, this lost team, somebody on that project is no longer working on their project or left the company, etc. I’ve seen cases like this that had to get it’s extended to years and stuff. That’s a typical way it works.

Of course, if you take the help of technology to run this, this can become a lot faster.

This can happen in a matter of weeks as well. Because when you are leveraging technology to get in place all the practices and processes necessary for this in a very short period of time as well. You can compress that time.

But, if we were doing this manually, this typically is like a few months of fad, even for a company that’s 50 to 200 people. And so, as company size grows, this can typically become a lot larger as well.

I’ve seen a wide range of companies where that are bare, like a handful of employees but need to get this as get-to-go because that’s a way for them to establish trust and prove that they are serious about this, and they are not a fly-by-night operator.

SaaS means that I’m a custodian of your data, and they use this as a technique to build that trust from the get-go. So I’ve seen companies that are barely just formed just a few days or they’re working at their first for their first beta customer, their first pilot, the one decent approach they want this in their pouch just because it helps increase confidence.

But if you’re not in one of those scenarios and trying to do to break into a new geography, you need to establish trust.

The other common reason companies do this is that when you grow to a certain size, where you need a definitive way of knowing whether you follow the right processes as a company rather than just anecdotal evidence that the people will do what’s right.

So once a company gets to a few hundred employees, senior management starts depending more on processes than just anecdotal information about whether we are doing the right things. That’s not just about information security. That is about various processes in the company as well.

So even if you were not in a scenario where you had to do this at the get-go because an external stakeholder wanted it, I’ve started seeing that there is an intrinsic motivation for companies to start becoming ISO 27001 complaints once they get to like a few hundreds of employees in size.

ISO is a holistic standard. And one of the mistakes I made originally was that I should consider it a security standard. I used to think all the work involved here would automatically be around code and vulnerabilities and security related to your infrastructure, AWS account, etc.

But the reality is that the standard encompasses all the departments of your company, and it looks at security a lot more holistically. That means there are a bunch of practices you need to start doing as an HR department, IT department, engineering department, etc.

For example, some of the things that take time is that you must institute policies in the company. You need to ensure that your employees know this policy and acknowledge these policies when they join periodically after that.

Your employees are going through a security training program periodically and stuff like that. So, there are a bunch of HR implications for this. And this takes a certain amount of time, depending on where you are as a company in that process already. You might be mature on that already, or you may not be.

You need to start having a process around access management, which means how you grant access to different company members to different systems. That has to be in a gated manner. Randomly people can’t get access to your database, AWS account, or other sensitive information. You need to think about how to grant change or remove access for people, ensuring that when people leave the company, their access is revoked safely, and so on.

Change management is how you make changes to your application. So, there’s a bunch of things that you need to do downstream.

Vulnerability & incident management is an important piece. Many companies haven’t thought about this until they start building a program like ISO 27001. Coming up with the vulnerability management program and looking for vulnerabilities, tracking their severities, and making sure that depending on the severity, you close these vulnerabilities in a certain amount of time and pen testing yourself, etc., becomes like a stream of work.

There are six or seven dimensions along which we need to do work, and I’ve seen that companies depending on where they are in the maturity cycle with that dimension, can take longer or shorter.

For example, tech-first companies have done some workaround like incident management, vulnerability management, or access management. Still, they are typically short on policies, training, change management, etc. Whereas there are other companies, who are not necessarily your normal technology startup. They tend to be a little bit more mature in terms of their HR practices at times, but they’re relatively green when it comes to other practices related to vulnerabilities, change management, access management, etc.

So you see both sides of the thing, but the fact is that it just depends on as a company, there are some strengths that you have and those things are usually that you’ll be okay and you’ll need relatively less work but in other places, you will need to do more work.

ISO 27001 will specifically ask you to check everything holistically of where you should look for vulnerabilities. If I’m a software company, I need to look for vulnerabilities in my application, hosting environment, etc.

But the vulnerabilities might be elsewhere if I’m a different kind of company. But you need to decide where the right place is to look for vulnerabilities. I keep saying ISO 27001 is a way to think about it. It’s a framework saying, look at it here itself.

But there are natural implications of this. E.g., you should be looking for vulnerabilities in your codebase, your application, and the environment where you’re hosting your application. And you should do it continuously.

And the most important thing that ISO 27001 is that it’s not just important for you to look at vulnerabilities, but you need to have a clear process as to what you will do with the vulnerability you find.

You need to have a clear policy around defining the vulnerability. We’re going to rate the vulnerability on severity. There is something that tells us that this is the severity of the vulnerability in whatever form. It is a low, medium, high, or something. And based on the severity, you will have internal SLAs that are okay; if the vulnerability is of so-and-so severity, we, as a company, are committed to fixing that vulnerability and patching it within a certain amount of time. You could say, for example, for a high vulnerability, I will fix it in seven business days.

You’re taking on commitments of the sort of I am going to do this in a certain amount of time and, depending on the lower vulnerabilities, will take longer, etc.

And the important bit is that not only do you have vulnerabilities, but you also tag them, then you fix them, and you follow this process, and you make sure that you’re reviewing the fact that this is happening.

It’s not just about saying I have a policy; you must ensure it is followed. The program is talking about all these kinds of things.

A pen test is also important in this. ISO says that you should look at this from both sides like you could look for vulnerability inside, but you should also do a black box test. And then you should have somebody who is actively looking for vulnerabilities from the outside of your organization. And you should do that at least once a year. And whatever vulnerabilities are found in the pen test follow the same process I discussed earlier. You tag them to the severity to ensure they’re getting fixed in a certain amount of SLA.

You follow that process, and you collect evidence about the fact that you’re doing this. So those are the requirements around vulnerabilities and penetration testing that ISO 27001 usually discusses.

It depends on the nature of the SaaS company, and I’ll give specific examples:

If you’re a general-purpose SaaS company, then the answer about compliance is that you need are almost always geo-specific.

If you’re selling in North America, I would recommend typically to start doing SOC2.

ISO 27001 is a good starting point if you’re selling in Europe, Asia-Pacific, or the Middle East.

Eventually, I’ve seen that most SaaS companies become global SaaS companies, so you would have to look at both likely. But then you can sequence it depending on what’s more important for you.

That’s a fairly good starting point, but depending on the kind of customers you have who might be from specific industries then or there, they’re from certain geographies, certain other compliances start becoming important.

For example, if you’re dealing with a customer or where the nature of your company will deal with any healthcare-related data, then HIPAA or HiTrust will get asked of you.

If you are dealing with credit card-related information, then PCI will get asked of you.

If you’re dealing with data of any form related to European residence, either directly or indirectly, you will get asked for GDPR.

The same is if you’re dealing with data of California residents and you get asked for CPRA and so forth.

That is like a long tail of compliances that will get asked for depending on the nuances of which you would segment and which industry you sell into.

But, it’s a good starting point unless you are like if I were a SaaS company in the healthcare space, I would say that HIPAA first, along with something like SOC2 or ISO. But unless you are in those specific scenarios, ISO 27001 and SOC2 are good starting points. But then, depending on the specific nature of your business, some other compliances become important.

Key Takeaways:

• Think of ISO 27001 as a trust enabler for your business to help you gain the trust of your customers. It’s a necessity must-have for your company.
• Because there are so many region-specific nuances, overlaps, and commonalities, embrace technologies, especially around compliance automation, to optimize the pain points.