SOC 2 and End-of-Life Open Source: How Auditors Are Evaluating Runtime Risk

SOC 2 and the Software Lifecycle

SOC 2 audits evaluate controls against the AICPA's Trust Services Criteria (TSC). Unlike PCI DSS or HIPAA, the TSC is principles-based rather than prescriptive: it defines what outcomes your control environment must achieve without specifying exactly how. This gives SOC 2 auditors significant discretion in assessing whether your specific implementation satisfies the criteria — and it means that the conversation about EOL software often comes down to how well you can document and explain your risk management posture.

Over the past two years, we have seen a consistent shift in how examiners approach CC7.1 (security monitoring) and CC8.1 (change management). Questions about software component lifecycle states and vulnerability management timelines are now standard in SOC 2 fieldwork, not exceptions.

The Relevant Trust Services Criteria

CC7.1: Detection of and Response to Security Events

CC7.1 requires that the entity uses detection and monitoring procedures to identify security events, evaluates those events, and responds to identified vulnerabilities and incidents. For EOL software, the examiner will ask: when a new CVE is disclosed against an EOL component you're running, what is your detection process, and what is your response? If the answer is "we learn about it eventually and evaluate whether we need to act," that is a weak control narrative. If the answer is "we receive CVE notifications from OSSeva within 24 hours of disclosure, evaluate CVSS score against our risk matrix, and require critical vulnerabilities to be patched within 72 hours per our documented SLA," that is a strong one.

CC8.1: Change Management

CC8.1 addresses infrastructure and system changes, including software updates and patches. For EOL components that have no upstream patches, the change management question becomes: how do you manage the absence of patches? The control needs to document that you have a defined process for evaluating vulnerability risk in EOL components, applying compensating controls or third-party patches, and escalating to risk acceptance when neither is available.

A1.2: Capacity and Performance

Less commonly cited but increasingly relevant: the Availability criteria include a requirement to manage capacity and performance and to address environmental, regulatory, and other threats. EOL software that carries unpatched vulnerabilities in its core processing path creates availability risk — not just security risk — and examiners reviewing high-availability claims will ask about the runtime's patch status.

What the Evidence Package Needs to Show

A SOC 2 evidence package for EOL OSS components should include the following for each covered period:

• A current inventory of all software components and their support status, including EOL date for EOL components.
• Vulnerability scan results showing CVEs identified against EOL components.
• For each identified CVE: the date detected, the risk assessment (CVSS score, exploitability given deployment context), and the remediation action taken (patch applied, compensating control implemented, or formal risk acceptance).
• Patch deployment records showing that patches were applied within the control's defined timeline.
• A roadmap to remediating EOL components, with target dates and owners.

The Risk Acceptance Alternative

For components where patching is not yet possible (waiting for a migration, dependencies not yet resolved), SOC 2 allows for documented risk acceptance as a valid control response — provided the risk acceptance is formal, time-bounded, and reviewed by appropriate management. An informal "we know about it" does not satisfy the criteria; a signed risk acceptance with a review date and documented compensating controls does.

Conclusion

SOC 2 is not a blocker for organisations running EOL OSS components — but it requires those organisations to have a documented, systematic risk management approach that examiners can evaluate and rely on. The organisations that fail on this point typically have good technical awareness of their EOL risk but have not translated that awareness into the formal documentation and process evidence that SOC 2 requires.