Incident Response Policy

1. What counts as an incident

Unauthorised access to personal data. Loss or corruption of it. A weakness that exposed it, whether or not anyone used the weakness. A supplier telling Warsha that one of these happened to them.

A service outage is not an incident under this policy unless data was affected.

2. What happens first

Contain: stop the exposure. This comes before understanding it, because an exposure that is still open is getting worse while it is being analysed.

Preserve: keep the logs and evidence needed to establish what happened, before anything is changed.

Assess: what data, whose, how much, and for how long.

3. Telling people

Warsha tells affected people when their data was involved, without waiting for the investigation to be complete. A notification that arrives after everything is understood arrives too late to act on.

A notification says what happened, what data was involved, what Warsha has done, and what you should do. It does not minimise, and it does not describe an incident as a "technical issue" when it was an exposure.

Where the law requires notifying an authority, Warsha does so within the time the law allows.

Where telling someone immediately would make the exposure worse — an open weakness that would be exploited — Warsha may delay the detail while still telling people that something has happened and what to do.

4. Afterwards

Every incident produces a written record: what happened, why, what was done, and what has changed so it does not happen the same way again.

Where the cause was a design weakness rather than a mistake, the fix is to the design.

5. What Warsha does not claim

Warsha has not undergone penetration testing and holds no security certification. It does not claim either, and will not until it has.

Stating this is part of the policy rather than an omission from it, because a security posture that is overstated is one people rely on.