Startup Security Questionnaire India: Answer It Honestly

A hospital security reviewer or enterprise procurement team is trying to decide one thing: if we put our data or our patients' data in this product, do we understand the risk? They do not expect a five-person startup to have the controls of a bank. They do expect you to know where the data sits, who can reach it, and what happens on a bad day.

Most questionnaires are a bank of the same topics reworded: data location, access control, encryption, backups, logging, vendors, incident response, staff practices. If you can answer those eight topics in your own words with evidence behind each, you can answer almost any questionnaire, whatever its format.

Before a questionnaire arrives, write a single page that you can attach to any reply. The act of writing it forces you to find out what is actually true, which is usually the hard part for an AI-built product where nobody remembers every setting the tool chose.

Keep it factual and dated. Every line should be something you could show a screen or document for.

1. 1What the product does and what personal or sensitive data it handles, in two sentences.
2. 2Where the data is stored: cloud provider, region, and the vendors that receive any of it.
3. 3How users and staff authenticate, and who has administrative access to production.
4. 4How data is protected in transit and at rest, and how secrets are kept out of code.
5. 5How backups are taken, how often, where they are stored, and the last time you tested a restore.
6. 6What you log, how long you keep logs, and who reviews them.
7. 7What you would do in an incident and who the contact is.
8. 8Known gaps and the date you plan to close each one.

The pattern for every answer is the same: say what is true now, in plain words, then name the evidence. Do not answer yes to a control you have half-built. "Partially, here is the scope" is a stronger answer than a yes that collapses when someone asks for a screenshot.

You will have gaps. The dangerous move is a confident yes that is not true, because questionnaire answers are often incorporated into the contract, and a false answer becomes a contractual problem and a trust problem at once. Many buyers also verify a few answers at random.

A good gap answer has four parts: the honest current state, the risk in one sentence, the compensating control if any, and a dated commitment. For example: MFA is enforced on the cloud console and code host but not yet on the admin panel; the admin panel is reachable only from a fixed set of addresses in the meantime; we will enforce MFA there by a named date. That reads as a team that knows its system.

Do not promise a certification you do not have. If a buyer asks for a framework such as ISO 27001 or SOC 2, say whether you are pursuing it, and describe the controls you do have. Whether a specific framework is a hard requirement is the buyer's call, and their procurement team can tell you.

Create one shared folder with dated screenshots and exports that back each answer: cloud region, access lists, MFA settings, backup settings, the last restore test, the vendor list and your incident plan. Refresh it each quarter and before each renewal.

Strip real personal data from anything you save. A screenshot of a customer table pasted into a shared drive for a questionnaire is itself an exposure. Store the folder somewhere with restricted access, and note the date next to each item so you never present stale evidence as current.

The Indian Computer Emergency Response Team (CERT-In) issued directions on 28 April 2022 under section 70B(6) of the Information Technology Act, 2000. They apply to service providers, intermediaries, data centres, body corporate and government organizations. A startup that runs a service in India as a company is likely to be a body corporate, but whether the directions apply to you in a given case is a question for a lawyer.

Several points from the directions text are relevant to a questionnaire. Covered entities must report the types of cyber incidents listed in Annexure I to CERT-In within 6 hours of noticing them or being told about them. The listed types include unauthorized access of IT systems or data, data breach, data leak, attacks on servers such as databases, attacks on applications, and malicious activity affecting cloud systems or AI and machine learning systems. Reports can go by email to incident@cert-in.org.in or by phone on 1800-11-4949, and CERT-In publishes reporting formats on its website.

The directions also require logs of all ICT systems to be enabled and kept securely for a rolling 180 days, maintained within the Indian jurisdiction, and provided to CERT-In on request or with an incident report. Entities must synchronize system clocks to NIC or NPL time sources or sources traceable to them, and must designate a point of contact to interface with CERT-In, sent to CERT-In in the annexed format. Read the directions and CERT-In's site for current forms and any later clarifications before you rely on this summary.

Attach the one-page note, answer in the table pattern above, cite evidence by file name, and send a short cover message that names your security contact. Offer a call. A ten-minute conversation where you explain your architecture clearly often resolves half the spreadsheet.

Then fix in order of risk. Access control on customer data, MFA on admin systems, a tested restore and a written incident plan usually come before anything cosmetic. Update the note when they are done, so your next questionnaire starts from a stronger page.