Last Updated onReading Time: 2 minutes
Increasingly we are seeing organizations that are deciding to use both ISO-27001 and SOC2 to demonstrate their commitment to information security. Most frequently this is driven by differing contractual requirements imposed upon them by their clients. Fortunately, if you develop your ISO-27001 and SOC2 controls concurrently – the amount of additional time/effort/cost can be minimized.
For different clients we have employed different approaches to meet client-imposed deadlines on one standard or the other; but our favored approach is to treat the SOC2 requirements as an “input” into the ISO-27001 Information Security Management System (ISMS) during the Risk Assessment and Risk Treatment Plan (RTP). In essence, failing to achieve SOC2 criteria is a risk that the ISMS must address. As we build the Risk Treatment Plan we need to verify that the specific criteria that the SOC2 Auditor will be using for each control is included in the RTP.
This approach naturally dovetails with ISO-27001/2 as the SOC2 controls are a subset of the ISO-27001/2 controls that we need to account for in our ISMS. Where SOC2 makes it a bit more interesting is in some cases the expected “audit criteria” for a particular control could be looked at as being prescriptive guidance. So in some cases based on your ISO-27001 Risk Assessment you may feel you don’t need a very robust control implementation to manage a risk that you don’t feel is very significant. However, the preliminary guidance that you received from your SOC2 auditor is more “prescriptive”. What then?
Let’s look at a real world example. We were working with a SAAS provider who only required non-complex six character passwords in their QA environment because they only work with scrubbed data in that environment. The ISO-27001 ISMS, which is focused on protecting electronic Patient Health Information (ePHI), believes that 6 character passwords are a small and acceptable risk (as there was no ePHI present and there were strong controls around migrating code into production). However, the preliminary guidance received from the SOC2 Auditor referenced low complexity 8 character passwords as an across the board requirement. So our client had two choices:
- Implement stronger passwords in the QA environment – although they felt that they were not necessary.
- Maintain their 6 character passwords and justify this choice to the SOC2 Auditor (which is highly likely to work- but not guaranteed to do so).
In this particular case the small amount of effort and low amount of additional control overhead far outweighed the small risk of having the SOC2 auditor issue a finding – so they migrated QA to 8 character passwords. Some examples will not be so cut & dried. Another client, whose in-house data center is very old and still uses sprinklers (successfully), opted to go against the prescriptive guidance given by the SOC2 Auditor and rationalized that decision based on cost and the implementation of compensating controls.
Preparing for ISO-27001 and SOC2 concurrently is a great choice if your clients (and/or marketing department) are mandating you provide both forms of attestation.