Incident Response and Breach Notification

1.1 A security incident is anything that puts the confidentiality, integrity or availability of the service or its data at risk: someone reaching data they shouldn't, data leaked, lost or damaged, an account or key of ours compromised, or harmful code in the service. A suspected incident is treated as one until it is ruled out.

1.2 A service incident is the service not working as it should: sites or the admin down, email not delivered, or scheduled work failing. These are shown on airtasites.jp/status.

3.1 The incident lead is our representative, Daniel Ray Smith, who decides on containment, tells the agencies affected and keeps the record. We are appointing a trusted person who will take over if the incident lead can't act; the continuity plan shows where that stands.

3.2 Your agency's owners receive our notices. For candidates' data your agency decides on reporting to the Personal Information Protection Commission and on notices to the people affected, because the law places those duties on you; we do the work that supports both.

3.3 Where a sub-processor is involved, we raise it with them at once and pass on what they tell us.

4.1 Throughout, we keep the evidence: logs, the activity log and the error records relevant to the incident are preserved and not deleted until the review is done.

5.1 If we become aware of a leak, loss or damage affecting your candidates' data, we tell your agency's owners by email within 48 hours, even if we don't yet know everything. This is a term of our contract (Terms, Section 14).

5.2 The first notice says what we know at that point:

5.3 We send updates as facts are confirmed and at least every business day while the incident is open. Outages are posted on airtasites.jp/status as soon as we have confirmed them.

6.1 Under Article 26 of the Act on the Protection of Personal Information, a business must report certain leaks to the Personal Information Protection Commission (PPC) and notify the people affected. For candidates' data that business is your agency: you entrust the data to us (Terms, Section 14).

6.2 A report is required when any of the following has happened or may have happened (Article 7 of the Enforcement Rules):

6.3 As the business entrusted with the data, the law treats our duty as met once we have told you (Article 26(1), proviso). We still do the work: we give you the facts in the order of the PPC's report form (what happened, the data involved, the number of people, the cause, any harm, what has been done for the people affected, any public statement and the steps to stop it recurring), and update them for the full report.

6.4 For personal data we handle for ourselves, such as the accounts of your team members, we report to the PPC and notify the people affected ourselves.

7.1 Where the people affected must be told, your agency sends the notice. We give you a draft in Japanese and English, and Settings › Privacy finds everything held about each person, so you can see exactly what to tell them.

8.1 Within two weeks of closing a Severity 1 or 2 incident, we write a review: what happened, the timeline, the cause, what worked and what didn't, and what we are changing. We share it with the agencies affected, and outages are summarised on the status page.

8.2 The incident log keeps every incident, every use of direct database access and every review for at least five years.

8.3 We rehearse this plan once a year with a worked example, and update it after every Severity 1 incident.

9.1 If you think you have found a security problem in AirTA Sites, write to hello@airtasites.jp with what you saw and how to reproduce it. We aim to reply within one business day and will tell you what we do about it.