This document discloses how OrionHub handles customer data, covering the six topics required by the AWS Marketplace Seller Guide: collection, storage, usage, sharing, retention, and backup. It is deliberately concrete — if you need a single sheet to answer a procurement or security questionnaire, this is it.
1. Data collection
| Data class | Collected from | Mechanism |
|---|---|---|
| Account & profile | End users | Keycloak OIDC sign-up flow or AWS Marketplace fulfillment |
| Cloud connection credentials | Tenant Owner / Maintainer | Form submission, encrypted before write |
| Secrets | Tenant members with write access | Form submission, encrypted via Vault Transit before write |
| GitLab tokens & repository metadata | Tenant Owner / Maintainer | Manual paste; metadata mirrored via GitLab webhooks |
| SBOMs & scan results | GitLab Ultimate CI pipelines | Pipeline artifact upload via authenticated webhook |
| Audit log events | The platform itself | Synchronous write on every state-changing API call |
| Billing metadata | AWS Marketplace | SNS notifications + Entitlement API polling |
2. Data storage
- Primary store: Amazon RDS for PostgreSQL 15. Storage encryption is enabled with a customer-managed KMS key. Tenants are isolated via Postgres Row-Level Security policies on every tenant-scoped table.
- Secrets store: HashiCorp Vault (Transit secrets engine). Plaintext values never touch our primary database; only ciphertext is stored. Decrypt operations are audit-logged.
- Object storage: Amazon S3 with SSE-KMS, default encryption on all buckets, public access blocked at the account level.
- Region: U.S. AWS regions by default (us-east-1 primary, us-west-2 disaster recovery). AWS GovCloud available for U.S. Government customers under separate engagement.
- Encryption in transit: TLS 1.2 minimum on all public endpoints; HSTS enforced. Internal service-to-service traffic runs in private subnets behind security groups.
3. Data usage
Customer data is used solely to operate the Service for the customer. Specifically:
- To authenticate users and authorize requests.
- To render the platform’s dashboards, drill-down details, and reports back to the same customer.
- To execute customer-initiated workflows (deployments, scans, imports, AI assistant runs).
- To produce audit log entries and security telemetry.
- To deliver platform notifications (transactional email).
We do not use customer code, SBOMs, scan results, or deployment artifacts to train machine learning models. AI features call third-party models on a per-request basis under the customer’s own configured model in the AI Model Registry; the customer chooses the provider.
4. Data sharing
| Recipient | Purpose | Data shared |
|---|---|---|
| Amazon Web Services (sub-processor) | Hosting, KMS, RDS, S3, IAM, CloudWatch, SES | All customer data at rest and in transit |
| HashiCorp Vault (managed by Nexagen on AWS) | Secret encryption / decryption | Ciphertext & decrypt requests only |
| Keycloak (managed by Nexagen on AWS) | OIDC authentication | User identifiers, session metadata, group membership |
| GitLab (customer-supplied or OrionHub-bundled) | Source control, CI/CD, scanning | Code, MR metadata, SBOMs — per customer’s GitLab plan |
| Customer’s configured AI provider | AI assistant / Doctor / codegen requests | Prompts the customer’s users submit, plus context the customer authorizes |
| Tenant members of the same tenant | Collaboration within the tenant | Per role; non-Owners cannot see billing or reveal secrets |
We do not share customer data with advertisers, analytics networks, or any party not listed above. We do not sell personal information.
5. Data retention
| Data class | Retention while active | Retention after termination |
|---|---|---|
| Account & profile | Life of the subscription | 30 days, then deleted |
| Cloud credentials & secrets | Life of the subscription | 30 days, then ciphertext purged + Vault key destroyed |
| Repositories, deployments, requirements | Life of the subscription | 30 days, then deleted |
| SBOMs & scan findings | 90 days rolling, plus latest per repo | 30 days, then deleted |
| Audit log | 395 days minimum | 365 days, then purged |
| Diagnostic / request traces | 30 days rolling | n/a (already aged out) |
| Encrypted backups | 35-day rolling window | Backups containing post-termination data are purged within 35 days |
6. Data backup
- Frequency: RDS automated daily backups + 5-minute point-in-time recovery window. Application-level logical exports run weekly to a versioned S3 bucket with object-lock.
- Encryption: All backups inherit the source encryption (KMS). Cross-region copies use a separate KMS key in the destination region.
- Geographic redundancy: us-east-1 → us-west-2 cross-region copy on a 24-hour lag.
- Restoration testing: Quarterly drill restoring a point-in-time copy to a staging account and validating tenant isolation policies.
- Backup retention: 35 days for RDS snapshots, 90 days for logical exports.
7. Customer access to their data
- Tenant Owners can export all tenant data on demand via
GET /tenants/<slug>/exportor by emailing support@nexagen.com. - Tenant Owners can request hard deletion via support@nexagen.com; we honor verified requests within 30 days.
- Individual users can request access, correction, or deletion of their personal profile data by emailing privacy@nexagen.com.
8. Sub-processor list
Current sub-processors are Amazon Web Services (compute, storage, managed services, email) and any AI provider the customer configures in their tenant. We notify Owners at least 30 days before adding a new sub-processor that processes customer content.
9. Contact
Privacy: privacy@nexagen.com
Security incidents: security@nexagen.com
Support & deletion requests: support@nexagen.com