The conference room fell silent. The VP of Sales had just asked me a seemingly simple question: "What's the difference between the Security criteria and the Common Criteria in SOC 2?"
I looked around the table—the CEO, CFO, CTO, and the entire executive team were waiting for my answer. This wasn't the first time I'd encountered this confusion, and it wouldn't be the last. In fact, over my fifteen years of helping organizations achieve SOC 2 compliance, this misunderstanding has derailed more implementations than any other single issue.
Here's the truth that nobody tells you upfront: every SOC 2 report includes Common Criteria—it's not optional, it's not negotiable, and understanding this is the foundation of everything that follows.
Let me clear up this confusion once and for all.
What Are Common Criteria? (And Why Your Auditor Keeps Mentioning Them)
In 2017, I was brought in to rescue a failing SOC 2 implementation. The company had spent six months working with a consultant who kept telling them to "focus on Security criteria." They'd built elaborate access controls, implemented network segmentation, and deployed a cutting-edge SIEM system.
Then their auditor dropped the bomb: "You're missing all your Common Criteria controls."
The CTO looked at me in disbelief. "We have Security criteria. Isn't that enough?"
This is where most organizations stumble. Here's what you need to understand:
Common Criteria are the foundational requirements that apply to EVERY SOC 2 report, regardless of which Trust Services Criteria you select. Think of them as the bedrock upon which everything else is built.
The AICPA (American Institute of Certified Public Accountants) structures SOC 2 around five Trust Services Criteria:
Security (always required)
Availability (optional)
Processing Integrity (optional)
Confidentiality (optional)
Privacy (optional)
But before you even get to any of these, you must satisfy the Common Criteria—the universal requirements that demonstrate you have a functioning control environment.
"Common Criteria aren't just another checklist item. They're the governance foundation that makes all other controls meaningful and effective."
The Five Components of Common Criteria: Your SOC 2 Foundation
The Common Criteria are organized into five components, based on the COSO Internal Control Framework. After implementing these across over 60 organizations, I can tell you that understanding these components is the difference between a smooth SOC 2 journey and a painful 18-month nightmare.
Component 1: Control Environment (The Culture Question)
This is where most technical teams roll their eyes. "We need to document our culture?" they ask. "That's not security—that's HR stuff."
Let me share a story that changed my perspective forever.
In 2019, I worked with a fintech startup that had phenomenal technical controls. Multi-factor authentication everywhere. Zero trust architecture. State-of-the-art encryption. Their infrastructure team was brilliant.
They failed their SOC 2 audit.
Why? Because during interviews, the auditor discovered that engineers routinely shared admin credentials "to move faster." The CEO regularly asked people to bypass change management "just this once" for urgent customer requests. Security policies existed on paper but were widely ignored in practice.
The control environment isn't about what you say—it's about what you actually do.
Control Environment Elements | What Auditors Actually Look For | Common Failures I've Seen |
|---|---|---|
Commitment to Integrity and Ethical Values | Evidence that leadership reinforces security in actions, not just words | Executives who bypass their own policies; Ethics training that's check-box only |
Board Independence and Oversight | Board or equivalent regularly reviews security and risk | No documentation of board security briefings; Rubber-stamp approval processes |
Organizational Structure and Authority | Clear reporting lines and security responsibilities | Security buried 4 levels deep; No clear escalation paths |
Commitment to Competence | Security team has appropriate skills and training | Understaffed teams; No security training budget |
Accountability and Performance | Security metrics tied to employee evaluations | Security is "nice to have"; No consequences for violations |
Here's what I tell every CEO: Your control environment is proven by what happens when nobody's watching.
I worked with a healthcare company where the CEO set the tone perfectly. During an all-hands meeting, she told the story of how she'd locked herself out of a system and asked IT to bypass the normal access request process. IT refused. Instead of being angry, she publicly thanked them for following procedure and used it as a teaching moment.
That's a strong control environment. And their SOC 2 audit reflected it.
Component 2: Communication and Information (The Documentation Dilemma)
Here's a conversation I've had approximately 47 times:
Client: "Our team knows what to do. Do we really need to document everything?"
Me: "If your lead engineer wins the lottery tomorrow and quits, can someone else maintain your security controls?"
Client: "Well... probably not."
Me: "Then yes, you need documentation."
Communication and Information criteria evaluate whether your organization:
Creates and maintains relevant, quality information
Communicates security information internally
Communicates with external parties (customers, vendors, regulators)
Let me break down what auditors actually want to see:
Information Type | What You Need | Real-World Example |
|---|---|---|
Security Policies | Documented standards for how security works | Acceptable Use Policy, Password Policy, Encryption Standards |
Procedures | Step-by-step instructions for security processes | Incident Response Playbook, Access Provisioning Procedure |
System Documentation | What systems exist and how they interact | Network diagrams, Data flow diagrams, System inventories |
Communication Records | Evidence of security communication | Security training attendance, Policy acknowledgments, Incident notifications |
External Communications | How you inform stakeholders | Customer security updates, Vendor security requirements, Breach notifications |
I once audited a company that had beautiful policies—professionally written, comprehensive, perfectly formatted. There was just one problem: nobody had read them. The documents had been created for a previous audit attempt two years prior and sat untouched on SharePoint.
During employee interviews, not a single person could tell the auditor where to find the security policies or what they said.
They failed.
"Documentation without communication is just expensive shelf-ware. Communication without documentation is just gossip. You need both."
Pro tip from the trenches: Create a simple security portal—a single webpage with links to all your key security documents. Make it part of onboarding. Reference it constantly. When I helped a SaaS company implement this, their policy awareness went from 23% to 89% in three months.
Component 3: Risk Assessment (The "What Could Go Wrong?" Exercise)
Risk assessment is where organizations either thrive or die in SOC 2. I've seen both extremes.
The thrivers approach it systematically. The struggling organizations treat it as a one-time paperwork exercise to satisfy the auditor.
Here's what the Common Criteria require for risk assessment:
Risk Assessment Component | What It Means | Frequency | Common Mistakes |
|---|---|---|---|
Risk Identification | Document what could go wrong | Annually minimum, or when significant changes occur | Generic risks copied from templates; Not specific to your business |
Risk Analysis | Evaluate likelihood and impact | After identifying risks | No quantification; Everything rated "high" |
Risk Response | Decide how to address each risk | Per risk identified | All risks marked "accept" with no justification |
Fraud Risk Assessment | Specifically address fraud scenarios | Annually | Overlooked entirely; Too focused on external threats |
Significant Changes | Reassess when major changes occur | As changes happen | No defined threshold for "significant" |
Let me tell you about a company that got this right.
In 2020, I worked with a payments company going through SOC 2 for the first time. Their CISO—a former auditor herself—implemented what she called "Risk Tuesdays."
Every Tuesday at 10 AM, the leadership team spent 30 minutes reviewing one area of the business for risks. They'd ask:
What data do we handle here?
What could go wrong?
What's the impact if it does?
What controls do we have?
What gaps exist?
Within six months, they'd systematically assessed their entire operation. When a major security incident occurred—a vendor breach that exposed some customer data—they had their risk register to reference. They'd already identified this scenario, rated the risk, and documented their response plan.
Their incident response was textbook perfect. The auditor called it the best-prepared organization he'd assessed that year.
The secret sauce? They treated risk assessment as an ongoing conversation, not an annual checkbox.
Component 4: Monitoring Activities (Proving Your Controls Actually Work)
This is where the rubber meets the road. You can have beautiful policies, clear communication, and thoughtful risk assessments. But if you're not monitoring whether controls actually work, you're building a house of cards.
I'll never forget a 2018 audit where I watched a CTO confidently tell the auditor, "Our access reviews happen quarterly."
The auditor asked, "Can you show me the last four quarters of reviews?"
The CTO pulled up their documentation. The reviews had happened in Q1 and Q2... then nothing for eight months.
"What happened in Q3 and Q4?" the auditor asked.
"We got busy with product launches," the CTO admitted.
That's a control deficiency. And it's shockingly common.
Here's what monitoring actually requires:
Monitoring Activity | What Auditors Verify | Evidence Needed | Frequency Requirements |
|---|---|---|---|
Ongoing Monitoring | Day-to-day security activities | SIEM alerts, log reviews, automated scans | Continuous or daily |
Separate Evaluations | Independent assessment of controls | Internal audit reports, penetration tests | At least annually |
Management Review | Leadership examining security metrics | Management meeting minutes, dashboard reviews | At least quarterly |
Deficiency Reporting | Issues escalated and tracked | Ticketing system records, remediation plans | As issues arise |
Corrective Actions | Problems actually get fixed | Closed tickets, retest evidence | Per deficiency |
Let me share a success story that illustrates perfect monitoring.
A healthcare technology company I worked with implemented what they called their "Security Heartbeat"—a weekly automated report showing:
Control failures (access reviews missed, patches overdue)
Security metrics trends (time to patch, incident response time)
Open security issues and their age
Upcoming audit requirements
Every Monday morning, this report went to the leadership team. Every control had an owner. Every missed deadline required an explanation.
When their SOC 2 audit came, the auditor said something I'll never forget: "I can tell within 15 minutes whether an organization takes monitoring seriously. You folks have this down to a science."
They passed with zero deficiencies.
"Monitoring isn't about catching people doing wrong things. It's about proving you're doing the right things consistently."
Component 5: Control Activities (The Actual Security Controls)
Finally, we get to what most people think SOC 2 is all about—the actual security controls. But here's the critical insight: control activities in Common Criteria are about the existence and design of controls, not their specific implementation.
Think of it this way:
Common Criteria asks: "Do you have controls?"
Security Criteria asks: "Are your specific security controls adequate?"
Control Activity Category | What It Covers | Example Common Criteria Controls |
|---|---|---|
Policy and Procedure Compliance | Following your documented processes | Change management followed; Access requests approved properly |
Transaction Processing | Accuracy and completeness of transactions | Input validation; Reconciliation processes |
Physical Controls | Protecting physical assets | Data center access controls; Asset management |
Segregation of Duties | No single person controls entire process | Developers can't deploy to production; Separate approval chains |
Management Review | Leadership oversight of operations | Review of security metrics; Approval of significant changes |
I worked with a financial services company that had a fascinating challenge. They had brilliant security engineers who'd built sophisticated automation. Access provisioning was fully automated. Security patching was automated. Vulnerability scanning was automated.
But here's what they'd forgotten: controls need human oversight.
Their access provisioning system had a bug that granted some users more access than requested. Their automated system had been operating for four months before anyone noticed.
The fix wasn't technical—it was procedural. They implemented monthly reviews of access provisioning logs. A human spot-checked 10% of access grants to verify correctness.
Simple. Effective. And it satisfied the Common Criteria requirement for management review of control activities.
How Common Criteria Connect to Everything Else
Here's where it all comes together. Once you've established your Common Criteria, the Security criteria (and any additional criteria) build upon this foundation.
Let me illustrate with a real scenario:
Without Strong Common Criteria | With Strong Common Criteria |
|---|---|
Security team implements MFA, but leadership bypasses it when inconvenient | Leadership enforces MFA universally, setting the tone (Control Environment) |
Access control procedure exists but isn't documented or communicated | Clear access control procedure, documented and regularly communicated (Communication & Information) |
Never assessed the risk of compromised admin accounts | Identified privileged access as high risk, requiring enhanced controls (Risk Assessment) |
Don't verify that MFA is actually enforced everywhere | Quarterly reviews of MFA enforcement; Exceptions tracked and justified (Monitoring Activities) |
MFA implemented but no process for handling failures | Documented procedure for MFA enrollment, issues, and exceptions (Control Activities) |
See how the Common Criteria create the scaffolding that makes Security criteria effective?
The Common Criteria Implementation Roadmap (From Someone Who's Done This 60+ Times)
After guiding dozens of organizations through SOC 2, here's the sequence that works:
Phase 1: Control Environment (Weeks 1-4)
Week 1: Assessment
Interview leadership about security commitment
Review organizational structure
Identify security roles and responsibilities
Assess current governance processes
Week 2-3: Documentation
Document organizational structure
Define clear security roles
Create or update code of conduct
Establish board/leadership security oversight process
Week 4: Implementation
Launch code of conduct acknowledgment
Hold leadership security training
Establish regular leadership security briefings
Document your commitment to competence (training plans, hiring criteria)
I remember implementing this with a 30-person startup. The CEO was skeptical: "We're too small for this formal stuff."
I asked him: "Do you want to be 30 people forever, or do you want to scale to 300?"
He got it. We established governance practices that scaled beautifully as they grew. Three years later, they're at 280 employees, and their control environment is still rock solid.
Phase 2: Communication & Information (Weeks 5-8)
Week 5: Audit Current State
Inventory existing documentation
Identify gaps
Assess current communication channels
Review document storage and access
Week 6-7: Create Core Documentation
Document Type | Priority | Typical Effort |
|---|---|---|
Information Security Policy | High | 8-16 hours |
Acceptable Use Policy | High | 4-8 hours |
Access Control Procedure | High | 8-12 hours |
Incident Response Plan | High | 16-24 hours |
Change Management Procedure | High | 8-12 hours |
Risk Assessment Methodology | High | 12-16 hours |
Business Continuity Plan | Medium | 16-24 hours |
Vendor Management Procedure | Medium | 8-12 hours |
Week 8: Communication Rollout
Create central security documentation portal
Launch company-wide security training
Establish regular security communication cadence
Implement policy acknowledgment tracking
Pro tip: Don't try to document everything perfectly before communicating. I've seen organizations spend months perfecting documentation while nobody in the company knows what the security requirements are. Better to communicate good-enough documentation and improve it based on feedback.
Phase 3: Risk Assessment (Weeks 9-12)
This is where many organizations stumble. They either:
Make it too complicated (150-page risk register that nobody maintains)
Make it too simple (5 generic risks copied from the internet)
Here's the sweet spot:
Week 9: Risk Identification
Identify key assets (data, systems, processes)
List potential threats to each asset
Consider fraud risks specifically
Document external and internal risk factors
Week 10: Risk Analysis
I use this simple but effective framework:
Risk Level | Likelihood | Impact | Response Priority |
|---|---|---|---|
Critical | High | High | Immediate action required |
High | High | Medium OR Medium | High |
Medium | Medium | Medium OR High | Low OR Low |
Low | Low | Low OR Low | Medium |
Week 11: Risk Response
For each risk, decide: Accept, Mitigate, Transfer, or Avoid
Document your decision rationale
Assign owners to mitigation actions
Establish timelines for risk treatment
Week 12: Risk Communication
Present risk assessment to leadership
Obtain approval of risk treatment decisions
Create risk dashboard for ongoing monitoring
Schedule next assessment cycle
A manufacturing company I worked with had a breakthrough moment during risk assessment. Their operations team identified that their industrial control systems had no network segmentation from the corporate network.
"How long has this been the case?" I asked.
"Since we implemented the systems twelve years ago," they admitted.
This risk had been invisible until they systematically assessed their environment. Within three months, they'd implemented network segmentation, reducing their attack surface dramatically.
"Risk assessment isn't about creating scary lists of what might go wrong. It's about making informed decisions on where to invest your limited security resources."
Phase 4: Monitoring Activities (Weeks 13-16)
This is where you prove your controls work consistently, not just when auditors are watching.
Week 13: Design Monitoring Program
List all security controls
Determine monitoring method for each control
Establish monitoring frequency
Assign monitoring responsibilities
Week 14: Implement Automated Monitoring
Control Type | Monitoring Method | Tool Examples | Frequency |
|---|---|---|---|
Access Controls | Automated access reviews | Okta, Azure AD, Google Workspace | Weekly automated, Monthly human review |
System Logging | SIEM alert monitoring | Splunk, Datadog, Sumo Logic | Continuous |
Vulnerability Management | Automated scanning | Tenable, Qualys, Rapid7 | Weekly scans |
Patch Management | Compliance reporting | Automox, Tanium, WSUS | Weekly reports |
Configuration Management | Configuration scanning | AWS Config, Security Hub, Chef InSpec | Daily automated checks |
Week 15: Establish Human Review Processes
Create review schedules and assign owners
Document review procedures
Implement issue tracking for findings
Establish escalation procedures
Week 16: Management Dashboard
Create executive-level security metrics dashboard
Schedule regular management reviews
Document review activities and decisions
I helped a SaaS company implement a brilliant monitoring approach. They created three tiers:
Tier 1: Automated and Continuous - Machine monitoring 24/7 Tier 2: Weekly Team Review - Security team reviews automated findings Tier 3: Monthly Leadership Review - Executives review trends and make decisions
This structure caught issues early while keeping leadership informed without overwhelming them.
Phase 5: Control Activities (Weeks 17-20)
Finally, we implement the actual controls—but now with the foundation to make them effective.
Week 17-18: Implement Technical Controls
Based on your risk assessment, implement controls such as:
Multi-factor authentication
Access control systems
Encryption (data at rest and in transit)
Network security controls
System hardening
Backup and recovery systems
Week 19: Implement Operational Controls
Establish and operationalize:
Change management process
Incident response procedures
Access provisioning and deprovisioning
Security training program
Vendor security assessments
Physical security controls
Week 20: Validate and Document
Test each control to verify it works
Document evidence of control operation
Create audit trail for monitoring
Prepare for assessment
Common Criteria Pitfalls (And How to Avoid Them)
After seeing dozens of SOC 2 audits, here are the most common ways organizations fail on Common Criteria:
Pitfall 1: Documentation Without Implementation
The Mistake: Beautiful policies that nobody follows.
Real Example: A tech company had a comprehensive security policy requiring quarterly access reviews. In 18 months, they'd completed exactly one review—during the week before the audit.
The Fix: Implement controls BEFORE documenting them. Document what you actually do, not what you wish you did.
Pitfall 2: Monitoring Without Action
The Mistake: Generating reports that nobody reads or acts on.
Real Example: A financial services company ran weekly vulnerability scans. They had 47 weeks of scan reports showing the same critical vulnerabilities. Nothing had been remediated.
The Fix: Every monitoring activity needs an owner and a response procedure. If you're going to monitor something, you must act on the findings.
Pitfall 3: Risk Assessment Theater
The Mistake: Generic risks with no connection to actual business operations.
Real Example: A healthcare startup's risk register listed "data breach" and "system downtime" as their top risks. But they couldn't articulate what specific data could be breached, through what attack vector, or which systems were most critical.
The Fix: Risk assessment must be specific to YOUR organization, YOUR data, YOUR systems, and YOUR threat environment.
Pitfall 4: One-Time Implementation
The Mistake: Treating SOC 2 as a project with an end date.
Real Example: A SaaS company worked frantically for 6 months to achieve SOC 2. They got their Type I report. Then everything stopped. By the time they went for Type II (measuring controls over time), nothing was being maintained.
The Fix: Compliance is operational, not project-based. Build it into business-as-usual processes.
Pitfall 5: Ignoring the Control Environment
The Mistake: Focusing purely on technical controls while ignoring culture and governance.
Real Example: A company had phenomenal technical security but toxic culture. Senior engineers regularly violated change management "because we know what we're doing." Leadership backed them. The auditor noted significant control environment deficiencies.
The Fix: Security starts at the top. Leadership must model the behavior they expect from everyone else.
The Common Criteria Checklist: Your Pre-Audit Sanity Check
Before your SOC 2 assessment, verify you can answer "yes" to all of these:
Control Environment
[ ] Organization chart clearly shows security roles and reporting lines
[ ] Leadership team receives regular security briefings (with documentation)
[ ] Board or equivalent oversight body reviews security at least annually
[ ] Code of conduct or ethics policy exists and is acknowledged by all employees
[ ] Security responsibilities are included in job descriptions
[ ] Performance evaluations consider security responsibilities
[ ] Background checks are performed on employees with sensitive access
[ ] Security training budget exists and is utilized
Communication & Information
[ ] Security policies exist and are accessible to all employees
[ ] Policies are reviewed and updated at least annually
[ ] All employees acknowledge policies annually
[ ] Security training is provided to all employees at hire and annually
[ ] System documentation is current (network diagrams, data flows, inventories)
[ ] Procedures exist for key security processes
[ ] External communications process exists (customer notifications, vendor requirements)
[ ] Security metrics are reported to management regularly
Risk Assessment
[ ] Formal risk assessment conducted at least annually
[ ] Risk assessment covers all critical systems and data
[ ] Fraud risk specifically assessed
[ ] Risks are rated for likelihood and impact
[ ] Risk treatment decisions are documented and approved
[ ] Risk register is maintained and updated
[ ] Significant changes trigger risk reassessment
[ ] Leadership reviews and approves risk assessment
Monitoring Activities
[ ] All critical controls are monitored
[ ] Monitoring frequency is defined for each control
[ ] Automated monitoring is implemented where possible
[ ] Human review processes are documented and executed
[ ] Control failures are detected and escalated
[ ] Security metrics dashboard exists
[ ] Management reviews security metrics at least quarterly
[ ] Independent assessment (internal audit or penetration test) occurs annually
Control Activities
[ ] Change management process is documented and followed
[ ] Access provisioning and deprovisioning procedures exist
[ ] Segregation of duties is maintained
[ ] Transaction processing controls are in place
[ ] Physical security controls are implemented
[ ] Control procedures are documented
[ ] Evidence of control operation is collected
[ ] Control deficiencies are tracked and remediated
What Success Looks Like: A Real Implementation
Let me close with a success story that demonstrates Common Criteria done right.
In 2021, I worked with a 50-person marketing technology startup pursuing their first SOC 2. The CEO initially viewed compliance as a "necessary evil" to close enterprise deals.
We started with the Common Criteria foundation:
Month 1-2: Control Environment
Established security steering committee with executive representation
Created clear security roles and hired a security engineer
Implemented quarterly board security briefings
Rolled out ethics training company-wide
Month 3-4: Communication & Information
Created 8 core security policies
Built security knowledge base
Launched monthly security newsletter
Implemented policy acknowledgment tracking
Month 5-6: Risk Assessment
Conducted comprehensive risk assessment
Identified 23 significant risks
Prioritized treatment of top 8 risks
Created risk dashboard for ongoing monitoring
Month 7-8: Monitoring Activities
Implemented SIEM for continuous monitoring
Established weekly security reviews
Created monthly metrics dashboard
Scheduled quarterly management reviews
Month 9-10: Control Activities
Deployed MFA across all systems
Implemented formal change management
Established access review process
Created incident response procedures
Month 11: Pre-Audit
Internal audit to identify gaps
Remediated findings
Collected evidence
Prepared for assessment
Month 12: SOC 2 Type I Audit
Passed with zero deficiencies
Auditor praised their "mature approach"
Closed 3 major enterprise deals within 60 days
But here's the best part: Six months later, the CEO told me, "SOC 2 didn't just help us close deals—it made us a better company. Our incident response is faster. Our development is more reliable. Our team has clarity. I'm a believer now."
That's what Common Criteria done right looks like. It's not compliance theater—it's operational excellence with an audit trail.
Your Common Criteria Journey Starts Now
Common Criteria aren't sexy. They're not the exciting technical controls that CISOs love to talk about at conferences. They're governance, documentation, process, and oversight.
But they're also the foundation that makes everything else possible.
After fifteen years in this field, I can spot a successful SOC 2 implementation in the first hour of assessment. It's not about the fancy tools or the impressive certifications on the wall. It's about whether the organization has solid Common Criteria.
"Show me an organization with strong Common Criteria, and I'll show you an organization that will pass their SOC 2 audit. Show me one with weak Common Criteria, and no amount of technical controls will save them."
Start with governance. Build communication and information systems. Assess your risks systematically. Monitor relentlessly. Implement controls deliberately.
Do this, and SOC 2 stops being a burden and becomes what it should be: proof that you run a well-controlled, mature organization that takes security seriously.
Because at the end of the day, that's what your customers, your partners, and your stakeholders actually want to know.