Trust & Security

Security Is How We Build, Not What We Sell

We build threat detection tools. Our own infrastructure is held to the same standard we help customers achieve. This page describes our controls, data architecture, and responsible disclosure process. We are not a managed security provider — ThretVyn does not perform incident response on your behalf.

Security Controls

Built With Security Controls in Mind

ThretVyn is designed with SOC 2 security controls as a guiding framework — including access control, encryption, change management, and incident response procedures. We are independently built and in early commercial operation; formal third-party SOC 2 Type II audit certification is on our roadmap. We do not claim SOC 2 certification at this time.

🔒
Encryption at Rest and in Transit

All customer data encrypted at rest using AES-256. All data in transit uses TLS 1.2 minimum, TLS 1.3 where supported. Keys managed via AWS KMS with quarterly rotation.

👤
Access Control

Role-based access control (RBAC) with least-privilege enforcement. Privileged access to production systems requires multi-factor authentication and is logged and reviewed weekly.

🏗️
Infrastructure Security

Hosted in AWS us-east-1. Network segmentation via VPC with private subnets for processing workloads. Security group rules reviewed quarterly. No direct internet access to processing layer.

📊
Logging and Monitoring

All administrative API calls logged via AWS CloudTrail. Application-level security events forwarded to centralized log system. Anomalous access patterns trigger automated review.

🔄
Incident Response

Written incident response procedures with defined severity levels. Security incidents escalated to CEO and notified to affected customers within 72 hours of confirmed impact.

🛡️
Dependency and Vulnerability Management

Dependencies scanned for known CVEs on every commit via automated pipeline. Critical CVEs remediated within 48 hours of disclosure. High severity within 7 days.

Data Architecture

What Data We Process

Understanding exactly what ThretVyn ingests, stores, and processes is fundamental to evaluating our security posture — and your own. We process event metadata and normalized security signals, not raw log files, user documents, or credential material. The table below describes precisely what we collect from each source type and what we do not.

SourceWhat We IngestWhat We Do NOT Store
EDR Detection events, process IDs, file hashes, technique codes Raw endpoint disk contents, user documents
Cloud Trail API call names, IAM role ARNs, timestamps, source IPs Request/response payloads, S3 object contents
Identity Auth event type, username, geo, device fingerprint Passwords, MFA seeds, session tokens
Vulnerability Disclosure

Responsible Disclosure Policy

ThretVyn welcomes responsible disclosure from security researchers. If you have identified a potential vulnerability in our product or infrastructure, please report it privately before public disclosure. We review all reports and acknowledge receipt within 24 hours. Confirmed issues are remediated within 30 days for critical severity, 7 days for high severity.

To report a security issue, email [email protected] with a description of the vulnerability, steps to reproduce, and your contact information. Include any proof-of-concept details that help us reproduce and triage. We do not take legal action against researchers acting in good faith under coordinated disclosure.

We do not operate a public bug bounty program at this time. We acknowledge all valid reports and will coordinate on public disclosure timing with the reporting researcher.

Report a Vulnerability