Trust Center
Trust Center: How Value Aligners Protects Customer Data
Last updated
This page describes how the Value Aligners platform protects customer data today: how people sign in, how data moves and where it is hosted, who can reach it, what is logged, and how the code is kept up to date.
Each practice below is one the platform's code and configuration show. The page is checked against them before every update, and each change is recorded in the change log at the bottom.
Encryption in transit
The app is served over HTTPS only, and browsers are told to keep using HTTPS for the site and its subdomains. The app's connections to its database are encrypted with TLS.
Hosting
The application runs on Microsoft Azure's managed app hosting, and customer records are kept in a managed MongoDB database service. Network access to the database is limited to an allowlist.
Sign-in and sessions
Passwords must be at least 12 characters, mix character types and not be a commonly breached password. Sign in with Google is verified on the server. Each signed-in request carries a signed session token that the server checks, and signing out revokes it.
Sign-in attempt limits
Failed password sign-in attempts are limited on the server, both from a single network address and against a single account, to slow down password guessing. Once a limit is reached, further attempts are turned away for a short time, with the same reply whether or not an account exists for that email address.
Password storage
New and changed passwords are stored as bcrypt hashes. Passwords and secrets are compared in constant time, and they are redacted from audit records.
Access control and customer separation
Routes that serve customer data require a signed-in session. Before returning an organization's records, the server checks that the signed-in account owns that organization instead of trusting an identifier sent by the browser. Staff tools need a separate staff authorization check on the server.
Web application protections
Responses carry a Content Security Policy and headers that block framing and content-type sniffing. Requests that change data need an anti-forgery (CSRF) token, HTML and script content is stripped from submitted text, and public forms are rate limited.
Audit logging
Changes to marketplace records and automated (agent) access to the API are written to an audit log that records who acted, when, and what changed. Account deletions are logged as well.
Account and data deletion
Account deletion is permanent: the account and its associated records are removed, the linked customer record at the payment processor is deleted, and the deletion is recorded in the audit log.
Payments
Card payments are made on Stripe's hosted checkout, so card details go to Stripe and are not stored on Value Aligners servers. Payment notifications from Stripe are accepted only with a valid signature.
Secrets management
Application secrets are kept out of source code and supplied at runtime through the hosting platform's protected settings and a managed key vault. The code repository has secret scanning with push protection.
Vulnerability and dependency management
Automated pull requests propose dependency updates for the app, the server and the build pipeline every week. Build pipelines run a dependency audit and static code analysis (SAST), and a passive dynamic scan (DAST) of the pre-production environment can be run on demand.
Change management
Code changes go through pull requests with assigned code owners. A production release is built and tested, deployed to a staging slot, smoke tested there, and only then swapped into production.
Side-by-side comparison
| Option | How | Scope |
|---|---|---|
| Encryption in transit | HTTPS only; HTTP Strict Transport Security (HSTS); TLS to the database | Web app, API and database connections |
| Hosting | Managed cloud hosting; managed database; database network allowlist | Application and customer records |
| Sign-in and sessions | Server-enforced password policy; Google sign-in verification; signed session tokens; revocation on sign-out | All user accounts |
| Sign-in attempt limits | Server-side limits on failed sign-in attempts, by network address and by account; one reply for known and unknown accounts | Password sign-in for all user accounts |
| Password storage | bcrypt hashing; constant-time comparison; redaction in audit records | User passwords and service secrets |
| Access control and customer separation | Server-side session and ownership checks; separate staff authorization | Customer data and internal tools |
| Web application protections | Security headers; CSRF tokens; input sanitization; rate limits on public forms | Web app and API |
| Audit logging | Audit records with actor, time and before-and-after values; secrets redacted | Marketplace records, automated access and account deletion |
| Account and data deletion | Hard delete of the account and related records; audit entry | User accounts and associated records |
| Payments | Hosted checkout; signature-verified payment notifications | Subscriptions and purchases |
| Secrets management | Runtime configuration and key vault; repository secret scanning | Credentials and keys used by the platform |
| Vulnerability and dependency management | Weekly automated dependency updates; dependency audit; SAST; passive DAST | Application code, dependencies and build pipeline |
| Change management | Pull request review; tested staging deployment before production | Every production release |
Certifications
Value Aligners does not hold a SOC 2 report or an ISO 27001 certification at this time, and this page does not claim any certification. It describes the practices in place today.
What this page leaves out
To protect customers, this page does not name internal systems, list configuration values or component versions, or describe internal procedures in detail. Those details are left out on purpose.
Frequently asked questions
Does Value Aligners hold SOC 2 or ISO 27001 certification?
Not at this time. This page describes the security practices in place today and does not claim any certification.
Where is customer data hosted?
On Microsoft Azure, with customer records in a managed MongoDB database service.
How is data protected in transit?
The app is served over HTTPS only with HTTP Strict Transport Security, and the app's connections to its database use TLS.
What happens after several failed sign-in attempts?
Further password attempts are turned away for a short time. Wait and try again, or use Forgot Password to set a new password.
Does Value Aligners store my card number?
No. Card payments are made on Stripe's hosted checkout, and card details go to Stripe.
How do I have my account and data deleted?
Use the contact details in the Privacy Policy. Deletion permanently removes the account and its associated records and is recorded in the audit log.
Change log
Published.
Why: Published for plan action S7.2 (trust marks AI can cite).
Added sign-in attempt limits.
Why: The platform now limits failed password sign-in attempts by network address and by account.
Created the page from the security practices shown in the platform's code and configuration.
Why: To give buyers one place that describes how customer data is protected, without certification claims.