SOC 2 audits aren’t hard because the controls are complicated. They’re hard because the evidence is scattered. Access reviews live in your identity provider. Encryption details are buried in infrastructure configs. Vendor risk assessments sit in spreadsheets. Incident response procedures exist in a wiki that hasn’t been updated since the last audit. Audit logs are in a database, but nobody’s aggregated them into the format your auditor wants.
Every quarter, someone spends days pulling data from six different systems, formatting it into a report, and hoping nothing changed since the last time they checked.
JieGou’s SOC 2 evidence aggregator eliminates that work. One API call returns a structured report covering six evidence sections — parallel-fetched from live platform data, cached for performance, and designed to fail gracefully if any section is temporarily unavailable.
The report structure
A single GET /api/soc2-evidence?accountId=X returns the full report. It contains nine sections organized around the evidence categories SOC 2 auditors care about:
| Section | What it contains | Source |
|---|---|---|
| Access Review | Per-user roles, permissions, department assignments, resource access counts, last activity | Governance module + permissions engine |
| Security Metrics | Failed auth attempts, blocked IPs, API key health, usage spike alerts | Security analytics |
| Encryption Inventory | 10 encryption controls with algorithms, key sizes, scope, and management details | Static catalog |
| Vendor Register | 11 third-party vendors with risk levels, certifications, and data access classifications | Static catalog |
| Incident Response | 6 procedures across 4 phases with severity definitions, SLAs, and step-by-step runbooks | Static catalog |
| Compliance Config | Active compliance frameworks, data residency rules, PII detection settings | Account configuration |
| Data Residency | Per-category residency modes (local only, cloud sync, cloud redacted) | Account configuration |
| Retention Policy | Audit log retention period and configuration | Account configuration |
| Audit Log Summary | 30-day event count, action breakdown, top 10 actors by activity | Firestore audit_logs |
The report is versioned (1.0.0) and timestamped. Every section includes its own generatedAt timestamp so auditors can see exactly when each piece of evidence was collected.
Access review
The access review section is the one auditors spend the most time on. JieGou generates it automatically from live platform data.
For every user in your account:
- Identity — email, display name, user ID
- Role — global role (Owner, Admin, Dept Lead, Member, Auditor, Viewer) with numeric level
- Departments — which departments the user belongs to
- Permissions — the full list of granular permissions their role grants (26 permissions across 8 categories)
- Resource access — count of recipes and workflows accessible to this user
- Last active — timestamp of the user’s most recent activity
The report also includes role distribution — how many users at each role level — so auditors can verify that privilege allocation follows the principle of least privilege.
API key summary rounds out the access review: total keys, which LLM providers are configured, and per-key details (provider, validity status, age). Auditors can verify that no stale or orphaned keys exist without digging through a separate key management console.
Encryption inventory
SOC 2 Trust Services Criteria CC6.1 requires organizations to document their encryption controls. JieGou’s encryption inventory catalogs 10 controls covering data at rest and in transit:
| Control | Algorithm | Scope |
|---|---|---|
| BYOK Key Encryption | AES-256-GCM | Customer API keys stored in Firestore |
| Firestore Data at Rest | AES-256 | All Firestore collections |
| Session Cookie Signing | RS256 (JWT) | Firebase Auth session cookies |
| Password Storage | bcrypt / scrypt | User password hashes |
| TLS — Istio Gateway | TLS 1.3 | All HTTPS traffic to *.jiegou.ai |
| TLS — Firebase Services | TLS 1.3 | Firestore & Auth API traffic |
| TLS — Redis Cluster | TLS 1.2+ | Redis cache connections |
| Document Freshness Hash | SHA-256 | URL document change detection |
| Session Cache Key Hash | SHA-256 | Redis session cache keys |
| Container Image Verification | SHA-256 | Docker image digests in ECR |
Each control includes the key size, who manages it (JieGou, Google Cloud, AWS, Firebase), the source module in the codebase, and whether it covers data at rest, in transit, or both. This isn’t a marketing claim — it’s a machine-readable inventory that maps directly to your infrastructure.
Vendor register
Third-party vendor management is a SOC 2 requirement. JieGou’s vendor register catalogs 11 vendors with structured risk assessments:
For each vendor:
- Risk level — critical, high, medium, or low
- SOC 2 certification status — whether the vendor holds SOC 2 Type II
- Other certifications — ISO 27001, FedRAMP, PCI DSS, HIPAA, and others
- Data access — what data the vendor can access and process
- Mitigations — specific controls that reduce risk for this vendor
- Review schedule — last review date and next review date
Vendors range from critical (GCP, AWS, Firebase Auth — they host your data) to medium (Resend for email, Redis for caching). LLM providers (Anthropic, OpenAI, Google AI) are classified as high — they process customer prompts transiently, but BYOK support and no-training policies mitigate the risk.
The register includes vendor-specific mitigations, not generic statements. For Stripe: “PCI DSS Level 1 certified — card data never touches JieGou servers.” For Redis: “Cache-only mode (persistence disabled) — no PVs.” These are the details auditors look for.
Incident response runbook
SOC 2 CC7.3 and CC7.4 require documented incident response procedures. The runbook includes 6 procedures across 4 phases:
Phase 1: Detection & Triage (all severities) — Confirm the alert, classify severity P1-P4, create an incident channel, preserve initial evidence.
Phase 2: Containment — Three severity-specific procedures:
- Data Breach (P1) — Identify affected accounts, disable compromised users, rotate API keys, flush session caches, preserve audit logs, notify customers within 72 hours per GDPR
- Unauthorized Access (P1) — Revoke sessions, disable accounts, check IP blocking, run access review, investigate lateral movement
- Service Outage (P2) — Check circuit breakers, failover to alternate LLM providers, verify Redis fail-open, post customer status updates
Phase 3: Eradication & Recovery (P1-P3) — Root cause analysis, fix deployment, production verification, service restoration.
Phase 4: Post-Mortem (P1-P2) — Blameless review within 48 hours, incident timeline compilation, corrective action tracking.
Each procedure step includes the responsible party (On-call Engineer, Security Lead, Infrastructure Engineer), SLA in minutes, specific tools to use (not generic categories — actual module names and commands), and escalation triggers for when the situation worsens.
Severity definitions have explicit response time SLAs: P1 Critical at 15 minutes, P2 High at 1 hour, P3 Medium at 4 hours, P4 Low at 24 hours.
Audit log summary
The audit log summary aggregates the last 30 days of activity into two views:
Action breakdown — counts per action type. How many recipe executions, workflow runs, role changes, API key operations, configuration updates, and other auditable events occurred in the period. This tells auditors what’s happening on the platform and whether activity patterns look normal.
Top actors — the 10 most active users by event count. Auditors use this to verify that high-activity accounts correspond to expected users (automation service accounts, power users) rather than anomalous behavior.
The summary is capped at 1,000 events for performance. For accounts with higher volumes, the raw audit log is always available through the governance module.
How it’s built
The evidence report is generated by parallel-fetching all nine sections simultaneously using Promise.all. Six sections come from live queries (access review, security metrics, compliance config, data residency, retention policy, audit log summary). Three are static catalogs (encryption inventory, vendor register, incident response runbook).
Fail-open design. Each dynamic section is wrapped in a .catch() handler. If the security metrics service is temporarily unavailable, the report still returns with the other eight sections populated and the failed section filled with safe defaults. The report always returns — it never fails entirely because one subsystem is slow.
Redis caching. The full report is cached for 5 minutes. During an audit, multiple team members may pull the same report repeatedly. Caching prevents redundant Firestore queries and keeps response times consistent.
Section-level access. You don’t always need the full report. Append ?section=access-review to get just the access review, or ?section=encryption-inventory for just the encryption catalog. Six sections are individually addressable: access-review, security-metrics, encryption-inventory, vendor-register, incident-response, audit-log-summary.
Permission model
The endpoint requires the audit:read permission, which maps to the Auditor role (level 15) or above. This means:
- Auditor, Dept Lead, Admin, Owner — can pull the report
- Member, Viewer — cannot access it
This aligns with the principle of least privilege. Your compliance team can generate evidence without needing admin access. Your engineering team members, who can run workflows and edit recipes, don’t get visibility into the security posture report unless their role warrants it.
Availability
SOC 2 evidence collection is available on Enterprise plans. Includes the full evidence report API, individual section access, access reviews, encryption inventory, vendor register, incident response runbook, and audit log summaries. Learn more about enterprise features or start a trial.