Skip to content

SOC 2 Evidence

BreachSpider supports SOC 2 Type II evidence collection for organizations that need to demonstrate their security posture to customers, partners, or insurers. While BreachSpider is not a SOC 2 compliance platform, its audit log and vulnerability management workflow generate evidence that maps directly to several SOC 2 Common Criteria.

SOC 2 Overview

SOC 2 (Service Organization Control 2) is an auditing framework developed by the AICPA. It evaluates an organization's controls across five Trust Services Criteria:

  1. Security (required)
  2. Availability
  3. Processing Integrity
  4. Confidentiality
  5. Privacy

BreachSpider evidence primarily supports the Security and Availability criteria.

Common Criteria (CC) Mapping

CC6.1 - Logical Access Controls

Requirement: The entity implements logical access security controls to protect against unauthorized access.

BreachSpider evidence:

  • LOGIN and LOGOUT events in the audit log demonstrate authentication tracking.
  • SESSION_REVOKED events show session management and forced logout capability.
  • API_KEY_CREATED and API_KEY_REVOKED events demonstrate credential lifecycle management.
  • Magic-link authentication (no passwords stored) provides evidence of secure authentication design.
  • Role-based access (admin vs member) demonstrates authorization controls.

Export: Filter audit log to LOGIN, LOGOUT, SESSION_REVOKED, API_KEY_CREATED, API_KEY_REVOKED.

CC6.2 - New User Provisioning

Requirement: The entity registers and provisions new users and manages their access.

BreachSpider evidence:

  • MEMBER_INVITED events document when new users were added, by whom, and what role they were assigned.
  • Each invitation includes the inviting actor (who authorized access) and the new member's email and role.

Export: Filter audit log to MEMBER_INVITED.

CC6.3 - Access Removal

Requirement: The entity deregisters and deprovisions users when access is no longer needed.

BreachSpider evidence:

  • MEMBER_REMOVED events document when users were removed, by whom, and when.
  • SESSION_REVOKED events demonstrate immediate access revocation capability.
  • API_KEY_REVOKED events show credential deactivation.

Export: Filter audit log to MEMBER_REMOVED, SESSION_REVOKED, API_KEY_REVOKED.

CC7.1 - Threat Detection

Requirement: The entity detects and monitors for security events.

BreachSpider evidence:

  • CVE monitoring across 354,000+ vulnerabilities with 15-minute KEV ingestion demonstrates continuous threat detection.
  • Alert configurations (email, Teams, Slack, webhooks) demonstrate monitoring infrastructure.
  • ALERT_RULE_CREATED events show that monitoring rules are actively maintained.
  • WEBHOOK_FIRED events demonstrate that alert delivery is operational.

Export: Filter audit log to ALERT_RULE_CREATED, ALERT_RULE_CHANGED, WEBHOOK_FIRED.

CC7.2 - Monitoring for Anomalies

Requirement: The entity monitors system components for anomalies.

BreachSpider evidence:

  • EPSS-based prioritization demonstrates automated anomaly detection in the vulnerability landscape (EPSS spikes indicate emerging exploitation activity).
  • Watchlist alerts demonstrate targeted monitoring for specific threats.
  • BCS score changes demonstrate dynamic risk assessment that responds to new intelligence.

CC7.3 - Response to Security Events

Requirement: The entity responds to identified security events.

BreachSpider evidence:

  • FINDING_ACKNOWLEDGED events demonstrate systematic response to identified vulnerabilities.
  • TICKET_CREATED events demonstrate initiation of remediation actions.
  • TICKET_CLOSED events demonstrate completion of remediation.
  • The full triage chain (finding > ticket > close > acknowledge) demonstrates an end-to-end response process.

Export: Filter audit log to FINDING_ACKNOWLEDGED, TICKET_CREATED, TICKET_CLOSED.

Availability Criteria (A1)

A1.1 - Processing Capacity

BreachSpider evidence:

  • Health endpoint (GET /api/v1/health) returns real-time status of the platform including database connectivity, pipeline status, and processing times. Monitoring this endpoint demonstrates availability oversight.
  • Pipeline status data shows the health and freshness of CVE ingestion, matching, and alert delivery.

What to Export for SOC 2 Readiness

For a SOC 2 readiness assessment or Type II audit, export the following from the BreachSpider audit log:

  1. 90-day audit log export (CSV or PDF), filtered to:

    • Authentication events: LOGIN, LOGOUT, SESSION_REVOKED
    • Credential management: API_KEY_CREATED, API_KEY_REVOKED
    • User lifecycle: MEMBER_INVITED, MEMBER_REMOVED, ROLE_CHANGED
    • Vulnerability response: FINDING_ACKNOWLEDGED, TICKET_CREATED, TICKET_CLOSED
    • Monitoring: ALERT_RULE_CREATED, WEBHOOK_FIRED
    • Reporting: REPORT_GENERATED

  2. This export demonstrates:

    • Access controls are enforced and logged (CC6.1, CC6.2, CC6.3).
    • Threats are detected and monitored (CC7.1, CC7.2).
    • Security events receive documented responses (CC7.3).
    • Continuous monitoring is operational.

  3. Include the export alongside your evidence from other tools (Vanta, Drata, Secureframe, or manual evidence collection).

Important Note

BreachSpider is one data source in a comprehensive SOC 2 compliance program. The audit log evidence described above supports specific Common Criteria, but SOC 2 compliance requires controls across your entire technology stack, organizational processes, HR practices, and vendor management. Work with your SOC 2 auditor to determine which BreachSpider evidence is applicable to your specific scope.