# Corvalon HRM: SOC 2 Trust Service Criteria Controls Mapping

Last updated: 2026-07-07

This document maps Corvalon HRM platform controls to SOC 2 Trust Service Criteria (TSC). Corvalon HRM targets all five TSC categories: Security, Availability, Confidentiality, Processing Integrity, and Privacy.

> **Status:** Corvalon HRM has not yet undergone a SOC 2 examination. This mapping is maintained as audit-readiness documentation describing controls as currently implemented; a Type I examination is planned on the launch roadmap.

---

## Security (Common Criteria)

Security controls are required for all SOC 2 reports.

### CC1: Control Environment

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC1.1 | Organizational commitment to integrity | Code of conduct, security training, background checks for personnel with data access |
| CC1.2 | Board/management oversight | Quarterly security reviews, risk assessments, compliance dashboard |
| CC1.3 | Organizational structure | Defined security responsibilities, separation of duties in RBAC (17 roles); toxic-combination analysis in `Documents/security/SoD_Permissions_Matrix.md` (SOX-06) |
| CC1.4 | Competence commitment | Security training for all developers, annual security awareness program |

### CC2: Communication and Information

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC2.1 | Internal communication | Append-only audit trail for all config changes; a database backstop trigger records a mutation even when an application call site omits its explicit audit write, so completeness is enforced at a single chokepoint rather than per call site (SOX-02); real-time notifications via the transactional outbox event queue |
| CC2.2 | External communication | Trust center, vulnerability disclosure policy, incident notification process |

### CC3: Risk Assessment

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC3.1 | Risk identification | Continuous DAST (OWASP ZAP baseline on every push plus a scheduled full scan) and SAST scanning; third-party penetration test planned pre-launch (not yet performed) |
| CC3.2 | Risk analysis | CVSS-based severity classification, remediation SLAs (Critical: 24h, High: 7d) |
| CC3.3 | Fraud risk | Segregation of duties in payroll (dual approval), anomaly detection engine, platform-wide SoD toxic-combination matrix (`Documents/security/SoD_Permissions_Matrix.md`) |
| CC3.4 | Change impact | All changes go through PR review, automated test suites, staging validation |

### CC4: Monitoring

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC4.1 | Ongoing monitoring | CloudWatch metrics/alarms, OpenTelemetry tracing, Prometheus metrics |
| CC4.2 | Deficiency communication | Automated alerting, incident response escalation, SLA dashboards |

### CC5: Control Activities

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC5.1 | Risk mitigation | Defense-in-depth: schema isolation + RLS + field encryption + RBAC |
| CC5.2 | Technology controls | MFA enforcement (10 roles), JWT with short expiry, CSRF protection |
| CC5.3 | Policy enforcement | Automated policy checks via CI/CD pipeline, pre-commit hooks |

### CC6: Logical and Physical Access

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC6.1 | Access provisioning | RBAC with 17 roles, least-privilege assignment, approval workflows |
| CC6.2 | Authentication | Argon2id password hashing, MFA (TOTP + WebAuthn), account lockout (5 attempts/30 min) |
| CC6.3 | Access revocation | Immediate session invalidation on user deactivation, JWT blacklisting |
| CC6.4 | Access reviews | Periodic access review reports, role assignment audit trail |
| CC6.5 | Physical access | AWS data centers (SOC 2 certified), no on-premises components |
| CC6.6 | Threat management | WAF rules, rate limiting (Redis-backed), IP allowlisting, CORS lockdown |
| CC6.7 | Transmission security | TLS 1.2+ on all connections, HTTPS-only webhooks; events stay inside the encrypted PostgreSQL database (transactional outbox) |
| CC6.8 | Unauthorized software | Container image scanning (Trivy), dependency auditing (Dependabot, govulncheck) |

### CC7: System Operations

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC7.1 | Vulnerability detection | Continuous scanning: DAST, SAST, dependency audit, container scan |
| CC7.2 | Anomaly monitoring | Payroll anomaly detection, login pattern analysis, rate limiting |
| CC7.3 | Incident evaluation | Severity classification (CVSS), documented triage process |
| CC7.4 | Incident response | Documented IR process, 72-hour breach notification, blameless postmortems |
| CC7.5 | Audit-log tamper-evidence | Each `audit_log` row carries a `prev_hash`/`row_hash` chain; a daily worker cron verifies both the live and archived chains and emits `hrm_audit_chain_verified_total` / `hrm_audit_chain_broken_total` metrics, so any silent modification or deletion below the archive boundary is detected (SOX-08) |

### CC8: Change Management

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC8.1 | Change authorization | PR-based workflow, automated test gates, backlog item / `D-NNN` decision required per change, `prod` + Terraform-apply GitHub Environment reviewer gates, per-deploy change-evidence record. Full authorize -> test -> approve -> deploy flow and the solo-founder compensating control documented in `Documents/trust/Change_Management_Policy.md` (SOX-03). |

### CC9: Risk Mitigation

| Criteria | Control | Implementation |
|----------|---------|----------------|
| CC9.1 | Risk mitigation | Vendor assessment for sub-processors, DPA agreements, SLA monitoring |
| CC9.2 | Vendor management | Sub-processor list maintained, annual vendor security reviews |

---

## Availability (A)

| Criteria | Control | Implementation |
|----------|---------|----------------|
| A1.1 | Capacity management | ECS Fargate services with per-environment task counts and CloudWatch alarms; load-based auto-scaling policies are on the roadmap |
| A1.2 | Recovery objectives | RDS Multi-AZ with automatic failover (production), 30-day point-in-time recovery, AWS Backup snapshots (90-day daily, 365-day monthly) with cross-region copy, documented RTO/RPO |
| A1.3 | Recovery testing | Documented DR runbook; quarterly restore drills are scheduled on the operational calendar (first drill not yet executed) |

**Key controls:**

- PostgreSQL Multi-AZ deployment with automatic failover (production)
- Daily automated backups with AES-256 encryption and cross-region snapshot copies
- ECS rolling deployments with zero-downtime updates
- Health check endpoints with circuit breaker patterns
- Redis session cache (single-node today; replication on the roadmap)

---

## Confidentiality (C)

| Criteria | Control | Implementation |
|----------|---------|----------------|
| C1.1 | Confidential information identification | Data classification (PII, PHI, financial), field-level sensitivity tagging |
| C1.2 | Confidential information disposal | Configurable data retention policies (90 days to 7 years by category); audit-log retention purge runs under a dedicated `hrm_audit_purge` role restricted to `SELECT`/`DELETE` on `audit_log`, and every delete is gated on rows already covered by a chain-verified archival batch, so append-only integrity is preserved and nothing is purged before it is archived (SEC-09); GDPR erasure with anonymization where legal retention requires record continuity (extension of anonymization across all historical record versions is in progress) |

**Key controls:**

- **Vault Transit encryption** for SSN, bank accounts, EIN, MFA secrets (4 dedicated keys with per-tenant derivation)
- **OIDC client-secret encryption:** SSO client secrets are encrypted with a Vault Transit key rather than stored in plaintext; the encryptor fails closed on deployed environments (stage/production) if no Vault client is configured (SEC-01)
- **Field-level security** in both Go backend and frontend (RBAC-driven field visibility)
- **Schema-per-tenant isolation** (~303 tables per tenant, no shared data tables)
- **PostgreSQL RLS** as defense-in-depth layer
- **Audit-log retention purge** via a dedicated, least-privilege `hrm_audit_purge` role, archive-gated so append-only integrity holds (SEC-09)
- **Tenant offboarding** with complete data purging workflow
- **Legal hold** system prevents deletion of data under litigation hold

---

## Processing Integrity (PI)

| Criteria | Control | Implementation |
|----------|---------|----------------|
| PI1.1 | Processing accuracy | Payroll accuracy target >99.9% against reference calculations |
| PI1.2 | Input validation | Zod schema validation (frontend), Go struct validation (backend), parameterized SQL queries |
| PI1.3 | Error detection | Bi-temporal data model for point-in-time accuracy, retro pay engine for corrections |
| PI1.4 | Output review | Payroll comparison reports, anomaly detection, dual-approval workflows |
| PI1.5 | Data integrity | Transactional outbox pattern (no lost events) with retry/backoff; exhausted-retry rows form an operable dead-letter set surfaced in the admin Event Queue page; audit-trail completeness enforced by a database backstop trigger (SOX-02) and tamper-evidence by the `audit_log` hash chain (SOX-08) |

**Key controls:**

- **Bi-temporal model** on all mutable entities: business-time (valid_from/valid_to) and system-time (system_from/system_to) for complete audit history
- **Payroll validation:** Multi-step payroll runs with preview, approval, and comparison against prior periods
- **Garnishment calculations** tested against federal and state limits for all garnishment types
- **Retro pay engine** automatically calculates corrections when retroactive changes are detected
- **Import engine** uses two-phase commit: validate dry-run, then explicit commit

---

## Privacy (P)

| Criteria | Control | Implementation |
|----------|---------|----------------|
| P1.1 | Privacy notice | Privacy practices documentation, cookie policy, data processing transparency |
| P1.2 | Choice and consent | Consent management, opt-in/opt-out controls, purpose limitation |
| P2.1 | Data collection | Minimization principles, purpose-bound collection, documented data categories |
| P3.1 | Data use | Purpose limitation enforcement, AI data governance (output redaction, per-user opt-out, per-tenant feature flags) |
| P3.2 | Data retention | Configurable retention policies by data category (employee records: 7 years, applicant data: 2 years, audit logs: 7 years) |
| P4.1 | Data disclosure | Sub-processor list, DPA framework, cross-border transfer documentation |
| P5.1 | Access rights | Data subject request (DSR) portal: access, correction, deletion, portability |
| P5.2 | Correction rights | Self-service profile editing, DSR correction requests with audit trail |
| P6.1 | Data quality | Input validation, duplicate detection, data integrity checks |
| P7.1 | Monitoring | Privacy compliance dashboard, DSR SLA tracking, consent audit trail |
| P8.1 | Dispute resolution | DSR appeal process, regulatory complaint handling |

**Key controls:**

- **GDPR compliance:** Right to access, rectification, erasure, portability, and restriction
- **CCPA/CPRA compliance:** Do-not-sell, right to know, right to delete, opt-out of automated decision-making
- **US state privacy laws:** Support for Virginia VCDPA, Colorado CPA, Connecticut CTDPA, and emerging state laws
- **Data retention engine:** Automated enforcement of retention schedules with configurable policies per data category
- **AI data governance:** automated redaction of sensitive identifiers in AI outputs, per-user AI opt-out enforced at the gateway, model bias auditing, feature-level restrictions per tenant (input-side PII stripping on the roadmap)
- **Legal hold integration:** DSR erasure requests automatically check for legal holds before processing
- **Global Privacy Control (GPC):** GPC browser signal detection with automated opt-out request filing (the standardized `/.well-known/gpc.json` disclosure endpoint is on the roadmap)

---

## Evidence Collection

Corvalon maintains automated evidence collection for SOC 2 audit readiness:

| Evidence Type | Collection Method | Frequency |
|---------------|------------------|-----------|
| Access logs | Append-only audit trail | Continuous |
| Change records | Git commit history + PR reviews | Every change |
| Vulnerability scans | DAST/SAST/dependency reports | Every PR + weekly |
| Penetration tests | Third-party engagement reports | Planned (pre-launch engagement; none performed yet) |
| Access reviews | RBAC role assignment reports | Quarterly |
| Incident reports | IR ticketing system | Per incident |
| Backup verification | Restore drills per DR runbook | Quarterly (scheduled; first drill not yet executed) |
| Uptime metrics | CloudWatch / status page | Continuous |

---

## Report Availability

Corvalon HRM has not yet undergone a SOC 2 examination, so no SOC 2 report exists today. A Type I examination is planned on the launch roadmap, with Type II to follow after an observation period.

Until then:

1. This controls mapping is available as audit-readiness documentation.
2. Security questionnaires and architecture reviews are supported under NDA.
3. Examination status updates are published at the [Trust Center](/trust/compliance).

**Contact:** compliance@corvalonhrm.com