SOC 2 common criteria explained without the jargon

Decoding the CC-Series: The Five Pillars of Trust

The Common Criteria (CC) are the foundational building blocks of the SOC 2 Security Trust Services Category. Think of them as the 'must-haves' regardless of what your software actually does. Whether you are a FinTech API or a niche SaaS, the AICPA requires you to demonstrate competency across five specific areas: Control Environment, Communication and Information, Risk Assessment, Monitoring Activities, and Control Activities. These are collectively known as the CC-Series.

A common misconception is that SOC 2 is purely a technical 'firewall and password' audit. In reality, the Common Criteria are heavily weighted toward governance and corporate culture. For instance, CC1.1 through CC1.5 focus almost entirely on integrity, ethical values, and how management assigns authority. If you don't have a formal board or a clear whistle-blower policy, you are already failing the first hurdle of the Common Criteria before a single server has been scanned.

Governance and the 'Tone at the Top' (CC1 & CC3)

The CC-Series starts with the 'Control Environment' (CC1 series), which is the most overlooked section by technical founders. Auditors look for evidence that the 'tone at the top' supports security. This isn't about code; it's about whether you have an HR process that includes background checks and whether your employees have signed a confidentiality agreement. If your corporate culture treats security as a nuisance, the auditor will spot it here.

Risk Assessment (CC3 series) is another critical pillar. You aren't expected to be bulletproof, but you are expected to prove that you know where your holes are. An auditor will want to see a Risk Register—a list of things that could go wrong, from a data breach to a lead developer quitting unexpectedly. You must show that you’ve identified these risks and decided whether to fix them, ignore them, or outsource them.

• A formal Risk Assessment document updated at least annually.
• Meeting minutes showing security is discussed at the executive level.
• Signed 'Code of Conduct' agreements for every employee and contractor.
• Documented 'Reporting Lines' or an organisational chart.
• A Vendor Risk Management process for third-party tools like AWS or GCP.

Logical Access and Technical Safeguards (CC6)

Once you move past the governance sections, CC6 and CC7 deal with the 'Logical and Physical Access' and 'System Operations'. This is where most developers feel more at home. CC6.1, for example, requires that you manage identities and access. In practical terms, this means MFA (Multi-Factor Authentication) is non-negotiable for every single door into your environment. If one engineer can access your production database via a password alone, you will receive a qualified (failed) report.

The 'Logical Access' criteria also demand a 'Joiners, Movers, Leavers' process. You need to prove that when someone leaves the company, their access is revoked within a set timeframe—usually 24 to 48 hours. During an audit, the practitioner will pick five random former employees and ask for proof of exactly when their GitHub and AWS access was terminated. Discrepancies here are the number one cause of last-minute audit stress.

• A formal Change Management policy (no merging to Prd without review).
• Proof of 'Peer Review' or 'Pull Request' approvals for all code changes.
• Automated vulnerability scanning reports (e.g., Snyk, Dependabot).
• An incident response plan that has been 'tabletop' tested.

Change Management and Monitoring (CC7 & CC8)

CC8.1 focuses specifically on 'Change Management'. In a modern CI/CD environment, this doesn't mean a weekly 'Change Approval Board' meeting that kills velocity. Instead, it means having a documented path for code from a local machine to production. The auditor needs to see that code is reviewed by someone other than the author and that automated tests are passing before deployment.

System Operations (CC7) covers how you monitor for anomalies. It isn't enough to have logs; you must prove you are looking at them. For a startup, this might mean having Slack alerts for 403 errors or high CPU usage. The specific artefact required here is often an 'On-Call' schedule or evidence of a 'Post-Mortem' report after a minor outage. Proving that you learn from failures is a core requirement of the Common Criteria.

Implementation Strategy: Real-World Application

One of the biggest mistakes founders make is trying to 'do the CCs' in a vacuum. The Common Criteria are designed to be integrated into your daily workflow. If you treat SOC 2 as a 'project' that finishes once the report is signed, you will face a nightmare during the following year's Type 2 audit. You must automate the evidence collection. If you aren't using a platform to track these controls, you will spend 20% of your engineering time manually taking screenshots for auditors.

Finally, understand that the 'Common' in Common Criteria means they apply to everyone, but the *implementation* is scoped to your business. You don't need a 24/7 guarded data centre if you are 100% on AWS; you just need to review AWS's own SOC 3 report. Tailor your controls to your actual tech stack, and don't let a consultant sell you a 100-page policy manual that doesn't reflect how your team actually works. Keep it lean, keep it evidence-based, and keep it focused on the CC series.

Frequently asked questions