SOC 2 on Your Terms: A Guide for Kamatera Users

Cloud

If your organization handles customer data in the cloud, achieving SOC 2 compliance is an important milestone. Kamatera provides a secure, high-performance foundation. But the full responsibility for compliance is shared between the provider and the user. That means while Kamatera manages the security of the infrastructure, like physical data centers, core networking, and hardware, you manage security in the cloud, including your operating systems, applications, and data access policies.

This guide walks through what SOC 2 actually requires at the infrastructure level, and how to meet those requirements on Kamatera.

Key takeaways

• Type II is what enterprise customers want, so plan for the full observation period from day one.
• These six things drive the Security criterion: access control, network security, encryption, logging, change management, and incident response.
• Configuration without documentation doesn’t count. Every control needs a written policy behind it.
• The most common audit findings are avoidable: open firewall rules, shared credentials, and unrevoked access.
• SOC 2 is not a one-time project. Your controls need to run consistently for the entire observation period

What is SOC 2 Type II

SOC 2 is a framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates how a company manages customer data. It’s organized around five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. For most companies going through SOC 2 for the first time, Security is the only required criterion. The rest are optional. In this guide, we’ll focus on the Security criterion.

There are two types of SOC 2 reports. Type I is a point-in-time assessment. It confirms that your controls are designed correctly at a specific moment. Type II covers a period of time, typically six to twelve months, and confirms that those controls are actually operating as intended. Type II is what most enterprise customers want to see.

The distinction matters for how you plan your infrastructure setup. You’ll need documented, consistent, repeatable processes across the entire observation period.

What the Security criterion requires

The Security criterion (formally called the Common Criteria) covers how you protect your systems from unauthorized access, both from the outside and from within. At the infrastructure level, this breaks down into several areas:

Access control. Only authorized users and systems should be able to reach your infrastructure. This means managing who has SSH access, how credentials are issued and revoked, and whether access is logged.

Network security. Your infrastructure should be segmented and protected. Public-facing services should be isolated from internal systems, and inbound traffic should be restricted to what’s explicitly required.

Encryption. Data should be encrypted in transit and at rest. This applies to your databases, your storage volumes, and any data moving between services.

Monitoring and logging. You need to be able to demonstrate that you know what’s happening on your systems. This means collecting logs, retaining them for an appropriate period, and having a process for reviewing and responding to anomalies.

Change management. Changes to your infrastructure should be documented, reviewed, and tracked. Ad hoc changes with no audit trail are a common finding in SOC 2 audits.

Incident response. You need a defined process for identifying, responding to, and documenting security incidents, even if one never occurs during your observation period.

How Kamatera supports your SOC 2 posture

Kamatera doesn’t hand you a SOC 2 certification. No infrastructure provider does, because SOC 2 audits your organization’s controls, not just the platform you run on. But Kamatera gives you the building blocks to implement those controls correctly.

Customers are responsible for configuring and operating their environments in accordance with their own compliance requirements and risk policies.

Firewall configuration

Kamatera’s cloud console lets you configure firewall rules at the network level before your instance is ever exposed to the public internet. For SOC 2, this means you can enforce a default-deny posture, blocking all inbound traffic and explicitly allowing only what’s required. Document every rule and the business justification for it. That documentation becomes part of your evidence package.

Private networking

Use Kamatera’s private network functionality to keep internal service communication off the public internet entirely. Your database should not be reachable from a public IP. Your internal APIs shouldn’t be either. Segment your infrastructure so that compromise of one component doesn’t automatically mean compromise of everything.

Access management

SSH access to your Kamatera instances should be key-based, not password-based. Maintain a record of who has access to which servers, and revoke access immediately when someone leaves the team or changes roles. For SOC 2, auditors will want to see that this process exists and that it is followed consistently.

Use Kamatera’s team management features to control who has access to the cloud console itself, and apply the principle of least privilege: give people access to what they need and nothing more.

Encryption in transit and at rest

Enforce TLS for all public-facing endpoints. For data at rest, encrypt your storage volumes and databases. Kamatera’s NVMe SSD infrastructure supports encrypted storage configurations. Customers should ensure encryption is properly configured and documented according to their compliance requirements.

Logging and monitoring

Kamatera gives you access to system-level logs on your instances. Feed these into a centralized logging solution. Options like Datadog, Grafana Loki, or the ELK stack all work well on Kamatera infrastructure. SOC 2 auditors want to see that logs are collected, retained for a defined period (typically at least 90 days, often longer), and that there’s a process for reviewing them. Automated alerting on anomalous activity strengthens this further.

Snapshots and backups

Kamatera’s snapshot functionality lets you take point-in-time backups of your instances. For SOC 2, you need a documented backup policy: how often backups run, how long they’re retained, and how you’ve tested restoration. Test your restores. (Auditors ask.)

What you need to document

Infrastructure configuration alone won’t get you through a SOC 2 audit. Auditors are evaluating whether your controls are formalized, communicated, and consistently applied. For each control area, you need written policies and evidence that those policies are followed.

At minimum, prepare documentation for:

• Your access control policy, including how access is granted, reviewed, and revoked
• Your network security architecture, including firewall rules and the reasoning behind them
• Your encryption standards, covering both transit and at rest
• Your logging and monitoring policy, including retention periods and review processes
• Your backup and disaster recovery policy, including test results
• Your incident response plan, including how incidents are classified, escalated, and documented
• Your change management process, including how infrastructure changes are proposed, approved, and recorded

None of this needs to be complex. A clear, honest document that reflects how your team actually operates is more valuable than an elaborate policy that nobody follows.

Common mistakes to avoid

Treating SOC 2 as a one-time project. Type II compliance is ongoing. The controls you put in place need to run consistently for the entire observation period. Starting your audit preparation six months before your target report date is not too early.

Leaving audit trails to chance. If you can’t produce evidence that a control was operating at a specific point in time, auditors will treat it as if it wasn’t. Automate your evidence collection wherever possible.

Overly permissive firewall rules. One of the most common infrastructure findings in SOC 2 audits is firewall rules that are broader than necessary. Review every rule and tighten anything that doesn’t have a clear justification.

Shared credentials. If multiple people are using the same SSH key or the same console login, you can’t demonstrate individual accountability. Every person who accesses your infrastructure should have their own credentials.

No offboarding process. Access that isn’t revoked when someone leaves is a recurring audit finding. Build offboarding into your HR process, as well as your security checklist.

Getting started

SOC 2 compliance is a process, not a product. The infrastructure layer is where a lot of teams feel the most uncertainty, but it’s also where the controls are most concrete and testable. Get your Kamatera environment configured correctly, document what you’ve done and why, and treat compliance as an ongoing operational discipline rather than a one-time audit exercise.

If you’re starting from scratch, the right order is: lock down access, segment your network, enable encryption, set up logging, document everything, then engage an auditor. Don’t wait until everything is perfect to bring in your auditor. Most will do a readiness assessment that tells you exactly where your gaps are before the formal observation period begins.

Kamatera’s infrastructure gives you the flexibility and control to build a compliant environment without the overhead of more expensive managed platforms. The controls are in your hands. This guide is a starting point for putting them in the right place.