The security questionnaire

The email arrives with a subject line like "Vendor security assessment" and a spreadsheet attached. If you have never seen one before, the first reaction is panic. Forty-odd questions about encryption, access controls, incident response, data retention. You built a web project, not a security programme.

The good news: most of these questions are not about your code. They are about your infrastructure. And infrastructure choices made early determine whether you can answer them at all.

What they are actually asking

Security questionnaires vary, but the categories are consistent:

• How is data encrypted at rest and in transit?
• How are credentials and API keys managed?
• Who has access to production systems, and is that access logged?
• What happens if something goes wrong at 3am?
• What is your backup strategy, and how long would a restore take?

None of these are trick questions. They are a checklist of controls that a reasonably careful operator would have in place. The problem is that "reasonably careful operator" implies infrastructure decisions most solo developers have never had reason to make.

The infrastructure gap

If you deployed to a basic VPS or a cheap shared host, the honest answers are uncomfortable.

Data encryption at rest: probably not configured explicitly. In transit: yes, if you remembered to set up TLS. Credential management: environment variables pasted into a dashboard somewhere, or a .env file you hope is in .gitignore. Access logs: whatever the platform provides by default, which is usually not much. Backup strategy: manual, occasional, undocumented.

Incident response: you. At whatever hour it happens. With no runbook.

This is not negligence — it is the natural result of building fast and not needing to answer these questions before now.

What changes when infrastructure does it

When the platform handles these things by default, the answers are different.

Secrets are stored in an encrypted vault and injected at runtime. They are not in your repository, not in your build logs, not in your deploy output. You can describe exactly how credential management works because there is a documented, consistent process — not "I think I pasted it in the dashboard last year."

Automated backups run on a schedule and are tested. You know your recovery point because the system has a defined one. Uptime monitoring runs continuously and alerts go somewhere before your users notice. Access to production is logged.

None of this requires a compliance programme. It requires infrastructure that makes good behaviour the default rather than a deliberate extra step.

The part that surprises people

Most developers assume the questionnaire is about code quality, testing, or development processes. Those sections exist, but they are usually short. The bulk of the document is about infrastructure: where data lives, how it is protected, who can touch it, and what happens if something goes wrong.

That is why switching to better infrastructure can change your answers without changing a single line of project code. The platform's properties become your properties.

---

Prodwise stores secrets in an encrypted vault, runs automated backups, and monitors every project continuously — on all plans. See what's included →