Procedures for detecting, assessing, containing, and reporting security incidents and data breaches
Email: aitacs@skillbuilder.club
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 (per HIPAA 45 CFR §164.304).
"Data Breach" — a Security Incident that results in the confirmed unauthorized acquisition, access, use, or disclosure of personal data or PHI that compromises the security, confidentiality, or integrity of such data (per HIPAA 45 CFR §164.402 and GDPR Art. 4(12)).
"Unsecured PHI" — PHI that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through encryption or destruction (per HIPAA 45 CFR §164.402).
"Provider" — Artem Chukov / AITACS CRM, acting as Data Processor (GDPR) and Business Associate (HIPAA).
"User" — the therapist, psychologist, or coach, acting as Data Controller (GDPR) and Covered Entity (HIPAA).
This policy covers all security incidents and data breaches affecting:
a) The AITACS CRM server infrastructure (MySQL database, API endpoints, hosting environment);
b) User accounts (unauthorized access, credential compromise);
c) Data in transit (interception of communications between browser, server, or AI provider);
d) Third-party subprocessor incidents (OpenAI, hosting provider, Firebase) that affect AITACS CRM data;
e) User-side incidents (lost/stolen devices, compromised credentials) reported to the Provider.
| Severity | Definition | Examples | Response Time |
|---|---|---|---|
| Critical | Confirmed breach of PHI or personal data with high risk to data subjects | Database compromise with data exfiltration; unauthorized access to clinical records; ransomware on server | Immediate — within 1 hour |
| High | Confirmed unauthorized access without evidence of data exfiltration, or breach of non-clinical 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; user 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, User 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 User accounts
— Taking affected endpoints offline if necessary
— Rotating database credentials
Assess scope: determine which Users, End Clients, data categories, and systems are affected. Identify the attack vector.
Determine if the incident qualifies as a Data Breach — i.e., whether personal data or PHI 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: was the data transmitted to OpenAI de-identified at
the time? If yes, the exposed data is not PHI and does not constitute a HIPAA breach. The de-identification
audit markers (_deidentified, _server_deidentified) provide 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. See Section 5 for detailed notification requirements and timelines under GDPR and HIPAA.
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 (HIPAA) or as required by applicable law.
Communicate lessons learned to affected Users if appropriate.
When a confirmed Data Breach involves personal data or PHI, the Provider must notify the relevant parties within the timelines required by law. GDPR and HIPAA have different requirements:
72 hours
To the Controller (User): 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: 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.
60 days
To the Covered Entity (User): the Business Associate must notify the Covered Entity no later than 60 calendar days after discovery of the breach.
To HHS: the Covered Entity's obligation. Breaches affecting 500+ individuals must be reported to HHS within 60 days. Smaller breaches are reported annually.
To Individuals: the Covered Entity's obligation. Must notify affected individuals without unreasonable delay, no later than 60 days after discovery.
Exception: if the breach involves only de-identified data (per Safe Harbor), it is not a breach of PHI and HIPAA notification is not required.
All breach notifications from the Provider to the User 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 / PHI involved;
e) Whether the affected data was encrypted or de-identified at the time of the breach;
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 User (Covered Entity / Controller) regarding notification to data subjects or authorities;
i) The contact details of the Provider's incident response contact.
Users (therapists, psychologists, coaches) play a critical role in the security ecosystem. User-side incidents are the most common breach vector.
Users 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 client data in localStorage or browser storage;
b) Suspected account compromise — unexpected login notifications, password reset emails not initiated by the User, 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 client data displayed on screen;
e) Accidental disclosure — the User inadvertently shared client data with an unauthorized person (e.g., sent an export file to the wrong email);
f) Phishing — the User clicked a suspicious link or provided credentials to a site impersonating the Platform.
If you suspect a security incident involving your AITACS CRM 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 / User report / Subprocessor notification]
Severity: [Critical / High / Medium / Low]
Classification: [Security Incident / Confirmed Data Breach]
Description: [Narrative of what happened]
Systems Affected: [Server / Database / API / User Account / Third-party]
Data Categories Affected: [PHI / Personal Data / De-identified Data / Account Data]
Data Subjects Affected: [Number and type: End Clients / Users]
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 CRM's security architecture is the dual-layer de-identification of data before AI transmission. This has a direct impact on breach classification:
Under 45 CFR §164.402, a "breach" is defined as the unauthorized acquisition, access, use, or disclosure of
Protected Health Information. Data that has been de-identified per Safe Harbor (45 CFR
§164.514(b)) is not PHI. Therefore, if an incident affects only the data stream between the
Platform and OpenAI, and the de-identification filters were functioning correctly at the time (as evidenced by
the _deidentified and _server_deidentified audit markers), the incident does
not constitute a HIPAA breach and does not trigger HIPAA notification obligations.
Under GDPR, if the personal data involved in a breach was rendered unintelligible to unauthorized persons (e.g., through encryption or de-identification), the Controller may not be required to notify data subjects (Art. 34(3)(a)). The de-identification applied to AI-transmitted data significantly reduces the risk classification of incidents involving that data stream.
However, incidents affecting the MySQL database or localStorage — where full, identifiable data is stored — are treated as potential PHI/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. Users 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: aitacs@skillbuilder.club
WhatsApp: +972-53-609-5496
Web: skillbuilder.club
Response SLA: initial acknowledgment within 24 hours; full assessment within 48 hours; containment for Critical/High within 4 hours.
Terms of Service · Privacy Policy · Data Processing Agreement (DPA) · Business Associate Agreement (BAA) · Subprocessor List · User Security Requirements · Informed Consent Template