The first hours of a security incident are the ones that determine everything afterwards, and they are the hours in which organisations behave worst — because nobody has decided in advance who does what, and the people who could decide are asleep or in a meeting. Writing this down on a calm day is the entire preparation, and almost nobody does it.
The first decision is who declares. Someone must be able to say this is an incident and start the process, without waiting for permission, on partial information. That person needs to be named, needs a deputy, and needs to know that declaring something that turns out to be nothing is an acceptable outcome. Organisations where declaration requires a senior sign-off lose their first two hours to trying to reach a person.
Preserve before you fix. The instinct is to restart the affected server, rotate the credentials and get service back, and doing that destroys the evidence you will need to establish what happened and what was accessed. Take a snapshot, export the logs, capture the memory if you can, and only then remediate. This is the step that separates an incident where you can eventually tell customers what was affected from one where you can only say you do not know — and the second answer is far more damaging.
The Indian reporting clock is the constraint that shapes the first day. CERT-In's directions require specified incidents to be reported within six hours of noticing them, and sector regulators impose their own — a SEBI-regulated entity reports to SEBI's portal as well, and financial and insurance entities have their own paths. Six hours from noticing, not from understanding. That means the report goes in on partial information, with updates following, and a team that waits for root cause has already missed it.
Run containment, investigation and communication as three parallel tracks with different owners, because one person cannot do them and they interfere with each other. Containment stops the bleeding. Investigation establishes scope: what was accessed, whose data, over what period. Communication handles regulators, customers, staff and, if it gets that far, the press. The commonest failure is a single technical lead trying to do all three, doing the first well and the others not at all.
Then be careful what you say early. The pressure to reassure is strong and the temptation is to say no customer data was affected before anyone could possibly know. A statement that has to be corrected later does more damage than the original incident, because it changes the question from what happened to whether you are being straight. Saying we are investigating and will update by a stated time is always available, always accurate, and buys you the room to find out.
