DEV Community: Aditya Khare

Common SOC 2 Failures (Real World)

Aditya Khare — Fri, 17 Apr 2026 17:36:49 +0000

A field-tested breakdown from actual audit trenches

If you’ve ever worked on a SOC 2 audit—especially in a Big 4 or fast-scaling startup—you already know this:

👉 Most companies don’t fail because they lack controls.
👉 They fail because their controls don’t work in reality.

This post breaks down real-world SOC 2 failures that repeatedly show up during audits, readiness assessments, and quality reviews.

No theory. Just what actually goes wrong.

1. “We Have a Policy” (But No One Follows It)

What companies say:

“Yes, we have an access control policy.”

What auditors find:

Policy exists (nicely documented)
No evidence of implementation
Employees unaware of it

Failure Example:

Password policy requires 12 characters
System allows 6-character passwords

Root Cause:
Policies are written for compliance—not operations.

Audit Impact:
➡️ Control design may pass
➡️ Control effectiveness fails ❌

2. Access Reviews Done… Just Before the Audit

What companies say:

“We perform quarterly access reviews.”

What actually happens:

No reviews for 9 months
Suddenly performed 1 week before audit
Backdated approvals

Failure Example:

Terminated employee still has system access
Reviewer signs off without validation

Root Cause:
Control performed for audit—not as a business process.

Audit Impact:
➡️ Exception + potential control failure
➡️ Trust breakdown with auditor

3. Shared Accounts Everywhere

What companies say:

“Only authorized personnel use admin accounts.”

Reality:

Shared credentials like admin@company.com
No accountability
No audit trail

Failure Example:

Critical production change made
No way to identify who did it

Root Cause:
Convenience over control.

Audit Impact:
➡️ Major failure under Logical Access
➡️ Security risk beyond compliance

4. Change Management Exists Only on Paper

What companies say:

“All changes are approved and tested.”

What auditors see:

Changes pushed directly to production
No approvals
No testing evidence

Failure Example:

Hotfix deployed without review
Breaks system functionality

Root Cause:
Startups prioritize speed over governance.

Audit Impact:
➡️ Control failure under Change Management
➡️ High risk if impacting customer data

5. Logging Enabled… But Never Reviewed

What companies say:

“We monitor system activity.”

Reality:

Logs exist
No one reviews them
No alerts configured

Failure Example:

Suspicious login activity in logs
No action taken

Root Cause:
“Enable logging = compliance” mindset.

Audit Impact:
➡️ Monitoring control fails
➡️ Weak security posture

6. Vendor Management Is Completely Ignored

What companies say:

“Our vendors are secure.”

Reality:

No vendor risk assessment
No SOC reports collected
No contracts with security clauses

Failure Example:

Critical SaaS vendor without SOC 2
No due diligence performed

Root Cause:
Blind trust in third parties.

Audit Impact:
➡️ Third-party risk control failure
➡️ Red flag for customers

7. Employee Offboarding Delays

What companies say:

“Access is revoked immediately upon exit.”

Reality:

Access removed days/weeks later
HR and IT not aligned

Failure Example:

Ex-employee logs in after leaving
Still has GitHub / AWS access

Root Cause:
Lack of automated offboarding workflows.

Audit Impact:
➡️ High-risk control failure
➡️ Potential data breach scenario

8. Evidence Fabrication / Backdating

Yes, this happens more than you think.

What companies do:

Create fake evidence
Modify timestamps
Generate screenshots post-facto

Failure Example:

Audit logs don’t match submitted evidence

Root Cause:
Pressure to “pass the audit at any cost.”

Audit Impact:
➡️ Immediate trust breakdown
➡️ Possible audit qualification
➡️ Long-term reputational damage

9. Misunderstanding “Control Frequency”

What companies think:

“We did it once = control complete”

Reality:

Control requires periodic execution
Frequency not defined or followed

Failure Example:

Risk assessment done once in 2 years
Expected annually

Root Cause:
Lack of clarity in control design.

Audit Impact:
➡️ Control effectiveness failure

10. Tool Dependency Without Process

What companies say:

“We use Okta / AWS / Jira, so we’re compliant.”

Reality:

Tools configured incorrectly
No defined process
No monitoring

Failure Example:

MFA enabled but not enforced
Users bypass controls

Root Cause:
Assuming tools = controls.

Audit Impact:
➡️ Design + effectiveness failure

🔍 Key Pattern Across All Failures

After seeing dozens of SOC 2 audits, one pattern is clear:

SOC 2 failures are not technical problems. They are operational discipline problems.

💡 How to Avoid These Failures

1. Make Controls Operational

Embed into daily workflows
Not just documentation

2. Evidence as a Byproduct

If control is real, evidence will exist naturally

3. Automate Where Possible

Access reviews
Offboarding
Logging alerts

4. Define Ownership Clearly

Every control must have an owner

5. Think Like an Auditor

Ask:

Can this be tested?
Is it repeatable?
Is there evidence?

🚀 Final Thought

SOC 2 is not about passing an audit.

It’s about proving that your company:

Operates securely
Protects customer data
Has discipline in execution

Companies that treat SOC 2 as a checkbox struggle every year.
Companies that build real controls pass effortlessly.

ITGC Audit Explained Like You’re in Big 4

Aditya Khare — Fri, 17 Apr 2026 17:32:34 +0000

If you’ve ever worked in a Big 4 firm—or even interacted with one—you’ve probably heard the term ITGC Audit thrown around like it’s basic knowledge.

But here’s the truth:
Most people think they understand ITGC… until they actually have to perform one.

Let’s break it down the way it’s explained inside Big 4 teams—structured, practical, and aligned with how audits really happen.

🔍 What is ITGC (in real terms)?

IT General Controls (ITGC) are the foundational controls that ensure IT systems are:

Secure
Reliable
Properly managed

Think of ITGC as the “trust layer” of financial and operational systems.

If ITGC fails → everything built on top of it becomes questionable.

That’s why ITGC is critical for:

Financial audits (SOX)
SOC 1 / SOC 2 reports
Internal audits
Regulatory compliance

🧠 Big 4 Mindset: Why ITGC Exists

In Big 4, ITGC is not just about controls—it’s about risk assurance.

The core question auditors ask is:

“Can we rely on this system for accurate financial reporting?”

If the answer is no, then:

Substantive testing increases
Audit risk increases
Client pressure increases

🧱 The 3 Pillars of ITGC

Every ITGC audit revolves around these three core areas:

1. Access Management

Ensures that only the right people have the right access.

Key Controls:

User provisioning & de-provisioning
Role-based access (RBAC)
Privileged access restriction
Periodic access reviews

Big 4 Lens:

“Can unauthorized users access sensitive financial systems?”

Typical Risks:

Terminated employees still having access
Excessive admin rights
Lack of approval for access changes

2. Change Management

Ensures that system changes are controlled, tested, and approved.

Key Controls:

Change request approval
Segregation of duties (Dev vs Prod)
Testing & validation
Migration approvals

Big 4 Lens:

“Can someone manipulate system logic without detection?”

Typical Risks:

Direct changes in production
No testing evidence
Same person developing and deploying code

3. IT Operations

Ensures systems run reliably and issues are handled properly.

Key Controls:

Job monitoring
Backup and recovery
Incident management
Batch processing controls

Big 4 Lens:

“Will the system run consistently without data loss or failure?”

Typical Risks:

Failed jobs not investigated
Backups not tested
No incident tracking

🧪 How ITGC Testing Works (Big 4 Approach)

This is where theory ends and real audit begins.

Step 1: Understand the Control

What is the control doing?
What risk is it addressing?

Step 2: Test of Design (TOD)

Ask:

“Is this control designed effectively?”

Check:

Proper approvals
Defined process
Clear ownership

Step 3: Test of Effectiveness (TOE)

Now the real work.

You:

Select samples (usually 25–40)
Inspect evidence
Verify consistency

Example:

Access request → Check approval → Verify system update → Match timestamps

Step 4: Document Like a Pro

Big 4 documentation is:

Structured
Evidence-backed
Reviewer-proof

If it’s not documented → it didn’t happen

📂 What Evidence Looks Like

In real audits, you’ll deal with:

Screenshots from systems
Access request tickets (ServiceNow, etc.)
Change tickets
User listings (Excel dumps)
Approval emails

Golden Rule:

Evidence must be complete, accurate, and time-stamped

⚠️ Common Big 4 Observations

These come up again and again:

❌ No evidence of approval
❌ Same person doing multiple conflicting roles
❌ Missing logs or incomplete data
❌ Control performed but not documented
❌ Delayed access removal

🧩 Linking ITGC to Financial Audit

Here’s where things get serious.

If ITGC is effective:

Auditors rely on system-generated reports
Less manual testing

If ITGC is deficient:

Reports are unreliable
More manual verification required
Audit effort increases significantly

💼 What Makes a Strong ITGC Auditor (Big 4 Level)

It’s not just about ticking boxes.

Top performers:

Understand risk, not just control
Ask the right questions
Identify gaps beyond checklist
Write sharp, defensible documentation

🚀 Final Takeaway

ITGC is not just an audit requirement—it’s the backbone of trust in digital systems.

When done right:

Businesses operate securely
Financial data is reliable
Auditors sleep better

When done wrong:

Everything is at risk

💡 Closing Thought

“In Big 4, you’re not just auditing controls—you’re validating trust.”

If you're building a career in IT Audit, mastering ITGC is not optional—it’s your core weapon.

ITGC vs GITC — What’s the Real Difference?

Aditya Khare — Fri, 17 Apr 2026 17:28:22 +0000

If you’ve worked in IT Audit long enough, you’ve probably heard both terms:

ITGC (IT General Controls)
GITC (General IT Controls)

And at some point, you’ve wondered:

“Are these actually different… or just Big 4 jargon?”

Let’s clear this up properly—the way it’s understood inside audit teams.

🔍 The Short Answer

There is NO fundamental difference between ITGC and GITC.

They both refer to the same concept:
Controls that ensure IT systems are secure, reliable, and properly managed.

The difference is mostly terminology, not substance.

🧠 Why Two Names Exist

🔹 ITGC (IT General Controls)

More commonly used in:
- Audit reports
- SOX documentation
- Industry standards

🔹 GITC (General IT Controls)

Often used:
- Internally within firms
- In certain Big 4 teams
- In older documentation or regional practices

Big 4 Reality:

Different teams, same controls, different naming habit.

🧱 What Both Actually Cover

Whether you call it ITGC or GITC, the scope remains identical.

1. Access Management

User provisioning & de-provisioning
Role-based access
Privileged access controls

2. Change Management

Change approvals
Testing & validation
Segregation of duties

3. IT Operations

Job monitoring
Backups & recovery
Incident management

🧪 Example (Same Control, Different Naming)

Scenario: User Access Control

In one project → called ITGC - Access Control
In another → called GITC - Logical Access

But testing remains identical:

Check approval
Verify access granted
Validate timestamps

⚠️ Where Confusion Happens

1. Interviews

Candidates think:

ITGC = something technical
GITC = something different

❌ Wrong

2. Documentation Differences

Some firms label sections differently:

“ITGC Testing”
“GITC Workpapers”

Again—same content underneath.

3. Client Conversations

Clients may assume:

Two frameworks exist

You clarify:

“It’s just naming—controls are the same.”

🔗 How Big 4 Actually Treats It

Inside Big 4:

Methodology → same
Testing approach → same
Risk assessment → same

Only difference:

Terminology depends on team, geography, or template

💼 Interview-Ready Answer

If someone asks:

“What’s the difference between ITGC and GITC?”

You answer:

“There is no conceptual difference. Both refer to General IT Controls covering access, change management, and IT operations. The variation is purely in terminology used across firms or documentation.”

🚀 Final Takeaway

Don’t overcomplicate it.

ITGC = GITC
Same controls
Same risks
Same audit approach

💡 Closing Thought

“In IT Audit, confusion often comes from terminology—not from concepts.”

Master the concept, and the naming won’t matter.

SOC 2 End-to-End Guide (Big 4 Style)

Aditya Khare — Tue, 14 Apr 2026 17:14:00 +0000

If ITGC is the foundation, SOC 2 is the proof.

In the Big 4 world, SOC 2 isn’t just a report—it’s a trust certificate that tells your clients:

“Your data is safe with us.”

Whether you're an auditor, a startup founder, or working in IT risk—this guide breaks down SOC 2 the way it’s actually executed in real engagements.

🔍 What is SOC 2?

SOC 2 (System and Organization Controls 2) is a framework developed by the AICPA to evaluate how organizations handle customer data.

It is based on Trust Services Criteria (TSC):

Security (mandatory)
Availability
Processing Integrity
Confidentiality
Privacy

🧠 Big 4 Perspective: Why SOC 2 Matters

SOC 2 is not about compliance—it’s about market trust.

Clients (especially US-based) will ask:

“Do you have a SOC 2 report?”
“Can we rely on your controls?”

Without SOC 2:

Deals get delayed
Security reviews get intense
Trust becomes a blocker

🧱 Types of SOC 2 Reports

🔹 Type I

Point-in-time assessment
Answers: Are controls designed properly?

🔹 Type II (Gold Standard)

Covers 3–12 months
Answers: Are controls working consistently over time?

Big 4 Reality:

Most serious companies go directly for Type II

🏗️ SOC 2 End-to-End Lifecycle

Let’s walk through how a SOC 2 engagement actually happens.

1. 🧭 Scoping & Readiness Assessment

Before audit begins, we define:

Systems in scope
Trust criteria applicable
Control gaps

Activities:

Process walkthroughs
Risk identification
Gap analysis

Output:

Readiness report
Remediation plan

2. 🛠️ Control Design & Implementation

Now the company builds controls aligned to SOC 2.

Examples:

Access reviews (quarterly)
MFA implementation
Change management workflows
Incident response procedures

Big 4 Lens:

“Does this control actually mitigate the risk?”

3. 📄 Documentation (Critical Phase)

This is where most companies struggle.

You need:

Policies (Security, Access, Change Mgmt)
SOPs
Control descriptions
Risk-control matrix (RCM)

Golden Rule:

If it’s not documented, it doesn’t exist

4. 🧪 Audit Testing Phase

This is where auditors step in.

a. Test of Design (TOD)

Is the control properly designed?

b. Test of Effectiveness (TOE)

Is the control working consistently?

Example:
Control: User access approval

Test:

Sample 25 users
Check approval evidence
Verify system access logs

5. 📊 Evidence Collection

Expect to provide:

Screenshots
System logs
Access listings
Change tickets
Incident reports

Big 4 Expectation:

Complete
Accurate
Time-stamped
Tamper-proof

6. 🧾 SOC 2 Report Issuance

Final deliverable includes:

1. Independent Auditor’s Report

Opinion: Clean / Qualified

2. System Description

Infrastructure
Software
People
Processes

3. Control Matrix

Control description
Tests performed
Results

4. Exceptions (if any)

⚠️ Common SOC 2 Failures (Real World)

❌ No consistent evidence across period
❌ Manual controls without proof
❌ Weak access management
❌ No segregation of duties
❌ Policies exist but not followed

🔗 SOC 2 vs ITGC (Quick Clarity)

Area	ITGC	SOC 2
Focus	Core IT controls	Broader trust framework
Scope	Internal systems	Customer-facing trust
Usage	Financial audit	Client assurance
Depth	Technical	Technical + Governance

💼 Tools Commonly Used in SOC 2

ServiceNow / Jira → Tickets
Okta / Azure AD → Access control
AWS / GCP → Cloud logs
Vanta / Drata → Automation

🧠 What Big 4 Auditors Look For

Consistency over time
Strong audit trail
Logical access control maturity
Proper documentation
Risk alignment

Not just:

“Control exists”
But:
“Control is reliable”

🚀 How to Crack SOC 2 (Career Angle)

If you're in IT Audit / Risk:

Master:

ITGC fundamentals
SOC 2 framework mapping
Evidence validation
Documentation writing

Bonus:

Learn cloud environments (AWS/GCP)
Understand SaaS architectures

📌 Final Takeaway

SOC 2 is not just a report—it’s a business enabler.

It:

Builds customer trust
Accelerates sales
Strengthens internal controls

💡 Closing Thought

“SOC 2 doesn’t prove you’re perfect—it proves you’re reliable.”