SOC 2 evidence for SSH access on Linux servers
A SOC 2 audit asks you to show who reached your production servers and what they did, across the whole period the auditor tests. Shell history can't prove that, because every user can edit their own. shellz records each login on your Linux servers, flags any recording that's incomplete or altered, and logs who opened it afterwards. That helps you meet the access and monitoring criteria. It doesn't replace your auditor's judgement, and shellz hasn't completed a SOC 2 audit of its own yet.
Choose shellz if
- Your auditor wants evidence of what admins did on Linux servers, and today all you have is
.bash_history. - The evidence has to span a Type 2 window of several months and show that nothing was trimmed out of it.
- You want to answer a sample request during the audit by searching for a session and exporting its transcript.
- You need audit evidence on a startup budget. The first 10 active devices cost nothing. Past that, Commercial bills each teammate $10 a month and storage at $1 per GB.
Look at a PAM suite or gateway if
- Your auditor or a customer contract expects access to be approved per request, or admin passwords to sit in a vault.
- Windows, database or Kubernetes access is in scope alongside Linux.
- Your vendor policy requires every tool that touches production to hold its own SOC 2 report.
- Your SOC needs these sessions inside its SIEM today, and shellz has no SIEM export yet.
At a glance
| Capability | What shellz gives you | Still yours to provide |
|---|---|---|
| CC6.1: logical access is secured | Partial: a record of every login to your Linux servers, by account and source IP | SSO, MFA, SSH key management and network rules |
| CC6.2 and CC6.3: access is granted and removed with approval | Partial: shows whether an account kept logging in after its removal date | Onboarding and offboarding tickets, plus periodic access reviews |
| CC7.1: unauthorized changes are detected | Partial: root changes to the recorder's own settings are reverted and alerted | File integrity monitoring for the rest of the system |
| CC7.2: systems are monitored for anomalies | Partial: alerts for bypass attempts, tampering and servers that stop reporting | Monitoring for everything outside the terminal |
| CC7.3 and CC7.4: security events are evaluated and handled | Yes: replay, searchable transcript, and export as .cast or .txt | An incident response process and its ticket trail |
| Proof the evidence wasn't edited | Yes: each session shows verified, gap or tampered | Nothing extra |
| Record of who viewed the evidence | Yes: an audit log of who opened which recording | Nothing extra |
| Kept for the whole audit window | Yes on Commercial, with no time limit. The free plan keeps only the newest 50 recordings | A written retention policy |
A Type 2 audit tests your controls over months
SOC 2 comes in two kinds. A Type 1 report checks that your controls are designed sensibly on a single day. A Type 2 report checks that they actually worked over an observation period, which you choose with your auditor. Vanta describes the usual range as three to twelve months.
For server access, that means evidence from across the period. Your auditor may pick a handful of dates and ask what happened on production that day. Shell history is a weak answer. It keeps typed commands without their output, and the user who typed them can edit or delete it.
Session records support the access and monitoring criteria
SOC 2 audits measure your controls against the AICPA's Trust Services Criteria. The security section, called the common criteria, is numbered CC1 to CC9. Two groups matter for server access. CC6 covers who can log in and how that access is granted and removed. CC7 covers how you watch your systems and respond when something goes wrong.
None of these criteria names session recording. They describe outcomes, and you choose controls that achieve them. A recording of each login is evidence that access controls were used as designed, that someone was watching, and that you could reconstruct an incident. Your auditor decides whether that evidence is enough for your environment.
Offboarding is a good example. If an engineer left on 3 March, the session list for their account should stop on or before 3 March.
Recordings carry their own proof of integrity
Expect questions about whether anyone could have edited the recordings. shellz signs each piece of a recording on the server and chains it to the piece before. A missing or altered piece breaks the chain, and the session is marked with a gap or tampered badge instead of verified.
After upload, recordings sit in write-once storage with a retention lock. Your admins can't alter or remove them, and neither can shellz staff. If root on a server changes the recorder's settings, shellz puts them back within seconds and reports it. Uninstalling needs sign-off in the dashboard, and if a host stops checking in for roughly a minute, you get an alert.
Full root on a machine can always tamper with the programs running there. shellz is built to catch that and say so, and each session's integrity badge records the outcome.
The audit log covers people reading recordings, too
Terminal sessions can show customer data, internal hostnames and the occasional secret printed by mistake. An auditor reviewing your controls may ask who could see that material.
Every playback is logged, and opening a recording requires signing in again. Owner, admin and member roles control who may watch. Perfect Secrecy comes with every plan: the decryption keys live on your teammates' passkeys, so shellz employees have no way to read a session. Passwords entered at hidden prompts, sudo included, are left out.
Retention has to outlast the observation window
If your Type 2 window is twelve months, you need recordings from the first day of it when the audit starts. Pick a retention period that covers the full window plus the time the audit takes, and write it into your policy.
Plan limits matter here. The free plan keeps your newest 50 recordings, which suits a trial. Personal Pro keeps recordings for 90 days, which is shorter than most windows. Commercial has no retention cap. It bills $10 monthly per teammate and $1 monthly per stored GB (plans).
Answering a sample request takes a search and an export
This walkthrough is illustrative. Your auditor asks for evidence of production access on three dates and a list of who logged in to db-01 in the last quarter.
- Open the session list for
db-01and filter by user or source IP to see who connected and when. - For each sampled date, open the sessions and check that each one shows as verified.
- Export the transcripts as
.txtfor the evidence folder, or as.castif the auditor wants to replay them. - Pull the viewer audit log to show who on your team reviewed those sessions.
Gaps to plan for in your audit
Your vendor review will list shellz as a young supplier with no SOC 2 report yet. It records Linux terminals only. Windows, RDP, databases and kubectl exec need another tool. It doesn't grant or revoke access, block commands or send logs to a SIEM yet.
Weighing a full privileged access suite for SOC 2 instead? Read the PAM vs session recording guide. For the emergency logins auditors ask about, see break-glass access.
Questions
Does SOC 2 require SSH session recording?
No. The Trust Services Criteria describe outcomes, such as restricting logical access and monitoring for anomalies, and leave the controls to you. Session recordings are one way to show those controls worked. Your auditor decides what evidence is sufficient.
Is shellz SOC 2 compliant?
shellz itself hasn't been through a SOC 2 audit yet. It gives you access and monitoring evidence for your own audit, and your vendor review will flag its missing report.
How long should I keep session recordings for a SOC 2 Type 2 audit?
At least as long as your observation period plus the time the audit takes. Observation periods commonly run three to twelve months. Commercial keeps recordings with no time limit.
Could an admin delete a recording before the auditor sees it?
Not after upload. Recordings are stored write-once under a retention lock. If part of a session never arrived or was altered on the way, its integrity badge shows a gap or tampering.
Which SOC 2 criteria does session recording help with?
Mainly CC6.1 to CC6.3 on logical access and CC7.1 to CC7.4 on monitoring and incident handling. You still need SSO, access reviews and an incident process alongside it.
Related comparisons
- PAM vs session recording: do you need a PAM suite yet?/guides/pam-vs-session-recording
- Trace a command on a production Linux server to the person who ran it/use-cases/incident-investigation
- Recording break-glass access to Linux servers/use-cases/break-glass-access
- pam_tty_audit and auditd vs session recording/compare/auditd
Sources
Competitor details come from public documentation and pricing pages, last checked on November 4, 2026. Products change; if something here is out of date, tell us at hello@shellz.dev and we will correct it.