<- Back to all blog posts

Free SOC 2 Training

August 26, 2021

Are you searching for a way to enhance your organization's security awareness training? Look no further than Haekka! Schedule a demo with us to discover how we can help you reduce costs by 75% while boosting employee satisfaction with our training by 81%.
Schedule a demo

This SOC 2 training is provided free for use. Haekka offers a fully integrated training platform in Slack, enabling customers to meet their compliance, privacy, and security training requirements using modern, relevant content delivered 100% in Slack.

Introduction to SOC 2

SOC 2 is a framework for auditing the internal processes and procedures for an organization. It is an increasingly popular standard, especially for technology companies that sell software and services to businesses. SOC 2 is governed by the American Institute of CPAs (AICPA).

SOC 2 is different than more strict regimes such as GDPR, HIPAA, or PCI in that SOC 2 is much more catered to the organization. SOC 2 is about what organizations say they do to protect data. The flexibility of SOC 2 comes from the selection of controls and trust services categories.

SOC 2 is divided into five services categories:

  1. Security
  2. Availability
  3. Integrity
  4. Confidentiality
  5. Privacy

Organizations can choose one or more services categories to be audited against. The Security category is universal to all SOC 2 audits so is not optional. It is sometimes called the Common Core. Many companies only attest to the Security category and it covers information security, making it the equivalent of a cybersecurity certification.

SOC 2 offers two types of reports.

  1. Type 1 Reports. These reports audit ****the defined policies and procedures of an organization. An organization states the controls it will attempt to meet in SOC 2 and then a Type 1 Report simply verifies that the organization has policies and procedures written to meet those controls.
  2. Type 2 Reports. These reports audit the implementation of those policies and procedures. These occur after Type 1 Reports. These reports review internal processes and documentation to ensure that the policies and procedures from the Type 1 Report are actually implemented and being followed.

SOC 2 is not prescriptive. Each SOC 2 report is customized to the organization. The organization, usually with the help or an auditor, choses what controls are relevant. Those controls are the only controls tested.

In order to standardized SOC 2 and hold the reports to a level of rigor, only organizations that are approved by AICPA can issue SOC 2 reports. This means organizations cannot work with any auditor or firm, like they can for HIPAA or GDPR; though, in practicality, many large auditor firms are approved by AICPA and offer audits against all regimes.

For the purpose of this training, the course is structured around the AICPA Trust Services Criteria. The Trust Services Category for each section of this course is called out in the title using [Category] format. Additionally, common criteria are denoted using the format CCx.x, where x are numerical values.

SOC 2 is tailored to organizations but the most common ways in which companies attest to SOC 2 are by addressing the common criteria controls that for the Security category.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] Control Environment

Control Environment encompasses 5 Common Criteria controls. These controls center on setting up proper organizational structures in support of the objective of the organization. As organizational objectives are highly specific, the structures put in place for Control Environment controls are highly specific to the organization.

  1. CC1.1: The entity demonstrates a commitment to integrity and ethical values. Organizatiosn need to establish and document their commitment to ethics and integrity. This can be accomplished with directives from the top (management a board), creating a standard of conduct for the organization, and assessing adherence to codes of conduct and correcting non-adherence.
  2. CC1.2: The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control. This is a board specific control to ensure the board of directors uses its oversight power, is independent from management, and has the skills necessary for oversight and organization-level protection of data, either directly through members or through the use of consultants.
  3. CC1.3: Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives. Management and the board need to create appropriate roles, groups, duties, separation, and reporting to operate the business effectively.
  4. CC1.4: The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives. The company needs to ensure it is hiring people with the skills to effectively fill the defined roles. These skills include technical competencies and making sure that succession plans are in place. Additionally, companies need to keep employee skills relevant and up to date through effective training.
  5. CC1.5: The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives. The company needs to set performance expectations and then evaluate individuals against those expectations. Incentive and accountability structures need to be put in place and enforced for employee and contractor performance against expectations.

Privacy and Security are org-level initiatives that need to be baked into the structure and operations of your company, from the board of directors down.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] Communication and Information

Communication is an essential aspect of any information security management system (ISMS). This set of SOC 2 controls require that companies put effective processes in place for both internal communications and external communications.

  1. CC2.1: The entity obtains or generates and uses relevant, quality information to support the functioning of internal control. Companies need to define the types of information required for internal operations, have systems collect relevant data, turn that data into required information, and continually assess information to ensure it is meeting the requirements of the company.
  2. CC2.2: The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. Internal communication channels are established, including special purpose channels for whitleblowers and to / from the board. Information about internal operations and controls, responsibilties and roles, and security awareness is communicated across the company to relevant groups and individuals. The company defines the appropriate channels and frequency to meet its internal control objectives.
  3. CC2.3: The entity communicates with external parties regarding matters affecting the functioning of internal control. This mandates similar controls to the above, but for external communications. Of note, there are additonal external communication requirments that are not a part of this control, but are required for regulations like GDPR and CCPA and pertain to external communications about personal data collection and usage.

Communication is essential to effective internal and external operations. SOC 2 requires that you are intentional about this communication and document the procedures associated with communications.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] Risk Assessment

Using a risk-based framework is essential to effective security. Understanding risk, prioritizing those risks, and then aligning resources to mitigate prioritized risk helps to ensure companies manage their data and assets.

  1. CC3.1: The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives. This control is more about objectives for the company that risk itself. The company needs to establish crystal clear objectives, assign appropriate resources to those objectives, and report accordingly to meet those objectives. With clear objectives, it is easier for organizations to assess risk. Objectives relate directly to criticality, which is a key factor in determining risk (next control).
  2. CC3.2: The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. The entity assesses risk at different levels in the company, across different groups, and for both internal and external factors. The process for determining risk it to identify systems (inventory), assign criticality or data classification of those systems, threats to those systems, impact and likelihood of those threats. The first step is a digital / system inventory, something that cloud-first companies can do in a mostly automated way.
  3. CC3.3: The entity considers the potential for fraud in assessing risks to the achievement of objectives. Fraud is a key consideration in assessing and managing risk. It is imperative that companies assess the areas of potential fraud and the motivations for fraud, both internally and externally.
  4. CC3.4: The entity identifies and assesses changes that could significantly impact the system of internal control. Changes should trigger a re-assessment, or at least refresh, of risk. Changes can be technical or organization related (leadership, partners, vendors, etc.). Conducting privacy impact assessments with certain changes is a best practice to consider.

Assessment and management of risk is a dynamic process that spans technical and organization-wide factors. Risk management is a team sport.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] Monitoring Activities

Security is not a set it and forget it problem. Companies must continually monitor and test their controls to ensure continued effectiveness of procedures and technical implementations.

  1. CC4.1: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. The company establishes a baseline for processes and implementation and then tests against this baseline on a regular basis. Frequency of testing should be informed by the rate of change of the company processes and technology. Some examples of monitoring are penetration testing, internal audit, and security certifications.
  2. CC4.2: The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate. The results of monitoring are communicated to relevant and accountable groups. The results, as well as corrective action plans, are reported and tracked by management and the board of directors, when relevant.

Good security hygiene is ongoing. Systems, processes, and tools need to be put in place to continually monitor performance of a information security management program at your company.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] Control Activities

Control activities are the policies, procedures, and associated technical implementations that make up the backbone of an information security management system (ISMS).

  1. CC5.1: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. The company puts controls in place to minimize and mitigate risk.
  2. CC5.2: The entity also selects and develops general control activities over technology to support the achievement of objectives. Specifically to technology, controls are put in place on acquisition of technology, access rights to technology, and to maintain the confidentiality, integrity, and availability of data.
  3. CC5.3: The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action. The company codifies controls in written policies. These policies are put into action through associated procedures. There is a clear responsibility for these policies and procedures. Policies and procedures are reviewed on a regular basis.

Controls are established, followed, and continually monitored through policies and procedures.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] Logical and Physical Access Controls

Logical and physical access controls have been redefined in the state of cloud computing and shared responsibility. Many physical access controls and, increasingly, logical access controls are managed by 3rd parties. But there importance remains paramount to securing company systems and data.

  1. CC6.1: The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives. This is an extremely broad control. First, company need to establish an inventory of all systems. This inventory is then protected through the use of access controls (access roles and groups), identification and authentication of users, restriction of access points like ports, and encryption. Network segmentation is an additional way to isolate systems and minimize risk by reducing the size of the access planes.
  2. CC6.2: Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized. A procedure should be implemented to request, grant, and remove access to information systems. As a part of this procedure, acccess to systems should be reviewed on a regular basis.
  3. CC6.3: The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives. This control is similar to the above, extending it by adding in role-based access controls and then reviewing those roles and rules on a regular basis.
  4. CC6.4: The entity restricts physical access to facilities and protected information assets (for example, data center facilities, backup media storage, and other sensitive locations) to authorized personnel to meet the entity’s objectives. Similar to CC6.2 but for physical access, procedures are created to request, grant, and revoke physical access. These access requests and access lists are reviewed on a regular basis.
  5. CC6.5: The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity’s objectives. Software and data on systems that are to be retired or cease to be used is identified and made unreadable and unusable.
  6. CC6.6: The entity implements logical access security measures to protect against threats from sources outside its system boundaries. In order to address the threats from external access, different methods need to be employed. CC6.6 mandates limiting the types of external communications (ports and protocols), implementing additional controls for remote access such as multi-factor authentication, and perimeter protections such as firewalls and intrusion detection systems.
  7. CC6.7: The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity’s objectives. Specifically addressing the transmission of data, companies need to put processes in place to restrict sending data and encrypt data in transmission and data stored on removable media (tape drives and USB drives). An additional requirement in this control is protecting mobile devices that serve as information assets.
  8. CC6.8: The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives. Software and configuration changes should be restricted using a documented process and associated technology. Anti-virus and anti-malware software is also required to satisfy this control.

Software and physical access controls need to be established and documented for all information assets, whether those assets are wholly owned by the company or virtual / cloud.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] System Operations

System operations is a broad area under SOC 2 covering change management, event management, and security incident detection and response.

  1. CC7.1: To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities. Another broad control, this ensures companies create configuration standards for and then monitors systems to ensure compliance with those standards. Additionally, this control mandates that companies conduct vulnerability scans on a regular basis and after significant changes to the technology environment.
  2. CC7.2: The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events. This control is basically event management. Policies, procedures, and tools need to be used to monitor for, detect, filter, and analyze events to determine anomalies. These anomalies are then investigated and mitigated if need be. The tools and policies need to be evaluated on a regular basis.
  3. CC7.3: The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures. Security events need to be evaluated on an ongoing basis. These policies and procedures need to evaluate the exposure of personal information, which is used to determine is a security incident is a data breach.
  4. CC7.4: The entity responds to identified security incidents by executing a defined incident-response pro-gram to understand, contain, remediate, and communicate security incidents, as appropriate. Security incident management is extended in this control so that formal policies and processes are in place for detecting, investigating, and communicating security incidents, both internally and externally. Additionally, mitigating security incidents, and associates threats, is a required part of this control. Sanctions are imposed on individuals and groups that are responsible for security incidents.
  5. CC7.5: The entity identifies, develops, and implements activities to recover from identified security incidents. A company needs to be able to recover from a security event and share relevant information about the event internally and externally. One key part of this process is conducting and documenting thorough investigations of the event to identify and correct the root cause.

Policies, procedures, and best practice security controls need to be put in place to detect, investigate, and recover from security incidents and changes from baseline configurations.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] Change Management

There is only one common criteria control for change management, but it is extremely extensive what it requires, which is a fully baked and implemented process to manage changes to systems, hardware, software, and infrastructure.

  1. CC8.1: The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. Companies need to create and follow a change management process. Baseline configurations for hardware and software are required as a starting point. Changes to these baseline configurations need to be documented - from request through approval and actual change in baseline. Additionally, changes to baseline need to be proactively identified for the purpose of mitigating risk.

Change management should be integrated into technology operations and system development to ensure consistency of software and hardware configurations.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

[Security] Risk Mitigation

The first step in risk management is risk assessment, which is covered in a previous section of the common criteria. The second step is mitigating the risk, which is covered in this last section of the common criteria.

  1. CC9.1: The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions. While not going as far as detailing out the requirements for a business continuity, or disaster recover plan, this control requires that companies have documented policies and procedures for responding and recovering from incidents that disrupt business, including technology incidents where systems and data are unavailable.
  2. CC9.2: The entity assesses and manages risks associated with vendors and business partners. This control falls under the umbrella of 3rd party risk management. With the increasing reliance on technology (cloud + SaaS) and services, managing the risk and relationships with 3rd parties has never been more important. Companies need to establish clear policies and procedures related to contracting and terminating relationships with partners and vendors as well as ongoing management of these 3rd parties.

Managing the risk associated with business continuity and 3rd parties is an essential part of an effective information security management system (ISMS).

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!


The availability controls are an additional set of criteria that are specific to the Availability Trust Service Category.

  1. A1.1: The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives. To meet this requirement, companies need to establish a capacity planning processes. This process should include current capacity and utilization, forecasting for utilization, and adjusting capacity to ensure adequate to meet forecasted capacity demand.
  2. A1.2: The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure to meet its objectives. This controls requires companies create a disaster recovery program. This program should include an assessment of risks that could cause a disaster, evaluation of data to backup, implementation a backup strategy with data backups stored off site, and creation of policies and procedures to implement alternative infrastructure. The cloud, with multiple regions and availability zones within regions, make this control easier to address but having a backup infrastructure for recovery is expensive to maintain if the resources are kept warm / ready.
  3. A1.3: The entity tests recovery plan procedures supporting system recovery to meet its objectives. This control requires that companies test the above two controls to ensure the established backup and recovery system works.

Meeting the availability trust service category mandates capacity planning and fully built disaster recovery plan.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!


Confidentiality extends the common criteria with two additional controls.

  1. C1.1: The entity identifies and maintains confidential information to meet the entity’s objectives related to confidentiality. Companies need to put procedures in place to classify data and to define retention periods for data. During the defined retention period, companies need to ensure data is not destroyed or rendered unusable.
  2. C1.2: The entity disposes of confidential information to meet the entity’s objectives related to confidentiality. Once data reaches the end of it's retention period, as defined under C1.1 above, data needs to be identified for deletion and then destroyed using defined data destruction procedures.

Data must be classified and have a designated retention period after which procedures need to be established and followed to destroy data.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!


Integrity, or processing integrity, is a set of controls that extends the common criteria and focuses on data protections and monitoring of data.

  1. PI1.1: The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services. Companies need to clearly define the data that they collect, including data elements such as identifiers, and provide that information to users. This is a similar control to requirements in GDPR around data transparency for users.
  2. PI1.2: The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity’s objectives. Companies need to define the inputs to their products and services, monitor those inputs for compliance, and document input usage and activities. In the case of modern technology products, this often includes inputs from data sources via API.
  3. PI1.3: The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity’s objectives. This control is about the processing, or usage of data. Companies need to define how they use or process data, keep a record of processing, and detect errors in processing. Keeping records of processing activity can be onerous given the volume of data that many modern technology products use.
  4. PI1.4: The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity’s objectives. This control is the inverse of the above, PI1.2, control. Companies need to protect information that is the output of processing and keep a record of outputs. This can be anything from information that is derived or calculated to simply displaying information to users.
  5. PI1.5: The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity’s objectives. This control mandates that companies securely store data, monitors for tampering with stored data, and keeps a record of data storage activities. Additionally, backup or archives of data need to be similarly secured.

Adding the Integrity Service Category mandates additional requirements on data definitions and secure storage.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!


Other than Security and the common criteria, the Privacy Trust Category under SOC 2 is far and away the most extensive. Much of the controls under Privacy mirror, or are very close, to the requirements of privacy regulations like GDPR and CCPA. The Privacy controls are broken out into 7 different sub-categories, which we outline and summarize below.

P1.0: Notice and Communication of Objectives Related to Privacy

Companies need to communicate with data subjects, or individuals, about the data they collect, how they use it, who they share it with, and what choices data subjects have about their data. These communications need to use clear language that can be easily understood.

P2.0: Choice and Consent

Companies need to inform data subjects about their choices in regards to personal data collection and usage. Companies also need to get consent before data is collected and when changes are made to collection practices and data usage. The consent can be explicit or implicit so companies can choose opt-in and opt-out consent workflows. Explicit consent is required for sensitive information.

P3.0: Collection

Companies need to create special procedures for collection of data. Collected data should be limited to what is needed, the data should be collected in lawful and "fair" ways, and sources of data should be checked for reliability. When personal information is to be retained, explicit consent is required from the data subject.

P4.0: Use, Retention, and Disposal

Data is only used for the express purposes for which it was collected, it is only retained during the time necessary for that express purpose, and it is destroyed when after the retention period is over.

P5.0: Access

In order to control access to personal data and be transparent about access, companies need to authenticate users in order for them to access their data, establish a process for data subjects to update or correct information, and communicate any denials for access requests or correction requests.

P6.0: Disclosure and Notification

There are several controls under this sub-category. Companies need to evaluate and have commitments from their partners and 3rd parties around privacy and reporting. The company must maintain a record of data disclosures to 3rd parties. Companies must establish and implement a breach notification policy and process.

P7.0: Quality

Companies need to ensure information is accurate and relevant for the intended purpose.

P8.0: Monitoring and Enforcement

Companies need to clearly communicate the pathways and contacts that data subjects should engage in order to file disputes or complaints. The company must maintain a record of these disputes and any instances of non-compliance.

Suffice it to say, adding the Privacy Trust Category to your SOC 2 Certification is a lot of work; but, considering how closely it aligns with new regulations and how top of mind privacy is for business, certifying for Privacy has a lot of value.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

SOC 2 Reports

SOC 2 Reports are increasingly used by software companies that server other businesses as customers. These reports are a means to measure and show how your company is performing against the SOC 2 controls to which you attest.

These reports are validated by 3rd party auditors. They provide assurances to partners and customers that you have committed to certain controls and are addressing those controls. Some companies have started to put their SOC 2 reports, or at least their summary reports, publicly on their websites.

There are two types of reports:

  1. SOC 2 Type 1 Reports are used to document that you have policies and procedures in place to meet the relevant SOC 2 controls for your company. These can be obtained in a very short of time once you start an engagement with a 3rd party auditor.
  2. SOC 2 Type 2 Reports demonstrate that you have implemented your policies and procedures. Typically, there is a defined time period between your Type 1 Report and Type 2 Report. This period of time is the period in which the implementation of your policies and procedures is assessed.

SOC 2 Reports are valuable in building trust with your partners and customers. A SOC 2 Type 2 Report go deeper than SOC 2 Type Report in that it assesses the operation, not just the definition, of your security program.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

© 2020 DayZero Inc. All rights reserved.

Questions? Reach out to us - hello@haekka.com

Schedule a demo

Start delivering training via Slack today.

Get started with a free trial by scheduling a demo today. One of our training experts will walk you through a live Haekka demo.

Excellent! We received your demo request. You should be redirected to our scheduling system. If you ran into an issue, please contact us.
Hmm. Something went wrong while submitting your form.
Please refresh and try again.