In Plain English…
What is a SOC 2 Control?
A control is something you do to keep the bad guys out. There could be other reasons to perform controls, but we’ll get into that later.
It could be something non-technical, or something incredibly sophisticated – here’s a few examples to demonstrate the range of categories:
- Company XYZ performs a background check on new hires prior to the first day of employment.
- Access to the ABC system is disabled within 24 hours of termination.
- ABC systems are monitored for performance, availability, and capacity metrics. Alerts are sent to the SRE team for resolution according to the Issue Response Policy.
If a control isn’t stopping a bad guy, then it’s not working properly.
What separates a good SOC 2 Control from a bad one?
One thing that separates a good SOC report from a bad SOC report are the quality of the controls.
If you have reviewed other company’s SOC 2 reports for your own compliance needs, you probably are aware that control quality varies widely from report to report. Here are the top 3 control mistakes I encounter as a SOC 2 auditor – controls that are:
- Too Vague – Failing to define the control action occurring with enough specificity. “The IT team performs monitoring and investigates issues” leaves me wondering what systems are they monitoring? What does that monitoring look like? What does ‘investigates issues’ mean? vs. “The production environment is monitored for anomalous activity and alerts are sent to the on-call engineering personnel. Alerts are triaged and risk-rated within 24 hours, and tracked to resolution in a ticket according to defined SLAs for each risk level.”
- Too Specific – Naming specific tools or vendors in the control. E.g. “The SFTP server is monitored using SolarWinds” is not helpful because A) tools and servers come and go all the time, and it takes extra work to keep the control updated, and B) the control should convey the action performed, and naming a specific brand name can often be misleading as the way it is configured or the service performed may not be typical.
- Confused with a process – it is not a control to say “Software engineers develop the code and merge it into the master branch.” That information alone does not fight bad guys – of course you are doing development work if you have a product. However, it is a control to say “Code changes are reviewed for security vulnerabilities by a peer engineer prior to release to the production environment.”
Looking for an auditor who can help guide you through the SOC 2 process? – Contact Render
