What is SOC 2 Compliance?

Back to learning

SOC 2 compliance is how a service organisation gives customers independent evidence that its controls are designed and, for Type II reports, operating over time. It matters most for SaaS and technology providers that store customer data, run customer-facing systems, or provide infrastructure that other businesses rely on.

SOC 2 is not a certification that proves a product is secure in every situation. It is an audit report against selected Trust Services Criteria, usually starting with security and sometimes extending to availability, confidentiality, processing integrity, and privacy. The useful question for a customer is not "do you have SOC 2?" It is "what systems, controls, period, and exceptions are covered by the report?"

Type I and Type II Answer Different Questions

A SOC 2 Type I report looks at control design at a point in time. It can help an early SaaS business show that policies, access controls, logging, change processes, and vendor governance have been designed and documented. It does not prove those controls operated consistently for months.

A SOC 2 Type II report tests control operation over an examination period, commonly six to twelve months. Auditors sample evidence: access reviews completed, production changes approved, incidents handled, alerts reviewed, backups tested, vendors assessed, and exceptions tracked. That is why Type II preparation is less about writing a beautiful policy pack and more about running the same control reliably enough that evidence exists when asked.

For security, platform, and compliance teams, SOC 2 is therefore an operating rhythm. A control owner needs to know what the control is, when it runs, what evidence it produces, where that evidence is stored, and how exceptions are handled.

What Evidence Looks Like

The evidence should connect to real systems. A screenshot taken on audit day is weaker than a ticket, log, or workflow record created when the control actually ran. Auditors and customers both want to know whether the control is part of production practice or a manual exercise performed only during assessment.

SaaS Trust Depends on Control Operation

SOC 2 can become list-heavy quickly because the underlying criteria are broad. In a SaaS business, the practical themes are usually familiar: who can access customer data, how code reaches production, whether security events are detected, whether services are available, whether incidents are handled, and whether customer commitments are honoured.

Access reviews are a good example. The control is not just "review access quarterly." The useful work is confirming that staff, contractors, service accounts, support roles, database access, cloud privileges, and identity groups still match business need. Exceptions need owners and deadlines. Removed access needs proof. Overpowered roles need a reason or remediation.

Change management works the same way. A team should be able to show that production changes are reviewed, tested, deployed through an approved path, and traceable to a person or service account. Emergency changes can exist, but the process should explain how they are approved, reviewed after the fact, and recorded.

Logging is another area where SOC 2 and security operations meet. Logs should help reconstruct important events without storing unnecessary sensitive data. A good audit trail records access, administrative actions, security decisions, deployments, incidents, and configuration changes. It also needs retention, integrity, queryability, and restricted access so it can be trusted during customer due diligence or incident review.

Product Controls Help, But They Are Not the Report

Security tooling can support SOC 2 evidence by enforcing access, detecting suspicious traffic, preserving logs, and documenting actions. Peakhour's edge controls, bot detection, rate limiting, WAF, API protection, and log forwarding can provide useful evidence for application security and abuse controls. They do not replace the organisation's control design, auditor judgement, or management responsibility.

The same caution applies to automation. A dashboard that shows blocked traffic may support a security control, but the control also needs defined ownership, review cadence, escalation rules, exception handling, and evidence that someone acted when risk changed.

What Teams Need to Decide

Before starting or refreshing SOC 2 work, decide the report scope. Which product, infrastructure, support process, people, locations, and vendors are included? Which Trust Services Criteria are relevant to customers? Which controls are already running in production, and which are only policy intent?

The strongest SOC 2 programs are built from normal work: reviewed changes, disciplined access, useful logs, tested response paths, and clear ownership. If the evidence has to be invented at audit time, the control is probably not operating.