On this page
1. Infrastructure
- Primary hosting: Amazon Web Services, ap-south-1 (Mumbai). Data residency for all production user data is in India.
- AI evaluation: Assessment text is transmitted to Anthropic's Claude API (US) for scoring. Disclosed in-product before each assessment. Anthropic does not train on data submitted via their API.
- DNS & edge: DNSSEC-enabled DNS provider with DDoS protection at the edge.
- Environment isolation: Production, staging, and development environments are fully isolated. Engineers have no default production access.
2. Encryption
- In transit: TLS 1.3 for all client-server connections. HSTS enforced. TLS 1.2 accepted only for legacy compatibility; TLS 1.0 and 1.1 blocked. All API-to-API traffic (us → Anthropic, us → payment processor) uses TLS 1.3.
- At rest: AES-256 encryption for all data at rest, including databases, object storage, and backups. Keys managed via AWS KMS with periodic rotation.
- Passwords: Stored using Argon2id with per-user salt. Never logged, never transmitted, never viewable by our team.
- Secrets: Application secrets are stored in a dedicated secret manager, rotated on a schedule, and never committed to source control.
3. Access controls
- Least privilege: Internal access to production is restricted to a small, named set of engineers with business need. Reviewed quarterly.
- MFA: Mandatory multi-factor authentication on all internal tools (source control, cloud console, observability, email).
- Audit logging: All production access and privileged actions are logged to an immutable audit trail with 12-month retention.
- Session management: Sessions expire after inactivity. Active sessions can be revoked from your account settings. Suspicious logins trigger re-authentication.
- B2B SSO: SAML and OIDC SSO (Google Workspace, Microsoft Entra) available on Enterprise plans. SCIM provisioning on roadmap.
4. Application security
- Secure development: Code review required on every change. Branch protection on main branch.
- Dependency scanning: Automated vulnerability scanning on all third-party dependencies on every pull request and daily.
- Static analysis: SAST tooling runs on every pull request for common security issues.
- Web application defenses: CSRF tokens, Content Security Policy headers, SameSite cookies, input validation, output encoding, rate limiting on authentication and scoring endpoints.
- Penetration testing: External penetration test on roadmap before SOC 2 audit.
5. Data handling
- Tenant isolation: B2B customer data is logically isolated per account. No cross-tenant reads in application queries.
- Backups: Encrypted daily backups with 30-day retention. Quarterly restore testing.
- Data residency: Production data remains in ap-south-1 (Mumbai). Customers requiring specific residency beyond this should contact sales before subscribing.
- Data deletion: Account deletion removes personal data within 30 days. Anonymized usage data may be retained for product improvement.
- Exports: Self-service JSON and CSV exports available from account settings.
6. Assessment integrity controls
These are specific to our product — they protect the scoring signal, which is the thing customers pay us for:
- Copy-paste is disabled on all answer inputs
- Forward-only navigation — candidates cannot revise an answer after seeing the next question
- Architecture diagrams are drawn from a pool and selected randomly per session
- Adaptive AI follow-ups prevent pre-prepared or generic AI-generated answers from scoring well
- Continuous timer — no pause option — to prevent long external research windows
- Session tokens bind a specific assessment to a specific candidate and cannot be shared
7. Incident response
- IR plan: We maintain a written incident response plan covering detection, triage, containment, eradication, recovery, and post-mortem.
- Breach notification: If we confirm a personal-data breach affecting your account, we will notify you within 72 hours of confirmation, in line with GDPR Art. 33 and DPDPA 2023 requirements.
- On-call: A designated on-call engineer responds to security alerts. Escalation paths are documented.
- Post-incident: We publish redacted post-mortems for any incident that affects customers.
8. Compliance & attestations
- GDPR: Aligned. See our Privacy Policy for data subject rights and legal bases.
- India DPDPA 2023: Aligned. Grievance Officer contact is listed in our Privacy Policy.
- SOC 2 Type 1: On roadmap. Planned audit in 2026.
- ISO 27001: Under evaluation based on customer demand.
11. Landing page protections
Even before signup, this marketing site (threatready.io) applies abuse protections so signup forms, the demo, and the auth modal cannot be used to attack our infrastructure or yours.
- Content Security Policy: The page enforces a CSP that limits where scripts, styles, fonts, and images can come from.
frame-ancestors 'none'prevents the page from being framed for clickjacking. - Form rate limiting (client-side): Email submissions through the auth modal, newsletter signup, and demo evaluation are rate-limited per browser session — 5 auth attempts per minute, 3 newsletter submissions per 5 minutes, 5 demo evaluations per 5 minutes. The product backend enforces stricter, IP-based limits independently.
- Honeypot fields: Hidden fields invisible to humans but filled in by automated bots cause submissions to be silently dropped.
- Input validation: Email addresses are validated against RFC-aligned patterns and length caps before being forwarded. Demo answer text is capped at 5,000 characters.
- Parameter sanitisation: All values forwarded from the landing page to the product (mode, plan, email, provider) are character-class restricted and length-capped before
encodeURIComponentto prevent URL-injection. - External links: All links opening new tabs include
rel="noopener noreferrer"to prevent reverse tabnabbing. - Permissions Policy: Geolocation, camera, and payment APIs are disabled at the document level. Microphone is allowed only because the demo offers voice input — and is stopped automatically when you switch tabs.
- No password capture: The landing page never accepts passwords. The auth modal forwards an email to the product app, which handles authentication on its own domain.
Real enforcement of rate limits, abuse detection, and account security happens server-side in the product backend. The protections on this page slow down casual abuse and reduce the load that reaches our APIs.
9. Responsible disclosure
We welcome good-faith security research. If you believe you have found a vulnerability in ThreatReady, please report it to us privately:
- Email: [email protected]
- Encryption: PGP key available on request (to be published at /.well-known/security.txt)
- Response SLA: Acknowledgement within 2 business days. Initial assessment within 7 business days.
Safe harbor
We will not pursue legal action against researchers who:
- Report in good faith and give us reasonable time to fix before public disclosure (at least 90 days unless actively exploited)
- Do not access, modify, or exfiltrate data beyond what is necessary to demonstrate the issue
- Do not use the vulnerability to disrupt service for others
- Do not attempt social engineering of our staff
Out of scope
- Denial-of-service attacks (do not test these)
- Brute-force or rate-limit testing against production
- Reports based on outdated third-party libraries without a demonstrable exploit
- Missing best-practice headers without evidence of exploitability (nice-to-know, not in scope for bounty)
We currently do not run a paid bug bounty program, but we credit reporters publicly in our security acknowledgements unless they prefer anonymity.
10. Security contact
For security disclosures: [email protected]
For business inquiries about security posture, SIG / CAIQ / security questionnaires: [email protected]