पाठशाला Pathshala · संचालन Sanchālan, Operations · Lesson 21 · Build

Security and infrastructure basics before the first enterprise customer

The first enterprise deal arrives with a security questionnaire of a few hundred rows. Twenty controls, one owner and a two-page incident plan answer most of it honestly.

Pathshala, The Founder Library · 11 October 2026 · 6 min read

Vintage brass keys scattered across a dark surface. — Photograph: Magda Ehlers · Pexels

The first enterprise customer rarely says no on security. It says not yet, by sending a spreadsheet of a few hundred questions and waiting. A company that can answer it in a week, truthfully, closes the deal that quarter. A company that has to build the answers from nothing loses two months, and sometimes the deal.

This lesson sets out what the questionnaire is really testing, the controls a team of ten to fifty can run without a security hire, the Indian rules that apply whether or not a customer asks, the incident plan, how to answer the questionnaire itself, and the monthly hour that keeps it all true. It assumes a software company running on a major cloud provider; most of it applies to any company holding customer data.

What the questionnaire is really asking

Enterprise questionnaires look different but descend from a few common frameworks. The Cloud Security Alliance’s Cloud Controls Matrix has 197 control objectives in 17 domains, and its companion questionnaire, the CAIQ, turns them into simple yes-or-no questions for assessing a cloud provider. A bank or a large Indian conglomerate will send its own version, often longer, built on the same ideas.

Read a few hundred rows and they reduce to a handful of questions. Who can get into your systems, and how do you stop the wrong people? Where is our data, is it encrypted, and can you get it back if something fails? Are your systems kept up to date and is your code reviewed? Will you notice an attack, and what will you do when you do? Has anyone written any of this down, and does anyone own it? The reviewer on the other side is not expecting a small company to look like a bank. They are looking for honest answers, a named owner and no gaps in the few controls that matter most.

Identity and access first

A stolen or guessed password is the cheapest way into a small company, which is why access controls come first. Put every work account behind one identity provider, the one the company already uses for email, and enforce multi-factor sign-in rather than offering it. Microsoft’s security team reported in 2019 that multi-factor authentication blocks over 99.9 per cent of account compromise attacks. No other single control a small company can switch on in an afternoon does as much.

Then three rules. Leavers lose access on their last day, from a written checklist that covers the identity provider, the cloud console, the code repository, the password manager and every tool outside single sign-on; the questionnaire will ask how quickly, and the answer must be the same day. Admin rights are few and named: production and cloud administration limited to the people who need it, listed, and reviewed every quarter. Nothing is shared: no team logins, and secrets kept in a password manager or a secrets store, never pasted into code, documents or chat.

Data, backups and encryption

Start with a one-page data map: what customer data and personal data the company holds, in which systems, in which region, and who can reach it. Every later answer depends on it. Then encrypt data in transit everywhere and at rest in every database, disk and backup; on the major cloud providers this is a setting, and it should be on. Back up production data automatically to a separate account, and restore it once a quarter to prove the backup works, recording how long it took. Write down how long data is kept and how a customer’s data is deleted when their contract ends.

Indian law now asks for much of this regardless of any customer. Section 8(5) of the Digital Personal Data Protection Act 2023 requires a data fiduciary to protect the personal data in its possession or under its control, including data processed on its behalf, by taking reasonable security safeguards to prevent a breach, and the Schedule sets the penalty for failing to do so at up to ₹250 crore. The [DPDP lesson](/library/dpdp-act-what-it-requires-of-your-product) sets out the rules and their commencement dates.

Systems, code and logs

For the rest of the infrastructure, use a published baseline rather than inventing one. The Center for Internet Security’s Implementation Group 1 is a set of 56 safeguards it calls essential cyber hygiene, intended as the minimum for an enterprise of any size. A small company will not do all 56 in a month, but the controls run in a sensible order: know what devices, accounts and software you have; configure them securely; keep them patched; control who has admin access; keep logs; back up; train people. Add two habits specific to software companies: every change to production is reviewed by a second person and deployed through the pipeline, and dependency scanning is switched on in the code repository.

A row of black server cabinets with red cables in a lit data centre. — Logs from every one of these systems kept for 180 days in India with their clocks in step. CERT-In asks for both. Photograph: Brett Sayles · Pexels

Logging is where Indian rules are most specific. The CERT-In directions of 28 April 2022, issued under section 70B of the Information Technology Act and applying to service providers, intermediaries, data centres, body corporates and government organisations, require logs of all ICT systems to be enabled and kept securely for a rolling 180 days within Indian jurisdiction, and system clocks to be synchronised with the NTP servers of NIC or NPL or sources traceable to them. Many questionnaires ask about log retention. The Indian answer starts at 180 days.

A questionnaire is not passed by having every control. It is passed by having the few that matter, an owner, and the honesty to date the rest.

The incident plan

Every questionnaire asks for an incident response plan, and every company needs one before it needs one. Two pages is enough. Who leads: one named incident lead and a deputy. Who decides: on shutting systems down, on paying for outside help, on what to tell customers. Who tells whom: customers, the board, and the regulators. The first hour: contain, preserve the logs, start a written timeline. The contact list: the cloud provider’s support, a security firm on call, the company’s lawyer, and CERT-In.

The reporting clocks are short. CERT-In’s directions require the incidents listed in their annexure to be reported within six hours of noticing them or being told of them. The DPDP Act, in section 8(6), requires a personal data breach to be intimated to the Data Protection Board and to each affected person in the form and manner the rules prescribe. Six hours is not long enough to work out who should make the call. Put the names in the plan, and once a year run a tabletop exercise, a stolen laptop or an access key leaked in a public repository, against the clock.

Answering the questionnaire

Build a security pack once and reuse it: a two-page overview of how the company handles security, an architecture diagram showing where customer data lives and how it moves, the short policy set every employee has signed, the list of vendors that process customer data, and an answers library, a sheet of every question received so far with the approved answer. The first questionnaire takes a week. The fifth takes a day, because most of it is already answered.

Answer every row truthfully. Where a control is not in place, say so and give a date: “Not yet. Quarterly access reviews begin in January.” Most reviewers expect gaps in a small company and will work with a dated plan; few will forgive a yes that turns out to be false. When enterprise deals start to depend on a formal certification, that is a separate project with its own budget and auditor. The controls here are its foundation either way.

The monthly security hour

Put one hour a month in the security owner’s calendar, on the same day as the monthly close. Access: compare the identity provider against the payroll list and remove anyone who has left; once a quarter, review every admin right. Backups: confirm last month’s backups ran; once a quarter, restore one and time it. Patching: check that devices and servers are inside the patch rule. Logs: confirm retention is still 180 days and clocks are synchronised. Paper: update the answers library with every new question received and every control added, and change any answer that is no longer true. Once a year, run the tabletop exercise, have every employee re-sign the policies, and walk the checklist above from the top.

Nothing here is legal advice, and the checklist is a starting point, not a certification. Regulatory requirements checked on 10 October 2026; confirm the current position with counsel before relying on it in a contract.