Vulnerability Disclosure Policy
Vulnerability Disclosure Policy
At PsyData Labs L.L.C. ("PDL"), the security and privacy of our systems, networks, and the sensitive behavioral and psychological data we process are foundational to our operations. We recognize the invaluable role the independent security research community plays in helping us maintain a robust security posture. This Vulnerability Disclosure Policy (VDP) outlines our expectations, the defined scope of our program, and the coordinated process for reporting security vulnerabilities.
1. Safe Harbor Authorization
PDL considers activities conducted consistently with this policy to constitute "authorized" conduct under the Computer Fraud and Abuse Act (CFAA), the NY SHIELD Act, and similar state and international computer misuse laws. We will not initiate legal action or law enforcement investigations against security researchers who strictly adhere to this policy. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will formally state that your actions were authorized by PDL. Furthermore, we will not bring any claim against you for circumvention of technology controls under the Digital Millennium Copyright Act (DMCA) for good-faith security research.
2. Program Scope
2.1. In-Scope Assets
The following technical assets and environments are explicitly in-scope for security research and testing:
- Production Cloud Environments: Hosted applications, APIs, and microservices directly managed by PDL within our designated production Virtual Private Clouds (VPCs).
- AI and Inference Systems: Data processing pipelines, batch jobs, and models evaluating Behavioral Data (D-BEH), Psychological Signals (D-PSY), and Inference Outputs (D-INF).
- Research Enclaves: Approved internal research environments, telemetry aggregation points, and secure data notebooks.
- Staging Environments: Only staging architectures explicitly tagged as S1 (which process strictly synthetic data). All other staging or UAT environments are out-of-scope.
2.2. Out-of-Scope Assets
The following assets are strictly prohibited from security research and testing:
- Third-party SaaS applications, infrastructure providers, and vendor subprocessors (Testing must be limited strictly to PDL-owned implementations and configurations).
- Any staging, testing, or UAT environments containing restricted production data (S2 or S3+ classification) that are not explicitly tagged as S1.
- Client, partner, or third-party endpoint devices and networks.
- Systems managing physical building security or corporate IT infrastructure not directly tied to the PsyData platform.
2.3. Out-of-Scope Vulnerabilities
Please refrain from testing or reporting the following types of vulnerabilities, as they carry unacceptable risks to our operations and do not qualify for this program:
- Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks, or any testing that degrades service reliability (SLO policies).
- Social engineering attacks (e.g., phishing, vishing, tailgating) directed at PDL employees, contractors, clients, or research participants.
- Physical security testing of PDL facilities.
- Vulnerabilities requiring physical access to a user's device, or Man-in-the-Middle (MitM) attacks on a user's local network.
- Missing HTTP security headers, TLS configuration weaknesses, or DNS configuration issues (e.g., SPF/DMARC) that do not result in a demonstrably exploitable vulnerability.
- Spamming, automated vulnerability scanner reports, or volumetric alerts without verifiable proof of concept (PoC).
3. Code of Conduct and Expectations
When conducting security research on PDL systems, you are required to adhere to the following rules of engagement:
- Data Protection: Make every effort to avoid privacy violations, destruction of data, and interruption or degradation of our services. You must only interact with test accounts you own or accounts where you have explicit, documented permission from the account holder.
- Strict Prohibition on Data Exfiltration: You must never access, download, modify, or exfiltrate sensitive data. If you inadvertently encounter or gain access to High-Risk Psychological Profiles (H-RP), special-category data, or raw psychological signals, you must halt testing immediately and notify us.
- Compliance: Comply with all applicable federal, state, and international laws and regulations.
4. Reporting Guidelines
If you believe you have discovered a security vulnerability, please submit a detailed report to our Security and Compliance teams at security@psydatalabs.com. We highly recommend using PGP encryption for all communications. Your report must include:
- A clear, concise description of the vulnerability and its potential impact.
- Step-by-step instructions to reliably reproduce the issue, including proof-of-concept (PoC) scripts, screenshots, or sanitized HTTP requests/responses.
- The specific assets, URLs, or IPs affected.
- Your contact information for remediation coordination.
5. Service Level Agreement (SLA) Timelines
PDL aligns its vulnerability remediation targets with SOC 2 (TSC CC6), ISO/IEC 27001:2022, and the NY SHIELD Act. We commit to the following transparent SLA timelines for valid, reproducible reports:
- Initial Acknowledgment: Within 48 hours of report submission.
- Triage & Categorization: Within 3-5 business days.
- Remediation Targets (Based on NIST/CVSS Risk Tiering):
- Critical Severity (e.g., IAM bypass, network segmentation failure, cryptographic control compromise): Remediated within 7 calendar days.
- High Severity: Remediated within 30 calendar days.
- Medium Severity: Remediated within 60 calendar days.
- Low Severity: Remediated within 90 calendar days.
6. Confidentiality and Coordinated Disclosure
PDL operates strictly under a coordinated disclosure model. To protect our research participants, clients, and intellectual property, we request that you maintain absolute confidentiality regarding any discovered vulnerabilities until we have explicitly confirmed that the issue has been remediated. Public disclosure prior to remediation authorization places sensitive behavioral data stores at risk and violates the safe harbor terms of this policy. Once remediation is validated, public disclosure and attribution can be coordinated with the PDL Security Lead.