This post is for healthtech founders, CTOs and sales leads who have just received a hospital security questionnaire, usually a spreadsheet with a hundred or more questions, a deadline of a few days and a note that "IT will review before we proceed". It is also for the marketing lead who has been asked why the deal stalled in IT.
The point is simple: most questionnaire answers already exist somewhere in your company, in engineers' heads or in scattered documents. Assembling them into a single trust pack before a deal needs it turns a three-week scramble into a same-day reply. The post lists what to put in the pack, how to write each document, and how to keep it honest. It is a practical checklist, not a security audit and not legal advice.
One limit up front. The data hook for this topic is "typical hospital IT vendor requirements", and there is no public, authoritative list of what Indian hospitals ask. What follows is a working structure based on common categories and on the laws and directions that clearly apply. Compare it with real questionnaires you receive and adjust.
What the questionnaire is really asking
A hospital IT or information security team is trying to answer four questions about you:
- What data will you touch, and where does it live?
- Who can access it, and how is that controlled and logged?
- How do you find out when something goes wrong, and what do you do?
- If we leave, or you fail, what happens to our data and our operations?
Every question in a long spreadsheet maps to one of these. Seeing that helps you reuse answers and spot when a question is really asking something outside your product.
The trust pack: documents to pre-assemble
Keep the pack in one folder, with a version date on each file and an owner for each.
1. Product and data-flow overview
A two-page description of what the product does and a data-flow diagram showing data entering, moving through and leaving your system. Mark where personal data appears, where it is stored, what is encrypted in transit and at rest, and which third parties handle it. This is the document IT reads first, and an incomplete diagram prompts many follow-up questions.
2. Data inventory
A table of data fields you collect or process, why each is needed, who can see it and how long it is kept. If you can avoid collecting a field, remove it. Hospitals respond well to a vendor who asks for less.
3. Vulnerability assessment and penetration test summary
A short summary of the most recent external test: date, who performed it (an internal team or an independent firm), scope, number of findings by severity and remediation status. Share the executive summary, not the full report, and only under a non-disclosure agreement. Do not describe a test as independent unless it was. If you have no test yet, say so, and state when one is scheduled.
4. Security policies
Short, real policies for access control, password and authentication, change management, backup and recovery, incident response and employee onboarding and exit. A policy that nobody follows is worse than none, so write only what you do.
5. Data protection posture
A plain summary of how you comply with India's data protection law. The Digital Personal Data Protection Rules, 2025 were notified on 14 November 2025 with an eighteen-month phased compliance period, and the Act places the main duties on the data fiduciary, which will usually be the hospital. As a processor you should state: what you do with the data, that you process on the hospital's instructions, your security safeguards, how you support breach notification and how you delete data at exit. Have your counsel review the wording. Our DPDP overview for healthcare marketing covers the marketing-side obligations, which are a separate subject.
6. Incident response summary
One page: how incidents are detected, who is the contact, how quickly you notify the hospital, and what the notification contains. Include the CERT-In position. The CERT-In directions of 28 April 2022 require service providers, intermediaries, data centres and body corporate to report specified cyber incidents within 6 hours of noticing them, to keep logs of ICT systems for a rolling 180 days within Indian jurisdiction, and to synchronise system clocks with NIC or NPL time sources. Say how your practice meets each, or state clearly where you rely on a cloud provider.
7. Availability and uptime history
A record of uptime over the last twelve months, incident dates and durations, and what changed afterwards. Pull it from your monitoring tool or status page, and show the real figures. A candid history with fixes is more convincing than a claim of perfect service. Add your support hours, escalation path and response targets.
8. Business continuity and exit
Backup frequency, recovery time and recovery point targets you actually test, the last restore test date, and the data export format and timeline if the hospital leaves.
9. Subprocessor list
Names of cloud, messaging and analytics providers that touch hospital data, their roles and hosting regions.
10. Integration notes
Standards you support. If you integrate with the national digital health ecosystem, the Ayushman Bharat Digital Mission is the official source for its specifications; state exactly which parts you support and which are on the roadmap.
Mapping question categories to documents
Most questionnaires group questions under a handful of headings. Use the mapping below to route each question to the document that answers it, and to find gaps.
| Category | Typical question | Source document | Evidence to attach |
|---|---|---|---|
| Governance | Who is responsible for security? | Security policies | Named owner, org chart extract |
| Access control | How are users authenticated and removed? | Access policy, product overview | Role list, offboarding checklist |
| Encryption | Is data encrypted in transit and at rest? | Data-flow diagram | Diagram with encryption points marked |
| Logging | What is logged and how long is it kept? | Incident summary | Log retention statement, CERT-In alignment |
| Vulnerability management | When was the last test? | Test summary | Executive summary under NDA |
| Third parties | Who else touches our data? | Subprocessor list | Names, roles, regions |
| Resilience | What are your backup and recovery targets? | Continuity summary | Last restore test date |
| Privacy | Do you comply with the data protection law? | Data protection posture | Processing terms |
| Exit | What happens to our data on termination? | Exit summary | Export format and deletion process |
Building the answer bank
The answer bank is a table, not a document. One row per reusable answer, with these fields:
- Question tag: the category above plus a short label, such as
encryption-at-rest. - Answer: two or three sentences, starting with yes, no or partly.
- Evidence: the document name and version date.
- Owner: the person who confirms accuracy.
- Last reviewed: a date; anything older than six months is flagged.
- Status: current, changing or planned.
- Approved for external use: yes or no, set by the owner.
Sales then answers new questionnaires by tag, and escalates only the rows marked changing or the questions that match no tag. After each questionnaire, add the new questions you could not match. After five or six, the bank covers most of what hospitals ask.
