Book a call
All talks and takeaways

Answer bank

The security questionnaire answer bank

Thirty supplier security questions with model answers and the evidence behind each one, so the next questionnaire starts from proof.

A startup that returns a security questionnaire in two days with evidence beats one that needs six weeks. I'm starting to see the same thirty questions in a lot of NIS2-flavoured questionnaires, phrased a little differently each time. Each answer below is a template with brackets for the real facts. An answer only belongs in a reply when the evidence under it exists.

From the talk: NIS2 for startup engineers: what to build first

Governance and risk

Who in your company is accountable for information security?
[Name, role] is accountable. The founders approve the security policy and review the risk register every [twelve] months.
Evidence: The signed policy and the dated risk register.
Do you have an information security policy?
Yes. It covers access, data handling, incidents, suppliers, and secure development. Management approved it on [date].
Evidence: The policy with its approval date.
How do you assess security risk?
We keep a risk register that rates each risk by likelihood and impact, with an owner and a treatment. We review it every [quarter].
Evidence: The register and the minutes of the last review.
Has your management body had security training?
Yes. The founders completed [course] on [date].
Evidence: Completion records.
Do you hold a certification such as ISO 27001 or SOC 2?
Not yet. Our controls follow NIS2 article 21, and we share the evidence for each control on request. [We plan certification by date.]
Evidence: A control-by-control evidence index.

Access and identity

How do employees sign in to production systems?
Through single sign-on, with MFA enforced at the identity provider, [provider]. We don't use shared accounts.
Evidence: The identity provider's MFA policy and the list of users.
Do you use multi-factor authentication?
Yes, for every human account. Admins use phishing-resistant MFA ([passkeys or hardware keys]).
Evidence: MFA enforcement settings and an admin list with their factors.
How do you manage privileged access?
We grant admin rights per role, for a limited time, and review them every [quarter]. One sealed break-glass account raises an alarm when anyone uses it.
Evidence: Role definitions, the last access review, and the break-glass alarm rule.
How quickly do you remove access when someone leaves?
On their last working day. We remove access in the identity provider, which removes it from every connected system.
Evidence: The offboarding checklist and a recent offboarding record.
Do your systems use long-lived credentials?
No. Workloads use roles, and our CI/CD deploys through OIDC with short-lived credentials.
Evidence: The IAM credential report showing no active user access keys.

Data protection

Where is our data stored and processed?
In [cloud provider] [region], in the EU. A policy blocks other regions. The provider handles account metadata and billing in [locations].
Evidence: The data map, the region policy, and the sub-processor list.
Is data encrypted?
Yes. At rest with [AES-256] keys we manage in [KMS], and in transit with TLS 1.2 or higher.
Evidence: Encryption settings per data store and the TLS policy.
Who manages the encryption keys?
We do, in [KMS], with key rotation on and key use logged.
Evidence: The key policy and rotation settings.
How do you back up data?
We take daily encrypted backups, copy them to an isolated account with deletion protection, and keep them for [35] days.
Evidence: The backup plan and the vault lock setting.
Have you tested restoring from backup?
Yes. Our last restore test, on [date], took [duration].
Evidence: The dated restore test record.

Detection and incidents

How do you detect security incidents?
Managed threat detection ([GuardDuty]) runs in every account. Audit logs go to a separate, write-once log archive. [Five to ten] high-signal alerts page the on-call person.
Evidence: Detector settings, the alert list, and the paging rota.
How long do you keep logs?
We keep audit logs for [twelve] months in a separate account that application staff can't change.
Evidence: Retention settings and the bucket's object lock.
Do you have an incident response plan?
Yes. It names the roles and the decision owner. It covers the NIS2 24-hour, 72-hour, and one-month reporting deadlines and GDPR breach notification.
Evidence: The runbook.
How soon will you notify us of an incident that affects our data?
Within [24] hours of becoming aware, and sooner where our contract with you says so.
Evidence: The runbook and the contract clause.
When did you last test your incident response?
On [date], with a tabletop drill. The decision on significance took [time].
Evidence: The drill record with its findings.

Development and vulnerabilities

Describe your secure development process.
Every change goes through a pull request with review, automated tests, dependency review, secret scanning, and static analysis before it can merge.
Evidence: Branch protection settings and a sample pull request.
Is your infrastructure defined as code?
Yes, in Terraform. Only the pipeline applies it, after review.
Evidence: The repository and the pipeline configuration.
How do you handle vulnerabilities in dependencies?
Automated alerts and update pull requests. We fix critical issues within [7] days and high ones within [30].
Evidence: The patch policy and the alert history.
Do you have penetration tests done?
[Yes. An independent firm last tested us on date. / Not yet.] We run continuous posture checks against the CIS benchmark and fix the findings in code.
Evidence: The posture report, and the external test summary where one exists.
How do you separate production from development?
Separate cloud accounts, with no production data or production credentials outside production.
Evidence: The account structure and the access policy.

Suppliers and continuity

Which sub-processors do you use?
[List with purpose and location.] We tell customers [30] days before we add a new one.
Evidence: The sub-processor list and the notice clause.
How do you assess your own suppliers' security?
We review critical suppliers before we sign and once a year after. Their certifications and data locations stay on file.
Evidence: The supplier register and the last review.
What are your recovery time and recovery point objectives?
Recovery time [4 hours], recovery point [24 hours] for production. Our last restore test confirmed both.
Evidence: The continuity plan and the restore test record.
Do you have a business continuity plan?
Yes. It covers the loss of a region, a key supplier, and a key person. We last reviewed it on [date].
Evidence: The plan with its review date.
Is there an exit plan if we stop using your service?
Yes. We export customer data in [format] within [30] days, then delete it and confirm in writing.
Evidence: The exit clause and the export procedure.

What I leave out on purpose

I leave out ISO 27001 or SOC 2 on day one, a GRC platform, and a 60-page policy set. Certification can come later. The evidence behind these answers is what an auditor asks for anyway.

Next step

I highly recommend bringing the last questionnaire a customer sent to a thirty-minute call. We'll mark which answers already have proof and which ones need a build. Which question took your team the longest last time?

Book a call

These takeaways are an engineer's reading of the rules and the tools. I wrote them to help teams decide what to build. They aren't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.

Let's talk.

A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?