Next-Gen SCA: Securing Modern SDLCs with Pipeline Composition Analysis. Register now for the upcoming webinar

SOC 2 Type II Compliance

Tony Loehr
Developer Advocate

Developed by the American Institute of CPAs (AICPA), SOC 2 Type II is prescribed to organizations handling sensitive information to verify the safe handling of precious data. SOC 2 Type II compliance is verifiable by way of security controls, similarly to other compliance frameworks such as FedRAMP or SLSA. This compliance framework is designed to improve the trust between SaaS vendors and their customers.

SOC, standing for System and Organization Controls, defines criteria for managing sensitive data and tools. These reports are unique to each organization,  The key difference between SOC 1 and SOC 2 is the scope of security controls implemented; SOC 1 addresses controls relevant to a service organization’s handling of client financial information, whereas SOC 2 addresses controls relevant to an organization’s operations and compliance as defined in AICPA’s Trust Services Criteria (TSC).

Scope of SOC Compliance Requirements

SOC compliance requirements entail controls over a predetermined scope. The domain of SOC 2 compliance expands to the following categories: infrastructure, software, people, data, and procedures.

  • Infrastructure: The physical and hardware components (networks, facilities, and equipment) that support an organization’s IT environment and help deliver services. 
  • Software: The operating software and programs (utilities, applications, and systems) an organization uses to facilitate data and system processing.
  • People: The personnel (managers, developers, users, and operators) involved in the management, security, governance, and operations to deliver customer services. 
  • Data: The information (files, databases, transaction stream, and tables) you use or process within the service organization. 
  • Procedures: The manual or automated methods that bind processes and keep service delivery ticking along. 

Trust Service Principles

SOC provides the notion of trust service principles, which serves to establish a quantifiable standard for data handling. This collection of principles rests upon five fundamental ideas: security, availability, processing integrity, confidentiality, and privacy.

Security

The security principle refers to the protection of system resources against unauthorized access. Access controls help prevent potential system abuse, theft or unauthorized removal of data, misuse of the software, and improper alteration or disclosure of information.

Examples include:

Availability

The availability principle refers to the accessibility of the system, products, or services as stipulated by a contract or service level agreement (SLA). As such, both parties agree to the minimum acceptable performance level for system availability.

Examples include: 
  • Performance monitoring
  • Disaster recovery
  • Security incident handling

Processing Integrity

The processing integrity principle addresses whether or not a system achieves its purpose (i.e., delivers the correct data at an acceptable price at the right time). Accordingly, data processing must be complete, valid, accurate, timely, and authorized.

Examples include:

Confidentiality

SOC standards define data as confidential if organizations restrict access and disclosure to a specified set of persons or organizations. Encryption is an essential control for protecting confidentiality during transmission.

Examples include:

Privacy

The privacy principle addresses the system’s collection, use, retention, disclosure and disposal of personal information in conformity with an organization’s privacy notice and criteria outlined in the AICPA’s generally accepted privacy principles (GAPP)

Examples include:
  • Cookie opt-in banners
  • Data purge processes

Note: An updated version building upon these principles may be found in the AICPA’s Privacy Management Framework (PMF).

SOC 2 Type II Compliance 

SOC 2 is a report on an organization’s system and the suitability of the design controls. This audit takes two different forms: SOC 2 Type I and SOC 2 Type II. Similar to levels within SLSA, Type II is a more advanced stage of achieving SOC 2 compliance than Type I. 

Type I describes an organization’s systems, processes, and ability to meet the required trust principles. Type II details the operational effectiveness of these Type I criteria.

The baseline security controls needed to fulfill the guidance set by the AICPA fall into four main categories, including access controls, change management, system operations, and mitigating risk.

Access Controls

Logical and physical access controls entail restrictions on assets to prevent access by unauthorized personnel.

Example: The principle of least privilege is enforced, preventing source code and data access by extraneous entities.

Change Management

Change management refers to implementing a controlled process for managing changes to IT and operational systems. This includes methods for preventing unauthorized changes to code, security controls, environmental settings, and other configurations within the SDLC.

Example: Security control configurations are actively monitored to prevent unsanctioned changes that can result in weakened security posture.

System Operations

The management of operations controls that can monitor ongoing operations, detect anomalous behaviors, and resolve any deviations from organizational procedures.

Example: Excessive cloning of repositories in a short period of time can indicate malicious intent or insider threat.

Mitigating Risk 

This control includes methods and activities that allow the organization to identify and respond to risks. The mitigation strategy also seeks to address any subsequent business risks that could lead to disruption of regular operations.

Example: Implementing a contingency plan, such as outlined in the NIST SSDF, helps an organization determine a course of action should a code leak occur.

SOC 2 Compliance with Cycode

Cycode helps organizations comply with SOC 2 Type II requirements by consistently applying security policies at all stages of the software development cycle. Cycode offers security policies to establish access control, provide source fidelity, and monitor for violations that can result in vulnerabilities.

The Cycode platform may be used to detect excess permissions in resources; examples include CI/CD workflows that depend on unknown 3rd parties components, or cloud configurations that allow unsupervised shared admin roles. Cycode is able to identify exactly what policies need to be fixed to comply with a mandate. It also provides remediation assistance in the form of fix suggestions, code fixes, and in some cases automated remediation to efficiently solve the detected issues.

Cycode helps to automatically generate the specific evidence auditors are looking for with regards to specific compliance mandates and security controls. Our system shows the policies in place as part of each security control and can generate suitable evidence to use for attestation–this process helps organizations fulfill auditor needs and frees up time developers would otherwise spend manually verifying audit fulfillment status.

One of the most significant issues with common security tools is the prevalence of false positives. Cycode’s data-driven security tools aggregate data from multiple stages in the development pipeline to create complex insights, detect anomalies that can signal a vulnerability, and avoid false positives.

Want To Learn More?

A great place to start is with a free assessment of the security of your DevOps pipeline