The data we hold is not ours. We treat it that way.

softsight.ai is a Next.js marketing site hosted on Vercel’s global edge network. There is no public database behind it, no end-user accounts, and no admin panel exposed to the internet. The attack surface is small by design.

• TLS everywhere. All traffic uses TLS 1.2 or higher. HTTP requests redirect to HTTPS. HSTS is enabled with a one-year max-age and the includeSubDomains directive.
• Strict security headers. Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and frame-ancestors restrictions are set at the edge.
• No third-party trackers. No Meta Pixel, no LinkedIn Insight Tag, no session replay, no fingerprinting SDKs. Analytics are cookieless and aggregated.
• Form submissions over HTTPS to vetted sub-processors. The demo, beta, careers, and ROI calculator forms transmit directly to Formspree over TLS, with a copy written to a private Google Sheet for internal review. No form data touches a SoftSight-owned server.
• No secrets in the browser. API keys for third-party services are encrypted environment variables on Vercel and are not exposed to client-side code.
• Bot defence and DDoS mitigation. Provided at the edge by Vercel’s platform.

The AI Project Manager (AIPM) and SurveyGuard products run separately from the marketing site, on cloud infrastructure with stronger isolation and tighter controls.

Network and infrastructure

• Production systems run inside a private VPC. Application services are not directly reachable from the public internet — only specific HTTPS entry points are exposed via a managed load balancer.
• Internal service-to-service traffic is encrypted in transit. Databases live on private subnets with no public IP.
• Workload identities are short-lived. Long-lived credentials are avoided in favour of scoped, rotating tokens.
• Production, staging, and development environments are fully isolated. Customer data does not move into non-production environments under any circumstances.

Application security

• Authentication uses industry-standard protocols (OAuth 2.0 / OIDC). Passwords, where they exist, are hashed with a modern KDF (Argon2 family). MFA is supported and required for administrative roles.
• Authorisation is enforced at the API tier. Tenant isolation is row-level in the database, with foreign-key constraints on tenant identifiers for every record that contains customer data.
• Input validation, output encoding, parameterised queries, and modern framework defaults defend against injection and XSS classes of bugs.
• Rate limiting and abuse detection apply at every public endpoint.

SurveyGuard specifics

SurveyGuard’s 15 detection layers process respondent telemetry in under 200 milliseconds at the entry point of every survey. Detection thresholds are not configurable downward for commercial reasons — that commitment is also written into our Terms of Service. The reputation network is built from cross-survey signals and never identifies individual respondents to other customers.

Encryption

• In transit. TLS 1.2 minimum, TLS 1.3 preferred, on every external and internal hop that crosses the network.
• At rest. AES-256 on database storage, object storage, backups, and log archives. Disk encryption is enabled at the cloud-provider layer.
• Key management. Encryption keys are managed in a cloud-provider KMS, with rotation policies and audit trails on every use.

Backups and durability

• Customer data is backed up daily. Point-in-time recovery is enabled for transactional databases.
• Backups are encrypted, replicated across availability zones, and tested by restore drill on a documented cadence.

Retention and deletion

• Customer data is retained for the term of your subscription. On termination, we make data available for export for 30 days and then delete it within an additional 30 days, except where applicable law requires longer retention.
• Marketing-site form submissions are retained per the periods in our Privacy Policy.
• Aggregated, de-identified statistics produced from customer data may be retained indefinitely. They cannot be reverse-engineered to identify a customer, supplier, project, or respondent.

• No standing access. No engineer or operator has continuous, unprivileged-by-default access to customer data in production. Access for a specific incident or feature is requested in writing, time-boxed, granted by a separate approver, logged, and revoked automatically.
• Strong authentication. SSO for internal tools where supported. Phishing-resistant MFA (security keys or platform authenticators) is required on every account that touches production or personal data.
• Device hygiene. Company-issued laptops are managed, encrypted, screen-locked, and required to run current OS versions. Personal devices are not used for production access.
• Joiners, movers, leavers. Access is provisioned through a documented checklist on hire, reviewed quarterly, and revoked the same day a team member leaves. Quarterly access reviews are recorded.
• Audit logging. Production access, configuration changes, and security-sensitive events are logged to an append-only store with retention separate from production credentials.

• Code review. Every production change goes through peer review before merge. Security-sensitive changes (authentication, authorisation, payments, detection logic) require a second reviewer with explicit security ownership.
• Dependency hygiene. Automated vulnerability scanning on every pull request. Critical and high-severity advisories are triaged within one business day.
• Static and dynamic analysis. Linting, type checking, and static security analysis run in CI. Dynamic application security testing is run against staging on a documented cadence.
• Secrets management. Secrets live in a managed secrets store, never in source control. Secret scanning is enabled at the repository and CI level.
• Branch protection. Direct pushes to the main branch are forbidden. Signed commits are required for protected branches.
• Penetration testing. External penetration testing is scheduled annually once the platform reaches general availability, with findings tracked to remediation.

We maintain a written incident response plan covering detection, triage, containment, eradication, recovery, and post-incident review. The plan is rehearsed at least twice a year.

• Detection. Monitoring covers platform health, anomaly detection on authentication and access patterns, dependency advisories, and abuse signals on public endpoints.
• Containment. An on-call engineer is reachable around the clock for production-impacting security events. The first responder has the authority to contain (revoke credentials, rotate keys, take an endpoint offline) without waiting for further approval.
• Customer notification. If we experience a personal data breach affecting your information and likely to result in a risk to your rights, we will notify you and any competent supervisory authority within the timelines required by applicable law (typically within 72 hours under GDPR). Notifications are written by a human on the founding team, not a template.
• Post-incident review. Every security incident — successful or not — gets a blameless retrospective and an action list. Material lessons are reflected in this page on the next review.

We rely on a small set of named sub-processors. We’ve chosen each one because their security and privacy posture is mature, and we keep this list current alongside our Privacy Policy.

We do not sell or rent personal data, and we do not share it with advertising networks. Vendor changes are reflected here, on the Privacy Policy, and notified by email to enterprise customers in advance where contractually required.

We’re early-stage and we say so. Rather than imply certifications we don’t yet hold, here’s exactly where each one is.

If your procurement process needs evidence we don’t yet have a certification for — questionnaires, architecture diagrams, control mappings — write to security@softsight.io and we’ll respond with what we can share under NDA.

We welcome reports from researchers and engineers who find security issues in our systems. We will not pursue legal action against anyone who reports in good faith and follows the guidance below.

Safe harbour

• Test only against accounts and assets you own or have explicit permission to test.
• Do not access, modify, or delete customer data beyond what’s necessary to demonstrate the issue.
• Do not run denial-of-service tests, send mass phishing, social-engineer SoftSight staff, or test physical security.
• Do not publish a vulnerability before we’ve had a reasonable chance to remediate it — we aim for 90 days from acknowledgement, faster for critical issues.

Out of scope

• Findings from automated scanners without a working proof of concept;
• Missing security headers without a demonstrable exploit;
• Social-engineering of staff, suppliers, or respondents;
• Issues in third-party services we use (please report to them directly);
• Self-XSS, clickjacking on non-sensitive pages, and other low-severity classes without a meaningful impact.

Recognition

We don’t currently run a paid bounty programme, but we maintain a researcher recognition list and will credit your work — with your permission — on a future security acknowledgements page. As the company grows, paid bounties will follow.

• Security issues and vulnerability reports: security@softsight.io
• Privacy and data subject requests: privacy@softsight.io
• Legal and contractual questions: legal@softsight.io
• Vendor security reviews and questionnaires: security@softsight.io — we’ll respond under NDA where required.