The SOC 2 Guide

DC1: Types of services provided

Describe what services the service organization provides as it relates to the system in scope.

DC2: Principal service commitments and system requirements

This section lets the reader know what commitments and system requirements the service organization is making, and which documents the reader can find these commitments in (e.g. MSA, SLAs, Privacy Policy, etc.). This helps give the reader context as to what trust services categories are in-scope and why.

DC3: Components of the system

The components described here include the infrastructure, software, people, procedures, and data that support and make up the system. For many Cloud Service Providers (CSP), the infrastructure section will include their hosting provider (such as Amazon Web Services). The software section should list the software and applications that support delivering the service in scope. The people section should include an overview of the departments or key personnel that support the system and what they do. Procedures should state what procedures are and their purpose. Data should discuss what the data is that the system processes (what is your customer data), as well as any other data that directly supports the system.

DC4: System incidents

Describe any security incidents that rose to the level where your company failed to either meet criteria, your commitments to customers, or your system requirements.

DC5: Applicable trust services criteria and related controls

Describe the criteria that are in-scope so that the reader understands the criteria the service organization is being measured against. The service organization will also discuss in detail the control environment and describe the controls that support it. This is a narrative section that is essentially a lighter version of the information security policy.

DC6: Complementary user entity controls (CUECs)

CUECs are the controls that the service organization's customers need to have in place in order for the system and control environment to be complete and achieve its objectives. For example, maybe the customers need to have their own logical access controls in place so that only authorized users access the service, otherwise, unauthorized access may cause you to fail to meet your security commitments.

DC7: Complementary subservice organization controls (CSOCs)

The service organization will discuss the subservice organizations that support the system and control environment. Subservice organizations are vendors that you cannot meet your criteria, commitments, or system requirements without. For most CSPs, that is going to be the cloud hosting provider (AWS, GCP, Azure, etc.)

Buying Security by TL;DR Sec

Buying Security
A fantastic guide synthesized from almost two hundred resources, as well as a survey of over a hundred security professionals.

Breaks down the types of security consulting, motivations behinds assessments, potential vendors, as well as how to scope and prepare for your assessment.

Practical guidance for companies

NPSA UK Secure Innovation
Competition to succeed in emerging technology can be intense. This guidance outlines cost-effective measures that you can take from day one to better protect your ideas, reputation and future success.

This can even become the basis of your SOC 2. These are real threats, which suggest threat models which could apply. If they do apply, it can really help to target policies to deal with specifically these.

Tailscale's Security Policies

Tailscale's public SOC 2 Policies on GitHub
Tailscale has several security policies in place to properly identify, respond to, and mitigate potential security risks. All employees, vendors and contractors working with Tailscale must follow these policies in order to best protect Tailscale's and its customers' data.

They've published these publicly for transparency, so that you can see where they are in terms of security maturity.

Comply SOC 2 Automation Tool

Comply open source automation

• Policy Generator: markdown-powered document pipeline for publishing auditor-friendly policy documents
• Ticketing Integration: automate compliance throughout the year via your existing ticketing system
• SOC 2 Templates: open source policy and procedure templates suitable for satisfying a SOC 2 audit

JupiterOne's Policy Builder

Standup-alone polices or integrated policy builder
A set of foundational but comprehensive policies, standards and procedures designed for cloud-native technology organizations. The policy package covers the requirements and controls for most compliance frameworks and best practices, in a lightweight approach.

They can be used as stand-alone documents. But the structure is designed to be best suited for use with the jupiter-policy-builder CLI and the policies app on the JupiterOne platform.

Minimum Viable Secure Product

List of the minimal controls
Minimum Viable Secure Product is a minimalistic security checklist for B2B software and business process outsourcing suppliers.

They recommend that all companies building B2B software or otherwise handling sensitive information under its broadest definition implement at least the following controls, and are strongly encouraged to go well beyond them in their security programs.

A Guide to personal security

US DNC Security Checklist
They strongly recommend anyone who works in politics, campaigns, or really anyone who has a device or an account on the internet, take these steps to secure them.

A guide that is broken down into easy to follow steps for personal security. While it is directed at those in a specific industry there is really good starter advice here, that can get you far. (Don't listen to the advice about LastPass though, the approved list of Password Managers should be BitWarden, 1Password, Chrome Password Manager, and Apple Keychain.)

Authress: Authentication & Authorization

User Management and Access Control
Quick start complete application security, by adding Authress to your stack.

Authress is the only complete authentication solution for B2B, so it helps gets your application security most of the way towards compliance. If you're looking for an alternative list of solutions, the Auth Situation Report contains many more.

Create emergency access roles in AWS

AWS Break Glass emergency role configuration

It is recommended to restrict access to the AWS account that hosts your production environment. In these cases it may be necessary to provision a user or role with elevated permissions to be used only in emergency cases.

This type of role is typically called a "Break Glass Role" and is usually used in On Call situations or other circumstances when quick mitigating action is needed.

Prowler - Perform best practice assessments

Open source documentation & guide

Prowler is an Open Source security tool to perform AWS, GCP and Azure security best practices assessments, audits, incident response, continuous monitoring, hardening and forensics readiness.

It contains support for hundreds of controls covering CIS, NIST 800, NIST CSF, CISA, RBI, FedRAMP, PCI-DSS, GDPR, HIPAA, FFIEC, SOC2, GXP, and many more.

NodeZero

Open Source PenTesting Platform

The NodeZeroTM platform empowers your organization to reduce your security risk by autonomously finding exploitable weaknesses in your network, giving you detailed guidance about how to prioritize and fix them, and helping you immediately verify that your fixes are effective.

Auth: Situation Report

All you need to know before adding auth to your project

If you’re someone who builds software, no matter if you’re on the backend or frontend or even on the product side, sooner or later you have to concern yourself with securing the thing. Or you realize that data privacy laws are very real and you must have a strategy for user data sharing. So you want to implement some sort of authentication. More likely, you’re looking for a solution, open-source or otherwise, that will solve this problem for you. And here comes confusion. This report has some of the answers.