Incident Readiness

The value of a data-centric security platform during an incident is that many of the questions incident responders normally struggle with have immediate, evidence-backed answers. Realizing that value requires that the platform has been configured with incident response in mind — not reconfigured during the incident itself.

Pre-incident configuration

Things that should be in place before anything happens:

Emergency authorization roles. A small set of principals authorized to execute emergency operations — emergency revocation, emergency policy change, bulk access revocation. Not every administrator should hold this role; it should be narrow enough to be meaningful and broad enough to be reachable during an off-hours incident.

Incident-scoped deny policies. Drafted and tested, but not published. When an incident scope is established, the draft is published (through the policy workflow's emergency path if necessary) to cut off access to the affected data.

Evidence scope templates. Pre-defined evidence-pack scopes for common incident types: "all activity by principal X in the last N days," "all activity against data objects with tag Y in the last N days," "all decisions for object Z in its full lifetime." These can be invoked quickly when the incident pattern becomes clear.

Streaming destinations. The audit event stream should already be flowing into your SIEM and incident response tooling. An incident is not the time to start wiring integrations.

Runbooks. Documented procedures for each type of incident the organization anticipates. Runbooks change; the platform's role in them doesn't change much, so runbooks can be written once and maintained.

Incident playbooks

Suspected principal compromise

A user's credentials may have been compromised; their access may have been used to exfiltrate data.

1. Revoke the principal's identity in the identity provider. This is the authoritative stop. Lattix follows.
2. Query the ledger for all activity by the principal in the relevant time window. This produces the set of data objects they accessed or attempted to access.
3. Emergency-revoke any shares or access grants the principal issued during the window. Passport shares, Data Room invites, external grants.
4. Publish a deny policy excluding the principal from all future access, even if their identity-provider account is somehow re-enabled during investigation.
5. Export an evidence pack scoped to the principal and the window. This is the working artifact for the investigation.

Suspected key compromise

A KEK is suspected to have been exposed.

1. Emergency-revoke the KEK. This is an irreversible operation; the KEK is moved to retired and all cached DEK releases derived from it are invalidated.
2. Query the ledger for all unwrap events under the KEK. This produces the set of objects an adversary with the KEK could potentially access.
3. Generate a successor KEK under the same encryption profile.
4. Trigger bulk re-wrap of affected objects from alternate wrapped copies (if available) or re-wrap during their next natural access. Objects that cannot be re-wrapped become permanently inaccessible — this is intentional; an adversary with the compromised KEK cannot access them either.
5. Notify the regulated-data stakeholders. If the KEK covered regulated data, notification obligations may apply.

Data exposure event

A specific set of records has been identified as exposed (ransomware leak site, mistaken publication, insider disclosure).

1. Identify the specific CIDs of the exposed records. If the exposure is of envelopes (common with ransomware), the exposed data is already ciphertext — the ZTDF envelope is designed exactly for this case.
2. Query the ledger for all access to those CIDs historically. This establishes how the exposed copies came to exist.
3. Revoke access at the policy layer. Any future unwrap attempt on the exposed envelopes will fail.
4. Export evidence packs for the affected CIDs. These become part of the regulatory disclosure if one is required.
5. Assess the exposure. If the records were exposed as envelopes only, and the KEK is not compromised, the practical exposure is minimal. If the records were exposed as cleartext (because someone unwrapped them and mishandled the result), the exposure is real and follows normal breach-notification logic.

Regulatory inquiry

A regulator requests evidence about specific data access.

1. Scope the inquiry. Specific data objects, specific principals, specific time window, specific regulatory framework.
2. Export an evidence pack for the scope. Review it before release.
3. Provide the pack through the regulator's preferred channel. The pack is cryptographically signed; the regulator can verify authenticity without contacting Lattix.
4. Record the interaction. The export itself is a ledger event; the regulator's subsequent requests should be recorded in your incident log.

Most regulatory inquiries are not emergencies — they have weeks of response time. The evidence export capability turns what is historically a multi-week correlation exercise into a single-day production.

Post-incident

After the incident is resolved, the work continues:

Post-incident review. Replay the incident against the ledger. What was the actual exposure? How quickly did the platform's controls engage? What would have reduced the exposure further?

Policy updates. If the incident revealed a gap — a policy that should have been tighter, a classification that should have had a dedicated encryption profile — update the configuration and record the rationale.

Runbook updates. If the runbook didn't quite match reality, update it. Incidents are the best (worst) source of runbook validation.

Drills. Pick a sample of what you learned and turn it into a quarterly drill. Run it in advisory mode in a test tenant. Confirm the response works in people's muscle memory, not just on paper.

What not to do

Don't wait for the incident to start exporting evidence. Evidence-pack scopes should be defined and tested in advance. An incident running 40 hours in with a partial timeline is not the moment to be learning the UI.

Don't reconfigure mid-incident. Except for the specific deny policy scoped to the incident, don't make broad configuration changes during the active phase. They add uncertainty when the system most needs to be predictable.

Don't treat the ledger as a log. The ledger is evidence. It is queried for specific facts, not grepped like a log. The structured queries are faster and produce more defensible answers than ad-hoc exploration.

Don't under-communicate. The platform makes it easier to answer questions about the incident, but it doesn't produce the communication the organization owes to regulators, customers, and internal stakeholders. The platform supports good communication; it doesn't replace it.