The first SOC 2 audit is rarely about whether your security is good. It is about whether you can prove your security is good, in the format your auditor expects, for a defined window of time, across a defined population of systems. For Linux access — SSH, sudo, the audit trail that surrounds them — the proof is more specific than a SOC 2 reading guide will tell you.
This article walks through the three Trust Services Criteria that touch Linux access (CC6.1, CC6.6, CC7.2), translates each into the artefacts an auditor will actually request, and shows where on a typical fleet you find them. Where Linux Identity features map cleanly, we say so without burying it; where the work is yours regardless of tooling, we say that too.
The relevant criteria, in plain English
SOC 2 is governed by the AICPA Trust Services Criteria. The 2017 framework (updated in 2022) groups criteria into five categories: Security (mandatory), Availability, Confidentiality, Processing Integrity, and Privacy. The Security category is the one every SOC 2 report covers, and it contains the controls that bear on Linux access.
The three controls that matter most:
- CC6.1. "The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives." Translation: access is restricted to authorised users, by something more rigorous than "Bob knows the password."
- CC6.6. "The entity implements logical access security measures to protect against threats from sources outside its system boundaries." Translation: external-facing access surfaces are protected. For Linux, that means the bastion, the VPN edge, and the SSH service itself.
- CC7.2. "The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events." Translation: you have logs, the logs are reviewed, and incidents are followed up on.
A pedantic reading would add CC6.2 (user provisioning), CC6.3 (role-based access), CC6.7 (data transmission), and CC7.3 (incident response) to the list. Those matter, but the heavy lifting on Linux access lives in 6.1, 6.6, and 7.2.
The three artefacts an auditor actually asks for
Across half a dozen first-time SOC 2 Type II audits in the last 18 months, the same three artefact requests show up. The wording varies; the substance does not.
Artefact 1: access lists tied to identity
The literal request: "Provide a list of all individuals with administrative access to production Linux hosts as of 31 December." The harder follow-up: "For five randomly selected individuals on that list, provide evidence of when access was granted, who approved it, and what business need it supports." And then: "For five randomly selected terminated employees during the audit period, provide evidence that production access was removed within your stated SLA."
With static SSH keys, this is hard. The list of who has access is the union of every authorized_keys file across the fleet, deduplicated by key fingerprint, joined to a key-to-human mapping that lives in someone's head. Onboarding evidence is a PR in a config-management repo, which often does not record who approved it. Offboarding evidence is the absence of the key after a re-run of Ansible, which is not the same thing as proof that the key was actually revoked everywhere it had been trusted.
With an SSH CA tied to your IdP, the answer is a single SQL query against the cert-issuance log filtered by date range, joined to the IdP's user directory. The list of currently-authorised humans is the list of currently-active IdP accounts in the relevant groups. Approval evidence is the IdP's group-membership history. Revocation evidence is the IdP deprovisioning event, plus the certificate-issuance record showing that no certs were issued to that identity after that timestamp.
Same control, two different costs of evidence.
Artefact 2: audit logs of privileged commands
The literal request: "Provide the audit logs for production Linux sudo invocations for the month of October." The harder follow-up: "Pick five high-risk commands (rm -rf, dd, iptables -F, anything matching /etc/shadow access). For each, describe the alert and response procedure."
The default Linux answer is syslog plus auditd. Both work; both have rough edges for audit-evidence purposes. Syslog can be edited if the system was compromised before logs were shipped. Auditd is verbose enough that retention quickly becomes expensive and the signal-to-noise ratio is poor. Neither one is, by default, tamper-evident in the way an auditor wants.
The properties that make a privileged-command log audit-ready:
- Every invocation is captured at the syscall or PAM layer, not parsed from stderr.
- Each record names the identity (not the local Unix user, the human in your IdP).
- Each record carries a cryptographic link to the previous record, so tampering produces a detectable break.
- Logs are shipped within seconds, to WORM (write once, read many) storage where neither you nor your vendor can delete them within the retention window.
The Linux Identity audit log meets all four. The properties are independently auditable: a customer can re-derive the expected sha256 root hash from the raw rows and confirm it matches.
Artefact 3: evidence of timely revocation
The literal request: "Provide your access-revocation SLA, and evidence that it was met for terminated employees during the audit period." The harder follow-up: "For one terminated employee selected at random, demonstrate the exact times of (a) IdP deprovisioning, (b) last successful SSH cert issuance, (c) last successful SSH session, and that (b) and (c) align with your stated SLA after (a)."
This question is almost impossible to answer with static keys and well-written without an identity-bound flow. The cert issuance log gives you (b) directly; the audit log gives you (c) directly; the IdP gives you (a). The three timestamps drop into a row that the auditor can verify.
The control-to-feature mapping
To be specific about what Linux Identity provides versus what is generic SSH best practice:
| Control | What the auditor wants | Where it comes from |
|---|---|---|
| CC6.1 | Access list tied to identity | SSH CA cert issuance log joined to IdP |
| CC6.1 | Approval evidence on new access | IdP group membership history |
| CC6.1 | Periodic access reviews | Quarterly export of active principals per host class |
| CC6.6 | Strong auth at network boundary | SSH cert auth + IdP MFA + source-address binding |
| CC6.6 | No long-lived shared secrets exposed externally | 4 to 8 hour cert TTL; no static keys on disk |
| CC7.2 | Privileged-command logging | Sudo PAM module + hash-chained audit log |
| CC7.2 | Log integrity | sha256 hash chain + WORM object storage |
| CC7.2 | Anomaly detection | Alert webhook on high-risk command patterns |
| CC7.3 | Incident response capability | Session recordings retained 90 days; immutable |
What auditors do not actually require
Three things that come up in generic SOC 2 advice and are not really required for Linux access:
FIPS 140-2 cryptographic modules. The TSC do not require FIPS validation. Some auditors and many enterprise customers will ask for it as part of their own due diligence, but it is not a SOC 2 control. The relevant point for our purposes: the Linux Identity SSH CA is hosted in a managed KMS that is FIPS 140-2 Level 2 validated, so the question becomes a non-issue without you having to source another vendor.
Daily log reviews. CC7.2 requires monitoring, not human-eyes-on-every-log-line. Automated alerting on a defined set of suspicious patterns, with a documented review cadence (often weekly for routine alerts, immediate for high-severity), is what auditors accept. The output is the alert and the disposition, not a daily certification.
Air-gapped jump hosts. Some compliance frameworks require physical isolation between admin networks and production networks. SOC 2 does not. A well-designed SSH bastion in a separate VPC subnet, with MFA at the IdP, satisfies CC6.6.
The two-quarter audit window
SOC 2 Type II requires evidence across a minimum period, typically three months for the first report and six to twelve months thereafter. The hardest part of the first audit is not technical; it is that the controls need to have been operating for the duration of the window. A control that you implemented two weeks before the window closes does not count.
Practical consequence: if you are aiming for a Type II report in Q4, the access-management changes need to be in production by end of Q1. That is the window in which an audit might start in early Q2 covering Q2 and Q3. If you are doing the SSH CA rollout, the 90-day plan gets you operational in time for a Q3 start; pushing the same plan to Q3 puts a Q1-next-year report at risk.
What we recommend reading next
For the SSH-side rollout, the Series A SSH article covers the design rationale and the OpenSSH CA production guide covers the configuration. For sudo, the JIT sudo article covers the audit log shape that maps onto CC6.6 and CC7.2. The security page documents our control plane and threat model.
Linux Identity is built specifically for the SOC 2 evidence shape described here. Free under 10 hosts and 5 users; see pricing or get started.