Information Security Policy
The rules everyone who runs AirTA Sites follows to protect the service and the data agencies entrust to it.
In short
- Two-step sign-in on every account that can reach the service, and access only for those who need it.
- Critical vulnerabilities fixed within 72 hours, high ones within 14 days.
- Every release passes the same checks, including the isolation test, and is recorded.
- Reviewed every year, and after any serious incident.
This summary is a guide to the text below. The text is what applies.
Purpose and ScopeLink to this section
1.1 This policy sets the rules AirTA G.K. follows to protect AirTA Sites and the data it holds: candidates' data entrusted by agencies, agencies' own data, and the systems and accounts that run the service.
1.2 It applies to everyone who can reach the service or its data, whether employee, officer or contractor, and to every device and account they use to do so.
ResponsibilityLink to this section
2.1 Our representative is responsible for information security and for personal data, approves this policy, and decides on exceptions to it. An exception is recorded with its reason and an end date.
2.2 Everyone this policy applies to reads it before receiving access and again after each review, is bound to confidentiality in writing, and reports at once anything that may be a security incident.
Access ControlLink to this section
3.1 Access to production systems and data is given only to people who need it for their work, at the lowest level that does the job, and is removed on the day it is no longer needed.
3.2 Every account that can reach the service, including hosting, the database, the code repository, email and payments, uses two-step verification. Credentials are kept in a password manager and never shared, written down or put in code.
3.3 Access is reviewed every quarter: each account is checked against who needs it, and the review is recorded.
3.4 We enter an agency's admin only as the "AirTA Sites support" member, which records what it opens in the agency's activity log. Work on an agency's data in the database goes only through the support script, which records its reason there. Direct access to the database console is for incidents only, and each use is recorded in the incident log.
Handling DataLink to this section
4.1 Candidates' data is used only as the agency instructs (Terms, Section 14). It is not copied out of the service except into the encrypted backups, or to the agency at its request.
4.2 Candidates' data is never used to develop or test the service. Tests use made-up agencies and people, removed when the test is done.
4.3 Data is kept only as long as the agency's settings, the Terms and the law require, and is deleted as the data handling document describes.
Vulnerability ManagementLink to this section
5.1 Dependencies are checked for known vulnerabilities at every release, and a release can't go out with a high or critical one.
5.2 Once a fix is available, a critical vulnerability in the service or its dependencies is fixed and released within 72 hours, and a high one within 14 days. Where no fix exists, we limit the exposure and record why.
5.3 Work computers and their software are kept up to date, and security updates are installed as they are released.
Change Management and Secure DevelopmentLink to this section
6.1 Every change reaches production only through the release command, which runs the type checks, the full test suite, lint, the isolation test and the dependency check, stops at the first failure, and records each run with its time and version. There is no way to skip a check.
6.2 Database changes are written by hand as migrations that can safely run more than once, and every new table is placed under row-level security in the same change.
6.3 Security behaviour is covered by tests: separation between agencies, roles, sign-in limits, cleaning of what people type and upload, and what reaches the AI. A control is shown as live on the Trust Center only when its evidence exists in the code.
6.4 Secrets are kept in the hosting provider's encrypted settings and on encrypted work computers, never in the code or its history.
SuppliersLink to this section
7.1 Every company that processes personal data for the service is listed at airtasites.jp/subprocessors before it receives any, under written terms that protect the data at least as well as our Terms. Agencies get 30 days' notice of a new one.
7.2 Each supplier's security terms, breach notice terms, data location and published audits are reviewed every year and when its contract changes. What the review finds is recorded and acted on.
DevicesLink to this section
8.1 Computers used to run the service have full-disk encryption on and lock their screens after no more than five minutes.
8.2 Candidates' data is not kept on any other device. A lost or stolen device is reported the same day, signed out of every account, and its keys are replaced.
Incidents and ContinuityLink to this section
9.1 Incidents are handled under the incident response plan (airtasites.jp/trust/incidents), including notice to agencies within 48 hours where candidates' data is affected.
9.2 Backups, restore tests and recovery follow the continuity plan (airtasites.jp/trust/continuity). A restore is tested at least once a quarter.
RecordsLink to this section
We keep these records for at least 5 years:
- every release and the result of each check
- every incident, every use of direct database access, and each review
- every restore test
- supplier reviews, access reviews and reviews of this policy
Agencies' activity logs are kept with the agency's other data.
ReviewLink to this section
11.1 This policy is reviewed every year, after any Severity 1 incident and after any significant change to the service or its suppliers. Each version is dated, and the current one is published here.
Breaking this policy is a breach of the person's duties to us, and may also breach our contracts with agencies. It is handled accordingly.