As the leading provider of SOC 2 reports to small-mid size cloud services businesses in Asia-Pacific, we get a lot of questions about how to achieve SOC 2 in a “process-light” or “fit-for-purpose” way. Can you achieve SOC 2 without being process heavy?
Why SOC 2 is process-light by design
Contrasting SOC 2 with other leading standards like ISO 27001, it's a set of criteria that is adaptable to any organisation and takes a risk-based approach. ISO 27001 is often seen as more onerous and process-heavy as it sets a prescribed approach to what's required in the information security management system (ISMS). The criteria in SOC 2 sets out principles that should be considered but with a lot of flexibility for what that may look like in each specific business context and type of services.
The SOC 2 focus on "operational effectiveness" of information security means a lot of the requirements can be achieved by systematic solutions. These require minimal, if any, manual process as they achieve the criteria by design of the system. These are common in cloud-services businesses in particular where leading cloud-infrastructure (AWS, GCP, Azure) is used that is designed to achieve compliance by design, or with tools and settings that make it easy to achieve compliance.
As a starting point, there’s nothing in the SOC 2 criteria or underlying standards (AT-C 105 & 205) , that prescribes process-heavy practices. All the processes and policies for your business can and should be defined in a way that fits your context and culture. AWS and Microsoft for example, have hundreds of system components, huge global teams, and large and diverse customers. Implementing the same sort of control practices they do for your small cloud software business, probably doesn't make sense and won't be effective when applied in your context.
What do SOC 2 audits expect?
SOC 2 assessments and audits, take a risk-based approach that consider your environment when determining what is "effective" to satisfy the criteria. Achieving SOC 2 does not mean your processes need to be onerous and comprehensive. It's about ensuring there is a clearly defined and communicated approach that considers security principles in the design. There should be a consistent manner for following those practices with documentation retained in system trails or other records.
Our best practices series is all about exploring what those good practices are; why they’re important, how they can be implemented, and what the key control components are. That way you can implement a starting point that satisfies the core criteria but also makes sense for your business. Information security risks tend to increase in significance as you grow, so it makes sense to start with a baseline and build in governance that supports continual improvement and revision over time.
What does process-light look like?
If that all sounds very hypothetical, let’s explore some examples of how you can achieve SOC 2 in a process-light way that meets the same purpose but in a way that fits your smaller scale. The Incident Management and Risk Management control areas will be used as examples, since they are commonly seen as the most process-heavy by our clients.
Incident Management
The heavy version
For enterprise businesses, a comprehensive incident management process is a necessity. There’s a large team of support personnel that requires a consistent, clearly defined approach. Detailed procedures ensure everyone knows their responsibilities and what to do in any incident situation that may arise. The volume of service desk tickets and incidents is naturally larger and more diverse due to the broader range of systems and higher volume of users. Knowledge of those systems and their underlying code and architecture is often more limited and disbursed across a broader team, so it can be much harder to resolve incidents. Having tracking systems, review meetings, reporting and clearly defined policies and procedures are critical to manage that scale.
The light version
Contrast that with a small tech startup; the CTO and Dev lead are often responsible for incident management and know the ins and outs of the systems, internal and external stakeholders. They can manage incidents as part of their broader responsibilities as they know first-hand how to treat the incident priority, communicate to other stakeholders, and resolve the incidents. But all the same principles apply; so you can have a formal policy that identifies the CTO as the owner of Incident Management and the Dev Lead as the operational manager and perhaps first responder. That may then have a 1 page to set out how incidents are:
Instead of a comprehensive policy, procedures, response plans, on-call rota, and checklists and support manuals, you may cover it all in a single defined process managed closely by the CTO.
Risk Management
The heavy version
For enterprise businesses, particularly regulated industries, risk management is a significant function of the business with a large team of dedicated personnel. The risk register may be updated daily with new risks, adjusted ratings and treatment actions, and adapting to incidents and issues raised in the course of operations.
It’s important to have detailed criteria supporting the risk ratings, defined roles and responsibilities of how the individuals and teams work together, procedures for handling risks, treatment plans, committees, and reporting processes for management and the Board. With a broad business focus and systems, the risks to be identified are endless and typically require detailed definitions to be clearly classified and defined for the understanding of broader business stakeholders.
The light version
In a tech startup, the roles may be one person owning the risk function, or it may be a part of the senior management teams broader responsibilities. That management team can be directly involved in the risk assessments removing the need for separate reporting and approval processes.
The classifications may be low-high ratings with simple criteria that allows some judgement of management, and enough clarity to compare and prioritise the risks accordingly. Rather than an endless, long risk register, there's a fairly standard set of risks that apply to a single product cloud services provider. The light version of risk management can be;
The same principles apply to all the other control areas. They should be pragmatic, focused on the roles, responsibilities, stakeholders involved and the nature and scope of your business. That means if you’ve a smaller and simpler business environment, you can and should have a lighter version of your policies and processes that aligns to that. The usual processes can be more centralised, simplified and often combined, compared to larger businesses that need to separate those out based on more dispersed responsibilities.
Our InfoSec Compliance Toolkit brings together control examples, templates, how-to-guides, software solutions and practice notes to help our clients implement the process-light approach that fits their business. The toolkit can be provided upon completion of our Readiness Assessment. Get in touch if you want to learn more, or discuss how we can support your process-light goals.