Privacy at ThreatPosture.
ThreatPosture uses customer and operational context to provide protective-intelligence decision support while treating customer-specific information as distinct from public-source intelligence.
Collect what is needed to provide and secure the service.
Depending on how you use ThreatPosture, information may include account and authentication details, organization and protected-profile details, policy or procedure documents you choose to provide, demo/contact information, readiness actions and decision history, user actions and service/technical records used to operate, secure and troubleshoot the platform.
ThreatPosture also processes publicly available and authorized external information for protective-intelligence analysis, including public reporting, public social content, official weather and hazard information, public events and other lawful open-source material. Public-source material and customer-private operational context are intentionally treated as different evidence classes.
ThreatPosture is not designed to harvest guest or employee PII from customer systems, and customers should not provide unnecessary personal information. The service does not require internal guest lists, employee files, credentials or private surveillance feeds to provide its core open-source protective-intelligence function.
Use customer information for the service and its security.
Customer information may be used to create and administer accounts, configure protected profiles, generate profile-specific intelligence and decision support, process customer-provided policy context, preserve readiness history, deliver requested communications, maintain security, investigate service issues and improve reliability and product quality.
Customers should provide only information they are authorized to provide and should avoid entering unnecessary sensitive information into public website forms.
Customer context is intended for authorized users and approved service paths.
ThreatPosture uses authenticated access, organization/protected-profile authorization boundaries and database row-level security for customer-specific product data. Privileged service credentials remain server-side and are not exposed to the browser.
Access-control design and current security posture are described on the Trust & Security page.
Specialized providers support the service.
Core providers currently include Vercel for web application hosting and delivery, Supabase for database and authentication infrastructure, Resend for transactional email, and OpenAI services for AI-assisted analysis. Additional public information sources may be processed as part of the protective-intelligence service.
Retention should follow service, security, contractual and legal needs.
Retention periods can differ by data type and customer relationship. Readiness history is intentionally persistent so authorized customers can preserve continuity and after-action context; it should not be treated as an immutable legal record. Contract-specific retention or deletion requirements should be documented in the applicable customer agreement or data-processing terms.
ThreatPosture is still formalizing automated retention and verified-deletion procedures. Until those controls are operationally validated, we do not claim a universal automatic deletion period.
Applicable privacy rights depend on jurisdiction and relationship.
Where applicable law provides access, correction, deletion, portability or opt-out rights, ThreatPosture will evaluate properly submitted requests and respond as required. Privacy and account-support requests may be sent to support@threatposturehq.com.
This notice should match the product we actually operate.
ThreatPosture may update this notice as the service, commercial relationships, subprocessors and legal requirements evolve. Material promises should be reflected in actual operating controls rather than added as unverified marketing claims.
Current public notice updated August 25, 2026.