Talk to sales

Legal

Security

How this website is built and run, how we approach security on the systems we operate for clients, and how to tell us if you find something wrong.

Last updated 20 August 2026

This website

The site is static almost everywhere: pages are rendered at build time and served as files over HTTPS. That removes most of the attack surface a conventional CMS carries, because for the majority of routes there is no server-side code, no database and no admin login to compromise.

  • No third-party scripts. No analytics, tag managers, advertising or social embeds. The site makes no requests to any domain other than its own.
  • No cookies, and no storage written unless you change the theme.
  • One server endpoint — the contact form. Everything else is a static file.
  • TLS is terminated at the edge by our host, with certificates renewed automatically.

The contact form

It is the only place the site accepts input, so it is the part worth describing precisely.

  • Every field is validated on the server, not only in the browser. Client-side checks are a convenience; they are never the control.
  • A hidden honeypot field catches automated submissions. Bots receive an ordinary success response and nothing is sent, so they get no signal to adapt to.
  • Nothing is stored. There is no database behind the form. Your message is delivered as email and the site retains no copy.
  • The email credential is send-only — it can dispatch a message but cannot read, list or inspect anything. If it leaked, it could not be used to retrieve past enquiries.
  • If the form is misconfigured it fails loudly with an error rather than silently accepting and discarding an enquiry.

Secrets and access

  • Credentials are never committed to version control. They are held as environment variables in the hosting platform, and local development files containing them are excluded from git.
  • API keys are scoped to the narrowest permission that does the job.
  • Access to production is limited to the people who need it, and removed when they do not.

How we approach client systems

The same reasoning applies to what we build and operate for clients, adjusted to what each system actually needs:

  • Infrastructure defined as code and changed through review, so what is running is inspectable and reproducible rather than assembled by hand in a console.
  • Managed platform services in preference to self-administered servers, so patching is handled by the platform rather than depending on someone remembering.
  • TLS everywhere, and a web application firewall at the edge where the design calls for one.
  • Least-privilege identities between services rather than one shared credential.
  • Dependencies updated deliberately, not left to drift for years.
  • Backups with tested restores — an untested backup is a guess, not a safeguard.
  • Logging and alerting that a human actually receives, because we operate what we build.

What we do not claim

MindStack does not hold SOC 2, ISO 27001, or any other third-party security certification, and this page is not an audit. We are a small team and we would rather say that plainly than imply coverage we do not have.

If your procurement process requires an audited framework, a signed security questionnaire, or contractual terms such as a data processing agreement, raise it early. We will tell you directly what we can meet, what we cannot, and what it would take — before you spend time on a process that cannot conclude.

Reporting a vulnerability

If you find a security problem in this site or in something we built, please tell us at saurabnand951@gmail.com. Include enough detail to reproduce it. We will acknowledge within one business day and keep you informed while we fix it.

We ask that you give us a reasonable chance to fix an issue before publishing it, and that you do not run automated scans against production systems, access or modify data belonging to other people, or degrade service for anyone else while testing. Report in good faith and we will treat you the same way.