Procedures for detecting, assessing, containing, and reporting security incidents and data breaches
Email: talent@aitacscrm.app
WhatsApp: +972-53-609-5496
Subject line: [SECURITY INCIDENT] — Brief description
Initial response: within 24 hours · Full assessment: within 48 hours
"Security Incident" — any attempted or successful unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations in the Platform.
"Data Breach" — a Security Incident that results in the confirmed unauthorized acquisition, access, use, or disclosure of personal data that compromises the security, confidentiality, or integrity of such data (GDPR Art. 4(12)).
"Provider" — Artem Chukov / AITACS Talent, acting as Data Processor (GDPR).
"Recruiter" — the User of the Platform, acting as Data Controller (GDPR) with respect to Candidate personal data.
This policy covers all security incidents and data breaches affecting:
a) The AITACS Talent server infrastructure (MySQL database, API endpoints, hosting environment);
b) Recruiter accounts (unauthorized access, credential compromise);
c) Data in transit (interception of communications between browser, server, or AI provider);
d) Third-party subprocessor incidents (OpenAI, Hetzner hosting, Google Firebase, Google Calendar API, Zapier) that affect AITACS Talent data — see the Subprocessor List;
e) Recruiter-side incidents (lost/stolen devices, compromised credentials) reported to the Provider.
| Severity | Definition | Examples | Response Time |
|---|---|---|---|
| Critical | Confirmed breach of Candidate personal data with high risk to data subjects | Database compromise with data exfiltration; unauthorized access to Candidate records; ransomware on server | Immediate — within 1 hour |
| High | Confirmed unauthorized access without evidence of data exfiltration, or breach of non-Candidate personal data | Unauthorized login to admin panel; API key compromise; hosting provider breach notification | Urgent — within 4 hours |
| Medium | Suspected incident requiring investigation, or vulnerability discovered that could lead to a breach | Unusual API traffic patterns; failed brute-force login attempts; unpatched vulnerability discovered | Priority — within 24 hours |
| Low | Minor security event with no data exposure risk | Single failed login attempt; Recruiter reports phishing email; minor configuration issue | Standard — within 48 hours |
The following six-phase procedure is executed for all incidents classified as Medium severity or above:
Detect the incident through: server log monitoring, anomalous traffic alerts, Recruiter reports, subprocessor notifications, or automated security tools.
Triage: assign severity level (Critical / High / Medium / Low). If severity is Critical or High, proceed immediately to Phase 2. Log the incident with timestamp, detection source, and initial description.
Preserve evidence: take screenshots, save relevant logs, record the state of affected systems before making any changes.
Short-term containment: isolate the affected component to prevent further damage. Actions may include:
— Revoking compromised API keys or access tokens
— Blocking suspicious IP addresses at the server level
— Disabling compromised Recruiter accounts
— Taking affected endpoints offline if necessary
— Rotating database credentials
Assess scope: determine which Recruiters, Candidates, data categories, and systems are affected. Identify the attack vector.
Determine if the incident qualifies as a Data Breach — i.e., whether personal data was actually accessed, acquired, used, or disclosed in an unauthorized manner.
Risk assessment: evaluate the nature of the data involved, the number of data subjects affected, the likelihood of harm, and whether the data was encrypted or de-identified at the time of the incident.
Key question for AI-related incidents: which of the three AI mechanisms was affected
(see Privacy Policy §3)? If the chat assistant or
candidate-analysis pipeline was affected and the data was de-identified at the time, the exposed data is
a pseudonym plus job-relevant professional data, not directly identifying information — this materially
lowers risk. If the résumé/document-import pipeline was affected, the data was not
de-identified and must be assessed as a full personal-data exposure. The ai_screening_log
audit table (fields redacted, model used, human_reviewed flag) provides evidence for this
determination.
Document findings in the Incident Report (see Section 7).
If the assessment confirms a Data Breach, the Provider initiates the notification process. GDPR Art. 33: notification to the Controller must occur no later than 72 hours after the Provider became aware of the breach — this deadline is absolute and cannot be extended by the phase of investigation. Where the affected data subjects are also subject to the Israeli Privacy Law or the Law of Ukraine "On Protection of Personal Data" (see Terms of Service §9.1), the Provider notifies the Controller of that fact so the Controller can assess any additional local notification obligation. See Section 5 for full notification content requirements.
Eradicate the root cause: patch the vulnerability, remove malicious code, close the attack vector.
Recover: restore affected systems from clean backups if necessary. Verify data integrity. Re-enable disabled accounts with new credentials. Monitor for recurrence.
Verify: confirm that the containment measures are working and the attack vector has been closed before returning systems to full operation.
Conduct a post-mortem analysis: what happened, how it was detected, what worked in the response, what needs improvement.
Update security measures: implement additional safeguards to prevent recurrence. Update this Incident Response Policy if gaps were identified.
Finalize the Incident Report (Section 7) and retain for a minimum of 6 years or as required by applicable law.
Communicate lessons learned to affected Recruiters if appropriate.
When a confirmed Data Breach involves Candidate or Recruiter personal data, the Provider must notify the relevant parties within the timelines required by GDPR Art. 33–34.
To the Controller (Recruiter): the Provider (as Processor) must notify the Controller without undue delay, and no later than 72 hours after becoming aware of the breach.
To the Supervisory Authority: the Controller's obligation. The Provider assists the Controller in preparing the notification.
To Data Subjects (Candidates): required when the breach is likely to result in a high risk to the rights and freedoms of natural persons (Art. 34). The Controller decides; the Provider assists.
Exception: notification is not required if the data was encrypted or de-identified such that it is unintelligible to unauthorized persons.
All breach notifications from the Provider to the Recruiter shall include, to the extent available:
a) The date and time the breach was discovered;
b) A description of the nature of the breach (what happened);
c) The categories and approximate number of data subjects affected;
d) The categories of personal data involved;
e) Whether the affected data was encrypted or de-identified at the time of the breach, and which of the three AI mechanisms (if any) was involved;
f) The likely consequences of the breach for data subjects;
g) The measures taken or proposed to address the breach and mitigate harm;
h) Recommendations for the Recruiter (Controller) regarding notification to data subjects or authorities;
i) The contact details of the Provider's incident response contact.
Recruiters play a critical role in the security ecosystem. Recruiter-side incidents are the most common breach vector.
Recruiters must report the following to the Provider as soon as possible:
a) Lost or stolen device that was used to access the Platform and may contain cached Candidate data in localStorage, IndexedDB, or browser storage;
b) Suspected account compromise — unexpected login notifications, password reset emails not initiated by the Recruiter, or unfamiliar activity in the Platform;
c) Malware infection on a device used to access the Platform;
d) Unauthorized observation — a third party observed or photographed Candidate data displayed on screen;
e) Accidental disclosure — the Recruiter inadvertently shared Candidate data with an unauthorized person (e.g., sent an export file to the wrong email, or to the wrong Client Employer);
f) Phishing — the Recruiter clicked a suspicious link or provided credentials to a site impersonating the Platform.
If you suspect a security incident involving your AITACS Talent account:
1. Change your password immediately — use a strong, unique password generated by a password manager.
2. Enable or re-verify 2FA on your account.
3. Change your email password if you suspect email compromise.
4. Report to the Provider using the contact details at the top of this document.
5. If a device was stolen: remotely wipe it if possible (Find My iPhone, Find My Device for Android, Windows remote wipe). Report the theft to local law enforcement.
6. Document everything — write down what happened, when, and what you observed. This helps the investigation.
The Provider uses the following structure for all incident reports. A completed report is retained for a minimum of 6 years.
Incident ID: [Auto-generated: INC-YYYY-MM-NNN]
Date/Time Detected: [YYYY-MM-DD HH:MM UTC]
Date/Time Reported: [YYYY-MM-DD HH:MM UTC]
Reported By: [Internal monitoring / Recruiter report / Subprocessor notification]
Severity: [Critical / High / Medium / Low]
Classification: [Security Incident / Confirmed Data Breach]
Description: [Narrative of what happened]
Systems Affected: [Server / Database / API / Recruiter Account / Third-party]
AI Mechanism Involved (if any): [Chat assistant / Candidate analysis / Document import / None]
Data Categories Affected: [Candidate Personal Data / De-identified Data / Recruiter Account Data]
Data Subjects Affected: [Number and type: Candidates / Recruiters]
Was data encrypted/de-identified? [Yes / No / Partially]
Containment Actions: [What was done immediately]
Root Cause: [Identified after investigation]
Eradication & Recovery: [Steps taken]
Notifications Sent: [To whom, when, content summary]
Preventive Measures: [What will be done to prevent recurrence]
Report Completed By: [Name, Date]
A core element of AITACS Talent's security architecture is de-identification of Candidate data before transmission to two of its three AI mechanisms. This has a direct impact on breach classification — but, unlike a single blanket claim, it must be assessed per mechanism.
For the "Elia for HR" chat assistant and the AI candidate-analysis feature, name, phone, email, and résumé
link are stripped before the AI call, and the exchange is logged in ai_screening_log with a
human_reviewed flag. If an incident affects only this data stream, and the de-identification
was functioning correctly at the time (as evidenced by that log), the exposed data is a pseudonym plus
job-relevant professional data — this materially reduces breach severity and may support a conclusion that
notification to data subjects under GDPR Art. 34(3)(a) is not required, because the data was rendered
unintelligible to unauthorized persons.
The résumé and company-document import feature necessarily transmits identifying data (name, contact details) as extracted from the uploaded document — this is not a de-identified data stream. An incident affecting this pipeline must be assessed as a full personal-data exposure, with no de-identification mitigation available, and is subject to the full notification analysis in Section 5.
Incidents affecting the MySQL database or localStorage/IndexedDB — where full, identifiable Candidate data is stored regardless of which AI mechanism is or is not in use — are treated as potential personal-data breaches and subject to full notification requirements.
9.1. This Incident Response Policy shall be reviewed and updated at least annually, or immediately following any significant incident.
9.2. The Provider shall conduct a tabletop exercise (simulated incident walkthrough) at least once per year to test the effectiveness of response procedures.
9.3. Lessons learned from actual incidents and from tabletop exercises shall be incorporated into this Policy within 30 days.
9.4. Recruiters will be notified of material changes to this Policy via email or in-app notification.
For incident reports, security questions, or concerns:
Artem Chukov — Incident Response Lead
Email: talent@aitacscrm.app
WhatsApp: +972-53-609-5496
Web: aitacscrm.app/talent
Response SLA: initial acknowledgment within 24 hours; full assessment within 48 hours; containment for Critical/High within 4 hours.
Terms of Service · Privacy Policy · Informed Consent Template · Cookie Policy · Data Processing Agreement (DPA) · Recruitment Data Sharing Agreement · Subprocessor List · Security Requirements · Incident Response Policy · Security Overview · Refund Policy · Copyright Policy · Contact Us