How SOC 2 compliance works: Control implementation

In our second installment covering Thoropass’s SOC 2 compliance, we’ll be focusing on the control implementation process. This is the “meat and potatoes” of your compliance posture.

ICYMI, you can read our post about the first steps and gap analysis here.

For context, Thoropass (Laika at the time) decided to tackle SOC 2 compliance to instill trust in our customers, investors, partners, and employees. We’ve seen too many clients’ sales procurement processes slowed by the lack of certification. As a startup, we know the importance of information security to protect against risks and breaches. Thoropass proudly accomplished SOC 2 Type 1 compliance in 2020, and we’re staring down our Type 2 in the first half of 2021.

Recap: Gap analysis

We left off the first step of SOC 2 at our remediation plan. That plan is based on findings from our gap analysis and initial key requirements, like our data flow and network diagrams, defined roles and responsibilities of data owners, and data classification.

To recap those initial tasks: our compliance architects kick-off SOC 2 by understanding what controls are in place and operational, and which are missing. We then organize your data by asking some basic questions:

• What type of data do you store or transfer?
• Where does that data live?
• How does it move through your organization?
• Who has access to the data?

The answers to these questions help tell a full story to your SOC 2 auditors about your information security. Where there are gaps in your controls, those gaps form a SOC 2 remediation and implementation plan.

Learn more about the SOC 2 gap analysis process –> 

Prioritize compliance tasklist

To keep tasks organized for our compliance architects and our clients, our team places each compliance task into a prioritized list. The tasks in your list will depend on the maturity of your business, but most of our clients need to execute the tasks we’ve listed below as examples.

Technical controls for SOC 2

We recommend starting with time-consuming technical tasks first. These will require IT help and likely a developer with access to your code.

Complete technical tasks upfront to avoid delaying the audit process down the road. And many require implementing new tools which take time and research to deploy, so our compliance architects like to tackle more general tasks while they’re in a hurry-up-and-wait pattern.

Role-based access control

Protect against unauthorized access to sensitive data by implementing role-based access control. Abbreviated to RBAC, this control ensures appropriate employees have “just enough access” to complete their job functions and prevent possible data leaks.

RBAC adheres to the Personnel and Data Classification Schema outlined in the first SOC 2 compliance steps. Based on your data classification and defined roles and responsibilities, employees will be granted appropriate access rights.

For example, Thoropass’s SOC 2 compliance automation platform allows our customers to be in different roles like administrator, contributor, view-only, and training. On your systems, you’ll need to create similar scaled access, based on business needs. Luckily, most cloud and software providers should have RBAC built-in (e.g. Slack, Google Suite, Figma), which you can leverage to fulfill this requirement.

Controls

There are many controls across ISO 27001, SOC 2, HIPAA, and other regulations that call for RBAC. This task ensures appropriate access controls have been implemented, like usage restrictions of personal data, secure engineering principles, working in secure areas, and threat intelligence feeds.

Formal change management

We implemented change management and software development lifecycle processes to ensure that standardized procedures are used for handling all changes. Change management covers all types of processes implemented to prepare and support changes taking place in an organization. In the context of information security, change management refers to a process formally introduced, reviewed, and approved, in an organization-wide system.

As we’ve stated, our founders built information security into Thoropass from the beginning. Implementing change management processes on our engineering and product teams wasn’t a huge leap from how we had been operating already.

Controls

Managing risk associated with making changes in your systems mitigates risks such as the deployment of unauthorized changes, product availability, or the introduction of vulnerabilities.

This is a great example of the emphasis SOC 2 and the AICPA place on changes being controlled to prevent data loss or leaks.

Secure product architecture

Securing product architecture involves…well, a lot of technical safety nets. For example, separating your organization’s dev and testing environments from production, establishing expiration dates, time-outs, and locks on accounts, and many more recommendations.

Sensitive data, like personal information (PI), should not be used for internal testing, training, or research. SOC 2 asks development teams for proof of change testing on a non-production environment and stakeholder sign-off before introducing them to a production system.

If this sounds like change management, it should. It’s another step toward creating a “ring-fence of security” around your organization’s data. In practice, it means getting timed-out of software, having a series of steps between any code changes and production environments, and keeping any production data out of testing.

Controls

Once we established data flow and network diagrams, implementing secure product architecture was substantially easier. Those controls are closely tied to this technical task and overlap with transmission confidentiality, configuration management system, security controls oversight and continuous monitoring.

General SOC 2 requirements

While we worked on some of the technical tasks listed above, the team simultaneously tackled the easier-to-dos. These can be completed while you’re waiting to consider vendors and get your IT team’s attention.

Security training

While this may not be a favorite activity, SOC 2 requires all employees to complete security awareness training. This should strengthen knowledge across your organization to prevent cybersecurity threats across the board.

Security training is certainly a “buy it or build it?” question for many new tech organizations. If you choose to streamline your SOC 2 with Thoropass, we have proprietary training included with our platform, available to all your employees.

Controls

Security training meets controls like formal indoctrination, separation of duties, incident handling, and rules of behavior. By completing training, each of your employees will be able to hold responsibility for protecting your business.

Risk management committee

SOC 2 requires independent oversight of the development and performance of internal controls. As a best practice, we created a committee to address and mitigate risk. Assign employees monitoring tasks to stay compliant with policies, distributing the policies, and ensuring comprehension. Your employees are responsible for the control activities within your organization.

The Risk Committee schedules and plans any necessary audits or testing to ensure minimal business disruption and addresses any internal or external risks discovered facing the firm.

Our risk committee has our founders, our head of risk and security, and our head of operations.

Controls

Risk management, as a main goal of SOC 2, meets controls like risk identification, assessment, register, ranking, remediation, and response. Some of these controls overlap with Security Training for your employees; which is a good example of how SOC 2 requirements aren’t necessarily one requirement to one related action.

Employee onboarding and opff-boarding process

Implement hiring and termination procedures for employees and contractors. This looks like checklists that ensure new hires are correctly provisioned with access are vetted, and are knowledgeable regarding their role in company security policies and practices. Further, make sure that terminated employees’ access is removed and devices are returned.

SOC 2 recommends a background check after reviewing a candidate to ensure they possess the qualifications to perform the role. This is an important HR control and best practice as well as a requirement for several frameworks.

Controls

By completing this HR SOC 2 requirement, you’ll cover personnel screening, workplace investigations, and confidentiality agreement controls (among many others). Again, a good example of how SOC 2 should touch each employee in your organization.

Vendor selection and management

Our founders faced the challenge of “build it or buy it?” many times while starting Thoropass. When it comes to certain SOC 2 controls, we knew the answer was certainly, “buy it.” As you’re selecting vendors to help fulfill your SOC 2 requirements, do your own due diligence and procurement process.

Auditors need to understand why you selected that particular vendor, what type of data the vendor stores, transfers, or processes, and see a record of your contract with them. Understanding the criticality of vendors and the associated risk when vendors have access to sensitive information is highly important to the SOC 2 process.

We input and store all that information in Thoropass.

Logging and monitoring

We needed to install monitoring and logging tools within critical systems. These tools monitor configuration, change management, network traffic, user activities, antivirus, and more. When there is an anomaly, the tools alert and escalate the incident response according to a predefined process.

In the spirit of least privilege, consider setting up a centralized monitoring and logging environment that’s segregated from other resources. Our founders recommend using existing functionality/features provided by cloud service providers:

• AWS: refer to the Amazon CloudWatch quick start guide
• Google Cloud: refer to the Stackdriver logging tool (also works with AWS)
• Microsoft Azure: refer to the Azure logging and auditing documentation

Any tool selected should store event logs securely and monitor them for suspicious activity, triggering the incident response process when an anomaly is detected. We decided to use CloudWatch and Datadog for our logging and monitoring.

Controls

Investing in logging and monitoring tools will fulfill host intrusion detection and prevention systems, file integrity monitoring, anti-malware, and embedded technology security program controls. Choosing a solid provider meets a few controls, just like it fulfills some of our task lists.

Endpoint security

Our compliance architects started implementation by installing a trustworthy endpoint protection system. The systems of choice include BitDefender, which protects from threats to transmitted, stored, and processed data. We also configured firewalls, disc encryption, and USB read-write protections through JumpCloud, which is our cloud service provider endpoint.

Endpoint security systems provide an automated asset inventory (see: asset inventory in the first step of SOC 2 certification). This should reduce the time and resources spent on IT administration. When you’re implementing an endpoint protection system, some tools will offer monitoring & logging of the company machines as part of the service. Two requirements, one vendor.

Controls

Implementing an endpoint security system at least partially fulfills information security and privacy controls. These include controls like publishing security and privacy documentation, statutory, regulatory, and contractual compliance, and testing, training, and monitoring.

Evidence review

Once your task list is complete, it’s time for your compliance team to review the evidence you’ve gathered for auditors along the way. Remember, a SOC 2 Type 1 audit focuses on a point in time, but a Type 2 audit tests the operational effectiveness of your implemented controls. You’ll need to keep all your receipts to pass that all-important audit.

When your evidence has been reviewed internally, it’s time for a risk assessment. And we’ll pick up our SOC 2 story right there, in the next post of this series!