Our road to cyber security certification: We did it! Lessons learned

I haven’t posted anything in recent months, for a good reason: I was super focused and busy with our final steps towards our certification. And it worked, we achieved the certifications!

Hard work pays off!

And now that we reached this milestone I want to share a few of the lessons learned on this journey.

Be realistic: From SOC 2 Type 2 into Type 1

SOC 2 Type 1 and Type 2, which are the differences?

For those who are not familiar with SOC 2, let me first explain the difference between SOC 2 Type 1 and SOC 2 Type 2.

If you look at the definition from AICPA’s (American Institute of Certified Public Accountants), there are two types of reports:

• a Type 1 report on management’s description of a service organization’s system and the suitability of the design of controls; and
• a Type 2 report on management’s description of a service organization’s system and the suitability of the design and operating effectiveness of controls.

As you have noticed, the only difference is that the SOC 2 audit not only reviews the design of the controls but also their operating effectiveness.

In practice, that means that during the Type 1 audit, the auditor reviews that the controls were appropriately designed and, at the time of the audit, they have been implemented.

On the other hand, the Type 2 audit reviews the same but also includes asking for evidence to prove that it’s true that you had the controls implemented during the reporting period.

The reporting period can be as little as 3 months (which could happen with a new service that must be audited soon), while the usual period is 12 months.

Shoot for the moon, even if you miss you’ll land on the stars

Initially, our plan for 2021 was to achieve SOC 2 Type 2 at the same time as ISO 27001. Although we were in a very good position to pass both audits, we had to build the ISMS (risk assessment, KPI, internal audit, etc.), the documentation, the additional operating procedures, and so on. All that required a joint effort from different teams, which had to be dealt with as we kept developing our Event Store Cloud and improving our EventStoreDB.

As we progressed, we identified that we would not have as much time as we expected initially to complete everything at least 3 months before the external audit. Because of that, we decided to change the audit scope from a Type 2 into a Type 1.

The lesson we learned from this is to be realistic about your available resources to reach your goals.

Planning allowed us to identify delays

Aligned with the previous lesson is the planning. As we had a defined plan, with tasks duration, dates, and assignees (I already said that I love Gantt charts), we were able to identify deviations.

The deviations happened because of the difficult balance between operations, development, and the new activities required to achieve the certifications.

Just in case you don’t know, you usually have to plan your audit months ahead of the estimated dates with certification entities. Also, if you request a change for the audit scope or date less than 30 natural days before the beginning of the audit, then the certification entity may charge you a fee.

We had to change the date we had initially scheduled and the scope of the SOC 2 certification (from a Type 2 into a Type 1). But as we had a plan, we could observe that we were not going to reach our initial goals time enough before, so the changes that we requested from the auditor didn’t have any extra cost.

The lesson we learned from this was to keep the plan updated and review it frequently to identify potential problems and address them on time.

Reduce data duplication as much as possible

Implementing an ISMS requires adding new inventories to keep track of assets, issues, rights, etc.

We are using a commercial GRC (Governance, Risk, and Compliance tool), yet it is not easy to find a tool that solves all your needs, so a spreadsheet came to the rescue!

Let’s accept it, a spreadsheet is super versatile, easy to implement, and almost everybody is used to working with them, so its implementation is quick and easy… but the counterpart we faced is that that they grow in number and we face the risk for having non-updated data.

To use an example here, we have several spreadsheets with our employees' list (to keep their assets, their tools access, etc.). Fortunately, our employee rotation is very very low, but what happens when an employee leaves? We have procedures in place for everything needed, but there is a manual work overhead because of the multiple spreadsheets we have.

There is inefficiency when lots of manual work is required and also the risk of missing something (which to be reduced requires additional verification lists, which then add more manual work). An application could solve this issue.

We are now exploring tools that will ease our transition from multiple spreadsheets into our own application to address this situation. Among these tools, we can mention Zoho Creator, Airtable, and Smartsheet, although there are many more.

Since building and using these spreadsheets, we’ve identified what we need and we’re in a better position to develop our own solution.

The lesson we learned from this was that next time we need a spreadsheet we will create it using a tool that allows us to scale it up in the future.

SOC 2 or ISO 27001 first?

Our approach has been to address ISO 27001 requirements first and then go for SOC 2 ones. The only reason for that was that I was more experienced with ISO 27001.

If somebody wants to ask if having ISO 27001 already implemented required little effort to implement SOC 2 I will say that it’s true that they both share many components, but no matter which one you implement first: you will end up writing documentation specific for each one.

I tried to reuse as much as possible, and we succeeded on that, but anyway there is multiple documentation that is only required in one of the frameworks, so you won’t be able to avoid writing specific documentation for each one.

But I can recommend you to take a look at this great spreadsheet that AICPA released mapping SOC 2 against ISO 27001 (and other frameworks), as it will help you quickly find out which requirements you’ll have already covered with ISO 27001, and which not.

The lesson learned from this is that embrace patience; you will have to write certain documentation specific to each framework.

Find an auditor that will be able to audit all the frameworks you have in your plan

I’m not reinventing the wheel, you’ll find out plenty of blog posts about the benefits of using the same audit firm to audit both frameworks at the same time.

But keep in mind that when an ISO 27001 auditor is auditing you, he will expect to find certain information, while the SOC 2 auditor will expect another one. This doesn’t mean that they are separate worlds, but at the end of the day, they have to ensure that you’ve fulfilled what the framework requires, and as there are differences, you will face that certain evidence is for ISO 27001 only and other will be for SOC 2 only.

Don’t worry, what doesn’t kill you makes you stronger, and we can assure you that complying with them has made us more secure than implementing a single framework.

Our experience with our audit firm was very positive and I think we made a great team together with them, because we’ve tried to use the external audit process as part of our improvement (that’s something I’ve always explained to my customers when it was me the auditor), so on this occasion, I applied the same rule to us.

Although we supplied evidence for both SOC 2 and ISO 27001 together, and the auditors were together during the interviews, the process required lots of time from our side. I don’t want to imagine how painful it would have been if we had chosen two different audit firms.

The lesson learned from this was that we did right (and recommend) following the recommendation for choosing an audit firm that could audit all the frameworks we implemented (and we plan to implement).