Security Incidents & Compliance Events
Security Incidents & Compliance Events
Category: Customer Lifecycle | Audience: undefined | Page: 30 of 33
Table of Contents
- Generate a Post-Incident Report
- Align with Regulatory Notifications
- Manage Customer and Regulator Communication
Security Incidents & Compliance Events
Welcome to Elixia Health's comprehensive guide on handling security incidents and compliance events. This document is designed to help you understand the processes and best practices for managing these critical events, ensuring the integrity and security of our clinical trial platform.
Key Concepts
- Security Incident: An event that compromises the confidentiality, integrity, or availability of our platform's data or systems.
- Compliance Event: An event that requires adherence to regulatory standards such as GDPR or HIPAA.
What You Can Do
- Detect and report security incidents
- Investigate incidents thoroughly
- Document root causes
- Generate post-incident reports
- Align with regulatory notification requirements
- Manage communication with customers and regulators
How To
Report a Security Incident
- Identify the incident and assess its severity:
- Recognize potential security incidents such as:
- Unauthorized access or login attempts
- Data loss, corruption, or unexpected changes
- Unusual system behavior or performance degradation
- Suspected malware or ransomware activity
- Accidental exposure of sensitive data
- Third-party breach notification
- Failed security controls or authentication issues
- Determine the severity level based on incident impact (refer to SEV 1-5 definitions)
- Document the initial observations and timing
- Preserve evidence (logs, screenshots, system state) without modifying the incident
- Use the MCT portal to log the incident:
- Navigate to Administration > Security > Incident Reporting
- Click on "Report New Incident" button
- Fill in the incident report form with the following information:
- Incident Title: Brief descriptive title (e.g., "Unauthorized Access Attempt - Patient Records")
- Date/Time of Detection: When the incident was discovered
- Date/Time of Occurrence: When the incident actually occurred (if different)
- Severity Level: Select SEV 1, 2, 3, 4, or 5 based on impact assessment
- Incident Type: Choose from categories (Data Breach, Malware, Unauthorized Access, System Failure, etc.)
- Affected Systems: List systems, databases, or applications involved
- Data Affected: Describe what data is potentially compromised (PHI, PII, system files, etc.)
- Number of Individuals Affected: Estimated count of data subjects or users
- Initial Description: Detailed narrative of what happened and how it was discovered
- Reported By: Your name, title, and contact information
- Preliminary Containment Steps: Any immediate actions already taken
- Attach relevant documentation or screenshots
- Submit the incident report
- Notify the incident response team immediately:
- For SEV 1 or 2 incidents: Call the incident response hotline immediately (do not wait for email)
- Phone: [Incident Response Contact Number]
- Provide incident report number from the MCT portal
- Verbally describe the situation and severity
- For SEV 3 or lower: Send email notification to [email protected]
- Include the MCT incident report number
- Provide a brief summary and severity assessment
- Ensure notification includes:
- Incident report number from MCT
- Severity assessment
- Initial containment status
- Key contacts for follow-up questions
- Maintain availability for immediate follow-up questions
- Do not attempt to investigate further without incident response team guidance for SEV 1/2
Investigate an Incident
- Initial Detection:
- Automated systems trigger an alert based on:
- Unusual login patterns or failed authentication attempts (Security Information and Event Management - SIEM)
- Abnormal data access patterns (Database Activity Monitoring - DAM)
- File integrity monitoring alerts (unexpected file modifications)
- Network anomalies (unusual traffic patterns, data exfiltration)
- Antivirus or malware detection alerts
- Manual reports from staff members
- Alerts are automatically routed to the Security Operations Center (SOC)
- On-call incident response team is immediately notified for critical alerts (SEV 1/2)
- Assessment and Containment:
- Response team triage the incident:
- Verify the alert is legitimate and assess scope
- Determine initial severity and impact
- Identify affected systems and data
- Assess ongoing risk and need for immediate containment
- Containment actions (if required):
- Isolate affected systems from network (for data breach scenarios)
- Disable compromised user accounts (for unauthorized access)
- Block suspicious IP addresses at the firewall
- Revoke API keys or tokens if compromised
- Implement emergency access controls to prevent further damage
- Document all containment steps with timestamps
- Preserve system state for forensic analysis
- Notify key stakeholders of containment actions
- Evidence Collection:
- Use automated tools to gather digital evidence:
- Log Aggregation: Collect all system logs, application logs, and security logs
- Security logs: Failed logins, permission changes, file access
- Application logs: User actions, data access, modifications
- System logs: Error messages, service restarts, system events
- Database Snapshots: Capture database state at time of discovery
- Transaction logs showing data changes
- User access logs with queries executed
- System table changes
- Memory Dumps: Capture volatile memory from affected systems (for malware investigations)
- Network Traffic: Export relevant network packets and traffic logs
- File Hashes: Calculate hash values of modified files to verify integrity
- Timestamps: Ensure all evidence is timestamped and chain of custody is maintained
- Store all evidence in secure, isolated storage
- Tag evidence with incident number for tracking
- Investigation:
- Analyze collected evidence to determine:
- Root Cause: What actually happened? (technical analysis)
- Review logs chronologically to trace the incident timeline
- Identify initial attack vector or point of compromise
- Determine if it was external attack, insider threat, or system misconfiguration
- Check for any vulnerability exploits or default credentials used
- Scope: How extensive is the impact?
- How many systems were accessed or compromised?
- What data was touched, viewed, or exfiltrated?
- How many data subjects are potentially affected?
- How long was the access active?
- Duration: How long did the incident occur?
- When did it start? (Could be before detection date)
- When was it stopped/discovered?
- Is it still ongoing?
- Intent: Was this accidental, malicious, or negligent?
- Prepare investigation findings document
- Create timeline of events with supporting evidence
- Document all findings with source citations
- Remediation:
- Implement steps to resolve and prevent recurrence:
- Immediate Fixes:
- Patch affected systems if vulnerability was exploited
- Change compromised credentials (passwords, API keys, certificates)
- Update firewall rules to block attack vectors
- Enable additional security monitoring
- System Hardening:
- Disable unnecessary services or ports
- Strengthen access controls and authentication
- Update security configurations
- Deploy additional security tools if gaps identified
- Process Improvements:
- Update security policies based on lessons learned
- Implement additional monitoring or alerting
- Improve incident response procedures
- Add compensating controls if needed
- Testing:
- Verify patches are applied and effective
- Test that systems are functioning correctly post-remediation
- Validate that controls are working as intended
- Post-Incident Analysis:
- Conduct a thorough review within 5-10 business days:
- What happened?: Objective summary of the incident
- Why did it happen?: Root cause analysis
- Why wasn't it detected sooner?: Detection/monitoring gaps
- Why wasn't it prevented?: Control failures
- What did we do right?: Positive actions taken
- What could we improve?: Lessons learned and recommendations
- Identify systemic improvements and preventive measures
- Assign action items with owners and deadlines
- Share findings with relevant teams for broader learning
- Final Documentation:
- Complete the incident report with all findings
- Include:
- Executive summary for leadership
- Detailed timeline of events
- Evidence summary and key findings
- Root cause analysis
- Remediation steps taken
- Recommendations for prevention
- Lessons learned
- Communicate final report to:
- Executive leadership
- Affected customers
- Regulatory bodies (if required)
- All relevant internal stakeholders
- Archive incident documentation for compliance records
Document the Root Cause
- Access the Investigation Checklist in the MTJ Site Coordinator portal:
- Log in to MTJ with your credentials
- Navigate to Studies > [Study Name] > Compliance > Investigation Checklist
- Or go to Security > Incident Management > Root Cause Analysis
- Select the incident from the list or create a new checklist if needed
- Click on "View/Edit Checklist" to open the form
- Fill out the checklist with detailed answers:
- Incident Overview Section:
- Incident ID: [Auto-populated from incident report]
- Title and Description: Summary of what occurred
- Date/Time of Incident: When it occurred
- Date/Time of Detection: When it was discovered
- Persons Involved: Names of individuals affected or responsible
- Root Cause Analysis Section (Five Whys or Fishbone Analysis):
- Why #1: What is the most immediate cause?
- Example: "User account credentials were compromised"
- Why #2: Why did that happen?
- Example: "User reused weak password across multiple systems"
- Why #3: Why was that allowed?
- Example: "Password policy enforcement was not enabled for that system"
- Why #4: Why wasn't the policy in place?
- Example: "Legacy system couldn't support strong password policies"
- Why #5: What is the ultimate root cause?
- Example: "System architecture didn't support modern security standards"
- Contributing Factors:
- List other factors that contributed to the incident:
- Process gaps or inadequate procedures
- Training deficiencies
- Configuration errors or misalignment
- Resource constraints
- Third-party issues
- Technical Details:
- System(s) involved
- Vulnerability or misconfiguration details
- Attack vectors if applicable
- Configuration settings that were incorrect
- Control Failures:
- Which security controls failed to prevent the incident?
- Why did the controls fail (disabled, not properly configured, etc.)?
- Were controls in place but not effective?
- Provide a comprehensive description of the root cause:
- Write a detailed narrative that explains:
- The sequence of events that led to the incident
- The underlying root cause (not just symptoms)
- Why the root cause was not identified earlier
- How the root cause relates to broader system or process issues
- Example structure:
"The incident was caused by [specific root cause]. This occurred because [underlying reason].
The root cause was not identified earlier because [detection gap]. To prevent recurrence,
we must address [systemic improvement needed]."
- Ensure the description is factual, objective, and evidence-based
- Avoid blame; focus on system and process improvements
- Save and submit the completed checklist
Generate a Post-Incident Report
- Access MCT and select the incident report template:
- Log in to MCT with Admin or Compliance Officer credentials
- Navigate to Security > Incidents > [Incident ID]
- Click on "Generate Report" or "Post-Incident Report Template"
- The template will open with predefined sections
- Fill in the required fields with incident details:
- Executive Summary (1-2 paragraphs):
- High-level overview of the incident
- Impact and severity
- Key resolution steps
- Incident Details:
- Incident ID, Title, Date/Time, Severity Level
- Type of incident and classification
- Affected systems and data
- Number of individuals affected
- Timeline:
- Initial occurrence time
- Detection time and method
- Initial response actions
- Containment completion time
- Resolution completion time
- Key milestones with timestamps
- Impact Assessment:
- Data compromised (types and quantity)
- Individuals affected (names if required for notification)
- Operational impact (downtime, service disruption)
- Regulatory or compliance implications
- Financial or reputational impact
- Root Cause Analysis:
- Root cause as documented in investigation checklist
- Contributing factors
- Technical analysis
- Response Actions:
- Immediate containment steps
- Remediation measures implemented
- Workarounds if applicable
- Lessons Learned:
- What did we learn from this incident?
- What should we do differently?
- Improvements to prevent recurrence
- Recommendations:
- List specific action items with owners and deadlines
- Prioritize recommendations by impact and feasibility
- Include estimated resources and effort
- Regulatory Notifications:
- Whether notifications are required (GDPR, HIPAA, etc.)
- Timeline for notifications
- Notification details and recipients
- Generate and review the report:
- Click "Generate PDF Report" or "Export Report"
- Review for accuracy, completeness, and clarity
- Ensure all required fields are populated
- Verify timeline is accurate and matches evidence
- Check that recommendations are specific and actionable
- Confirm that sensitive information is appropriately handled
- Obtain approval from Security Officer or CISO
- Finalize and save the report to incident file
Align with Regulatory Notifications
When a security incident or data breach occurs, notification to regulatory authorities and affected individuals may be required:
- GDPR (European Union Regulation):
- Notification Deadline: Within 72 hours of becoming aware of the breach
- Who to Notify:
- Supervisory Authority: The relevant Data Protection Authority (DPA) in the affected jurisdiction
- Example: CNIL (France), BfDI (Germany), ICO (UK)
- Data Subjects: Only if there is a high risk to their rights and freedoms
- High risk includes breaches of special categories of data (health, genetic data)
- Breaches affecting large numbers of individuals
- Breaches of authentication credentials
- Notification Content:
- Name and contact information of Data Protection Officer
- Description of the breach and likely consequences
- Measures taken or proposed to address the breach
- Contact point for further information
- Documentation: Maintain records of:
- When breach was discovered
- Date/time of notification to supervisory authority
- Justification if high-risk determination made
- Content of notifications sent
- HIPAA (United States - Health Insurance Portability and Accountability Act):
- Notification Deadline: Without unreasonable delay and in no case later than 60 calendar days after discovery of the breach
- Who to Notify:
- Affected Individuals: Provide notice in writing (email acceptable if indicated by individual)
- Media: If 500 or more residents in a jurisdiction are affected
- Secretary of HHS (Department of Health and Human Services): If 500+ individuals affected
- Business Associate: Notify your business associate of the breach if applicable
- Notification Content:
- Description of what happened (plain language)
- Description of types of information involved
- Steps individuals should take to protect themselves
- What you are doing to investigate and prevent recurrence
- Contact information for more information
- Documentation: Maintain records of:
- Breach notification log
- Notices sent with dates
- Individual responses or questions
- Media inquiries and responses
- Other Regulations:
- State Breach Notification Laws (US): Vary by state; some require notification within specific timeframes
- California CCPA: Requires "without unreasonable delay" notification
- Canada PIPEDA: Requires notification if breach poses significant risk of harm
- Check applicable regulations based on where your organization and data subjects are located
Manage Customer and Regulator Communication
- Create a new communication in the MCT portal:
- Navigate to Communications > New Communication
- Select communication type:
- Breach Notification: For required regulatory notifications
- Incident Update: For customer or internal stakeholder updates
- Status Report: For ongoing incident communications
- Post-Incident Summary: For closure communications
- Populate the communication form:
- Recipients: Select individuals, email lists, or roles to notify
- Subject Line: Clear, professional subject describing the communication
- Message Body: Detailed content tailored to audience
- Attachments: Include reports or supporting documentation as needed
- Urgency Level: Urgent, High, Normal, or Low
- Delivery Method: Email, SMS, Portal notification, or combination
- Assign it to the appropriate recipient:
- For Customers: Typically assigned to Customer Success or Account Management
- Use predefined notification templates for consistency
- Ensure message is appropriate for customer audience (non-technical language)
- Include action items if customers must take steps (e.g., reset passwords)
- For Regulatory Bodies: Assigned to Compliance Officer or Legal
- Use formal notification templates meeting regulatory requirements
- Include all required information per GDPR, HIPAA, or applicable regulation
- Send via certified method if required (GDPR requires written notification)
- For Internal Leadership: Assigned to Security Officer, CISO, and executives
- Include technical details and full impact assessment
- Provide clear recommendations and next steps
- For Affected Individuals: If required by regulation
- Assign to Compliance and Legal teams
- Ensure notification complies with language and format requirements
- Include instructions for protection measures
- Track and respond to communications, updating status as needed:
- Monitor response and delivery status:
- Sent: Confirmation of delivery
- Delivered: Confirmation recipient received the message
- Opened: Email open tracking (if available)
- Responded: Track replies and questions
- Acknowledged: Confirmation of receipt by regulatory authority
- Document responses:
- Log any questions or concerns raised by recipients
- Record regulatory feedback or follow-up requirements
- Track customer inquiries and resolutions
- Update communication status:
- Set status to "Acknowledged" when confirmations received
- Update status to "Resolved" when all follow-up items completed
- Include closure date and summary of outcome
- Maintain audit trail:
- Keep records of all communications sent
- Preserve replies and acknowledgments
- Document timeline of communications
- Archive communication records for compliance
Tips & Best Practices
- Regularly review and update your incident response plan.
- Conduct periodic training for your team on incident handling procedures.
- Maintain clear and open communication channels with both customers and regulators.
Next Steps
- Familiarize yourself with the MCT and MTJ portals.
- Review incident report templates and investigation checklists.
- Ensure your team is trained on incident response and compliance procedures.
Navigation
← Previous: Go-Live & Operations
📚 Documentation HomeNext: Scaling, Change & Maintenance →
Generated from MCT Knowledge Base • v1.1.0 • January 2, 2026