Security
Security overview
For security and vendor-risk reviews. Phone Validator doesn't have a SOC 2 report yet, so this page describes our controls in the areas a SOC 2 report covers.
Last reviewed October 2026. It describes the Phone Validator platform we run today.
At a glance
- Data minimization: lookups through the API store no phone numbers. Batch files are deleted 7 days after completion. Only the phone numbers being checked go to our carrier data provider.
- Role: we process the numbers you submit as your service provider and processor, under our Data Processing Addendum. We don't sell, share or compile them.
- Hosting: AWS, US West (Oregon). Data and backups are stored, and processing runs, in the United States. Requests are received at content delivery network locations in North America, Europe and Israel and forwarded encrypted to our servers.
- Encryption: TLS on every connection, encryption at rest, and application-level encryption of stored phone numbers and contact details.
- Access: staff use single sign-on with security-key multi-factor authentication and short-lived credentials. Customers sign in with passkeys or one-time codes. We store no passwords.
- Breach notice: within 72 hours of becoming aware of a security incident affecting your data.
Scope and system
This overview covers the Phone Validator service: the phonevalidator.com website, web lookups, batch processing, the API and our HubSpot app. These run as one application on AWS.
- Containers run on Amazon ECS in private subnets across two availability zones.
- The database is PostgreSQL on Amazon RDS, with multi-AZ replication and deletion protection.
- Files are stored in private, encrypted Amazon S3 storage.
- All traffic arrives through Amazon CloudFront and AWS WAF. Neither the application servers nor the database can be reached from the internet.
- The live service runs in its own AWS account in an AWS Organization. Audit logs and backup copies are held in separate accounts, so a compromise of the account that runs the service can't change or delete them.
Controls
Governance and risk
- A named person is accountable for security, privacy and vendor relationships.
- Written security procedures, an access register and a gap register with planned remediation are kept in version control and updated as controls change.
- Changes to the live service, access changes and security reviews are kept as dated records.
Access control
- Access to the live service is limited to named personnel. They sign in through AWS IAM Identity Center, protected by hardware security-key multi-factor authentication. Credentials are short-lived, and we keep no long-lived AWS access keys.
- Staff accounts with the subprocessors that hold customer data (AWS, Sentry and Google Workspace) also use single sign-on with security-key multi-factor authentication. Our telecommunications data provider accepts lookups only from our servers, and its customer portal holds none of your data.
- Account root credentials are removed or centrally managed, and service-control policies restrict regions and protect security settings.
- Access is granted on least privilege, reviewed at least once a year and removed promptly when no longer needed.
- Customer accounts use passkeys (WebAuthn) or one-time emailed codes, with an optional second step (authenticator app or security key). API keys, sign-in codes and session tokens are stored only as keyed hashes.
Change management
- Every change goes through a pull request and is reviewed before merge. Automated tests, static application security analysis, and dependency and container vulnerability scans must pass before a release is built, and secret scanning runs on every change.
- Application releases deploy only from the main branch through GitHub Actions, using short-lived credentials, by immutable image digest.
- Infrastructure is defined in code (OpenTofu). Changes are applied only from reviewed, merged code after an explicit approval of the plan.
Encryption and key management
- In transit: TLS 1.2 or newer on every hop, from the visitor to CloudFront, the load balancer, the application and the database, with the database certificate verified. Plain-HTTP API requests are refused on api.phonevalidator.com and redirected to HTTPS on our main site, so always use HTTPS.
- At rest: the database and backups are encrypted with AWS KMS keys, and batch files with Amazon S3 server-side encryption.
- In the application: phone numbers, contact details and other sensitive fields stored in the database are also encrypted with Rails Active Record Encryption. Its keys are held separately in AWS Secrets Manager.
Vulnerability management
- Application images are minimal (Chainguard-based), run without root privileges, and contain no shell or package manager.
- Images are scanned before release, and deployed images are rescanned weekly. Dependency, base-image and CI updates are checked weekly.
- Error reports go to Sentry with request data, cookies, headers and user details removed.
Logging and monitoring
- Cloud audit trails, network flow logs and edge access logs are delivered to a separate log archive account. Nothing in the account that runs the service can change or delete them.
- Application and firewall logs are kept 90 days, with phone numbers, emails and form contents filtered out.
- Alerts cover sensitive account activity, failed backups and failed scheduled deletions. Sentry monitors errors and availability.
Incident response
- We keep written runbooks for security alerts, compromised access and lost devices, and record incidents.
- We notify affected customers within 72 hours of becoming aware of a security incident affecting their data, as our DPA commits.
Availability and recovery
- The database runs across multiple availability zones, with point-in-time recovery for 35 days.
- Daily backups are copied to a separate backup account and kept for one year.
- Before launch, we tested restoring from the protected backup copy into an isolated account. Restore testing with current data, including full application recovery, is planned.
- Automated checks test the website and each API version around the clock and alert us. We can share recent availability history on request, and make uptime commitments only in an order form.
Personnel
- Access to customer data is limited to named personnel, who are bound by confidentiality obligations.
- Access is removed promptly when someone no longer needs it.
Vendor management
- We keep an inventory of the providers we depend on.
- Providers that process customer data are listed below, and each receives only the data it needs.
- We announce new subprocessors at least 30 days in advance, as the DPA describes.
Data handling
- Batch uploads: your browser normally extracts the selected phone column and uploads only that. If it can't, we tell you before uploading the whole file, then keep only the phone column.
- Retention: see our Privacy Policy. Short periods are enforced automatically every night, and customers can delete lookups, batches and their account themselves.
- Backups: deleted data can remain in encrypted backups until they expire, after 35 days, or one year for the protected copy.
- Opt-outs: people can ask us to stop looking up their number. Once a request is completed, every lookup channel honors it.
- Staff access: processing is automated. Staff open an order or record only for support, security or legal reasons.
Subprocessors
These process customer data. They store it in the United States, except that Google Workspace may store email you send us elsewhere (DPA Section 12.1). Our Privacy Policy lists the other providers we use for our own account, billing and website operations, such as Stripe, Cloudflare Turnstile, MaxMind and Fathom.
| Provider | Purpose | Data |
|---|---|---|
| Amazon Web Services | Hosting, storage, backups, email | Everything we store |
| Telecommunications data provider | Carrier, line type and porting lookups | The phone numbers being checked |
| Sentry | Error monitoring | Scrubbed error details |
| Google Workspace | Our email | Only data you choose to email us |
Certifications and testing
We don't yet have a SOC 2 or ISO 27001 report, or a third-party penetration test. In their place we provide this page, written answers to your security questionnaire and a countersigned DPA. Email legal@phonevalidator.com.
Your responsibilities
Some controls depend on you:
- Keep API keys secret, give each system its own key, and revoke keys you no longer use.
- Never put API keys in web pages or mobile apps.
- Accounts are single-user: there are no team seats, roles or single sign-on yet. For individual accountability, use a separate API key for each system or a separate account for each person.
- Turn on the second sign-in step for your account, use a shared business mailbox or keep the account email current when people leave, and remove passkeys and security keys you no longer use.
- Upload only the phone column, and don't send data the service doesn't need.
- Delete batches and lookups when you're done, if you don't want them kept for the full retention period.
- Tell us at security@phonevalidator.com if you suspect a key or account is compromised.
- Use results in line with our Acceptable Use Policy and the laws that apply to you.