Data Protection
This page documents the technical and organizational measures HarborGuard applies to customer data today. It is the public companion to the Data Processing Addendum (DPA) provided under contract. As the product matures, the commitments below will be tightened and formalized through audit.
Data classification
| Class | Examples | Handling |
|---|---|---|
| Customer secrets | Registry credentials, webhook signing secrets, SSO client secrets | Envelope-encrypted at rest; never logged; never returned through the API in plaintext |
| Scan artifacts | SBOMs, scanner output, vulnerability findings, evidence packs | Encrypted at rest; scoped to the originating organization |
| Account data | User profiles, organization settings, audit logs | Encrypted at rest; tenant-isolated |
| Telemetry | API access logs, performance metrics | Aggregated and short-retention by default |
Encryption in transit
- TLS 1.2 minimum on every public endpoint; TLS 1.3 preferred.
- Modern cipher suites only; legacy ciphers (RC4, 3DES, CBC-mode-with-SHA1) are disabled.
- Internal service-to-service traffic runs over the hosting provider's private network.
Encryption at rest
- Database: AES-256 disk encryption via the managed Postgres provider.
- Object storage: Server-side AES-256 encryption.
- Customer secrets: AES-256-GCM envelope encryption. Each secret is encrypted with a unique data encryption key (DEK); the DEK is wrapped with a key encryption key (KEK) held in the platform key store. See
src/lib/crypto.ts. - Backups: encrypted with the same primitives as the source store.
Key management
- KEKs are rotated periodically and on any suspected compromise. As the product matures, this cadence will be formalized and audited; until then, treat the published cadence as a target rather than a contractual commitment.
- KEKs are stored in a managed key-management service with strict IAM scoping.
- Plaintext KEKs are never written to disk or logs.
- Access to wrap/unwrap operations is auditable and limited to the running application identities.
Bring Your Own Key (BYOK)
BYOK / customer-managed keys are not yet available. Enterprise customers with this requirement can contact trust@harborguard.co to discuss the roadmap.
Data retention
The defaults below describe how HarborGuard handles each data class today. They are subject to change as the product matures, and will be locked in contractually for Enterprise customers via the DPA.
| Data | Default retention | Configurable? |
|---|---|---|
| Scan results and SBOMs | Retained while the workspace is active | Planned for Enterprise |
| Audit logs | Retained while the workspace is active | Planned for Enterprise |
| Evidence packs and reports | Retained while the workspace is active | Yes |
| Backups | Rolling backup window managed by the hosting provider | No |
| Deleted-account tombstones | Purged after the rolling backup window ages out | No |
Right to erasure
To request deletion of personal data or full workspace data:
- Email
privacy@harborguard.cofrom the address associated with the account, or from a verifiable account administrator. - We will acknowledge promptly and confirm the scope of the deletion request.
- Production data is purged on a best-effort basis as quickly as is operationally feasible; backups age out within the rolling backup window.
- We send a written confirmation when the purge completes.
Owners and administrators can also self-serve workspace deletion from Settings → Organization → Delete workspace, which schedules the same purge workflow.
Audit-log immutability
- Every privileged action — policy edits, member role changes, registry writes, exports — is recorded via
recordAuditEvent()(src/lib/audit.ts). - Audit-log exports are themselves audited.
- Audit records are append-only at the application layer; deletion is gated on workspace deletion.
- Streaming audit events to a customer SIEM via webhook is on the roadmap for Enterprise plans.
Tenant isolation
HarborGuard is a multi-tenant SaaS. Every database query is scoped by organizationId at the data-access layer; cross-tenant access is rejected at the API boundary. Database-level row security is on the roadmap as a defense-in-depth layer once the product reaches its first formal audit.