/ THE SHORT ANSWER
- 01Prepare reporting ownership before an incident occurs.
- 02Keep confirmed facts, hypotheses and unknowns separate.
- 03Protect evidence and avoid delaying action for a polished AI narrative.
/ dotSuper point of view
Creates a practical entry point to accountable security operations.
Prepare the decision route in advance
[1] The May 2022 FAQ provides further explanation, including reporting with information available at the time.
[2] Read both with qualified advice to determine the business's actual scope and other applicable obligations.
The operational problem is often a missing decision route.
Who receives the first alert?
Who can contact an external adviser?
Who decides whether an event is reportable, and who sends the report?
A document listing only an IT support number leaves important authority questions unanswered.
Create a primary and backup owner for each role.
Keep contact details available through a channel that does not depend entirely on the potentially affected environment.
Review the list when staff or service providers change.
A current two-page runbook is more useful during an incident than a long policy nobody can locate.
Build a factual timeline, not a persuasive story
Keep the time zone with each timestamp.
If the original source uses another time basis, retain it alongside any normalised display so the sequence can be reconstructed accurately.
Separate confirmed facts, working hypotheses and unknowns.
For example, an unusual login is a fact supported by a log; a belief that data was copied is a hypothesis until evidence supports it.
A generated summary should preserve those labels rather than smoothing them into one confident account.
Link each statement to its source and record who added it.
Restrict access to the incident workspace because it may contain personal data, credentials, confidential information or sensitive system details.
Do not place raw evidence into a general-purpose AI service without an approved data-handling basis and appropriate safeguards.
Create a pack that supports authorised reporting
It should also identify which statements are provisional.
Use the current official reporting process and any professional guidance relevant to the business.
The table is a proposed preparation checklist.
It is not a replacement for CERT-In's form, incident scope or other sectoral, contractual and privacy reporting requirements.
Avoid assuming that one report satisfies every obligation or that every security alert belongs in the same reporting category.
If AI helps draft a summary, require the reviewer to compare each factual statement with the underlying record.
Prevent the assistant from sending reports or contacting customers autonomously.
Preserve the approved version and the actual submission acknowledgement separately from the draft so the team can demonstrate what was communicated and when.
| Component | Include | Avoid |
|---|---|---|
| Timeline | Event and discovery times with zone | Unlabelled inferred times |
| Affected scope | Confirmed systems and accounts | Unsupported expansion |
| Evidence | Source and handling reference | Uncontrolled copies |
| Unknowns | Explicit open questions | Confident invented conclusions |
| Communication | Approved version and acknowledgement | Treating draft as submitted |
Worked example: prepare without inventing missing facts
By 10:30, the IT owner confirms the affected account and relevant login records.
The team does not yet know whether data was taken.
At 11:00, the authorised decision-maker receives a pack containing the known facts and the explicit unknown.
The elapsed preparation time is one hour from initial notice to decision pack.
This example does not define a lawful reporting deadline or prove that the organisation has met one.
The applicable clock and reportability depend on the actual facts and requirements assessed by the responsible professionals.
The useful behaviour is preserving uncertainty while enabling timely decisions.
The team can record further findings as supplements rather than delaying preparation until every forensic question is answered.
An AI-generated sentence claiming a confirmed data breach would be inappropriate if the evidence supports only suspicious access and an ongoing investigation.
Preserve evidence through the response
Record the source, collector and handling history for relevant files and logs.
Avoid uncontrolled copying, editing or deletion that could make later investigation harder.
Containment actions should follow the authorised incident process and account for operational safety.
Keep administrative access tightly controlled during the response.
Shared emergency credentials and informal messaging can create a second layer of uncertainty about who changed what.
Document necessary access and actions through approved methods rather than allowing the incident assistant to improvise system changes.
Watch for sensitive information in summaries sent outside the response team.
A useful management update may need only impact, actions and next review time.
Raw account identifiers, system secrets or employee details may be unnecessary.
Tailor the information to the recipient's role while retaining the full authorised evidence record.
Rehearse one realistic scenario
Ask the team to locate contacts, start a timeline and prepare the initial evidence pack.
Do this without sending a real report or changing production systems unless separately authorised.
Measure missing contacts, time spent locating logs and statements that reviewers could not substantiate.
The exercise should reveal decision and evidence gaps.
It should not be scored mainly on how quickly the assistant generates a polished document, because writing speed is only a small part of incident readiness.
dotSuper can help scope a controlled incident-workspace and evidence-organisation workflow.
Bring the existing response plan and a redacted scenario to an AI Readiness Sprint.
Qualified security and legal professionals should retain responsibility for reportability, containment, evidence handling and external communications.
What this page cannot conclude
- 01This is operational preparation, not legal advice or a complete incident-response procedure.
- 02The timeline is hypothetical and does not determine statutory compliance or reporting deadlines.
- 03This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Sources
- 01Cyber security directions, 28 April 2022CERT-In · accessed Sep 15, 2026
- 02FAQs on Cyber Security Directions, May 2022CERT-In · accessed Sep 15, 2026
This article was researched and drafted with AI assistance. Sources and limitations are provided for scrutiny; it is not an independent professional review or a compliance certification.
Our editorial standard · Found an error? Send a correction with its source.
/ CITE OR SHARE THIS GUIDE
Make the evidence easy to verify.
When you reference this guide, link to its canonical URL. That gives readers one stable place for the evidence, limitations and future updates.
dotSuper Research Desk. (September 15, 2026). Prepare an Indian SME Incident Evidence Pack. dotSuper. https://dotsuper.net/feeds/applied-systems/india-cert-in-incident-evidence