SOC 2 REQUIREMENTS

Introduction

“Do you have a SOC 2 report?”

For a growing SaaS or technology company, this question can come from a customer, a potential enterprise client, or even a partner before a deal moves forward. And while SOC 2 is often described as a compliance framework, what customers are really looking for is reassurance: Can this company be trusted to protect our data and keep its services secure and reliable?

That is what makes understanding SOC 2 requirements important.

SOC 2 is not a universal checklist where every business has to implement exactly the same controls. It is based on the AICPA Trust Services Criteria, with the specific requirements depending on the services a company provides, the systems it uses, the information it handles, and the risks associated with its operations. For businesses starting their SOC 2 journey, that can sound complicated. It does not have to be. Before getting into individual controls or the audit process, it helps to understand the core areas that form the foundation of SOC 2.

What exactly are we asking customers to trust us with?

SOC 2 scope defines the service, systems, people, infrastructure and data that are relevant to the examination. It does not automatically mean putting every application, employee and internal process in the company under the same microscope.

For a SaaS provider, for example, the scope might include its production application, cloud infrastructure, databases containing customer information, employee access to production systems, and third-party services supporting the platform.

Getting this right at the beginning matters.

A scope that is too broad can create unnecessary work. One that is too narrow may leave important systems or processes outside the picture. A well-defined scope keeps the SOC 2 effort focused on the services and technology that actually matter to customers.

Choose the Trust Services Criteria That Fit

Once the scope is clear, the next question is which Trust Services Criteria are relevant?

SOC 2 is built around five categories:

• Security
• Availability
• Processing Integrity
• Confidentiality
• Privacy

Security is the common foundation, focusing on protecting systems and information against unauthorised access and other security threats.

The other categories depend on the organisation’s services and commitments.

A cloud platform that promises reliable access to its service may place greater importance on Availability. A system processing financial transactions needs to consider Processing Integrity, where accuracy and completeness matter. Confidentiality is relevant when sensitive business information needs to remain restricted, while Privacy addresses how personal information is collected, used, retained, and disclosed.

The important point is that businesses should not choose criteria simply to make their SOC 2 report look more comprehensive. The criteria should make sense for the service being provided and the commitments being made to customers.

Make Sure the Right People Have the Right Access

Access management is where security policies start becoming real-world controls.

The principle is simple: employees should have access to the systems and information they need, and nothing more.

That can involve unique accounts, multi-factor authentication, role-based permissions, privileged access management, periodic access reviews, and timely removal of access when someone leaves the company or changes roles. Consider a former employee whose account still has access to a production system. Nothing may have happened yet. But the unnecessary access itself creates a security risk.

That is why SOC 2 is not simply about having an access control policy sitting in a document repository. Businesses need processes that control access throughout its lifecycle and evidence that those processes are actually being followed.

Turn Security Policies into Everyday Processes

A SOC 2 programme cannot live on paper.

Businesses need documented policies and processes covering areas relevant to their environment, such as information security, access management, incident response, change management, risk management, and employee responsibilities.

But documentation should describe reality, not create a better-looking version of it.

If a policy says access reviews happen quarterly, those reviews should actually happen. If an organisation has an incident response procedure, the people responsible for responding should understand their roles. This is one of the most important distinctions in SOC 2: a policy tells people what should happen; a working control demonstrates that it does happen.

Understand the Risks Before Deciding How to Manage Them.

Not every organisation faces the same security risks.

A company hosting sensitive customer information in the cloud may have very different priorities from a small software provider with a limited internal environment. SOC 2 therefore requires organisations to look at their own risk landscape rather than applying security measures blindly.

A practical risk assessment should consider questions such as:

• What sensitive information do we handle?
• Where does that information reside?
• Who can access it?
• Which systems are critical to our service?
• What could disrupt those systems?
• Which vendors or third parties introduce additional risk?

The objective is not to eliminate every possible risk. That is neither realistic nor practical.

The objective is to identify meaningful risks, understand their potential impact, and put appropriate measures in place to reduce or manage them.

Have a Plan Before an Incident Happens

Security incidents rarely arrive at a convenient time.

A suspicious login, compromised account, exposed credential, or unexpected system change can quickly become a much bigger problem if nobody knows what to do next.

That is why incident response is an important part of a strong SOC 2 environment.

Organisations should have a defined process for identifying, reporting, investigating, containing, resolving, and documenting security incidents. People should know their responsibilities, escalation paths should be clear, and important actions should be recorded.

The goal is not to pretend incidents will never happen.

It is to make sure that when something does happen, the organisation is prepared to respond rather than figuring out the process in the middle of a crisis.

Keep Evidence That Shows Your Controls Work

This is where SOC 2 becomes much more than a collection of security policies.

A business may say it reviews user access regularly, performs vulnerability assessments, trains employees, monitors systems, and maintains an incident response process.

The important question is: Can it prove it?

Depending on the control, evidence could include access review records, security training records, vulnerability assessment results, incident documentation, change approvals, risk assessments, or monitoring records.

Think of it this way: a policy is a promise about what the organisation does. Evidence shows what actually happened.

That distinction is particularly important during a SOC 2 examination because the organisation needs to demonstrate that relevant controls are not only designed appropriately but are operating as expected.

How Greyhound Can Help with SOC 2 Readiness

SOC 2 readiness is not only about documenting policies. Businesses also need to understand whether their actual technology environment supports the security commitments they are making.

This is where Greyhound can add value.

Greyhound helps organisations assess their security posture through automated security scanning and black-box penetration testing, helping uncover vulnerabilities that may not be visible through policies or documentation alone. Identifying these weaknesses early gives security teams an opportunity to remediate issues before they become larger problems or create challenges during a compliance assessment. Greyhound also supports evidence collection and security posture evaluation, giving organisations a clearer view of security findings, remediation efforts, and the technical state of their environment. The result is a more practical approach to SOC 2 readiness: understand where the weaknesses are, address them, and maintain evidence of the work being done. Rather than discovering security gaps when an examination is already underway, businesses can use proactive testing to identify and address those gaps earlier.

Conclusion

SOC 2 requirements can look like a long list of compliance tasks when viewed from the outside. In practice, the foundation is much easier to understand.

Define what matters. Protect it. Manage the risks. Prepare for what could go wrong. And keep evidence that shows your controls are actually working.

That is the thinking behind a meaningful SOC 2 programme. A SOC 2 report may be what customers see at the end of the process, but the real value lies in what happens behind it: stronger security practices, clearer accountability, better visibility into risk, and greater confidence in the systems handling customer information. And that is where SOC 2 should begin—not with a checklist, but with a clear understanding of what your business needs to protect and how you can prove that you are protecting it.