# Corvalon HRM Security Overview

Last updated: 2026-06-12

This document provides a public-facing overview of the security architecture, controls, and practices that protect customer data on the Corvalon HRM platform.

---

## Platform Architecture

Corvalon HRM is built on a modern, hardened technology stack:

| Layer | Technology | Purpose |
|-------|-----------|---------|
| API Server | Go (compiled, statically typed) | REST API, event consumers, background workers |
| Frontend | Next.js 16 (React 19, TypeScript) | Server-side rendered UI with BFF authentication proxy |
| Database | PostgreSQL 16 + pgvector | Primary datastore with row-level security and bi-temporal versioning |
| Event Queue | PostgreSQL transactional outbox + dispatcher service | Asynchronous event processing across 11 domain topics; events never leave the encrypted primary database |
| Encryption | HashiCorp Vault Transit | Field-level encryption for sensitive data (SSN, bank accounts, EIN, MFA secrets) |
| Cache | Redis 7 | Session management, rate limiting, distributed locks |
| Object Storage | S3-compatible (MinIO/AWS S3) | Document storage, audit log archival |
| Tracing | OpenTelemetry + Jaeger/X-Ray | Distributed request tracing across all services |
| Malware Scanning | ClamAV | Optional file upload scanning |

All components run in isolated containers with least-privilege networking. No component has direct internet access except through the load balancer.

---

## Authentication

### BFF (Backend-for-Frontend) Pattern

Corvalon HRM uses a BFF authentication architecture where the Next.js frontend acts as a secure proxy. The Go backend issues tokens but never sets cookies directly. Cookie management is handled exclusively by the BFF layer, ensuring tokens are never exposed to client-side JavaScript.

### Login Security

- **Password hashing:** Argon2id (with legacy bcrypt migration support)
- **Account lockout:** 5 failed attempts triggers a 30-minute lockout period
- **No enumeration:** Login failures return generic error messages to prevent username and tenant enumeration
- **Session management:** httpOnly, Secure, SameSite=Lax cookies with configurable domain scoping
- **CSRF protection:** Token-based CSRF prevention on all state-changing operations
- **JWT tokens:** 15-minute access tokens with 7-day refresh tokens; claims include tenant schema for zero-lookup routing

### Multi-Factor Authentication (MFA)

MFA is enforced for all privileged roles (10 of 15 roles require MFA):

| MFA-Required Roles | MFA-Optional Roles |
|--------------------|--------------------|
| HR Admin, Payroll Admin, System Admin | Employee, Manager |
| HR Generalist, Benefits Specialist | Recruiting Specialist |
| Compensation Analyst, Payroll Specialist | L&D Specialist |
| Compliance Officer, Grant Manager | Analytics Viewer |

Supported MFA methods:

- **TOTP** (Time-based One-Time Password): Compatible with any authenticator app (Google Authenticator, Authy, 1Password)
- **WebAuthn/FIDO2**: Hardware security keys and platform authenticators (Touch ID, Windows Hello)
- **Backup codes**: Single-use recovery codes generated at enrollment

Privileged users who have not enrolled in MFA are directed to mandatory setup before accessing the platform.

---

## Authorization

### Role-Based Access Control (RBAC)

Corvalon HRM implements a 15-role RBAC system with granular permissions:

- **5 foundational roles:** Employee, Manager, HR Admin, Payroll Admin, System Admin
- **10 specialist roles:** HR Generalist, Recruiting Specialist, Benefits Specialist, Compensation Analyst, Payroll Specialist, L&D Specialist, Compliance Officer, Grant Manager, Analytics Viewer, Union Steward
- **Super-role inheritance:** HR Admin and Payroll Admin inherit all permissions from their respective sub-roles

### Field-Level Security

Sensitive fields (compensation data, SSN, bank accounts) are protected at the field level. The Go backend enforces field visibility based on the user's roles and the frontend mirrors these restrictions for UX consistency. Backend enforcement is authoritative; client-side restrictions are UX convenience only.

### Row-Level Security (RLS)

PostgreSQL RLS policies enforce tenant isolation at the database level. Every query includes tenant context via `SET LOCAL app.tenant_id`, ensuring one tenant's data is never accessible to another, even in the event of application-layer bugs.

---

## Encryption

### Data at Rest

- **Field-level encryption:** Sensitive fields (SSN, bank account numbers, EIN, MFA secrets) are encrypted using HashiCorp Vault Transit before storage. Plaintext never reaches the database.
- **Per-tenant key derivation:** Each tenant's data is encrypted with a unique derived key using convergent encryption with tenant-specific context. Even with access to the encryption engine, one tenant's ciphertext cannot be decrypted with another tenant's context.
- **Transit keys:** Four dedicated keys (hrm-ssn, hrm-bank, hrm-ein, hrm-mfa) with convergent encryption enabled.
- **Database encryption:** PostgreSQL storage encrypted at rest via AWS RDS encryption (AES-256) or volume-level encryption.
- **Backup encryption:** All database backups are encrypted with AES-256 and stored with configurable retention policies.

### Data in Transit

- **TLS 1.2+** enforced on all external connections
- **HTTPS everywhere:** All API endpoints, webhooks, and frontend routes require TLS
- **Internal service communication:** TLS between all components (database, Redis, Vault)

---

## Tenant Data Isolation

Corvalon HRM implements defense-in-depth tenant isolation:

1. **Schema-per-tenant:** Each tenant receives a dedicated PostgreSQL schema (`t_<slug>`) containing all domain, auth, and audit tables (~303 tables per tenant). No shared tables for tenant data.
2. **Row-Level Security (RLS):** PostgreSQL RLS policies provide a second isolation layer. Even if application code incorrectly constructs a query, RLS prevents cross-tenant data access.
3. **Per-request search path:** Every database request sets `SET LOCAL search_path TO t_<slug>, public, reference` ensuring queries resolve to the correct tenant schema.
4. **Per-tenant encryption keys:** Vault Transit key derivation uses tenant ID as context, providing cryptographic isolation between tenants.
5. **JWT tenant binding:** JWT tokens include the tenant schema claim, preventing token reuse across tenants.

---

## Audit Trail

All state-changing operations are recorded in an append-only audit trail:

- **Immutable logging:** Audit records cannot be modified or deleted by application users
- **7-year retention:** Audit data is retained for seven years to meet regulatory and compliance requirements
- **Comprehensive coverage:** Every API mutation, login event, permission change, and data access is logged
- **Bi-temporal tracking:** All mutable entities use bi-temporal versioning (valid_from/valid_to for business time, system_from/system_to for system time), enabling point-in-time reconstruction of any record
- **Event-driven:** State changes produce events via the transactional outbox pattern inside the primary database, ensuring no audit events are lost even during failures

---

## AI/ML Governance

Corvalon HRM includes AI-powered features with comprehensive governance controls:

- **Model registry:** All ML models are registered with version tracking, training metadata, and approval status
- **Bias auditing:** Automated bias detection across protected classes with configurable thresholds
- **Output redaction:** AI responses are automatically scanned and sensitive identifiers (SSN, EIN, bank and routing numbers, and similar patterns) are redacted before display; input-side PII stripping is on the roadmap
- **Opt-out enforcement:** A per-user AI opt-out is enforced at the AI gateway, the single entry point for all AI features, before any data reaches the provider
- **Feature restrictions:** AI features can be disabled per tenant via feature flags
- **Explainability:** AI-driven recommendations include confidence scores and contributing factors
- **Human oversight:** AI outputs that affect employment decisions are advisory and never auto-executed; serving of employment-related ML models is gated on production approval status plus a passing bias audit within the past 12 months

---

## Vulnerability Management

### Continuous Scanning

| Tool | Scope | Frequency |
|------|-------|-----------|
| Dependabot | Go and npm dependencies | Weekly |
| govulncheck | Go vulnerability database | Every PR + weekly |
| DAST (ZAP) | Running application endpoints | Every PR + quarterly full scan |
| SAST (Semgrep) | Source code patterns | Every PR + weekly |
| Container scanning (Trivy) | Docker images | Every PR + weekly |

### Penetration Testing

- **External penetration tests:** A third-party engagement is planned pre-launch (none performed yet), with an annual cadence thereafter
- **Continuous DAST:** OWASP ZAP baseline scan on every push plus a scheduled full scan serves as the current dynamic-testing control
- **Remediation SLAs:** Critical (24 hours), High (7 days), Medium (30 days), Low (90 days)

### Responsible Disclosure

Corvalon maintains a vulnerability disclosure policy and welcomes reports from security researchers. Reports can be submitted to security@corvalonhrm.com. We provide safe harbor protections for researchers who follow responsible disclosure guidelines.

---

## Incident Response

Corvalon maintains a documented incident response process:

1. **Detection:** Automated alerting via monitoring, SIEM, and anomaly detection
2. **Triage:** Severity classification within 1 hour of detection
3. **Containment:** Immediate isolation of affected systems
4. **Investigation:** Root cause analysis with forensic evidence preservation
5. **Remediation:** Fix deployment per severity SLAs
6. **Notification:** Affected customers notified within 72 hours per GDPR requirements (sooner when possible)
7. **Post-incident review:** Blameless retrospective with published postmortem for significant incidents

---

## Infrastructure Security

- **Network isolation:** Dedicated VPC per environment; data-tier services (database, Vault, Redis) are not internet-reachable, with security-group chains (load balancer to application to database) enforcing least-privilege ingress
- **Least privilege:** IAM roles scoped to minimum required permissions
- **Secrets management:** All credentials stored in encrypted AWS SSM Parameter Store or HashiCorp Vault; no hardcoded secrets
- **Automated patching:** OS and dependency updates applied on a regular cadence
- **Monitoring:** CloudWatch metrics, alarms, and centralized logging
- **Distributed tracing:** OpenTelemetry instrumentation across all services for full request lifecycle visibility

---

## Compliance

Corvalon HRM is designed to meet the requirements of:

- **SOC 2 Type II** (Security, Availability, Confidentiality, Processing Integrity, Privacy)
- **GDPR** (EU General Data Protection Regulation)
- **CCPA/CPRA** (California Consumer Privacy Act / California Privacy Rights Act)
- **US state privacy laws** (Virginia VCDPA, Colorado CPA, Connecticut CTDPA, and others)
- **ADA / Section 508** (Accessibility)
- **WCAG 2.1 AA** (Web Content Accessibility Guidelines)

For detailed compliance information, see our [SOC 2 Controls Mapping](SOC2_Controls_Mapping.md) and [Privacy Practices](Privacy_Practices.md).

---

## Contact

- **Security reports:** security@corvalonhrm.com
- **Privacy inquiries:** privacy@corvalonhrm.com
- **General support:** support@corvalonhrm.com