Incident Response Policy
This policy defines how we detect, classify, respond to, and recover from security incidents that may affect the Platform and the personal data we process.
1 Purpose and Scope
This Incident Response Policy ("Policy") establishes a structured and systematic approach for the detection, assessment, containment, eradication, recovery, and post-incident review of security incidents affecting IsYourTraderReal.com ("Platform") and the personal data processed in connection with its operations.
The purpose of this Policy is to:
- Minimize the impact of security incidents on the Platform, its users, and data subjects whose personal data is processed.
- Ensure compliance with the General Data Protection Regulation (GDPR), specifically Articles 33 and 34 regarding data breach notification obligations.
- Provide clear roles, responsibilities, and procedures for incident response team members.
- Preserve evidence for forensic analysis and potential legal proceedings.
- Enable continuous improvement of security posture through lessons learned.
This Policy applies to all security incidents affecting the Platform's infrastructure, applications, databases, and any systems that process, store, or transmit personal data. It covers incidents originating from both internal and external sources, including but not limited to unauthorized access, data breaches, malware, denial-of-service attacks, and social engineering.
2 Incident Classification
Security incidents are classified into four severity levels based on their potential impact on the Platform, its users, and the personal data processed. Classification determines the response priority, resource allocation, and notification requirements.
Critical
Immediate threat to data integrity, widespread compromise, or active exfiltration of personal data.
- Confirmed data breach with personal data exposure
- Complete system compromise or root access by attacker
- Database exfiltration or ransomware encryption
- Active exploitation affecting multiple users
High
Significant risk to the Platform or data, potential for escalation if not addressed promptly.
- Unauthorized access to admin interfaces
- Exploitation of vulnerability with data exposure potential
- Targeted attack on Platform infrastructure
- Evidence of persistent threat actor
Medium
Limited impact with no confirmed data exposure, but requires investigation and remediation.
- Brute-force login attempts (blocked by Fail2ban)
- Suspected vulnerability exploitation attempt
- Unauthorized configuration changes detected
- Unusual traffic patterns or scanning activity
Low
Minimal risk, no data impact, informational incidents that may indicate broader trends.
- Port scanning from unknown sources
- Spam or phishing attempts targeting staff
- Minor policy violations by authorized users
- False positive security alerts
3 Response Team and Responsibilities
The Incident Response Team ("IRT") is responsible for managing all security incidents affecting the Platform. The team consists of the following roles:
- Incident Commander (IC): Leads the incident response process, makes escalation decisions, coordinates resources, and serves as the primary decision-maker during active incidents. The IC has authority to take emergency actions including service shutdown if necessary to protect data.
- Technical Lead: Responsible for technical investigation, forensic analysis, containment, and eradication of threats. Conducts root cause analysis and implements technical remediation measures.
- Data Protection Officer (DPO): Assesses incidents for GDPR implications, determines notification obligations, coordinates with the supervisory authority (UOOU), and manages data subject notifications when required.
- Communications Lead: Manages internal and external communications during and after incidents, drafts user notifications, and coordinates with legal counsel on public statements.
- Legal Counsel: Provides legal guidance on notification obligations, evidence preservation requirements, regulatory compliance, and potential liability.
On-Call Responsibility
The Incident Commander and Technical Lead maintain on-call availability for Critical and High severity incidents. All IRT members are expected to respond within 1 hour for Critical incidents and within 4 hours for High severity incidents during business hours.
4 Detection and Reporting
Security incidents may be detected through the following channels:
4.1 Automated Detection
- Intrusion detection systems: Automated monitoring of network traffic, server logs, and application logs for suspicious activity patterns.
- Fail2ban alerts: Automatic blocking and alerting for brute-force attempts, repeated failed authentications, and suspicious access patterns.
- Server monitoring: Real-time monitoring of system resource usage, process execution, file integrity, and configuration changes.
- Application monitoring: Error rate monitoring, unusual query patterns, and abnormal user behavior detection.
4.2 Manual Detection and External Reports
- Staff observation: Any team member who observes or suspects a security incident must report it immediately to the Incident Commander.
- User reports: Users who discover potential security vulnerabilities or suspect a security incident should report it immediately.
- Third-party notifications: Reports from hosting providers, sub-processors, security researchers, or regulatory authorities.
How to Report a Security Incident
If you have discovered a security vulnerability or suspect a security incident, please report it immediately to:
Email: security@isyourtraderreal.com
Please include as much detail as possible: what you observed, when it occurred, any screenshots or logs, and the potential impact. All reports are treated confidentially.
5 Response Procedures
The incident response process follows five sequential phases. Each phase must be documented in the incident record.
Identify
Confirm the incident is genuine (not a false positive), determine its scope and severity, and classify it according to the severity levels defined in Section 2.
- Verify the incident through multiple data sources and logs
- Determine affected systems, data, and users
- Assess whether personal data has been compromised
- Assign severity classification and activate appropriate response resources
- Begin incident timeline documentation
Contain
Limit the scope and impact of the incident by isolating affected systems and preventing further damage or data exposure.
- Isolate compromised systems from the network
- Block malicious IP addresses and access points
- Revoke compromised credentials and API keys
- Implement temporary access restrictions if necessary
- Preserve system state for forensic analysis before making changes
Eradicate
Remove the root cause of the incident from all affected systems and eliminate the attacker's presence.
- Identify and remove malware, backdoors, or unauthorized access mechanisms
- Patch or mitigate the vulnerability that was exploited
- Reset all potentially compromised credentials
- Verify removal is complete through scanning and log analysis
- Update security rules and configurations to prevent recurrence
Recover
Restore affected systems and services to normal operation while monitoring for any signs of the incident recurring.
- Restore systems from clean backups where necessary
- Verify data integrity and completeness after restoration
- Gradually restore services with enhanced monitoring
- Confirm all systems are functioning normally
- Maintain heightened monitoring for a minimum of 72 hours post-recovery
Lessons Learned
Conduct a thorough post-incident review to identify improvements and prevent similar incidents in the future.
- Conduct a post-incident review meeting within 5 business days
- Document the complete incident timeline, actions taken, and outcomes
- Identify root causes and contributing factors
- Develop and prioritize remediation recommendations
- Update this Policy, runbooks, and security controls as needed
6 Notification Requirements
The Controller is subject to the following notification obligations under the GDPR when a security incident involves a personal data breach:
6.1 Supervisory Authority Notification (Article 33 GDPR)
In the event of a personal data breach, the Controller shall notify the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.
Supervisory Authority
UOOU — Urad pro ochranu osobnich udaju (Office for Personal Data Protection)
Pplk. Sochora 27, 170 00 Praha 7, Czech Republic
Website: www.uoou.cz
The notification to the supervisory authority shall include:
- A description of the nature of the personal data breach, including the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned.
- The name and contact details of the Data Protection Officer.
- A description of the likely consequences of the personal data breach.
- A description of the measures taken or proposed to be taken to address the breach, including measures to mitigate its possible adverse effects.
6.2 Data Subject Notification (Article 34 GDPR)
Where a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the Controller shall communicate the breach to the affected data subjects without undue delay. The communication shall:
- Describe the nature of the breach in clear and plain language.
- Provide the name and contact details of the Data Protection Officer.
- Describe the likely consequences of the breach.
- Describe the measures taken or proposed to address the breach and mitigate its effects.
- Provide recommendations for data subjects to protect themselves (e.g., changing passwords, monitoring accounts).
6.3 Notification Timeline
T+0: Incident Detection
The clock starts when the Controller becomes aware of the breach. The Incident Commander is notified immediately.
T+4 hours: Initial Assessment
DPO assesses whether the incident constitutes a personal data breach and determines notification obligations.
T+24 hours: Internal Escalation
Full incident report prepared for senior management. Legal counsel engaged for regulatory notification review.
T+72 hours: Regulatory Notification
GDPR-mandated deadline for notifying the supervisory authority (UOOU) if the breach is likely to result in a risk to data subjects.
T+72 hours+: User Notification
If high risk to data subjects is identified, affected users are notified without undue delay via email and Platform notice.
7 Evidence Preservation
Preserving evidence is critical for forensic analysis, understanding the scope of an incident, and supporting potential legal or regulatory proceedings. The following evidence preservation procedures apply to all incidents classified as Medium severity or above:
- System logs: All relevant server logs, application logs, database logs, access logs, and network traffic logs shall be preserved in their original, unmodified form for a minimum of 12 months following the incident.
- Forensic images: For Critical and High severity incidents, forensic images (bit-for-bit copies) of affected systems shall be created before any remediation activities begin.
- Chain of custody: All evidence shall be handled with documented chain of custody, recording who accessed the evidence, when, and for what purpose.
- Secure storage: Preserved evidence shall be stored in a secure, access-controlled location separate from production systems, with encryption at rest.
- Incident documentation: The complete incident record, including timeline, communications, decisions, and actions taken, shall be preserved for a minimum of 5 years.
8 Communication Plan
Clear and timely communication is essential during incident response. The Communications Lead coordinates all internal and external communications according to the following guidelines:
8.1 Internal Communication
- All IRT members are briefed on the incident status at regular intervals (every 2 hours for Critical, every 4 hours for High).
- Incident status updates are shared through secure internal channels only. Incident details must not be shared on public or unsecured channels.
- Escalation decisions and significant findings are communicated to senior management immediately.
8.2 External Communication
- No public statements regarding a security incident shall be made without approval from the Incident Commander and Legal Counsel.
- User notifications shall be drafted by the Communications Lead, reviewed by the DPO and Legal Counsel, and approved by the Incident Commander.
- Notifications to data subjects shall be clear, factual, and free of technical jargon, and shall include actionable recommendations.
- The Platform may publish a security advisory on the website for incidents that affect a large number of users.
9 Post-Incident Review
A post-incident review ("PIR") shall be conducted for all incidents classified as Medium severity or above. The PIR is held within 5 business days of incident closure and produces a written report that includes:
- Incident summary: Description of the incident, classification, affected systems, and data impact assessment.
- Timeline: Complete chronological record of detection, response actions, and resolution.
- Root cause analysis: Identification of the underlying cause(s) of the incident, distinguishing between technical vulnerabilities, process failures, and human factors.
- Response effectiveness: Assessment of the response team's performance, including detection speed, containment time, communication quality, and adherence to this Policy.
- Remediation actions: Specific, measurable, and time-bound actions to prevent recurrence, assigned to responsible individuals with deadlines.
- Policy updates: Any recommended changes to this Policy, runbooks, security controls, or training programs.
Blameless Culture
Post-incident reviews follow a blameless approach. The goal is to understand what happened and how to prevent recurrence, not to assign blame. All team members are encouraged to share information openly and honestly during the review process.
10 Policy Review Schedule
This Incident Response Policy is reviewed and updated according to the following schedule:
- Annual review: This Policy is reviewed at least once per year, or more frequently if warranted by changes in the threat landscape, regulatory requirements, or organizational structure. The next scheduled review is March 2027.
- Post-incident updates: This Policy is reviewed after every Critical or High severity incident to incorporate lessons learned and improve response procedures.
- Regulatory changes: This Policy is updated when changes to applicable data protection law (including GDPR, national implementing legislation, or supervisory authority guidance) affect incident response or notification obligations.
- Testing: The incident response procedures described in this Policy are tested at least annually through tabletop exercises or simulated incident scenarios. Test results are documented and used to improve the Policy.
All changes to this Policy are documented with the date, nature of the change, and the person responsible. Previous versions of this Policy are retained for a minimum of 3 years.
11 Contact
For security incident reports, questions about this Policy, or to report a vulnerability:
Security Reports
Email: security@isyourtraderreal.com
For reporting security incidents, vulnerabilities, or suspicious activity.
Data Protection Officer
Email: dpo@isyourtraderreal.com
For questions about data protection and GDPR compliance.
Legal Department
Email: legal@isyourtraderreal.com
Signal Core s.r.o.
Rybna 716/24, Stare Mesto, 110 00 Praha 1, Czech Republic
This Incident Response Policy was last updated on March 22, 2026. It is subject to annual review and may be updated at any time to reflect changes in the threat landscape, regulatory requirements, or organizational procedures.