Controlling engineer access to production for SOC 2

How to control engineer access to production for SOC 2

When a customer or contract requires SOC 2, production access is usually one of the first questions in the security review, and the answer has to be backed by records, not promises. The organization owns its access controls. An independent CPA firm tests them and issues the report, and an implementation partner can prepare the access setup and the evidence the auditor will request. The answer depends on how engineers reach production today: whether they log in with shared accounts, personal SSH keys, cloud consoles or a kubectl context, and how many systems, accounts and clusters fall inside the examination's scope. Confirm that inventory before anything else, because every later control is measured against it.

Three criteria shape the design. CC6.1 asks for logical access security software, infrastructure and architectures that protect information assets, so the access path itself must be defined and enforced. CC6.2 requires that new internal and external users be registered and authorized before credentials are issued, and that credentials be removed when access is no longer authorized. CC6.3 requires granting, changing and removing access based on roles and system design, with least privilege and segregation of duties taken into account. In practice, that means a written rule for who may request production access, who approves it, how long it lasts, and who may approve their own requests (the answer should be no). Ask the CPA firm early which of these rules it expects to test and which sample populations it will draw from.

The main effort is in the evidence. Each approval, grant, session and removal needs a record that an auditor can sample, and many teams find that session-level records are the hardest to produce. Self-hosted open-source tooling such as Teleport can record SSH and Kubernetes sessions and emit structured audit logs to a SIEM, but feature coverage differs by edition. Teleport's Community Edition includes per-session MFA, audit logs and session recording with playback, while SSO with OIDC or SAML, access lists, access reviews and session moderation are listed as Enterprise only in the Teleport feature matrix. Confirm each capability your design depends on against the current matrix and your license before you rely on it, and ask the auditor whether the evidence format you plan to produce is acceptable.

How an engineer gets production access, step by step

The sequence turns a single access decision into a chain of records that an assessor can trace from request to revocation, so each grant can be shown to be authorized, limited and reviewed.

Submit a documented access request
The engineer asks for a specific production role, stating the systems, the business reason and the ticket or change it supports. The request is logged in the organization's ticketing or identity system, so it has an owner, a timestamp and a stated purpose. The output is the request record itself, which an assessor will compare against later grants. Confirm that your ticketing tool keeps that record immutable or at least timestamped.
Approve the request independently
Someone other than the requester, usually the system owner or a manager with authority over the role, reviews the request against the role definition and approves or rejects it. This is the segregation of duties check that CC6.3 expects, since the person who needs access should not be the only one deciding that they get it. The output is the recorded approval with the approver's identity and date. Confirm that approvers are not able to approve their own requests in your tooling.
Grant a time-bound, role-scoped credential
Access is provisioned only after approval, tied to the approved role and limited to the approved systems. Where the platform supports it, the grant expires without a manual step, so access does not persist after the work is done. CC6.2 requires that credentials are issued only after registration and authorization, so the grant event should reference the approval record. The output is the grant log showing who received which role, when and under which approval. Confirm how your platform sets expiry and whether that is an Enterprise or Community Edition feature.
Authenticate with MFA for each session
Each time the engineer opens a production session, they re-authenticate with multi-factor authentication, so a stolen or long-lived login alone does not open production. The output is an authentication event that records the method used and the outcome, which can be exported to the logging stack. Teleport Community Edition includes per-session MFA, so confirm it covers each connection type you need, such as SSH and Kubernetes.
Record the session
While the engineer works, the session is captured so that its actions can be replayed later. For SSH and Kubernetes, Teleport records full terminal output, and it can record database queries and application request events, with recordings stored in a filesystem, S3-compatible or Google Cloud Storage backend alongside audit events. The output is the session recording and its audit entry, which together show what was done and by whom. Confirm where recordings are stored, who can read them, and how long they are kept.
Revoke access when the work ends
When the grant expires, the task closes or the role changes, access is removed and the credential can no longer be used. Revocation should be logged with the reason and the actor, whether the removal was automatic or manual. CC6.2 requires that credentials are removed once access is no longer authorized, so the revocation record is part of the evidence. The output is the removal log that matches the original grant. Confirm that a departing engineer's access is removed through the same trail.
Review grants and recordings periodically
At set intervals, the system owner reviews who holds production roles, checks that each grant still has a valid approval, and samples session recordings against the requests that justified them. Access reviews are the control that catches grants that drifted from their original purpose. The output is a signed review record listing the reviewer, the population reviewed and any exceptions with their resolution. Teleport access lists and access reviews are Enterprise features, so if you use Community Edition, confirm how this review is performed and evidenced.

Designing least privilege and segregation of duties

The access model for production is decided before any engineer logs in. The cards below cover the design choices that auditors test under CC6.3 and CC6.2, and each one names the evidence it should leave behind. Read them together, because a role model that separates deploy rights from code authorship still fails if standing rights quietly accumulate.

Separate deploy rights from code authorship

The person who writes a change should not also be the only person who can push it to production. Under CC6.3, check that the group allowed to deploy is distinct from the group that merges code, and that a deploy requires a second identity or a pipeline gate. Evidence is the role membership list, the branch protection settings and deployment logs that show who released each change. Ask your engineering lead to confirm which accounts can bypass the gate.

Define roles per system

Each production system needs its own role catalog, written down with the actions each role permits, such as read logs, restart a service or change a database schema. Generic roles like admin hide the access that auditors want to see scoped. Under CC6.3, the role definitions are the evidence that access follows responsibilities. Review the catalog whenever a system is added, and keep the version history so the auditor can see what changed and when.

Time-limited elevation

Engineers who need elevated rights for an incident or a migration should receive them for a defined window, then lose them automatically. Standing administrator rights are the most common finding in access reviews because nobody remembers to remove them. Confirm that your tooling can grant and expire elevation without a manual cleanup step, and keep the grant record with its start time, end time and reason.

Separate requester from approver

The person who asks for production access should not be the person who approves it. Route each request through a second identity, and record both names, the justification and the decision. This is the core of segregation of duties applied to access. Ask whether approvers hold the rights they grant, because an approver who is also a member of the same elevated group defeats the separation.

Control break-glass accounts

Break-glass accounts exist for emergencies when the normal identity provider or approval path is down. Keep them few, store their credentials under dual control, and alert on every use. Under CC6.1 and CC7.2, auditors expect a documented trigger, a named owner and a review of each activation. Confirm with your team that break-glass use produces a log entry and a post-incident review, not just a sealed envelope that nobody checks.

Review standing rights on a schedule

Standing rights are the production permissions that remain after the work that needed them is finished. Schedule a review of who holds each role, record the reviewer, and remove what is no longer justified. Under CC6.2, removal of credentials once access is no longer authorized is a criterion in its own right, so the review record and the removal ticket together show the control operating. Ask your auditor which review frequency and sample they expect for your system.

What Teleport Community Edition includes and what it does not

Community Edition gives a self-hosted deployment the session-level controls that most production access evidence depends on. Engineers reach SSH and Kubernetes resources through Teleport, each session can require multi-factor authentication, and the platform records what happened during the session. The recordings and structured audit events can then be stored and exported for review, which gives the team something concrete to show an assessor when testing access restrictions.

Per-session MFA: Each access session can require a second factor, so a valid login alone does not open production.
Session recording with playback: SSH and Kubernetes sessions are captured as full terminal output and can be replayed for review.
Structured audit logs with SIEM export: Audit events can be exported to a SIEM so access records sit alongside other security logs.
Recording storage options: Recordings can be kept on a filesystem, in S3-compatible storage or in Google Cloud Storage, which lets the team match retention to its own evidence plan.

Before relying on these features, confirm the current feature list against the Teleport feature matrix and the Community Edition license, since editions change over time.

What session recordings prove and what they cannot prove

Session recordings show what an engineer did once connected, but they do not show that the connection should have existed. Teleport records SSH and Kubernetes sessions by capturing full terminal output, records desktop screen and mouse input, captures database queries and app request events, and stores the recordings in a filesystem, S3-compatible or Google Cloud Storage backend alongside its audit events. For CC7 monitoring and review, that gives a reviewer a complete trail of commands, queries and requests tied to an identity, which supports detecting anomalous activity and evaluating security events. Confirm with your own deployment where the storage backend lives, who can read it, and how long recordings are retained, because the recordings themselves become sensitive data.

A recording answers the question of what happened. An auditor will still sample other records to answer whether access was granted properly under CC6.2 and CC6.3: the approval record for each grant, the access list as it stood on the date the auditor selects, and evidence that someone reviewed the sessions and the list. Session playback does not replace any of these. Teleport's access lists, access reviews and session moderation are Enterprise features, and Community Edition offers access requests only through the CLI. If your reviews depend on those features, plan for the review evidence separately, such as a ticket export or a signed quarterly review, and confirm the exact feature set on Teleport's feature matrix.

Recordings alone do not show that access was authorized. A session can be fully recorded and still be a breach of policy if the engineer had no approved request, held a role broader than the job required, or used a shared account that hides who was present. Before you rely on recordings in a Type 2 examination, check that every recorded session maps to an approved request and a named individual, and that offboarding removed the person's access on time. Ask your auditor which combination of recordings, approvals and access reviews they will sample for the period, and build the process so each of those records exists without manual reconstruction.

What must be in place before the auditor samples access

An auditor testing production access starts by asking for the rules, the population of accounts and the records that prove each grant and removal followed those rules. The six items below connect so that every sampled access event can be traced back to a written policy, a defined role, an approval and a retrievable session record.

Written access policy

The policy states who may request production access, which roles exist, how privileged access is granted, how long it lasts and who approves it. Under CC6.3, access changes must follow roles, responsibilities or system design, so the policy is the rule the auditor compares each sample against. Check that it names an owner, carries a review date and was approved by management before the observation period began, and that engineers can find it in the wiki they actually use.

Current inventory of production systems

Auditors cannot test access to systems the organization has not listed. The inventory should name every production host group, Kubernetes cluster, database, cloud account and administrative console, along with the account types that reach each one. Check it against the cloud provider's account list and the Teleport resource list, and confirm that a new production system cannot appear without being added to the inventory.

Documented role definitions

Each role, such as read-only observer, on-call responder or database administrator, should list the systems it covers and the actions it permits. This is where least privilege and segregation of duties become concrete: no single role should both approve a change and deploy it. Check that every role in the directory maps to a documented definition, and that no engineer holds a role with permissions the definition does not describe.

Working approval record

Before access is issued, CC6.2 requires the organization to register and authorize the user. The approval record should show who requested the access, the business reason, the role granted, the approver and the time the grant took effect. A ticket that is closed after the credential already exists does not satisfy the control. Check a handful of recent grants end to end: the approval should predate the first login in the session logs.

Retrievable session recordings

For shell, Kubernetes and database access, the team should be able to pull a recording for any sampled session and show who connected, when, to which resource and what was run. Teleport Community Edition provides session recording with playback and exports structured audit logs to a SIEM. Check that recordings for a chosen date range can be found and played back within the time the team has committed to, and that the storage location is covered by the retention policy.

Recurring access review with signed output

CC6.2 also requires removing credentials once access is no longer authorized, and reviews are how the organization proves it. Each review should list every account and role on each production system, record the reviewer's decision to keep or remove, and be signed or approved in a dated record. Check that the review ran at the frequency the policy states, that removals were executed rather than only recorded, and that the reviewer is not the person whose access is under review.

Who owns the controls, who prepares evidence and who issues the report

The organization owns its controls. Under CC6.3, the organization decides who may be granted, changed or removed from access to production, based on roles, responsibilities and system design, with least privilege and segregation of duties taken into account. No tool or partner can make those decisions on its behalf, and the auditor will ask management to explain them.

Access policy: Management writes and approves the rules for who may reach production, which roles exist, and which of them may make changes.
Approvals: Named owners approve each request for production access before credentials are issued, which is the step CC6.2 asks the organization to perform before access is granted.
Reviews: Managers review production access on a set schedule and remove access that is no longer needed.
Exceptions: Emergency or break-glass access is approved, time-limited and followed up by a documented review.
Management assertion: Leadership signs the representations the auditor relies on, including the description of the access system.

Ask your CPA firm which of these items it will sample, and confirm that the people named as approvers hold the authority your policy assigns to them.

Questions about production access for SOC 2

Is Teleport Community Edition enough for SOC 2 production access?

It can cover some of the production access evidence, but whether it is enough depends on your single sign-on and access review requirements, and you should confirm that with your CPA firm before you build around it. Community Edition includes per-session MFA, structured audit logs with export to a SIEM, and session recording with playback. Single sign-on with OIDC or SAML, access lists, access reviews, device trust and session moderation are Enterprise features, and Community Edition supports GitHub SSO only. If your identity provider is not GitHub, or if your review process depends on access lists, plan for that gap explicitly. The Teleport feature matrix lists which capabilities sit in each edition.

Does per-session MFA satisfy the MFA requirement for production access?

Per-session MFA addresses the question of whether each privileged connection was verified with a second factor, which is the part most relevant to production access. It does not, on its own, answer where MFA is required across your environment, such as cloud consoles, the identity provider, remote access paths and administrative tools. Auditors typically look for MFA on every path into production, so map each path and show how each one enforces it. Confirm with your auditor how they want that mapping presented, and see the sibling page on SOC 2 multi-factor authentication for the wider picture.

How long must session recordings be kept for SOC 2?

The SOC 2 criteria do not state a retention period for session recordings or logs. Your organization sets the period in its own retention policy, and the auditor tests whether you follow that policy consistently. Choose a period that matches your contracts, customer commitments and any sector rules that apply to you, then document it and configure storage to enforce it. Teleport can store recordings on a filesystem, S3-compatible or Google Cloud Storage backend alongside audit events, so retention settings belong in your own storage lifecycle configuration. Confirm the period with your auditor before the observation window starts.

Will the auditor sample our session recordings?

Auditors commonly test a sample of access events within the examination period, and session recordings are a natural source of evidence for that test. They usually ask for a population of production sessions, select items from it, and check that each session was authorized, used MFA and matched an approved request. The exact sample size and method are set by the auditor, not by this page. To prepare, make sure you can list every production session in a period, link each one to a ticket or approval, and retrieve the recording on request.

What must our own team do to meet the production access controls?

Your organization owns the controls, so your team must define who may access production, approve requests, review access on a schedule and remove access when people leave or change roles. Engineers must follow the approval path, and someone independent of the requester should check that access was granted and removed correctly. Your team also keeps the policies, runs the access reviews and retains the records the auditor asks for. A partner can configure the tooling and document the process, but the decisions and the ongoing operation stay with you.

Can a consultant or implementation partner do the production access work alone?

A partner can design and implement the access model, configure self-hosted tooling inside your own infrastructure, and prepare the evidence and documentation for the examination. It cannot own the controls, approve access on your behalf over the long term, or issue the report. Only an independent CPA firm performs the SOC 2 examination and issues the opinion. Ask any partner to state in writing which tasks they perform, which remain yours and how the handover works. DeployOpen works on a fixed scope agreed in writing before work starts, and it prepares systems and evidence without issuing audit reports or attestations.

What drives the cost of controlling production access for SOC 2?

Costs fall into two groups: one-time setup, such as designing roles, integrating identity and deploying the access gateway, and recurring work, such as access reviews, recording storage and examination fees. The number of environments, the size of the engineering team, the number of identity sources and whether you need Enterprise features all change the total. The auditor's fee is set in its own engagement letter and is separate from the tooling and implementation work. When requesting a quote, ask for the scope in writing, the deliverables, what is one-time and what recurs, and which tasks remain with your staff.

How DeployOpen sets up production access for an audit

DeployOpen plans and implements the production access layer inside your own cloud accounts, data centers or air-gapped networks, then prepares the access rules, session records and approval evidence an auditor will sample. Your organization owns the control design and the access decisions, and an independent CPA firm decides whether the controls meet the criteria.

How we scope

Engagements are fixed-scope, with systems, environments and engineer roles agreed in writing before work starts.
The written scope lists which production hosts, clusters and databases fall under the access controls and which are excluded.
Scope records who approves access, who reviews it and which evidence the auditor will receive for each control.

How we build

We configure role-based access, least privilege groups and separation between engineering and approval duties on your infrastructure.
We set up per-session MFA, session recording and structured audit log export to the SIEM your team already runs.
We test that revoked access ends existing sessions and that recordings capture the activity your scope requires.

How we hand over

You receive configuration records, a control description for the access controls, and a walkthrough of where evidence is stored.
Evidence samples are organized by control so your team and the auditor can request access records without manual reconstruction.
Known gaps, such as features only available in a paid tier, are documented in the handover so your team can decide before the examination.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover access reviews, configuration changes when engineers or roles change, and version upgrades of the access platform.
Questions about what an auditor will accept should go to your CPA firm, which decides sufficiency of evidence.