SOC 2 Control Activities: Day-to-Day Operational Controls

I was sitting across from a frustrated VP of Engineering at a fast-growing SaaS company in Austin back in 2021. He'd just failed his first SOC 2 audit, and the rejection letter sat between us like a bomb.

"I don't understand," he said, rubbing his temples. "We have all the tools. We spent $400,000 on security infrastructure. Our penetration tests came back clean. How did we fail on control activities?"

I pulled out the auditor's report and pointed to a single line: "Unable to verify consistent application of documented controls in day-to-day operations."

They had beautiful policies. Expensive tools. But nobody was actually doing the daily work that makes SOC 2 meaningful.

That conversation changed how I approach SOC 2 consulting. Because here's the truth bomb: SOC 2 doesn't fail in the boardroom during policy creation—it fails at 2 PM on a Tuesday when someone takes a shortcut because "we need to ship this feature NOW."

What Control Activities Actually Mean (And Why Most People Get It Wrong)

After shepherding 40+ companies through SOC 2 certification over the past decade, I've learned that control activities are the most misunderstood component of the Trust Services Criteria.

Let me break this down simply: Control activities are the actions your team performs every single day to make your security policies real. They're the difference between having a fire alarm installed and actually checking it monthly to ensure it works.

Here's what I tell every client: If your controls only exist in documentation, they don't exist at all.

The Five Control Activity Categories That Matter

SOC 2 organizes control activities into specific categories. Let me walk you through each one with real examples from companies I've worked with.

Top-Level Reviews: Where Leadership Proves They Care

I worked with a healthcare tech startup in 2022 that had a brilliant CEO. Smart guy, visionary, but completely absent from security discussions. His CISO would send him weekly security reports. Know what happened to them? They went into a folder marked "Review Later" that never got reviewed.

Their audit failed. The auditor's note? "No evidence of management engagement with security program."

Six months later, same company, different approach. The CEO now:

• Attended a 30-minute security briefing every Monday morning

• Reviewed and signed off on the weekly security dashboard

• Participated in quarterly risk assessment meetings

• Asked questions and documented decisions in meeting minutes

They passed their next audit with flying colors.

"Control activities without management attention are like gym memberships—expensive commitments that make you feel good but produce no actual results."

What Top-Level Reviews Should Look Like

Here's the framework I've implemented across dozens of organizations:

Weekly Reviews (15-30 minutes):

• Current security incidents and status

• Key metrics: failed login attempts, vulnerability scan results, access request backlogs

• Upcoming changes that could impact security

• Resource allocation decisions

Monthly Reviews (60-90 minutes):

• Trend analysis of security metrics

• Vendor security assessment updates

• Training completion rates

• Budget vs. actual security spending

• Risk register updates

Quarterly Reviews (2-3 hours):

• Comprehensive risk assessment

• Control effectiveness evaluation

• Strategic security initiatives progress

• Disaster recovery testing results

• Third-party audit findings

The magic isn't in the meetings themselves—it's in the documented evidence that these reviews happened and drove decisions.

Here's a table showing the evidence auditors actually want to see:

Physical Controls: Yes, They Still Matter in the Cloud Era

I can already hear you thinking: "We're a cloud-native SaaS company. We don't have physical controls!"

Wrong. Dead wrong. And I've seen three companies fail their SOC 2 audits because of this exact misconception.

Let me tell you about a fintech startup I worked with in 2020. Fully remote, everything in AWS, no data center. They assumed physical controls didn't apply to them.

Then the auditor asked: "Where do your employees work from? Do they access production systems from home offices? From coffee shops? How do you control physical access to devices that can access your production environment?"

Crickets.

Physical Controls in Modern Organizations

Here's what physical controls actually mean today:

Office Locations (If You Have Them):

• Badge access systems with logs

• Visitor management procedures

• Secure areas for sensitive operations

• Video surveillance in key areas

• Equipment inventory and tracking

Remote Work Environments:

• Company-issued laptop requirements

• Encrypted hard drive mandates

• Screen privacy filters for public spaces

• Secure home office guidelines

• Device loss/theft reporting procedures

Data Center and Colocation:

• Vendor SOC 2 reports for physical security

• Access logs from data center providers

• Documented procedures for physical access requests

• Equipment disposal and destruction procedures

I implemented a physical control program for a 100% remote company that included:

They passed their audit. The auditor specifically commended their "comprehensive approach to physical security in a distributed environment."

Segregation of Duties: The Control That Prevents Insider Threats

This is where I see the most pushback, especially from startups. "We're only 12 people," they tell me. "How can we segregate duties when my lead engineer does everything?"

I get it. I really do. But here's a story that might change your mind.

In 2019, I consulted for a company that had suffered an insider breach. A developer with production access, database admin rights, and code deployment authority had exfiltrated customer data over six months. When they finally caught him, they realized he'd also deleted the audit logs of his own activities.

Damage: $3.2 million in direct costs, loss of two major clients, 18 months of reputation recovery.

The kicker? It would have been impossible if they'd properly segregated duties.

"Segregation of duties isn't about not trusting your team. It's about protecting them from the temptation of unsupervised power and protecting your organization from the 2% of people who will abuse that power."

Critical Segregation of Duties Controls

Here's the framework I implement even in small organizations:

Small Team Solutions

"But we only have 8 people!" Yes, I hear you. Here's how I solve this:

Use automation for the second pair of eyes:

• Automated code review tools that flag suspicious patterns

• CI/CD pipelines that enforce approval workflows

• Automated access reviews that require manager confirmation

• Database audit logging that's sent to external systems

Implement peer review requirements:

• All code must be reviewed by at least one other developer

• All production changes must have a second person on the Zoom call

• All access grants require a ticket and manager approval

Leverage third-party tools:

• Use services like AWS CloudTrail that you can't modify

• Implement SIEM solutions with immutable logs

• Use privileged access management tools that record sessions

I worked with a 9-person startup that implemented this:

Cost: $800/month in additional tools. Value: Passing SOC 2 and preventing potential insider threats.

Information Processing Controls: Where the Rubber Meets the Road

This is the big one. Information processing controls are the daily, ongoing activities that actually secure your data. And this is where most organizations have the biggest gap between policy and practice.

Let me share a painful example. In 2023, I was brought in to investigate why a company failed their SOC 2 surveillance audit after passing their initial certification.

The problem? Their policy said "all production changes must be documented and approved." Beautiful policy. But when the auditor sampled 25 production changes, 19 of them had no change ticket, no approval, and were pushed directly to production.

"We had a critical bug," they explained. "We needed to move fast."

The auditor's response? "Then your policy should say 'all production changes except when we don't feel like it.' Because that's what you're actually doing."

They lost their SOC 2 certification. Their biggest customer immediately triggered a contract review clause. It cost them $4.8 million in lost revenue.

The Information Processing Controls That Actually Matter

Based on 15+ years of experience, here are the controls that auditors scrutinize most heavily:

Change Management:

Access Management:

I implemented this framework at a 200-person SaaS company:

Vulnerability Management:

This is where I see organizations struggle with consistency. They start strong then get sloppy over time.

Backup and Recovery:

Here's a table showing the control activities I implement:

Performance Reviews: Ensuring Humans Stay in the Loop

Technology is fantastic. Automation is critical. But humans are still the most important control in your security program.

I learned this lesson the hard way in 2020. A client had beautiful automated controls. Their systems were pristine. They failed their audit because nobody was reviewing the output of those automated systems.

They had:

• Automated vulnerability scans (that nobody reviewed)

• Automated access logs (that nobody analyzed)

• Automated backup verification (that nobody checked)

• Automated security alerts (that everyone ignored)

The auditor's comment? "These aren't controls. These are expensive noise generators."

The Performance Review Controls That Pass Audits

Daily Reviews:

Weekly Reviews:

Monthly Reviews:

These are comprehensive deep dives. Here's the framework I use:

Quarterly Reviews:

This is where strategy meets execution:

The Control Activities That Kill Your Audit (And How to Fix Them)

After reviewing dozens of failed SOC 2 audits, I've identified the top control activity failures:

Failure #1: Inconsistent Application of Controls

The Problem: You have a control that says "all production changes require approval." Then someone deploys directly to production without approval because "it's urgent."

Real Example: A company I worked with had 47 emergency changes in a 6-month period. Every single one bypassed their change control process. They failed their audit.

The Fix:

• Create an actual emergency change process with documentation requirements

• Emergency changes must be reviewed within 24 hours

• Pattern of excessive emergency changes triggers process review

Evidence Table:

Failure #2: Evidence That Doesn't Exist

The Problem: Your policy says you do something. You probably do it. But you can't prove it.

Real Example: A client performed security training for all new hires. They just didn't document who completed it or when. During the audit, they couldn't prove any training had occurred.

The Fix: If it's not documented, it didn't happen. Period.

Evidence Requirements:

Failure #3: Controls Performed by the Wrong People

The Problem: The person who makes changes is the same person who reviews them.

Real Example: A company's database administrator made changes to production databases and then marked his own changes as "reviewed and approved" in the change management system.

The Fix: Segregation of duties enforced through tooling:

Building a Control Activities Program That Actually Works

After 15 years of implementing these programs, here's my battle-tested framework:

Phase 1: Document Current State (Week 1-2)

Don't start by writing policies. Start by documenting what actually happens.

Activities:

• Shadow your team for a week

• Document actual processes, not ideal processes

• Identify where documented procedures and reality diverge

• Map out who does what, when, and how

Deliverable: Current state process map showing actual control activities

Phase 2: Gap Analysis (Week 3-4)

Compare what you do to what SOC 2 requires.

Phase 3: Design Realistic Controls (Week 5-8)

This is critical: Design controls your team will actually follow.

I worked with a company that created a change management process requiring 7 approvals and 48-hour lead time. Within a month, everyone was routing around it. They ended up with worse compliance than before.

Principles for Realistic Controls:

• Minimize manual steps through automation

• Make compliance the path of least resistance

• Design for humans, not ideal robots

• Build in appropriate emergency procedures

• Match control rigor to actual risk

Phase 4: Implement and Train (Week 9-16)

Roll out controls with proper training and support.

Phase 5: Monitor and Adjust (Ongoing)

This is where most programs fail—they don't adapt.

Monthly Activities:

• Review control compliance metrics

• Gather feedback from teams performing controls

• Identify controls that aren't working

• Adjust procedures based on reality

Quarterly Activities:

• Comprehensive control effectiveness review

• Update procedures based on lessons learned

• Refresh training for struggling areas

• Celebrate successes and share best practices

The Daily Control Activities Checklist

Here's a practical checklist I give every security team. Print this, laminate it, put it on the wall:

Daily Control Activities (30-60 minutes total)

Weekly Control Activities (3-4 hours total)

Real-World Success: What Good Looks Like

Let me end with a success story that illustrates everything I've covered.

In 2022, I worked with a 85-person SaaS company going through their first SOC 2. They were terrified. Their engineering culture was "move fast and break things"—the opposite of compliance culture.

We implemented the control activities framework I've described here. Six months later:

Their Results:

• Passed SOC 2 Type II on first attempt

• Zero control deficiencies

• Auditor specifically praised their "mature control environment"

• Actually improved their development velocity by 15%

That last point surprised them. How did compliance make them faster?

Because good controls eliminate chaos. When everyone knows the process, follows the same procedures, and has clear approval paths, there's no confusion, no rework, no "wait, who was supposed to approve this?"

Their CTO told me: "I thought SOC 2 would slow us down. Instead, it made us professional. We ship faster now because we're not constantly firefighting our own mistakes."

"The best control activities don't feel like compliance overhead. They feel like the way professionals work."

Your Next Steps

Ready to build a control activities program that passes audits and actually improves your operations?

This Week:

1. Print the daily and weekly control activities checklists above

2. Shadow your team to document what actually happens today

3. Identify your top 3 control gaps

4. Schedule a meeting with your team to discuss findings

This Month:

1. Design realistic control activities for your top gaps

2. Select and implement tools to support your controls

3. Train your team on new procedures

4. Start documenting evidence

This Quarter:

1. Implement all critical control activities

2. Conduct monthly control effectiveness reviews

3. Build evidence collection into daily workflows

4. Prepare for your SOC 2 readiness assessment

Remember: Control activities aren't about creating bureaucracy. They're about building a system where security happens naturally, consistently, and provably—day after day, week after week, all year long.

Because when the auditor asks "How do you know your controls work?" the answer should never be "We think they do."

The answer should be "Let me show you the evidence from the last 365 days of daily operations."

That's how you pass SOC 2. That's how you build real security. That's how you protect your business and your customers.

Now go build something remarkable.