Kubernetes for SOC 2 controls

Kubernetes for SOC 2 controls: which criteria the cluster can support

Kubernetes can supply evidence for CC6.1, CC6.3, CC7.2 and CC8.1 when the cluster is configured on purpose. It does not make an organization SOC 2 compliant. SOC 2 is an attestation issued by an independent CPA firm after it examines the whole service organization's system, and the cluster is one component of that system. A platform or security lead should read the four criteria as places where specific settings produce records that an auditor can sample. Each criterion still needs a documented control, a named owner, a defined population of systems and records retained for the observation period.

SOC 2 is an assertion-based examination performed under AT-C section 205 of the AICPA attestation standards. The service auditor must obtain written representations from management, and management must describe the system against the AICPA's 2018 description criteria, DC 200. Under the 2017 Trust Services Criteria, the security common criteria CC1 to CC9 apply to every SOC 2. A Type 1 report covers the design of controls as of a date. A Type 2 report adds an opinion on operating effectiveness over a period, which is where a cluster's recorded behavior over time matters most. DeployOpen prepares the system, controls and evidence for that examination but does not issue audit reports, attestations or certifications. Only the independent auditor does.

Large parts of the examination sit outside the cluster. Policies for access reviews and joiner, mover and leaver processes in the HR system, vendor management, risk assessment, incident response procedures, change approvals by people, and business continuity are the organization's responsibility. Cloud account controls, physical data center access, endpoint management and the identity provider's own controls are often in scope too. The cluster supplies technical evidence for the criteria it touches, while the auditor evaluates the whole system described in management's description, including how people operate those controls day to day.

Before scoping, confirm with your auditor which trust services categories and system boundary apply, and whether the cluster, its GitOps tooling and its identity integration fall inside the description. Ask which evidence samples they will request across the observation period. Then write down, for each of CC6.1, CC6.3, CC7.2 and CC8.1, which cluster source produces the record, who owns the control, and how long the records are kept. Agree this list with your auditor early, because a gap found during the observation period is harder to explain than one found during planning. The sections that follow map each criterion to specific cluster features and settings.

Mapping CC6.1, CC6.3, CC7.2 and CC8.1 to Kubernetes controls

This table maps each SOC 2 common criterion in scope to the Kubernetes capability that supports it and the configuration that capability needs. Read it as a map of supporting controls that produce evidence for an auditor. It does not establish a pass or fail result, because the examination weighs whether controls operate as designed over a period. The main takeaway is that RBAC, authentication and audit logs only become useful evidence once they are configured and recorded consistently.

Criterion	Kubernetes capability	Configuration needed
CC6.1 Logical access security	OIDC or other authentication methods	Connect the API server to your identity provider with OIDC, disable shared static tokens and restrict client certificate issuance
CC6.1 Logical access security	Secrets encryption at rest	Enable an EncryptionConfiguration for Secrets, since Secrets are stored unencrypted in etcd by default
CC6.1 Logical access security	Pod Security Admission	Enforce Baseline or Restricted Pod Security Standards per namespace and record any exceptions with named owners
CC6.3 Access by role	RBAC	Bind roles to groups from your identity provider, prefer namespaced Roles over ClusterRoles and avoid wildcard verbs
CC6.3 Access by role	Least-privilege access to Secrets	Limit get, list and watch on Secrets to named service accounts, since these verbs return secret values to the caller
CC7.2 Anomaly monitoring	API audit logging	Define an audit policy covering authentication, RBAC changes and Secrets access, then ship logs to a central store
CC7.2 Anomaly monitoring	Monitoring and alerting	Alert on RBAC changes, privileged pods and failed authentication, with a documented triage path for security events
CC8.1 Every stage of a change	GitOps change flow	Store manifests in version control, require review and approval, and let the controller apply only merged commits

How a SOC 2 Type 1 and Type 2 report change the evidence you keep

A SOC 2 Type 1 report covers two things as of a specific date: management's description of the system, and whether the controls are suitably designed to meet the applicable Trust Services Criteria. It does not test whether those controls worked over time. For a Kubernetes platform, the evidence an examiner reviews at this stage shows that the design exists and is documented. Think of it as a snapshot of intent and structure.

For a Type 1 engagement, expect to produce:

A written system description that names the cluster, its node pools, its identity provider, its GitOps repository and its logging destinations
RBAC role and binding manifests, with a written explanation of who holds each role and why
Audit policy configuration for the API server, showing what is recorded and where it is sent
Network policy and Pod Security Admission settings, with the namespaces they apply to
Diagrams and runbooks for access requests, change approval and incident escalation

Before you commit to a Type 1 scope, confirm with your auditor which criteria apply, since the common criteria CC6, CC7 and CC8 are the ones most often tied to cluster controls.

How Kubernetes identity and RBAC support CC6.1 and CC6.3

CC6.1 and CC6.3 both start with who can reach the cluster, and Kubernetes answers that question differently from most platforms. It does not store normal users as API objects. Instead, the API server authenticates each request with X.509 client certificates, bearer tokens (including OpenID Connect and JWT tokens), webhook token authentication or an authenticating proxy. For SOC 2 evidence, the practical decision is which of these paths your organization uses for human access. Choose the path that ties cluster access to your identity provider, so joiners, movers and leavers are handled in one place. Confirm with your distribution which authentication methods are enabled and how the OIDC settings are configured. Long-lived client certificates and shared administrative credentials weaken this story because they outlive the person they were issued to and cannot be traced to one individual in the audit log.

CC6.3 asks the organization to grant, change and remove access based on roles, responsibilities or system design, so Kubernetes RBAC should map to job roles and be scoped per namespace wherever possible. Roles define permissions and RoleBindings attach them to users or groups within one namespace. ClusterRoles and ClusterRoleBindings reach across the cluster and should be limited to a small, named set of platform administrators. Segregation of duties has three questions that auditors often ask separately: who can change RBAC objects, who can deploy workloads and who can approve changes. A workable pattern is to let only the GitOps controller's service account write application resources, restrict RBAC edits to a platform team, and record approvals in the change system that CC8.1 evidence relies on. Illustrative example: a developer can create Deployments in a team namespace but cannot create bindings that grant themselves more access.

Secrets are where CC6.1 evidence often breaks down. Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest must be configured on the API server and verified. The configuration itself becomes evidence. The Kubernetes good practices guidance also calls for least-privilege RBAC that restricts list and watch access to Secrets, because a principal that can list Secrets in a namespace can read every value in it. Confirm who holds those verbs with a periodic export of role bindings and effective permissions. Where secret values should live in a dedicated store, the Secrets Store CSI Driver can mount values from an external store into pods, which can keep values out of etcd when the driver is not configured to sync them into Kubernetes Secrets. You still need to document who manages the external store and how access to it is logged. Decide this before workloads are onboarded, because moving secrets later means rotating them.

Pod Security Standards limit what workloads can do, which supports the least-privilege and system design side of CC6.3 and the protective architecture described in CC6.1. Kubernetes defines three levels: Privileged, which is unrestricted, Baseline, which blocks known privilege escalations, and Restricted, which is the most constrained. Pod Security Admission enforces one of these levels per namespace through namespace labels, and it can run in enforce, audit or warn mode. The decision is which level each namespace enforces. Restricted is the target for application namespaces, and any exception for Privileged or Baseline should be written down with an owner and a review date. Keep the namespace labels in version control so the change history shows when a level was loosened. Before an assessment, run the admission controller in audit mode against existing workloads to find pods that would be rejected. Your auditor determines whether this evidence is sufficient for your report.

Kubernetes for SOC 2 controls: evidence to keep for each audit period

Auditors test Kubernetes controls against evidence collected across the whole audit period. Each card below shows what an artifact proves, where it lives, who owns it and how often to export or review it. For a Type 2 engagement, collect evidence for the full period, and confirm with your auditor how they will select samples, since the auditor decides what they test.

RBAC definitions and current access listing

Role, ClusterRole, RoleBinding and ClusterRoleBinding manifests show what each subject is allowed to do, and a dated listing of live bindings shows who currently holds those rights. This supports CC6.3, which covers granting, changing and removing access based on roles and least privilege. Keep the manifests in Git and export the live listing from the API server with its timestamp. Platform engineering owns both files, while the security team reviews wildcard verbs and cluster-admin bindings. Export the listing on a fixed schedule you define, such as monthly, and again before each access review.

Identity provider group membership and reviews

Kubernetes does not store normal user accounts, so the identity provider is the source of truth for who belongs to each group that maps to a cluster role, typically through OIDC group claims. Keep dated exports of group membership, plus signed review records showing that managers confirmed or removed each membership. This evidence supports CC6.1 and CC6.3. Identity administrators own the exports, and the named reviewers own the sign-off. Confirm with your provider how group claims are issued in tokens and how removals reach active sessions.

API server audit logs and protected storage

Audit logs record requests to kube-apiserver, including the identity making the request, the verb, the resource and the response. They provide the traceability auditors expect for access events and support CC7.2 monitoring. Define an audit policy, forward logs off the control plane to access-restricted storage, and set retention to the period your policy and your auditor agree on in advance. Platform operations owns the pipeline and security owns access to the log store. Test log retrieval periodically and confirm that gaps in log delivery raise an alert.

Cluster baseline and version records

Pod Security Admission labels on each namespace show which Pod Security Standard (Privileged, Baseline or Restricted) is enforced. The EncryptionConfiguration for Secrets shows whether Secrets are encrypted at rest in etcd, which Kubernetes leaves off by default. Kubernetes version and upgrade records show which minor version runs where and when it changed. Export namespace labels and the encryption configuration without key material each time they change, and record the key provider and rotation process. Platform engineering owns these records, and the security team approves any namespace exemptions.

Git history and approval records for cluster changes

Git history records every change to manifests, Helm values and policy as code, and approval records show who authorized each change before it reached the cluster. Together they evidence CC8.1 across authorization, configuration, testing and implementation. Protect the main branch, require review on every merge, and keep the sync history from Argo CD or your pipeline alongside the repository log. Engineering leads own the review process. Export a dated record of merged changes and their approvers at the end of each period so the evidence is complete when the auditor asks.

Monitoring rules and alert triage tickets

Alert rules define what the monitoring stack watches in the cluster, such as failed authentication, privilege escalation or exec into running pods. Alert tickets show how each firing was analyzed and whether it was classified as a security event or dismissed. This is core evidence for CC7.2, which requires anomalies to be analyzed. Keep rule definitions in Git and tickets in your ticketing system with timestamps and dispositions. Security operations owns triage and the rule set. Sample closed tickets at each review and confirm that they record the analysis, not only the closure.

How a GitOps change flow supports CC8.1 for cluster changes

CC8.1 expects every change to infrastructure, software and procedures to be traceable from authorization through implementation. For a Kubernetes cluster, the practical way to meet that expectation is to make the desired state of the cluster a versioned artifact in source control and to make every change arrive through a reviewed pull request. The cluster then becomes a consumer of approved state rather than a place where people type changes. The auditor's question is not whether a GitOps tool exists, but whether a specific change can be traced to a request, a design decision, a review, an approval and a deployment record. In a typical flow, cluster manifests or Helm and Kustomize sources live in a repository per environment or per platform area. A developer or platform engineer opens a pull request containing the design rationale and the test results. A controller such as Argo CD watches the approved branch and applies the declared state to the cluster. Argo CD's sync history and the Git commit together give a record of what was applied, when and from which revision. Direct edits made with kubectl are a separate problem: Argo CD can report drift through its application status and can be configured to revert it automatically, and Kubernetes admission policies can deny changes to protected namespaces from non-controller identities. Confirm in your own test cluster which of these behaviors you enable, because a self-heal setting that reverts an emergency fix without a ticket is itself a change control question. The cluster does not enforce approval on its own. Branch protection, required reviewers, status checks, CODEOWNERS entries and restrictions on who can push to the release branch all live in the source control platform, such as GitLab or GitHub. Environment promotion, where a change moves from a development cluster to a staging cluster and then to production, is a pipeline and branch design decision. Separation of duties means the person who authors a change should not be the only person who approves or deploys it, and that rule must be written into repository settings and deployment permissions. Argo CD projects and RBAC then limit which repositories and namespaces each team can sync. Document each of these settings with its owner and the date it was last reviewed, because the auditor will test the configuration as well as the sample changes.

Kubernetes adds inputs to the change process that CC8.1 treats as part of the system's implementation and maintenance. The Kubernetes project releases approximately three times per year on a cycle of about 14 weeks, and it maintains the three most recent minor releases. The version skew policy requires kube-apiserver to be upgraded one minor version at a time and allows kubelets to be up to three minor versions older than kube-apiserver. Each upgrade is therefore a planned change that must pass through the same pull request and approval path as an application change, with its own test evidence. Write a patch and upgrade procedure that names the target version, the order of control plane and node upgrades, the rollback point such as an etcd snapshot taken with etcdctl, and the test suite that must pass before promotion. Confirm the current end-of-life dates on the Kubernetes releases page at the time of your review, since support windows move with each release. For an audit, a sample of changes is usually drawn from a period and each one is traced end to end. Prepare a simple evidence map: pull request link, approver identity, merge commit, Argo CD sync record, and the resulting cluster object version. Include emergency changes as well, and define how they are recorded after the fact. Ask your auditor which sample sizes and evidence formats they expect before you finalize the flow, and ask your Argo CD and source control administrators to export configuration snapshots on a schedule so the settings can be shown as they stood during the period.

Several decisions shape how strong this evidence will be. Decide whether Argo CD may self-heal production or only report drift, because each choice changes what a reviewer will see when someone bypasses Git. Decide who holds the administrator role in the source control platform and in Argo CD, because a platform administrator who can disable branch protection can bypass the approval record without leaving an obvious trace. Decide where audit logs from the Kubernetes API server are sent, so that a direct kubectl change in production can be matched against the Git history. Finally, decide how secrets are handled, because storing secret values in the repository would make the repository itself a sensitive store. Use encrypted secret references or an external secrets store, and confirm the approach with your security team before the first production sync.

Implementation effort depends mainly on how many clusters and environments exist, how many teams commit to the repositories, how mature the existing review practice is, and how many distributions or add-ons need upgrade procedures. Cost falls into a one-time build of the repository layout, the promotion pipeline, access roles and the evidence process, and a recurring cost for maintaining those controls through each Kubernetes upgrade and each Argo CD release. When requesting a quote, ask for the written scope to name the repositories, environments, approval rules to be configured, the upgrade procedure deliverable, and the evidence export that will be provided. A fixed scope agreed in writing before work starts makes it clear which controls are configured by the implementation team and which remain the client's operating responsibility.

Where Kubernetes for SOC 2 controls stops

Cluster controls produce evidence for some SOC 2 criteria, but the rest of the examination depends on work outside the cluster. The cards below mark where Kubernetes stops. The management description of the system and the auditor's opinion sit above all of them, and an auditor needs evidence for each item before either can be issued.

Written policies and risk assessment

The CC3 series expects a documented risk assessment and the policies and procedures the control environment depends on. Kubernetes can enforce settings that a policy describes, but it cannot write the policy, set risk tolerance or record who reviewed the assessment and when. Check that each cluster control traces to an approved policy with a named owner and review date, and that the risk assessment names the cluster as a system component.

HR onboarding and termination

Access granted through RBAC is only as current as the people process behind it. Onboarding decides when a person receives a role, which role that is, and who approved it. Termination decides when access ends. Kubernetes has no record of employment status, so a departed engineer can keep a client certificate, bearer token or kubeconfig until someone revokes it. Check that each HR event triggers removal from the identity provider, the cluster, CI credentials and any shared secrets the person could read.

Physical access to facilities

The CC6.4 series covers restricting physical access to facilities and the assets inside them. For a self-hosted cluster, that means the data center, colocation cage or cloud facility where control plane and worker nodes run. A cluster has no concept of a badge reader or a locked rack. Confirm who holds facility access, how visits are logged, how drives from failed nodes are destroyed, and whether the hosting provider's own assurance reports cover these points.

Anomaly monitoring and incident response

CC7.2 requires monitoring of system components for anomalies and analysis of each anomaly to decide whether it is a security event. Audit logs and metrics are inputs to that work, not the process itself. The cluster does not assign alerts to people, set severity levels or define when an event becomes an incident. Incident procedures must also cover steps outside the cluster, such as customer notice, evidence preservation on hosts and in cloud accounts, and coordination with the identity provider. Check that each alert source has a named triage owner and an escalation path.

Third parties and business continuity

Vendor and subservice organization management covers the cloud providers, colocation operators, managed database and registry services, and support contracts the cluster depends on. Each may need its own assurance report, contract terms and review schedule. Business continuity covers recovery objectives, a failover plan and the person who decides to fail over. etcd backups are one technical input, but a restore that has never been rehearsed does not show continuity. Ask each provider for its current report and record which criteria rely on it.

CIS Benchmark is not a criterion

The CIS Kubernetes Benchmark is a consensus secure configuration guide that covers upstream Kubernetes and several managed services. It is useful for hardening API server, kubelet, etcd and RBAC settings, and an assessor may read its results as supporting detail. It is not a SOC 2 criterion, though. Passing it does not prove that any criterion is met, because it says nothing about policies, personnel, facilities or monitoring. Use it as a configuration check and map its results to the criteria they support.

Configuration sequence for SOC 2 evidence in a Kubernetes cluster

This sequence turns a self-managed Kubernetes cluster into a system whose access, configuration, monitoring and change records can be shown to a SOC 2 auditor. The order matters because the system boundary sets scope, identity and RBAC decide who can act, and audit logs and GitOps records show what they did. The sequence ends with a dry run that confirms the evidence can be collected before the observation period begins.

Define the system boundary and in-scope clusters
Start with the team that owns the SOC 2 report, the platform team and the people who approve access. Agree in writing which clusters, namespaces, identity sources, log stores and Git repositories fall inside the system description. This boundary drives every later step, because CC6.1 expects logical access protections to cover the software, infrastructure and architectures that hold in-scope information. Record the boundary in the system description draft so the team and the auditor work from the same scope. Done when the report owner signs the boundary and every in-scope cluster has an inventory entry.
Confirm the Kubernetes version and support window
Check the minor version of each in-scope cluster against the Kubernetes release page and record its end-of-life date. As of September 2026, the supported minor releases were 1.37, 1.36 and 1.35, with end-of-life dates of October 28, 2027, June 28, 2027 and February 28, 2027 respectively. Confirm these dates again before you start, because the support window moves. Plan upgrades under the version skew policy, which requires kube-apiserver to move first, one minor version at a time, and allows kubelets to trail by up to three minor versions. Output: a version register for each cluster with its end-of-life date and next planned upgrade, which supports the system operations evidence in CC7.2 and CC8.1.
Connect cluster authentication to the identity provider
Configure the API server to trust your identity provider through OpenID Connect so workforce users sign in with their own accounts. Remove shared static tokens and long-lived credentials from human use. Kubernetes does not store normal users as API objects, so the identity provider becomes the source of who exists and which groups they belong to. Keep a small set of X.509 client certificate accounts for break-glass access, store them offline and log every use. Test sign-in for a sample of users and confirm that a leaver loses cluster access once the identity provider disables the account. Output: a login test record and a documented break-glass procedure, which supports CC6.1 and CC6.3.
Design RBAC roles and bindings with segregation of duties
Map each job function to a Role or ClusterRole and bind it to identity provider groups, so membership changes happen in one place. Separate duties so that no single group can both change a workload and approve that change, and limit reading Secrets to the people who need it. Pay close attention to create, update and patch verbs on workloads, and to list and watch on Secrets, because those permissions can expose data indirectly. Keep the role and binding manifests in version control. Output: a role matrix that links each role to a job function, an approver and a review owner, which supports the CC6.3 requirement to grant, change and remove access based on roles and least privilege.
Encrypt Secrets at rest and set Pod Security labels
Kubernetes stores Secrets unencrypted in etcd by default, so enable encryption at rest in the API server configuration. Confirm it by checking a test Secret in the etcd data path, then restrict list and watch access to Secrets using the RBAC matrix. If secret values must live in an external store, use the Secrets Store CSI Driver and document who can reach each source. Next, apply Pod Security Admission labels to every namespace, choosing the Baseline or Restricted standard for each workload, and record any Privileged exception with its owner and reason. Output: an encryption configuration, a namespace label inventory and an exception log, which support CC6.1.
Enable audit logging and route monitoring alerts
Turn on API server audit logging with a policy that records authentication events, authorization decisions and changes to RBAC, Secrets and workloads. Send the logs to storage that the platform team cannot edit or delete without a second approver. Retention is a policy decision, so confirm the required period with the report owner and your auditor before you set it. Deploy monitoring for control plane components and node health, and route audit-based and infrastructure alerts to a named on-call group with an acknowledgment record. Output: a test event that appears in protected storage and an alert that reaches a named person, which supports the monitoring for anomalies described in CC7.2.
Put cluster manifests under version control with approvals
Store cluster and workload manifests in a Git repository and protect the main branch. Require review from someone other than the change author, and link each merge to a ticket. Use the same path for production changes that your GitOps controller applies, and block direct edits to in-scope namespaces except through a documented emergency procedure. Record the testing evidence for each change, such as a staging deployment or a policy check, and keep the approval history in the repository. Output: a sample change traced from request through approval, testing, merge and reconciled deployment, which supports the authorization, testing, approval and implementation stages in CC8.1.
Write runbooks and rehearse evidence collection
Write runbooks for access reviews, cluster upgrades and anomaly triage. Each runbook should name its owner, its inputs, the steps and the record it produces. Then run a dry-run evidence collection: pull the role matrix, identity group membership, encryption configuration, namespace labels, audit log samples, alert history and merged change records. Check that each item can be retrieved with the timestamp and owner an auditor would expect. Close the gaps before the observation period begins and assign an owner to each one. Output: a dry-run evidence index mapped to CC6.1, CC6.3, CC7.2 and CC8.1. The auditor decides whether the evidence is sufficient.

What SOC 2 Kubernetes preparation costs and what it needs from your team

What drives the cost of SOC 2 Kubernetes preparation?

The main drivers are the number of clusters, how identity integration is built, how mature your existing GitOps and logging practices are, which trust services categories beyond security are in scope, and how much policy work is still missing. Number of clusters multiplies every configuration, evidence and access review step, because each cluster needs its own RBAC map, audit log pipeline and change record. Identity integration adds effort when single sign-on, group mapping and offboarding must line up with your HR and directory sources. Existing maturity matters: teams already deploying through Git with reviewed pull requests and centralized logs start with evidence largely in place. Each additional category, such as availability or confidentiality, adds criteria to test. Ask any provider to price each driver separately in a written, fixed-scope quote.

Which SOC 2 Kubernetes costs are one-time and which recur?

Initial configuration is one-time work, while evidence collection, access reviews, upgrades and retained support recur through the life of the environment. One-time work usually covers designing the RBAC model, enabling API server audit logging with a retention target, wiring identity, setting up the GitOps change flow and writing the system description and control narrative. Recurring work includes periodic access reviews of cluster roles and service accounts, reviewing change records against merged pull requests, retaining logs, and running Kubernetes upgrades. Kubernetes ships about three minor releases per year, according to the Kubernetes release cycle page, so upgrade effort recurs even when nothing else changes. Ask the provider to split the quote into a one-time implementation line and any recurring retainer or internal effort line.

How long does SOC 2 Kubernetes preparation take?

The build timeline depends on your cluster count, identity work and policy gaps, but the observation period is set by the auditor and your audit calendar, not by the build itself. A Type 1 report describes system design as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period. Your controls must operate consistently across that period, so the cluster must be stable and evidence must be collected from the start of the window. Your auditor will state the period length and testing dates. Build work should finish, or at least be verified, before the period starts so that the controls being tested are the ones you will keep running. Ask for a written timeline that shows build milestones separately from the auditor's observation window, and confirm both with your auditor.

What does the client team need to provide for this work?

You need to name owners, grant access to identity and cloud accounts, set change approval rules and select an independent auditor. Named owners should cover cluster administration, identity, logging, change approval and policy. Access includes the identity provider, directory groups, the cloud accounts that host the nodes, and read access to the Git repositories that hold cluster manifests. Change approval rules define who authorizes a change under CC8.1, how reviews are recorded, and which changes need emergency handling. Access decisions under CC6.3 need a documented request and approval path. Auditor selection is your decision, since independent CPA firms perform the examination. Agree these inputs in the scope document so that delays do not come from unassigned decisions.

Can an internal team prepare Kubernetes for SOC 2 without outside help?

Yes, an internal team can do the work if it has engineers who know Kubernetes authorization, logging and GitOps, and if it can dedicate time to documentation and evidence. The difficult part is typically the consistent operation of controls across the observation period and the written evidence that proves it, more than the cluster configuration itself. Internal teams often find these gaps: policies that describe a process nobody follows, access reviews that never happen, and change records that do not link to merged code. Map each control to a named owner, a schedule and an evidence source before you start. Consider outside help for the parts your team has not done before, such as writing the system description or designing audit log retention. Compare the cost of your team's time against a written, fixed-scope quote that lists the same deliverables.

Does SOC 2 Kubernetes work need a CPA firm to issue the report?

Yes, a Type 2 report is issued only by an independent CPA firm after an examination, and no platform implementer can issue it. DeployOpen prepares systems, controls and evidence for a compliance assessment but does not issue audit reports, attestations or certifications. A SOC 2 is an assertion-based examination under AT-C section 205 of the AICPA attestation standards, so management provides written representations to the service auditor. Management also prepares the description of the system against the AICPA's 2018 description criteria. Your auditor will tell you which evidence samples they need, which can shape how you configure logs and retain access records. Choose the auditor early, because their calendar often sets your observation window.

What should a fixed-scope written quote for this work include?

A useful quote lists scope, deliverables, assumptions, client inputs, exclusions and evidence handover in writing before work starts. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so the quote follows from the written scope. Ask for the cluster list and each cluster's role, the trust services categories in scope, the identity sources to integrate, the state of your existing GitOps and logging, and the policies you already have. Ask which items are fixed, which depend on your inputs, and what changes if scope grows. Confirm whether ongoing support, upgrades and evidence collection are separate retainers. Keep the auditor's observation window out of the build fee so that timing risk stays visible.

How DeployOpen scopes and delivers SOC 2 Kubernetes configuration and evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted Kubernetes inside your own cloud accounts, data centers or air-gapped networks. For SOC 2 work, we configure the cluster controls and collect the evidence that supports your system description, while independent auditors decide what your report says.

How we scope

Engagements are fixed-scope, with the Kubernetes clusters, namespaces and criteria covered agreed in writing before work starts.
Scope names which controls map to CC6.1, CC6.3, CC7.2 and CC8.1, and which systems produce the evidence for each.
Confirm with your auditor early which Trust Services Criteria categories are in scope, since this changes the control list.

How we build

We configure RBAC roles, identity integration and audit logging policy for the cluster, then test that access is granted and removed as designed.
We set up Secrets encryption at rest and Pod Security Admission, and document how each setting maps to a control.
GitOps change flow is configured so every cluster change has a recorded author, reviewer and deployment history.

How we hand over

You receive a control matrix linking each Kubernetes setting to its SOC 2 criterion, owner and evidence source.
Evidence collection runbooks explain where audit logs, RBAC exports and change records are stored, and how long they are retained.
Handover includes a walkthrough so your team can run the evidence process without us for the next audit period.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so controls stay configured as Kubernetes versions change.
We can review evidence samples before your auditor requests them, so gaps surface while there is time to fix them.
Support scope, response expectations and any recurring evidence reviews are written into the retainer before it begins.