A breach is simultaneously a technology, legal, customer, financial and governance event.
Incident commander with CFO and security
Immediate, with exercises twice yearly
Appoint an incident commander.
Incident timeline.
The first hours require containment without destroying evidence. Isolate affected systems, preserve logs, identify compromised accounts and use an incident commander to coordinate technical and business teams.
CERT-In directions require reporting of specified cyber incidents within the prescribed timeline. DPDP breach-notification duties depend on the Act, Rules and notified commencement. Other sector regulators, contracts and customers can create separate notices.
Finance should track payment fraud, business interruption, customer credits, forensic cost, insurance, legal fees and disclosure. The board needs facts, uncertainties, decisions and next update time.
| Control | What it covers | Operating rule |
|---|---|---|
| Detect and contain | Stop ongoing access and secure credentials. | Preserve forensic state. |
| Assess | Identify systems, data, persons and jurisdictions. | Separate confirmed facts from hypotheses. |
| Notify | Apply CERT-In, DPDP, sector and contract routes. | Control message consistency. |
| Recover | Restore safely and monitor recurrence. | Record cost and lessons. |
Pre-approve external forensic, legal, communication and cyber-insurance contacts. During an incident, procurement delay can increase loss.
Run tabletop exercises using realistic scenarios such as ransomware, cloud exposure, vendor breach and payment diversion. Record gaps and assign remediation dates.
Document the decision, owner, due date and evidence expected. A verbal explanation should be converted into a board note, approved working, contract amendment, portal acknowledgement or reconciliation before the item is treated as closed.
Rules, forms, thresholds and interpretations can change. The operating team should use the latest official source and the actual company facts instead of copying a control from another entity or prior year.
Ask four questions: Is the obligation or accounting treatment applicable? Has the underlying transaction been completely recorded? Does the evidence agree with the books and portal? Has an independent reviewer challenged the exception?
The review should distinguish a timing difference from an error, a judgement from a missing document, and a control failure from a one-time operational delay. Repeated small exceptions deserve root-cause action because they often become material during audit, fundraising, notice or distress.
The operating record should connect the control stages—detect and contain, assess, notify, recover—to the same transaction population. If the source list, accounting ledger, tax return, board record and management dashboard use different populations, the review can appear complete while exceptions remain outside the test.
Management should define an exception threshold, but the threshold must not hide repeated failures. A small error occurring every month can signal weak master data, unclear ownership or a broken interface. The reviewer should record root cause, immediate correction and preventive action separately.
Closure requires evidence. At minimum, the file should show who prepared the work, who reviewed it, which source documents were used, what differences remained and when the next follow-up is due. Screenshots without context or spreadsheets without source references are not a durable control record.
Map the actual data and money flows rather than relying on contract labels. Systems, vendors, user screens and bank accounts should agree with the legal role allocated in the contract; a platform cannot avoid regulatory responsibility through marketing terminology.
Incident and complaint data should feed the control review. Repeated consent withdrawals, failed settlements, customer complaints or access exceptions are evidence that the designed process is not operating as intended.