> For the complete documentation index, see [llms.txt](https://docs.linuxguard.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.linuxguard.io/audit-and-comply/audit-comply/soc2.md). # SOC 2 > **Note**: This page maps LinuxGuard against the AICPA **SOC 2 Trust Services Criteria 2017 (revised 2022)** (effective 2022-12-15). Last verified against the framework on 2026-05-31. Canonical framework document: [AICPA — 2017 Trust Services Criteria (Revised 2022)](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022). For the vocabulary contract used here, see [Audit & Comply](/audit-and-comply/audit-comply.md). ## Scope This page maps LinuxGuard's agent and console capabilities against the AICPA Trust Services Criteria 2017 (revised 2022). The mapping is scoped to controls in the Common Criteria (CC1-CC9), specifically CC6 (Logical and Physical Access), CC7 (System Operations), and CC8 (Change Management), plus the supplemental Trust Services categories for Availability (A1), Processing Integrity (PI1), and Confidentiality (C1). Controls in the Privacy category (P1-P8) are out of scope for the agent — LinuxGuard does not process personal data on customer behalf — and are listed in the mapping table as `Out of scope` rather than omitted. This mapping is informational and not a substitute for an independent audit by a qualified assessor. Customers remain responsible for selecting the SOC 2 report type (Type I covers design at a point in time; Type II covers operating effectiveness over a period), defining the system description and control objectives, executing the audit period activities, retaining a CPA firm to perform the audit, and remediating any control deficiencies identified. ## Shared responsibility > LinuxGuard is a security monitoring agent and console. Compliance with any framework requires customer-side controls in addition to LinuxGuard's capabilities. This mapping is informational and not a substitute for an independent audit by a qualified assessor. The shared-responsibility framing for SOC 2 TSC 2017 (rev 2022): * **LinuxGuard responsibility.** Produce continuous system access logging, behavioral monitoring, configuration baselines, drift detection, and identity intelligence for Linux systems in the SOC 2 audit scope. Maintain the framework version pin and per-control evidence pointers. Provide auditor-shareable evidence packages via the console. * **Customer responsibility.** Define the system description, identify the controls relevant to the selected Trust Services Criteria, design and operate management-level controls (governance, risk assessment, board oversight), administer the IAM platform and identity governance program, manage cryptographic keys and encryption, operate the business continuity and incident response programs, manage vendor relationships, and engage a CPA firm for attestation. * **Out-of-scope domains for this framework.** Privacy criteria (P1-P8), management governance controls, board oversight, vendor management, business continuity planning, and the customer's chosen application-layer controls. ## Control mapping The Tier column uses one of three labels and only those three: `Satisfies`, `Supports`, `Out of scope`. The Evidence column points to a row of the canonical [Evidence Location](/concepts/concepts/console/compliance-expansion.md#evidence-location) table or to a specific console page. See [Audit & Comply](/audit-and-comply/audit-comply.md) for the three-tier vocabulary contract. | Control ID | Description | Tier | Evidence | Notes | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `CC6.1` | Logical and physical access — implement logical access security software, infrastructure, and architectures over protected information assets | `Supports` | Console Audit pillar → Authorizations audit; Console Identity Intelligence; Config Drift events on SSHD/SSH baselines | LinuxGuard surfaces SSH configuration baselines, account inventory, SUDO rule baselines, and authorization audit. Customer responsible for the IAM platform, role definition, network access policy, and key management. | | `CC6.2` | Prior to issuing system credentials, registration and authorization of new internal and external users | `Supports` | Console Identity Intelligence; Console Audit pillar → Authorizations audit | LinuxGuard observes account creation events and tracks who has access. Customer responsible for the credential registration workflow, identity proofing, and approval gates. | | `CC6.3` | Manage points of access (interfaces, ports, protocols) — restrict access to authorized users | `Supports` | Console Zero Trust Enforcement → Config Drift on SSHD config | SSHD configuration baseline and drift detection surface unauthorized changes to system access points. Customer responsible for network access policy and firewall configuration. | | `CC6.6` | Implement logical access security measures to protect against threats from sources outside system boundaries | `Satisfies` | Agent log (raw events); Console Identity Intelligence → Brute Force Detection | eBPF-based authentication event capture records every login attempt with source IP, method, and timestamp. Brute force and targeted attack detection surface external threat patterns. | | `CC6.7` | Restrict transmission, movement, and removal of information to authorized users | `Out of scope` | n/a | Data loss prevention and information transmission controls are not addressed by LinuxGuard. | | `CC6.8` | Implement controls to prevent or detect and act upon the introduction of unauthorized or malicious software | `Supports` | Console Zero Trust Enforcement → Config Drift; Agent log (raw events) | File monitoring detects unauthorized modification of security-critical configuration files. Customer responsible for anti-malware deployment, software allowlisting, and supply-chain controls. | | `CC7.1` | Use detection and monitoring procedures to identify changes that may introduce new vulnerabilities | `Supports` | Console Zero Trust Enforcement → Config Drift; Config Drift events on six baselines | Drift detection across SSH, SSHD, accounts, groups, sudo, and SSH keys surfaces configuration changes. Customer responsible for vulnerability scanning, patch management, and the broader change-control program. | | `CC7.2` | Monitor system components and the operation of controls for anomalies indicative of malicious acts | `Satisfies` | Agent log (raw events); Console Zero Trust Enforcement → Signals | eBPF-based behavioral telemetry pipeline monitors processes, file access, and authentication events continuously. Signal records surface in the Zero Trust Enforcement console. | | `CC7.3` | Evaluate security events to determine whether they could or have resulted in a failure of the entity to meet its objectives | `Satisfies` | Agent log (raw events); Console Zero Trust Enforcement → Signals; Console Audit pillar | Signal records with process attribution, identity context, and confidence levels (HIGH/MEDIUM/LOW) enable evaluation of security events against objectives. | | `CC7.4` | Respond to identified security incidents through a defined incident-response program | `Supports` | Console Active Response; Support bundle; Agent log (raw events) | Active response playbooks and support bundle collection provide technical incident response capability. Customer responsible for the incident response program, escalation paths, and post-incident review. | | `CC7.5` | Identify, develop, and implement activities to recover from identified security incidents | `Out of scope` | n/a | Recovery program development, disaster recovery planning, and business continuity are not addressed by LinuxGuard. | | `CC8.1` | Authorize, design, develop or acquire, configure, document, test, approve, and implement changes to infrastructure, data, software, and procedures | `Supports` | Console Zero Trust Enforcement → Config Drift; Console Audit pillar → SUDO execution audit | Drift detection and SUDO execution audit surface infrastructure and configuration changes. Customer responsible for the change authorization workflow, change advisory board, and approval gates. | | `CC9.1` | Identify, select, and develop risk mitigation activities for risks arising from potential business disruptions | `Out of scope` | n/a | Business continuity risk identification and disaster recovery planning are not addressed by LinuxGuard. | | `CC9.2` | Assess and manage risks associated with vendors and business partners | `Out of scope` | n/a | Third-party risk management is not addressed by LinuxGuard. | | `A1.1` | Maintain processing capacity to meet system availability commitments | `Supports` | Console Infrastructure; Console Notifications on agent health | Agent health and console availability visibility support capacity monitoring. Customer responsible for capacity planning, autoscaling, and the broader availability program. | | `A1.2` | Authorize, design, develop, implement, operate, approve, maintain, and monitor environmental protections, software, data backup, and recovery infrastructure | `Out of scope` | n/a | Environmental protections, backup, and recovery infrastructure are not addressed by LinuxGuard. | | `PI1.1` | Obtain or generate, use, and communicate relevant, quality information regarding system processing objectives | `Supports` | Console Compliance Expansion → Reports; Console Audit pillar | LinuxGuard provides telemetry-driven evidence of system processing objectives. Customer responsible for defining processing objectives and the information-quality program. | | `PI1.4` | Implement policies and procedures to make available or deliver output completely, accurately, and timely | `Supports` | Console Zero Trust Enforcement → Config Drift | Drift detection surfaces unauthorized changes that could affect output integrity. Customer responsible for the application-layer output validation. | | `C1.1` | Identify and maintain confidential information to meet confidentiality commitments | `Out of scope` | n/a | Information classification and confidentiality program administration are not addressed by LinuxGuard. | | `C1.2` | Dispose of confidential information to meet confidentiality commitments | `Out of scope` | n/a | Information disposal and sanitization are not addressed by LinuxGuard. | | `P1.1 - P8.1` | Privacy criteria — notice, choice, collection, use/retention/disposal, access, disclosure, quality, monitoring | `Out of scope` | n/a | Privacy criteria are not addressed by LinuxGuard. The agent does not process personal data on customer's behalf — operational metadata (hostnames, IPs, usernames, paths) is collected for security monitoring purposes. | | `CC1.x` | Control environment — management governance, board oversight, organizational structure, commitment to integrity | `Out of scope` | n/a | Management-level governance controls are organizational responsibilities not addressed by LinuxGuard. | | `CC2.x` | Communication and information — internal and external communication of objectives and responsibilities | `Out of scope` | n/a | Communication program controls are organizational responsibilities not addressed by LinuxGuard. | | `CC3.x` | Risk assessment — specify objectives, identify and analyze risk, assess fraud risk | `Out of scope` | n/a | Risk assessment program controls are organizational responsibilities not addressed by LinuxGuard. | | `CC4.x` | Monitoring activities — ongoing and separate evaluations | `Supports` | Console Compliance Expansion → History; Console Compliance Expansion → Reports | LinuxGuard provides the technical evidence base for monitoring activities. Customer responsible for the monitoring program design and management evaluation. | | `CC5.x` | Control activities — selection and development of control activities, technology general controls, policies and procedures | `Supports` | Console Compliance Expansion → control detail | LinuxGuard provides telemetry-driven evidence of control activity operating effectiveness. Customer responsible for control design, policy administration, and procedure documentation. | > **Important**: Every Satisfies claim cites a specific agent feature and a specific evidence pointer. Every Supports claim states what the customer must implement to achieve full satisfaction. Every Out-of-scope row carries a one-line note explaining why — silence is interpreted as an implicit Satisfies claim. ## How to share with auditor Three export paths are available, depending on the CPA's evidence preference: * **Console Compliance Expansion reports.** Console pillar → Compliance Expansion → Reports produces dated, signed, auditor-shareable evidence packages (PDF / CSV / JSON) per [Compliance Expansion](/concepts/concepts/console/compliance-expansion.md#reports). Each report includes the framework version (SOC 2 TSC 2017 rev 2022), last-verified date, per-control coverage, per-server pass / fail breakdown, suppressions in effect, and a manifest with SHA-256 verification. For a Type II engagement, generate reports across the audit period to demonstrate operating effectiveness. * **Support bundles for host-level evidence.** `support-bundle collect` on each host produces a tar.zst archive with agent logs, redacted configuration, and a bundle manifest — see [Support Bundles](/operate/operate/support-bundles.md). Bundles are useful when the CPA wants raw host-level telemetry rather than a console-rendered report. * **Console CSV / JSON export per control.** Compliance Expansion → SOC 2 → control detail → Evidence tab exports per-control evidence in machine-readable form for CPAs who want to ingest evidence into their own GRC tooling. > **Security Note**: Support bundles include the raw `agent.log` and rotated segments. Attribute-key redaction (api\_key / \*\_token / \*\_secret) is applied; PII (hostnames, IPs, usernames, paths, command args) is NOT additionally redacted. Review every evidence package before sharing externally. See [Support Bundles](/operate/operate/support-bundles.md) for the per-file redaction status table. ## Cross-references * [**Audit & Comply**](/audit-and-comply/audit-comply.md) — vocabulary contract, framework version pin reference, forbidden-words list, scope statement template. * [**Compliance Expansion**](/concepts/concepts/console/compliance-expansion.md) — console pillar; canonical Evidence Location pointer set. * [**Audit**](/concepts/concepts/console/audit.md) — authorizations and SUDO execution audit feeding compliance evidence. * [**Support Bundles**](/operate/operate/support-bundles.md) — per-file redaction status table; pre-share PII warning. * [**Log Management**](/operate/operate/log-management.md) — log retention and rotation relevant to Type II audit-period evidence. * [**Glossary**](/reference/reference/glossary.md) — framework acronyms and compliance vocabulary definitions. *** *Last reviewed: 2026-05-31 against SOC 2 TSC 2017 (revised 2022) published 2022-12-15.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.linuxguard.io/audit-and-comply/audit-comply/soc2.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.