Skip to content

SOC 2 Type I Readiness Assessment

Organization: ZKProva System: ZKP-Powered Portable Credit Union Identity Domain: https://zkprova.com/ Assessment Date: 2026-02-22 Document Version: 1.4 Classification: Confidential

Table of Contents

  1. Executive Summary
  2. System Description
  3. Security Architecture Overview
  4. SOC 2 Trust Service Criteria Mapping
  5. Security (CC1-CC9)
  6. Availability (A1)
  7. Confidentiality (C1)
  8. Processing Integrity (PI1)
  9. Privacy (P1-P8)
  10. Access Control Policies
  11. Encryption & Key Management
  12. Audit Logging Coverage
  13. Data Retention & Deletion Procedures
  14. Incident Response Plan
  15. Change Management Process
  16. Vulnerability Management
  17. Business Continuity
  18. Known Gaps & Remediation Roadmap

Executive Summary

ZKProva provides a zero-knowledge-proof-powered portable identity system for credit union members, initially targeting Demo Credit Union (Demo CU) and its millions of members. The system allows members to prove credit union membership and selected claims (e.g., creditworthiness, account standing) to third-party lenders without revealing underlying personal data, using Groth16 ZK-SNARKs.

This document assesses ZKProva's readiness against the AICPA SOC 2 Type I Trust Service Criteria. It describes the controls currently in place, identifies gaps, and provides a remediation roadmap toward a formal SOC 2 Type I audit.

System Description

Components

Component Technology Purpose
Backend API Python / FastAPI (uvicorn) Core business logic, credential issuance, verification
Database PostgreSQL Persistent storage for members, credentials, audit logs
Cache / Rate Limiting Redis Session caching, sliding-window rate limiting
Frontend Next.js v15 Member and lender web interfaces
Cryptographic Engine Groth16 ZK-SNARKs, Poseidon hash, Ed25519 ZKP generation/verification, credential signing
Orchestration Kubernetes (Helm charts) Container orchestration, autoscaling
CI/CD GitHub Actions Automated lint, test, build, deploy pipelines
Monitoring Prometheus, Sentry Metrics collection, error tracking
Secrets Management Abstraction layer (env vars, AWS Secrets Manager, HashiCorp Vault) Secure secret storage and rotation

Data Flow Summary

  1. Credit union issues a W3C Verifiable Credential to a member, signed with Ed25519 and encrypted at rest with AES-256-GCM.
  2. Member generates a ZK proof (Groth16) selecting only the claims they wish to disclose.
  3. Lender verifies the proof cryptographically without accessing the underlying personal data.
  4. All operations are logged to the append-only audit_logs table.

Trust Boundary

  • Members authenticate via JWT tokens with bcrypt-hashed passwords.
  • Lenders authenticate via API keys with RBAC-enforced permissions.
  • Admin users have elevated privileges governed by role-based access controls.
  • All external communication is over TLS 1.2+.

Security Architecture Overview

Network Layer

  • All ingress traffic is routed through Kubernetes Ingress controllers with TLS termination.
  • Security headers enforced on all HTTP responses:
  • Strict-Transport-Security (HSTS) with a minimum max-age of 31536000 seconds.
  • Content-Security-Policy (CSP) restricting inline scripts and external resource loading.
  • X-Frame-Options: DENY preventing clickjacking.
  • X-Content-Type-Options: nosniff preventing MIME-type sniffing.

Application Layer

  • Authentication: JWT bearer tokens for members; API keys for lender integrations.
  • Authorization: Role-based access control (RBAC) with three roles: member, lender, admin. Verifier type-based claim filtering restricts which data fields each lender can request.
  • Rate Limiting: Tiered sliding-window rate limiting via Redis:
  • Free tier: conservative limits.
  • Standard tier: moderate limits.
  • Enterprise tier: elevated limits with burst capacity.
  • Input Validation: Request validation via Pydantic models on all API endpoints.
  • Webhook Security: Outbound webhook payloads signed with HMAC-SHA256 for integrity verification by receivers.

Cryptographic Layer

  • ZK-SNARKs: Groth16 proving system for zero-knowledge membership and claim proofs.
  • Hashing: Poseidon hash function (ZK-friendly) for circuit inputs.
  • Signatures: Ed25519 for W3C Verifiable Credential signing (DID:key method).
  • Encryption at Rest: AES-256-GCM for credential data stored in PostgreSQL.
  • Password Storage: bcrypt with appropriate cost factor.

Observability

  • Structured Logging: JSON-formatted logs via structlog with correlation IDs for request tracing.
  • Metrics: Prometheus metrics exposed at /metrics for scraping (request latency, error rates, ZKP generation time, active connections).
  • Error Tracking: Sentry integration for real-time exception alerting and triage.
  • Health Checks: Kubernetes startup, readiness, and liveness probes for each service.

SOC 2 Trust Service Criteria Mapping

Security (CC1-CC9)

CC1 -- Control Environment

Control Implementation Status
CC1.1 -- Commitment to integrity and ethical values Engineering team follows documented coding standards; PR review required for all changes. Partial -- Formal code of conduct document needed.
CC1.2 -- Board/management oversight Founding team reviews security posture quarterly. Partial -- Formal governance board and charter needed.
CC1.3 -- Organizational structure RBAC roles (member, lender, admin) with least-privilege defaults. Implemented
CC1.4 -- Commitment to competence Engineering team has cryptography and security expertise. Partial -- Formal training program needed.
CC1.5 -- Accountability Audit logs track all sensitive operations with user attribution. Implemented

CC2 -- Communication and Information

Control Implementation Status
CC2.1 -- Internal communication of security policies Security policies consolidated in a centralized MkDocs Material documentation site with full-text search, organized navigation by audience (API, Compliance, Operations), and CI-enforced build validation. Implemented
CC2.2 -- External communication Privacy policy published at zkprova.com; SECURITY.md and .well-known/security.txt published; webhook HMAC signatures validate data integrity in transit. Implemented
CC2.3 -- Communication of system changes CI/CD pipeline notifications; GitHub Actions status checks. Implemented

CC3 -- Risk Assessment

Control Implementation Status
CC3.1 -- Risk identification Cryptographic primitives selected based on formal security analysis (Groth16, Ed25519, AES-256-GCM). Formal enterprise risk register with 10 identified risks, scoring methodology, heat map, and quarterly review cadence. Implemented — see Risk Register.
CC3.2 -- Fraud risk assessment Rate limiting prevents abuse; RBAC prevents unauthorized data access. Partial -- Formal fraud risk assessment document needed.
CC3.3 -- Change-related risk assessment PR reviews and CI test gates catch regressions. Partial -- Formal change risk scoring needed.
CC3.4 -- Risk mitigation strategies ZKP architecture inherently minimizes data exposure; AES-256-GCM encryption at rest. Implemented

CC4 -- Monitoring Activities

Control Implementation Status
CC4.1 -- Ongoing monitoring Prometheus metrics, Sentry error tracking, structured logging with correlation IDs. Implemented
CC4.2 -- Deficiency evaluation Sentry alerts routed to engineering; GitHub Issues for tracking. Partial -- Formal deficiency tracking and escalation process needed.

CC5 -- Control Activities

Control Implementation Status
CC5.1 -- Selection of control activities Security controls selected based on system architecture (ZKP, encryption, RBAC). Implemented
CC5.2 -- Technology-based controls JWT authentication, API key validation, rate limiting, input validation (Pydantic), security headers. Implemented
CC5.3 -- Policy-based controls RBAC enforcement, verifier type-based claim filtering, tiered rate limits. Implemented

CC6 -- Logical and Physical Access Controls

Control Implementation Status
CC6.1 -- Logical access security JWT tokens for members, API keys for lenders, bcrypt password hashing. Implemented
CC6.2 -- User provisioning Member self-registration; lender accounts provisioned by admin with specific API keys. Implemented
CC6.3 -- User deprovisioning API key revocation supported; JWT token expiration enforced. Implemented
CC6.4 -- Restricted access to information assets RBAC roles restrict endpoints; verifier type-based claim filtering limits data exposure. Implemented
CC6.5 -- Restriction of physical access Cloud-hosted infrastructure; physical access managed by cloud provider (AWS/GCP). Delegated to IaaS provider
CC6.6 -- Management of credentials Secrets management abstraction layer supporting AWS Secrets Manager and HashiCorp Vault; bcrypt for passwords. Formal key rotation procedures with schedules, zero-downtime procedures, and audit trail requirements. Implemented — see Key Rotation Procedures.
CC6.7 -- Restriction on changes to system GitHub branch protection; CI/CD manual approval gate for production deploys. Implemented
CC6.8 -- Malicious software prevention Container images scanned via Trivy in CI (fail on critical/high CVEs); gitleaks secret scanning; Dependabot dependency monitoring; minimal base images. Implemented

CC7 -- System Operations

Control Implementation Status
CC7.1 -- Detection of anomalies Prometheus alerting rules; Sentry error tracking; structured log analysis. Semgrep SAST in CI detects code-level vulnerabilities; OWASP ZAP DAST in staging validates runtime security posture. Implemented
CC7.2 -- Incident management Engineering team responds to alerts; Sentry triage workflow. Formal incident response plan documented with severity levels (P0–P3), roles (IC, Engineering Lead, Communications Lead), escalation path, communication templates, and tabletop scenarios. Implemented — see Incident Response Plan.
CC7.3 -- Recovery from incidents Kubernetes self-healing (liveness probes, HPA autoscaling); database backups. Partial -- Formal disaster recovery runbook needed.
CC7.4 -- Communication of incidents Sentry notifications to team channels. Formal communication templates for internal escalation, customer notification, and post-mortem reports documented. Implemented — see Incident Response Plan.

CC8 -- Change Management

Control Implementation Status
CC8.1 -- Change authorization GitHub PRs with required reviews; CI/CD manual approval gate for production. Semgrep SAST scan gates all PRs; OWASP ZAP DAST validates staging before production promotion. Implemented

CC9 -- Risk Mitigation

Control Implementation Status
CC9.1 -- Risk mitigation through system design ZKP architecture provides data minimization by design; lenders never see raw member data. Implemented
CC9.2 -- Vendor risk management Dependencies managed via lockfiles; cloud provider SOC 2 reports leveraged. Partial -- Formal vendor risk assessment process needed.

Availability (A1)

Control Implementation Status
A1.1 -- System availability objectives Kubernetes HPA autoscaling; readiness and liveness probes ensure unhealthy pods are replaced. Partial -- Formal SLA document needed.
A1.2 -- Environmental protections Cloud provider manages physical infrastructure (power, cooling, fire suppression). Delegated to IaaS provider
A1.3 -- Recovery from disruptions Kubernetes self-healing; Redis used for ephemeral state only; PostgreSQL with automated backups. Formal BCP with per-component RPO/RTO targets, failover procedures, dependency map, and DR drill cadence. Implemented — see Business Continuity Plan.

Confidentiality (C1)

Control Implementation Status
C1.1 -- Identification of confidential information Credentials encrypted with AES-256-GCM at rest; ZKP proofs reveal only selected claims. Implemented
C1.2 -- Disposal of confidential information Automated cleanup of expired QR tokens, old verification logs, and expired credentials via scheduled retention jobs. Implemented

Processing Integrity (PI1)

Control Implementation Status
PI1.1 -- Completeness and accuracy of processing Groth16 proof verification provides mathematical certainty of claim validity; Pydantic input validation; webhook HMAC-SHA256 signatures ensure payload integrity. Implemented
PI1.2 -- Error detection Sentry error tracking; structured logging with correlation IDs for end-to-end request tracing. Implemented
PI1.3 -- Input validation Pydantic models enforce schema validation on all API inputs; type-based claim filtering restricts verifier requests. Implemented

Privacy (P1-P8)

Control Implementation Status
P1 -- Notice Privacy policy accessible via zkprova.com. Partial -- Privacy notice must detail all data practices.
P2 -- Choice and consent Members choose which claims to disclose in each ZKP; explicit consent model. Implemented (core architecture feature)
P3 -- Collection Only data necessary for credential issuance is collected; ZKP architecture minimizes data exposure. Implemented
P4 -- Use, retention, and disposal Automated data retention procedures clean up expired tokens, verification logs, and credentials. Implemented
P5 -- Access Members can view their own credentials and verification history. Implemented
P6 -- Disclosure to third parties ZKP ensures only selected claims (not raw data) are disclosed to lenders. Implemented (core architecture feature)
P7 -- Quality Credential data sourced directly from credit union systems of record. Implemented
P8 -- Monitoring and enforcement Audit logs capture all data access; RBAC enforces access boundaries. Partial -- Formal privacy breach notification process needed.

Access Control Policies

Authentication Mechanisms

User Type Authentication Method Token Lifetime Credential Storage
Member Username/password (bcrypt) -> JWT bearer token Configurable expiration bcrypt-hashed passwords in PostgreSQL
Lender API key in request header No expiration (revocable) Hashed API keys in PostgreSQL
Admin Username/password (bcrypt) -> JWT bearer token Short-lived expiration bcrypt-hashed passwords in PostgreSQL

Authorization Model

  • RBAC Roles:
  • member -- Can view own credentials, generate ZK proofs, view own verification history.
  • lender -- Can submit verification requests, receive ZK proof results (filtered by verifier type), manage webhook endpoints.

  • admin -- Can provision/revoke lender accounts, view system audit logs, manage system configuration.

  • Claim Filtering: Each lender (verifier) is assigned a verifier type that determines which credential claims they may request in a ZK proof. A lender configured for "basic membership verification" cannot request financial claims such as credit score or account balance.

Principle of Least Privilege

  • Default-deny on all API endpoints.
  • Role checked via middleware on every request.
  • Database credentials scoped per service (read replicas where applicable).

Encryption & Key Management

Encryption Standards

Context Algorithm Key Size Notes
Data at rest (credentials) AES-256-GCM 256-bit Authenticated encryption with associated data
Password storage bcrypt N/A (cost-factor based) Adaptive cost factor
Credential signing Ed25519 256-bit W3C Verifiable Credentials via DID:key
ZKP circuit hashing Poseidon Circuit-native ZK-friendly hash for circuit inputs
ZKP proving system Groth16 BN254 curve Succinct non-interactive proofs
Webhook payload signing HMAC-SHA256 256-bit Integrity verification for outbound webhooks
Transport TLS 1.2+ 2048-bit RSA / 256-bit ECDHE All external communication

Key Management

  • Secrets Abstraction Layer: The application uses a secrets management abstraction that supports multiple backends:
  • Environment variables (development).
  • AWS Secrets Manager (staging/production).
  • HashiCorp Vault (production alternative).
  • Key Rotation: Secrets manager backends support automated key rotation; application re-fetches secrets on rotation events.
  • Separation of Keys: Signing keys (Ed25519), encryption keys (AES-256-GCM), and API keys are stored and managed independently.

Formal Procedures

A comprehensive Key Rotation Procedures document has been published covering: - Complete key inventory with rotation schedules (JWT 90d, AES 180d, Ed25519 annual, TLS auto) - Zero-downtime rotation procedures with dual-accept windows - Application cache caveat (@lru_cache requires kubectl rollout restart) - Audit trail requirements (DB + structlog + CloudTrail)

Remaining Gap

  • HSM integration for Ed25519 signing keys is planned but not implemented (Gap #6, target Q3 2026).

Audit Logging Coverage

Audit Log Architecture

  • Storage: Append-only audit_logs table in PostgreSQL. Rows are insert-only; no UPDATE or DELETE operations are permitted on this table.
  • Format: Structured JSON via structlog with the following fields:
  • timestamp (ISO 8601, UTC)
  • correlation_id (UUID, links related log entries across a request lifecycle)
  • actor_id (user or service performing the action)
  • actor_role (member / lender / admin / system)
  • action (e.g., credential.issued, proof.generated, proof.verified, member.login, api_key.created)
  • resource_type and resource_id
  • ip_address
  • outcome (success / failure)
  • metadata (action-specific context; never contains raw secrets or PII)

Events Captured

Category Events
Authentication Login success, login failure, token refresh, token revocation
Credential Lifecycle Credential issuance, credential revocation, credential expiry
ZKP Operations Proof generation request, proof verification request, verification result
Admin Operations Lender account creation, API key issuance, API key revocation, role changes
Data Access Member data retrieval, verification log retrieval, audit log retrieval
System Events Rate limit exceeded, webhook delivery success/failure, scheduled cleanup execution

Log Retention

  • Audit logs are retained for a minimum of 7 years to meet financial services regulatory expectations.
  • Logs are indexed by timestamp, actor_id, action, and correlation_id for efficient querying.

Data Retention & Deletion Procedures

Automated Retention Policies

Data Type Retention Period Cleanup Mechanism
QR tokens (verification links) Short-lived (minutes to hours) Automated scheduled job deletes expired tokens
Verification logs Configurable (default: 90 days for detailed logs) Automated scheduled job archives and purges old entries
Expired credentials Removed after expiry + grace period Automated scheduled job deletes expired credential records
Audit logs 7 years minimum No automated deletion; archival to cold storage after 1 year
Member account data Until member requests deletion or account is deactivated Manual process triggered by member request

Deletion Procedures

  1. Automated Cleanup Jobs: Scheduled tasks run at defined intervals to identify and remove data that has exceeded its retention period.
  2. Member Data Deletion Requests: Upon receiving a deletion request, the system:
  3. Revokes all active credentials for the member.
  4. Deletes personal data from the members table.
  5. Retains anonymized audit log entries (actor_id replaced with a tombstone identifier) to maintain audit trail integrity.
  6. Lender Offboarding: When a lender is decommissioned:
  7. API keys are revoked.
  8. Webhook configurations are removed.
  9. Verification request history is retained in audit logs with anonymized lender references.

Incident Response Plan

Severity Levels

Level Definition Response Time Examples
SEV-1 (Critical) System-wide outage or confirmed data breach 15 minutes Database compromise, credential signing key leak
SEV-2 (High) Significant degradation or potential security event 1 hour API unavailability, unusual access patterns
SEV-3 (Medium) Limited impact, no data exposure 4 hours Single endpoint errors, non-critical dependency failure
SEV-4 (Low) Cosmetic or minor issue 24 hours UI rendering issues, non-critical log anomalies

Incident Response Phases

  1. Detection: Prometheus alerting rules, Sentry error notifications, and anomaly detection in structured logs trigger incident identification.
  2. Triage: On-call engineer assesses severity using the classification matrix above.
  3. Containment:
  4. API keys can be revoked immediately.
  5. Rate limits can be tightened dynamically.
  6. Kubernetes pods can be drained or isolated.
  7. Database credentials can be rotated via the secrets management layer.
  8. Eradication: Root cause analysis using correlation IDs to trace the full request path; patching of identified vulnerabilities.
  9. Recovery: Kubernetes self-healing restores service; database restored from backups if needed.
  10. Post-Incident Review: Blameless post-mortem document created; findings fed into risk register and backlog.

Communication

  • Internal: Engineering team notified via Sentry and alerting channels.
  • External: Affected credit unions and lenders notified within 72 hours for incidents involving personal data (per GDPR/CCPA requirements if applicable).

Formal Plan

A comprehensive Incident Response Plan has been documented covering: - Severity levels P0–P3 with response time SLAs (15 min – next business day) - Designated roles: Incident Commander, Engineering Lead, Communications Lead - Escalation path from CloudWatch/Sentry through PagerDuty to Slack #incidents - Three communication templates (internal escalation, customer notification, post-mortem) - Three tabletop scenarios (credential DB breach, complete outage, ZKP proof forgery)

Change Management Process

Development Workflow

  1. Feature Branch: Developer creates a branch from main for the change.
  2. Development: Code written with unit and integration tests.
  3. Pull Request: PR submitted on GitHub with:
  4. Description of the change and its purpose.
  5. Link to related issue or requirement.
  6. Test evidence (CI results).
  7. Code Review: At least one peer review required before merge.
  8. CI Pipeline (GitHub Actions):
  9. Linting (code style enforcement).
  10. Unit and integration tests.
  11. Build verification.
  12. Security scanning (dependency vulnerability checks).
  13. Merge to Main: Upon approval and passing CI, the PR is merged.
  14. Production Deploy: Manual approval gate in GitHub Actions required before deployment to production.

Deployment Process

  • Infrastructure as Code: Kubernetes manifests managed via Helm charts.
  • Rolling Deployments: Kubernetes performs rolling updates; readiness probes ensure traffic is only routed to healthy pods.
  • Rollback: Previous Helm release can be rolled back with a single command if issues are detected post-deploy.
  • Autoscaling: HPA (Horizontal Pod Autoscaler) adjusts replica count based on CPU/memory metrics.

Known Gap

  • Formal change advisory board (CAB) process for high-risk changes is not established.
  • Change classification (standard, normal, emergency) is not formally defined.

Vulnerability Management

Current Practices

Practice Implementation
Dependency scanning Dependabot monitors Python (pip) and JavaScript (npm) dependencies weekly; CI pipeline checks for known CVEs
Container image scanning Trivy scans backend and frontend Docker images in CI; fails on critical/high CVEs (#65)
Secret scanning Gitleaks runs in CI on every push to detect leaked credentials (#66)
Input validation Pydantic models enforce strict schema validation on all API inputs
Rate limiting Tiered sliding-window rate limiting prevents brute-force and abuse
Security headers HSTS, CSP, X-Frame-Options, X-Content-Type-Options on all responses
SAST (Static Analysis) Semgrep runs in CI on every push/PR with OWASP Top 10, Python, JavaScript, and security-audit rulesets; findings uploaded to GitHub Code Scanning (#103)
DAST (Dynamic Analysis) OWASP ZAP API scan runs against staging after every deploy using auto-generated OpenAPI spec; false-positive suppression via .zap/rules.tsv (#103)
Secrets management No secrets in source code; secrets fetched from AWS Secrets Manager or Vault at runtime

Vulnerability Response Process

  1. Identification: Vulnerabilities identified via CI scanning, security advisories, or external reports.
  2. Assessment: Severity rated using CVSS scoring.
  3. Remediation:
  4. Critical/High: Patched within 48 hours.
  5. Medium: Patched within 2 weeks.
  6. Low: Patched in next regular release cycle.
  7. Verification: Fix verified via CI pipeline and targeted testing.

Known Gap

  • Formal penetration testing program in progress — scope document prepared, firm selection underway (#67).
  • Responsible disclosure policy published (SECURITY.md, security.txt); private bug bounty program planned (#70).
  • ~~No SAST (Static Application Security Testing) tool integrated beyond linting.~~ — Semgrep SAST integrated in CI (#103).
  • ~~No DAST (Dynamic Application Security Testing) tool in pipeline.~~ — OWASP ZAP DAST integrated in staging deploy pipeline (#103).

Business Continuity

Infrastructure Resilience

Mechanism Implementation
Container orchestration Kubernetes with HPA autoscaling adjusts capacity based on load
Health checks Startup, readiness, and liveness probes detect and replace unhealthy pods
Database backups PostgreSQL automated backups (frequency and retention TBD for formal BCP)
Stateless application tier Application state stored in PostgreSQL and Redis; pods are disposable
Redis resilience Redis used for ephemeral data (rate limit counters, session cache); loss is non-catastrophic
Multi-AZ deployment Cloud provider multi-availability-zone deployment (if configured)

Recovery Objectives

Metric Target Status
Recovery Time Objective (RTO) < 1 hour Informal target -- formal documentation needed
Recovery Point Objective (RPO) < 1 hour (database backup frequency) Informal target -- formal documentation needed

Formal Plan

A comprehensive Business Continuity Plan has been documented covering: - Per-component RPO/RTO targets (RDS 24h/30min, ElastiCache 0/5min, EKS 0/15min, Secrets 0/10min) - Failover procedures for RDS Multi-AZ, AZ failure, EKS node exhaustion, and Secrets Manager outage - External dependency map with failure impacts and mitigations - Testing cadence: weekly RDS restore, quarterly DR drill, annual BCP tabletop - WAF emergency controls (block_all_traffic toggle)

Known Gaps & Remediation Roadmap

The following table summarizes all identified gaps and the planned remediation timeline.

# Gap SOC 2 Criteria Priority Target Completion
1 ~~Formal incident response plan with designated roles and communication templates~~ CC7.2, CC7.4 Critical Documented — Incident Response Plan
2 Annual penetration testing program CC4.1, CC7.1 Critical Q2 2026 (scope doc ready, firm selection in progress #67)
3 ~~Formal Business Continuity Plan and DR runbook~~ A1.3 Critical Documented — Business Continuity Plan
4 ~~Key rotation schedule and procedures document~~ CC6.6 High Documented — Key Rotation Procedures
5 ~~Formal risk register (enterprise-wide)~~ CC3.1 High Documented — Risk Register
6 HSM integration for Ed25519 signing keys CC6.6 High Q3 2026
7 Vendor risk assessment program CC9.2 High Q3 2026
8 ~~SAST/DAST integration in CI/CD pipeline~~ CC7.1, CC8.1 High Implemented — Semgrep SAST in CI + OWASP ZAP DAST in staging (#103)
9 ~~Formal RTO/RPO documentation~~ and DR testing A1.3 High RPO/RTO Documented in BCP; DR drill target Q2 2026
10 Employee security awareness training program CC1.4 Medium Q3 2026
11 Code of conduct and ethics policy CC1.1 Medium Q3 2026
12 Change advisory board (CAB) process CC8.1 Medium Q3 2026
13 Formal deficiency tracking and escalation process CC4.2 Medium Q3 2026
14 Privacy breach notification procedure and templates P8 Medium Q3 2026
15 Responsible disclosure / bug bounty program CC7.1 Medium SECURITY.md + security.txt published; private bounty planned #70
16 ~~Centralized security policy repository~~ CC2.1 Medium Implemented — MkDocs Material docs site with search, audience-organized nav, and CI build validation (#104)
17 Formal SLA documentation for lender integrations A1.1 Low Q4 2026
18 Privacy notice expansion (detailed data practices) P1 Low Q4 2026

Appendix A: Architecture Diagram Reference

                           +------------------+
                           |   Credit Union   |
                           |   (Demo CU)      |
                           +--------+---------+
                                    |
                          Credential Issuance
                          (Ed25519-signed VC)
                                    |
                                    v
+------------------+      +--------+---------+      +------------------+
|                  |      |                  |      |                  |
|    Member App    +----->+   ZKProva API    +----->+   Lender App     |
|   (Next.js UI)   |      |  (FastAPI/K8s)   |      |  (API Consumer)  |
|                  |      |                  |      |                  |
+------------------+      +----+----+----+---+      +------------------+
                               |    |    |
                  +------------+    |    +------------+
                  |                 |                 |
                  v                 v                 v
           +------+------+  +------+------+  +-------+-------+
           | PostgreSQL  |  |    Redis    |  |   Prometheus  |
           | (Data, Logs)|  | (Cache, RL) |  |   + Sentry    |
           +-------------+  +-------------+  +---------------+

Appendix B: Relevant Standards and Frameworks

Standard Relevance
W3C Verifiable Credentials Data Model Credential format and interoperability
W3C DID:key Method Decentralized identifier for credential issuers
AICPA SOC 2 Trust Service Criteria (2017) This assessment
NIST SP 800-63 (Digital Identity Guidelines) Authentication and identity proofing reference
NIST SP 800-53 (Security and Privacy Controls) Control framework reference
GDPR / CCPA Privacy regulation compliance (if applicable to members)

Appendix C: Document Control

Version Date Author Description
1.0 2026-02-22 ZKProva Engineering Initial SOC 2 Type I readiness assessment
1.1 2026-02-28 ZKProva Engineering Updated with security audit remediation (#62, #63), Dependabot (#64), Trivy scanning (#65), gitleaks (#66), pentest scope (#67), SECURITY.md (#70)
1.2 2026-02-28 ZKProva Engineering SOC 2 operational docs (#102): incident response plan (CC7.2/CC7.4), business continuity plan (A1.3), key rotation procedures (CC6.6), risk register (CC3.1)
1.3 2026-02-28 ZKProva Engineering SAST/DAST integration (#103): Semgrep SAST in CI (CC7.1/CC8.1), OWASP ZAP DAST in staging deploy pipeline, Gap #8 closed
1.4 2026-02-28 ZKProva Engineering Centralized docs site (#104): MkDocs Material with search, audience-organized nav, CI build validation, Gap #16 closed (CC2.1)

This document is intended for internal use and for sharing with prospective SOC 2 auditors. It does not constitute a formal SOC 2 report, which must be issued by an independent CPA firm.