Does this sound familiar to you?
The Sales team at your company keeps getting pushback from potential customers, particularly the larger ones. They insist on asking lots of invasive pre-sales questions about your company’s security practices, and it’s bogging down the process and you’re losing deals. The Director of Sales notices that many of the customers will accept something called a “SOC 2 report” in lieu of filling out the questionnaires, so he convinces the CEO that your company needs one of these, whatever it is. The CEO doesn’t really know what it is either, but he knows it’s something related to cybersecurity, and he wants the staff to just “make it happen.” So, he instructs the IT Manager to get “the security guy” to figure out what tools they need to buy or extra scans they need to run to pass an audit. The security engineer says “hey wait a minute!” … but everyone has already left to deal with the next fire.
Spoiler alert, this story doesn’t end with “and they lived happily ever after.”
This approach is bound to fail. Why? Because despite what some people may think, SOC 2 is not just a list of cybersecurity rules you need to follow. It’s something very different from that, and it can’t just be delegated down the org chart and be expected to succeed.
SOC 2: Descriptive, not Prescriptive
Some other security standards, like PCI-DSS for credit card data, are very well known for being prescriptive. These standards are very precise about exactly what you’re expected to do, with very little room for creative interpretation. The rules are clear in this game. For instance, PCI-DSS Requirement 1.1.7 states that you must review your firewall configuration every 6 months, no ifs, ands, or buts … or prepare to face the wrath of your PCI auditor!
SOC 2 follows a different philosophy – it is descriptive. Instead of telling you what you need to do, it tells you where you need to look and what you should expect to see. It will force you to take a holistic view of your business, sometimes in ways that may seem a bit unusual if you’re just expecting it to be a technical security framework.
For example, SOC 2 will have you examining your governance structure to make sure the very top of the org chart is setting expectations for security management and is providing oversight. You’ll also need to look at how you’re setting expectations for availability with your customers, and you’ll need to look at how you’re holding individuals accountable for security management. You’ll look on and on, until you’ve looked at every nook and cranny of your organization. There are plenty of traditional cybersecurity topics included as well, but the focus is always on how they’re managed by the organization rather than any specific configurations.
Now, think back to the poor, overworked “security guy” in our story. He should be able to manage some technical items, but is he really going to be in a position to ask the Board of Directors for annual attestation of their “independence from management”, or to ask Human Resources for records of all people hired and terminated in the past year? Of course not! A typical SOC 2 program will have wide ranging controls that will touch all corners of the business, so to be successful it has to be a company-wide priority with buy-in, oversight, and participation from senior management.
SOC 2 Compliance: Choose your own adventure!
It may come as a surprise that what you actually do for SOC 2, the rules you operate by (or controls, in auditor-speak) are left mostly up to you to determine. SOC 2 will define the high-level service objectives (or criteria), but you get to define the specific controls in the way you think is best for your business.
Let’s compare this to PCI-DSS’s ironclad mandate about 6-month firewall rule reviews. The closest parallel in SOC 2 is Criterion 6.6: “The entity implements logical access security measures to protect against threats from sources outside its system boundaries.”
Yikes! What is all this vague language about? This is where it gets tricky. Instead of being told exactly what you should do, it’s up to you to decide what combination of controls are appropriate for your business to meet this open-ended operational principle. You will likely need to implement several controls that, taken together, prove that you are taking this objective seriously.
So, let’s say that similar to PCI-DSS, you decide that periodically reviewing your firewall configuration will help meet Criterion 6.6. But you also know that your firewall configuration almost never changes, and you also have a strong network change control process, so you believe that an annual review is appropriate in this case to manage this relatively small risk. Well, if that’s what is right for you, and you can reasonably justify your decision, then that’s your choice! The point is that you create your own collections of controls to meet each objective.
Compliant to what then, myself?
Now I know what you’re thinking, if you get to write your own “rules” to this game, then why in the world would a SOC 2 compliance report be worth anything? Wouldn’t everyone just use the easiest possible controls? And why would any potential customer care about seeing your SOC 2 report if they know it’s not based on a rigorous set of universal controls, like PCI-DSS?
This is where an independent, external SOC 2 auditor comes in. Once you engage with an auditor, one of the most important things they will do is to validate that the controls you’ve selected meet the intent of each of the SOC 2 requirements. Ultimately, the SOC 2 report is just their opinion, or attestation (not certification), that you’ve met the spirit of the service criteria, so it is important that you all agree ahead of time where that line is drawn.
It can take a lot of hard work to get ready for your first SOC 2 audit. Organizations often struggle just to define all of the new controls they’ll need to follow. It’s difficult to know how rigorous your controls need to be if you’ve never gone through an audit before.
A good auditor will understand this, so they’ll often suggest controls they know will meet the audit requirements, which are usually tailored based on their understanding of your business practices. Don’t hesitate to discuss any suggested controls that you don’t believe to be appropriate for your business – the auditor is there to help you fine-tune them.
Sample SOC 2 Controls
Let’s take a look at a few SOC 2 principles and see what controls might be appropriate:
“… the Board of Directors demonstrates independence from management and exercises oversight … of internal controls.”
- Board structure is reassessed annually.
- Members of the Board acknowledge their independence and responsibilities annually.
- Board members oversee the creation and annual review of company code of conduct.
“… the [company] registers and authorizes new … users.”
- Access to systems requires documented access form and manager approval.
- Management conducts periodic access reviews for sensitive systems.
- A termination checklist is completed to remove access to sensitive systems.
“… the [company] implements controls to prevent or detect … malicious software.”
- Implement centralized anti-virus/anti-malware on all systems and devices.
- Monitor and apply vendor security patches in a timely manner in accordance with the documented patch management policy.
- Define and use standard configurations for all new build deployments.
A word to the wise here – you can’t just search Google and find “the list” of SOC 2 controls you “must follow” to be compliant. That list doesn’t exist, because each company’s controls will be unique to how they run their business. One size does not fit all!
SOC 2 Type II: Prove it to the auditor
So by now, you and your team have worked hard to define and implement your controls. You know that your environment is already more secure and better managed, but how do you show that to your customers?
The process you go through with the auditor to verify that the controls are appropriate and operating is actually the first audit, called a SOC 2 Type 1. This is a point-in-time test that ensures that you’re starting off your SOC 2 compliance program on the right foot. If there are controls the auditor believes aren’t quite being followed well enough to meet the objectives, usually you can work to improve your practices or modify the controls. It can be an iterative process, and usually no one “fails” a SOC 2 Type 1 audit if they’re making a reasonable effort to get their controls in place.
What happens though when all the excitement of preparing for the SOC 2 Type 1 is over? This is where the real challenge comes in, because now you’re committed to dutifully following all of the controls you’ve just established. Down the road, often a year later, you’ll sit down with the auditor to review how well you kept up with your controls during a SOC 2 Type 2 audit. This variety of audit report is much more valued by customers because it proves that you actually put your controls into practice over an extended period of time.
One of the most important parts about a SOC 2 Type 2 report is its transparency. Remember how this all started by setting your own rules for the game? All of those controls are spelled out in the final report, along with the auditor’s opinions on how well you followed them. A savvy consumer of this report, perhaps a pre-sales customer of yours, will do more than request that you provide them your SOC 2 Type 2 report – they’ll actually read it too. If you don’t put a lot of effort into designing strong controls, then expect uncomfortable follow up questions from your customers. Likewise for yourself, never just accept another company’s SOC 2 report as proof that they have a strong cybersecurity program in place. You need to review it carefully, and pay special attention to any exceptions noted by their auditors.
A word of warning: it is far too easy to stumble during a SOC 2 Type 2 audit, because you’ll have limited ability to correct mistakes that may have happened long ago. Forgot to document approvals for a series of emergency changes that happened months earlier? That could lead to an exception being noted on the report, and if you have several exceptions the auditor may not be able to issue a report you’d be proud to share with your customers.
A Better Approach
Now that we know more about SOC 2 compliance, let’s reimagine the story from the beginning and see how it could have gone differently:
After discussing with other senior executives, the CEO recognizes that a well run SOC 2 compliance program will help them manage the company more effectively and securely. The CEO informs the Board of Directors of the initiative, and delegates program implementation and oversight to the CISO. With the CEO’s backing, the CISO assembles a team of senior leaders, including representatives from Human Resources, Product Development, Internal IT, and Production Operations.
The team does a preliminary gap analysis and discovers several technical and operational issues that need to be addressed before they can define effective SOC 2 controls. Once those issues are remediated, they start to evaluate current business practices and document them as controls they feel meet the SOC 2 objectives.
The CISO engages with an external SOC 2 auditing firm, and they work together to refine and expand the controls. The auditor conducts an audit to verify that the controls are effective at that point in time, and they issue a SOC 2 Type 1 report. The Sales team starts to publicize to customers that the company is maintaining a SOC 2 compliance program.
The CISO convenes a permanent internal audit team to manage the controls over time. They periodically check that all controls are working as expected, and they address any ones that need improvement. They also make sure the organization is performing periodic testing activities, like incident response tabletop exercises and penetration testing on the production network.
After a year, the external auditor returns to perform another audit to review how well the company followed their controls over the previous 12 months. They examine records from that period, like all change tickets, security incidents, and employee terminations. The auditor issues a SOC 2 Type 2 report showing that the company is keeping up with their commitments to good cybersecurity governance. The auditor then returns every year to reassess the compliance program.
The Sales team, armed with the SOC 2 Type 2 report, is now able to break through to the next tier and sell to the larger customers. The CEO is thrilled that sales are up and the company is growing. And finally, the CISO can sleep a little bit easier knowing that there is an effective cybersecurity governance program in place!
And they lived happily ever after.
Want to get great cybersecurity content delivered to your inbox? Sign up for our monthly newsletter, Tales from the Click! https://fractionalciso.com/newsletter/
If your company doesn’t have someone dedicated to cybersecurity leadership, like a CISO, CSO, or Risk Manager, then preparing for a SOC 2 audit can be daunting. The team at Fractional CISO can help fill that leadership gap. We’re here to help you run and maintain an effective cybersecurity management program, including everything you need to prepare and maintain your SOC 2 compliance program. Contact us to see how we can help you!
