Security Policy

At WHYUSER, INC, we understand that we are processing highly sensitive Go-To-Market assets and proprietary sales intelligence. We will use commercially reasonable efforts to secure the Cloud Service from unauthorized access, alteration, or use and other unlawful tampering.

This document outlines the technical and organizational security measures we employ to protect Customer data.

1. "Privacy-First" Ingestion Architecture

WhyUser employs a 'Privacy-First' ingestion architecture. All unstructured data (e.g., Gong/Chorus transcripts) is programmatically redacted for Personally Identifiable Information (PII) at the ingestion layer (in volatile memory) before simulation processing occurs.

• No Raw Storage on Disk: We do not store raw sales transcript audio or full text files on disk; these are processed in volatile memory and immediately purged following signal extraction.
• Data Minimization ("Extraction-Only"): WhyUser employs an 'Extraction-Only' philosophy. Our ingestion engine surgically isolates only the specific business pain points, objections, and roles required for simulation calibration. All non-essential data, including names, contact details, and unrelated conversational filler, is programmatically discarded before the data enters our Context Graph.

2. Multi-Tenancy & Tenant Isolation

WhyUser's production platform is multi-tenant. Customer data is isolated at multiple layers:

• Storage: Each Customer is assigned a unique tenant identifier (prefix "t-"). All per-Customer data resides exclusively under that Customer's dedicated S3 prefix (e.g., s3://bucket/t-{tenant_id}/). Data belonging to different tenants resides under different, non-overlapping prefixes.
• Application: All reads, writes, and list operations are scoped by the authenticated tenant_id. No application code path supports cross-tenant reads in the ordinary course of business.
• Public Access: All S3 buckets have Block Public Access enabled at the account and per-bucket level. Bucket policies restrict access to authenticated service accounts only.

3. Encryption Standards

We mandate strict encryption protocols for all data traversing our systems or residing within our infrastructure:

• Data in Transit: All data transmitted between the Customer environment and the WhyUser platform is encrypted using industry-standard Transport Layer Security (TLS 1.2 or higher). We utilize secure API tunnels for all third-party integrations (e.g., Gong, Chorus). TLS is terminated at our Caddy edge reverse proxy; internal service-to-service traffic is confined to an internal Docker network.
• Data at Rest: Persistent data is encrypted at rest using AES-256 via AWS S3 Server-Side Encryption (SSE-S3). Compute instance block storage is encrypted.
• Key Management: Encryption keys are managed by AWS under WhyUser's AWS account. API keys and service credentials are stored in encrypted secrets storage and rotated on personnel change and on scheduled intervals.

4. Infrastructure & Edge Hardening

Our Cloud Service is hosted exclusively on Amazon Web Services (AWS) — AWS Lightsail Ubuntu compute instances and AWS S3 storage, in US-based regions only. AWS maintains SOC 2 Type II, ISO 27001, and FedRAMP certifications for its infrastructure services.

• Network: Instance firewalls restrict inbound traffic to HTTPS/443 and administrative SSH only. Administrative SSH access requires key-based authentication; password authentication is disabled at the host level.
• Edge Hardening: Our edge reverse proxy applies response security headers on all responses — Strict-Transport-Security (with preload and includeSubDomains), X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, and Referrer-Policy. The reverse-proxy administrative API is disabled. The Server identity header is stripped.
• Service Segmentation: Only the edge reverse proxy is bound to a public network interface. Application and data-plane services are not directly reachable from outside the host.

5. Access Control

• Least Privilege: IAM policies for all application and human access to AWS resources follow a least-privilege model. Only authenticated service roles can access Customer data S3 prefixes.
• Multi-Factor Authentication: MFA is required for the AWS root account and all IAM console users, as well as for source control (GitHub) and identity provider consoles.
• Access Reviews: Access is reviewed on personnel change and on a scheduled cadence at least annually.

6. Subprocessor & LLM Security

WhyUser leverages industry-leading Large Language Models (LLMs) to power our simulations. We enforce the following strict boundaries with our AI subprocessors (OpenAI, Anthropic, Google):

• Zero-Day Retention: Data processed via foundational LLM APIs is subject to zero-day retention.
• No Base Model Training: Data processed via API is not used for base model training.
• Outbound-Only Egress: LLM API calls are initiated from our processing tier only; no inbound path from LLM providers into WhyUser exists.

7. Vulnerability Management

• Continuous External Scanning: WhyUser uses Intruder.io for continuous automated external vulnerability scanning, integrated with Vanta for evidence automation.
• Dependency Scanning: GitHub Dependabot monitors open-source dependencies for known vulnerabilities in real time.
• Secret Scanning: Gitleaks enforces pre-commit secret detection locally and as a CI safety net on every pull request.
• Remediation Targets: Critical findings are addressed as soon as practicable; high-severity findings within 30 days; medium within 90 days.
• Manual Penetration Testing: An independent third-party manual penetration test is planned prior to General Availability.

8. Logging & Monitoring

• Management-Plane Events: AWS CloudTrail captures management-plane (API) events for the WhyUser AWS account.
• Edge Access Logs: Our edge reverse proxy emits JSON-formatted access logs captured by the container log driver.
• Storage Access Logs: S3 server access logging is enabled on the Customer-data bucket, with a lifecycle policy retaining logs for 12 months.
• Vulnerability Telemetry: Intruder.io provides continuous external scan results and alerts on newly discovered vulnerabilities.

9. Incident Response & Breach Notification

WhyUser maintains a documented Incident Response Policy with four severity levels and a defined six-phase response flow (Detect → Triage → Contain → Eradicate → Recover → Post-Incident Review).

For any confirmed Personal Data Breach affecting a Customer, WhyUser will notify the affected Customer without undue delay, and in any event within 72 hours of confirming the breach. Disclosure is subject only to delays specifically required by law enforcement or legal process.

10. Audits & Compliance

WhyUser is pre-SOC 2. Our Cloud Service is hosted exclusively on Amazon Web Services (AWS) infrastructure — Lightsail compute and S3 storage, US-based regions only — which maintains SOC 2 Type II, ISO 27001, and FedRAMP certifications. AWS's SOC 2 Type II report is available on request via AWS Artifact.

A Data Protection Addendum (DPA) is available at whyuser.com/dpa. For enterprise engagements, WhyUser offers a custom DPA in the Bonterms framework on request. WhyUser will complete your organization's standard vendor security questionnaire upon request.

Formal SOC 2 attestation will be pursued as driven by customer requirements, contractual obligations, and business stage.

For audit rights, security assessments, or to request our DPA, contact security@whyuser.com.

11. Security Inquiries & Vulnerability Reporting

If you have questions about our security practices, or if you believe you have discovered a vulnerability in our Service, please contact our security team immediately at security@whyuser.com. We will acknowledge reports within 5 business days.