Security and compliance, built in from day one.

Compliance roadmap

Where Velsa is heading. Specific timelines firm up as we approach each milestone.

Security practices

Velsa is engineered to a government security standard — not bolted on afterward. What follows is in place today, backed by code, configuration, and maintained evidence.

In place today

• Hardened, minimal images — Velsa runs on a minimal container image built and continuously scanned against the DISA STIG, CIS Docker Benchmark, and CISA Known Exploited Vulnerabilities baselines in an automated image factory, with a read-only root filesystem and a non-root runtime.
• Supply-chain security — every build produces a CycloneDX software bill of materials (SBOM); secret scanning gates the build; dependencies are scanned continuously (Dependabot and Trivy); and static analysis runs on every change.
• Continuous vulnerability management — container and OS scanning is intersected against the CISA KEV catalog, and OpenSCAP STIG compliance scans run against the runtime image with a maintained Plan of Action & Milestones (POA&M).
• Network isolation — application and database tiers run in private subnets behind security-group isolation and VPC endpoints; no direct internet exposure of internal services.
• Encryption — TLS in transit on a FIPS-aligned policy; AES-256 via AWS KMS at rest, across database, object storage, and backups.
• Authentication — single sign-on via Microsoft Entra ID (OIDC); passkeys/WebAuthn and TOTP two-factor, which can be required for administrators; individual per-user accounts; a separate magic-link portal for exhibitors; idle-session timeout; and automatic disabling of inactive accounts.
• Payments — Velsa stores no cardholder data. Card data is tokenized by a PCI DSS Level 1 processor through a pluggable gateway abstraction (BluePay, Stripe, and CardPointe adapters), keeping it out of Velsa entirely (SAQ-A scope).
• Access control & audit — application role-based access control with least privilege; authentication and authorization enforced on every request; and security-event and data-change audit logging.
• Single-tenant option — Enterprise and dedicated deployments run single-tenant — each in its own VPC with a dedicated database, so there is no shared database and no cross-tenant exposure.
• Secret management — no secrets in code or version control; runtime secrets via AWS-managed stores.

On the roadmap

• Customer-managed encryption keys (BYOK) — Enterprise
• Custom data-residency options — Enterprise
• Configurable audit retention and SIEM streaming
• Self-service full-account data export
• SOC 2 Type II attestation

Data handling

Where data lives

Customer data is stored in Amazon Web Services US-East (Northern Virginia). Backup copies are encrypted and retained within the same region. Data does not leave AWS infrastructure.

What we collect

Velsa is built to manage events at venues. The product collects what's necessary to do that: contact information for attendees and counterparties, contract and booking details, financial transactions related to events, and operational data about how venues are run.

What we don't do

• We do not sell customer data.
• We do not use customer data to train AI models.
• We do not share customer data with third parties for marketing.

Retention and deletion

Data is retained for the life of your account. On account deletion, customer data is permanently removed within 30 days, except where retention is required by law or regulation.

Export

Scoped exports — accounting and ledger data, and individual reports in CSV, Excel, and PDF — are available in the product today. A full self-service account export is on the roadmap; in the meantime, a complete export can be arranged on request.

Sub-processors

Velsa relies on the following third parties to deliver the product. This list is updated as the product evolves.

• Amazon Web Services Infrastructure, storage, compute, networking United States

Incident response

Velsa monitors infrastructure and application health continuously. In the event of a security incident:

1. Detection via CloudWatch alarms, application logs, and customer reports.
2. Triage by the engineering team within one business hour of detection.
3. Affected customers are notified within 72 hours of confirmed incident, in line with industry best practice.
4. Post-incident review documents root cause, customer impact, and corrective actions.

Responsible disclosure

If you've found a security issue in Velsa, please report it to security@velsa.io. Our full policy — scope, response times, and safe-harbor terms — lives on the security & disclosure page, and is also published in machine-readable form as security.txt. The summary below covers the essentials.

In scope

• The marketing site at velsa.io
• The demo environment at demo.velsa.io
• Public APIs and integrations (once published)

Out of scope

• Third-party services Velsa depends on (e.g., AWS) — report to the provider directly
• Social-engineering attacks against staff or customers
• Physical attacks against infrastructure or offices
• Findings that require an already-compromised device or network

Our commitments

• We acknowledge reports within three business days.
• We will not pursue legal action against researchers acting in good faith under this policy.
• With permission, we credit researchers in a public hall of fame once one exists.

Please don't

• Access, modify, or destroy data that isn't yours.
• Run automated scanning that disrupts service for other users.
• Publicly disclose the issue before we've had a reasonable chance to fix or mitigate.

Documents

Available now, or as Velsa matures:

• Privacy policy — how we collect, use, and protect information Published
• Terms of service — the terms under which Velsa is provided Published
• Data Processing Agreement (DPA) — available on request to privacy@velsa.io On request
• SOC 2 Type II report — available under NDA after audit completion Post-audit
• Penetration-test summary — commissioned as part of the SOC 2 engagement Post-audit