Connect Breach Reporting and Access Reviews to KlaritiQ

When a breach happens, the clock starts at the moment your own team detects it, not when someone remembers to log it. KlaritiQ can take that moment straight from your monitoring tool: the tool reports the breach, the CERT-In, RBI and DPDP deadlines start at once, and your admins are told. A second feed, from your identity system, lets KlaritiQ flag leavers who still have accounts and administrator accounts without multi-factor authentication. Rules you switch on, called guardrails, are checked every hour.

Everything here is a comparison of facts your own systems send. Nothing is estimated or written by a model.

Before you start: confirm the regimes

Deadlines only start for regimes a person has confirmed, because KlaritiQ never decides on its own that a law applies to you. Open Regulatory Clocks and confirm the ones that apply:

• CERT-In incident reporting.
• RBI cyber directions for NBFCs, if you are an NBFC.
• DPDP breach reporting (Rule 7).

If a regime is not confirmed when a breach is reported, the breach is still recorded. The reply lists the deadlines that were not started and why, so a missing clock is never silent.

Create a key for each system

Open Integrations, then Webhooks, and find Breach and access reports. Create one key for your monitoring tool (breach reports) and one for your identity system (access lists). Copy each key straight away: it is shown once. A key can send only its own kind of report, cannot read anything in KlaritiQ, and can be revoked at any time. Each key is limited to 200 requests an hour, and every key is listed in that same card.

Report a breach

Call this when your monitoring tool detects a breach:

curl -sS -X POST https://klaritiq.in/api/v1/intake/breach \
  -H "Authorization: Bearer $BREACH_KEY" \
  -H "Content-Type: application/json" \
  -d '{"externalId":"INC-1042","title":"Customer table exposed on a public bucket","detectedAt":"2026-10-06T08:30:00+05:30","severity":"high","personalData":true,"source":"splunk"}'

• externalId is your own id for this breach. Sending the same id again, for example when your tool retries, returns the first report and starts nothing new.
• detectedAt is when your team detected it, with a time zone such as +05:30 or Z. The deadlines count from here, so a time without a zone is refused.
• personalData says whether personal data was involved. Leave it out if you do not know yet: the DPDP duties then apply, because leaving a duty out is the worse mistake. Send false and they are not started.
• severity is optional: low, medium, high or critical.

What starts

The two "without delay" duties are shown as such. The Rules give no number of hours, so KlaritiQ does not invent one. Your admins get a notification and an email the moment the breach is recorded. Each clock is closed by attaching real evidence, such as a CERT-In acknowledgement or a DAKSH reference, never by ticking a box.

Send who has access to what

From your identity system, on a schedule such as hourly:

curl -sS -X POST https://klaritiq.in/api/v1/intake/identity \
  -H "Authorization: Bearer $ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -d '{"source":"okta","capturedAt":"2026-10-06T09:00:00+05:30","accounts":[{"ref":"u-1042","status":"active","privileged":true,"mfa":true,"lastLoginAt":"2026-10-05T18:00:00+05:30","employment":"current"}]}'

Send opaque account ids in ref, not names or email addresses: they are personal data and the checks do not need them. KlaritiQ then applies fixed rules:

• Critical: the person has left but the account is still active.
• High: an administrator account without multi-factor authentication.
• High: an administrator account not used for more than 90 days.
• Medium: an administrator account where multi-factor authentication was not reported.
• Low: any other active account not used for more than 180 days.

Anything your system did not report is listed as could not be assessed, never treated as fine. A list with any invalid account is refused as a whole, so an account is never quietly dropped. Sending an unchanged access picture again updates the current list in place, and the history keeps one entry for every real change.

Guardrails

Under Compliance, on the Guardrails tab, Switch on the DPDP starter set adds seven rules chosen from a library of six checks:

• an active policy exists for a topic such as security,
• no active policy is overdue for review,
• no statutory deadline has been missed,
• the access list is recent,
• there are no serious access gaps,
• every tracked AI system is signed off at its current version.

Every rule is re-checked each hour, and your admins are told once when a rule starts failing. A rule that cannot be checked, for example because no access list has ever arrived, fails and says why: it never passes by default. Mark a rule Block releases while failing and the release check in your deploy pipeline stops while it fails. The check names the failing rule only, and the details stay on the Guardrails tab for people signed in to KlaritiQ.

What this does not do

• It does not connect to your tools by itself. Your monitoring tool and identity system send the reports.
• It does not decide that something is a breach. A report is your system's claim, recorded as given.
• It does not file with the regulator for you. You still report to CERT-In, the RBI and the Board, and attach the evidence to close each clock.
• Silence is not safe. If no access list arrives, the "access list is recent" guardrail fails.

Common questions

Can a breach key read my data?

No. A breach key can only send breach reports. It cannot read evidence, decisions, access lists or anything else, it is shown only once when created, and you can revoke it at any time.

What happens if my monitoring tool sends the same breach twice?

Nothing new starts. Each breach has your own id, and sending that id again returns the first report. The deadlines are never started twice.

What if I do not know whether personal data was involved?

Leave personalData out. The DPDP duties then apply, so the 72-hour clock is running while you find out. If you later learn no personal data was involved, you can waive those clocks on the Regulatory Clocks page with a reason.

Do I have to use the starter guardrails?

No. They are a starting point. You can switch each rule on or off, remove it, and choose which ones block releases.

Was this article helpful?

Community Questions (0)

Still have questions?