CERT-In 6-hour reporting straight from the graph

The six-hour clock starts the moment an incident is "noticed". That word is doing a lot of work — it ends the comfortable era when the SOC could quietly investigate for a day before deciding whether to file. In practice, the regulator now expects a fact-shaped, machine-readable report submitted within six clock hours, and the SOC has to do that while the incident is still in motion. Anyone who has done this in anger knows the bottleneck: it is not the analysis, it is the assembly. Where are the affected assets? What is the time bound? Who owns the data classification? Which controls failed? Who has been notified? Each of those questions in a non-graph SOC is a separate query against a separate tool, and at minute 240 you are still copy-pasting between tabs.

A graph-native platform changes the assembly cost. Every fact the template asks for is already a node or an edge in the graph; the report is a traversal, not a scavenger hunt. This post walks through what that looks like in practice — section by section of the template — and compares the time spent against the manual screenshot workflow we still see at most enterprises.

What the template actually asks for

The CERT-In incident reporting template is, mercifully, structured. The fields fall into eight groups, and they map cleanly onto graph structures we already maintain. The table below is the mapping we use as a starting point in every onboarding.

Notice the column on the right. Six of the eight sections can be filled with high confidence by traversal; the other two are confirmations, not authoring. The point of automation is not to remove the analyst from the loop — it is to remove the assembly task and leave the analyst free for the judgement calls.

Walking the template, section by section

Time of detection and occurrence

Every incident node in the graph carries two timestamps: when it was first seen by the platform (the deterministic timestamp from the underlying telemetry) and when it was promoted to a reportable incident (the analyst's noticed timestamp). The first is the operational ground truth; the second is the regulatory clock. The template wants both, and the graph holds both. The auto-fill is literal: read the field, format to the regulator's clock, done.

Affected systems and data

This is the section that destroys the manual workflow. The template wants every system involved and the data classification of each. In a non-graph SOC, the analyst has to query the asset inventory, then the CMDB, then the data-classification register, then reconcile names across all three (because no two of them spell the same thing the same way). In a graph-native platform, the assets are nodes on the same graph as the incident, the data classifications are edges from those nodes, and the query is one traversal:

# Affected systems and data, in one traversal
MATCH (i:Incident {id: $incident_id})-[:AFFECTS]->(a:Asset)
OPTIONAL MATCH (a)-[:STORES]->(d:DataClass)
RETURN a.hostname     AS host,
       a.environment  AS env,
       a.business_owner AS owner,
       collect(distinct d.label) AS data_classifications,
       a.criticality  AS criticality
ORDER  BY a.criticality DESC;

The output drops directly into the template. If the analyst needs to narrow scope ("the incident only touched the production replica, not the dev mirror"), the narrowing is a graph edit recorded with provenance — not a hand-edit of a Word document that nobody can re-derive.

Indicators and threat-actor signals

Indicators of compromise — file hashes, IPs, domains, behavioural signals — are nodes attached to the incident via the detections that fired. The template wants them listed with classification (network, host, behavioural) and, where available, threat-actor attribution. The graph holds the IoC nodes, the threat-actor nodes, and the relationships between them. Auto-fill is a one-hop and a label join. The analyst checks the list, removes anything mis-attributed, and confirms. Five minutes, not an hour.

Initial impact and blast radius

This is the section where graph-native wins by an order of magnitude. The template asks for the initial impact assessment — what could the adversary have reached from the initial foothold? In a non-graph SOC the answer is a guess. In a graph-native SOC it is a k-hop traversal from the incident's compromised assets, bounded by the trust edges that existed at the time of compromise. The analyst sees, at a glance: this mailbox had a service-principal that could reach this database; this database holds customer PII; the read-only token on this database was used in the last hour from an unexpected location. The report becomes specific and defensible rather than hedged and vague.

Containment steps taken

Every SOAR playbook execution attaches a log to the incident node. The log carries the action taken, the actor (human or agent), the timestamp, and the outcome. The template asks for this in narrative form. The auto-fill renders the log to prose using a deterministic template, with each step linked back to the underlying execution record for the auditor to verify. The analyst edits for clarity and confirms; the underlying facts are immutable.

Notifications and downstream parties

Every notification — to a data owner, a partner, a customer, a sector regulator — is an edge in the graph from the incident to the notified party, with a timestamp and a notification artefact (the email, the message, the call note). The template wants the list. The traversal returns it.

The manual workflow, honestly compared

It is worth being concrete about the time savings. The numbers below are medians from the last twelve enterprise incident-response reviews we have done — six on a graph-native substrate, six on a conventional SIEM-plus-spreadsheet workflow. The minutes are wall-clock from the moment the SOC accepted the incident as reportable to the moment the regulator's portal received the submission.

The manual workflow is not impossible — many SOCs do hit the six-hour clock. But they hit it with no slack, every single time, and they do it by sacrificing the quality of the impact assessment because that section is the most expensive to populate honestly. The graph-native workflow turns the same report into a 50-minute exercise, leaving roughly five hours for the analyst to do what only a human can: judge severity, decide containment trade-offs, and brief leadership.

What the auditor sees

An auditor reviewing the submission six weeks later asks a small set of questions: how were the affected assets identified, how was the data classification confirmed, who authorised the containment actions, and how was the blast radius scoped. Each of those answers, in a graph-native workflow, links back to a specific traversal, an immutable detection-rule version, a signed playbook execution record, and a temporal edge in the graph. The audit conversation is short because the evidence is constructive.

The shape of the auto-filled report

The platform emits the report as a structured object — the template fields populated, the source traversals linked, the analyst confirmations stamped. The same object renders to the regulator's portal format, to a PDF for internal records, and to a JSON document for the platform's own audit log. Three outputs, one source, no copy-paste.

# A trimmed view of the auto-filled report object
{
  "report_id":   "RPT-2026-0521-0014",
  "tenant_id":   "tnt_84a3",
  "incident_id": "INC-4421",
  "noticed_at":  "2026-05-21T08:14:00+05:30",
  "occurred_at": "2026-05-21T07:46:11+05:30",
  "classification": "unauthorised_access:credential_compromise",
  "affected": [
    { "host": "app-prod-07", "env": "prod", "owner": "finance-eng",
      "data": ["pii.customer", "pii.kyc"], "criticality": "high" },
    { "host": "db-prod-02",  "env": "prod", "owner": "data-platform",
      "data": ["pii.customer"], "criticality": "critical" }
  ],
  "indicators": [
    { "type": "ip",    "value": "203.0.113.44",      "source": "edr+ndr" },
    { "type": "hash",  "value": "a91f...c3",         "source": "edr" }
  ],
  "blast_radius_k_hops": 2,
  "blast_radius_at": "2026-05-21T07:46:11+05:30",
  "containment": [
    { "action": "revoke_session",   "actor": "playbook:revoke-suspicious-session",
      "at": "2026-05-21T08:18:42+05:30", "outcome": "success" },
    { "action": "isolate_host",     "actor": "analyst:l2-priya",
      "at": "2026-05-21T08:23:11+05:30", "outcome": "success" }
  ],
  "notifications": [
    { "to": "data-owner:finance-eng", "at": "2026-05-21T08:25:00+05:30" },
    { "to": "internal:ciso",         "at": "2026-05-21T08:26:30+05:30" }
  ],
  "analyst_confirmation": "verified-by:analyst:l3-amit",
  "evidence_links": ["graph://incident/INC-4421@2026-05-21T07:46:11Z"]
}

"We used to take four to five hours just to assemble the report and then ten minutes to actually decide what to write. Now we take ten minutes to assemble and the rest of the window to think. The decisions are better. The submissions are also better." — SOC head, public-sector financial institution.

The decisions that remain human

Auto-fill does not erase the analyst. Three decisions inside the report are inherently judgement calls and should never be automated:

• Severity classification. The platform offers a default based on the detection's risk score and the blast radius; the analyst overrides upward or downward based on context the graph cannot know.
• Scope narrowing or widening. The blast-radius traversal returns a superset of what may actually be affected; the analyst confirms which paths the adversary actually walked.
• Narrative tone. The auto-rendered prose is factual and neutral. The analyst chooses whether to highlight specific facts the regulator should not miss.

The right framing is that automation moves the analyst from assembly to judgement. The clock is still tight; it is just no longer tight for the wrong reasons.

For the underlying substrate reasoning, see our whitepaper on graph-native correlation. For the sovereign-deployment dimensions that matter when the reporting workflow has to run inside a regulated estate, see air-gapped and DPDP-first.