Hi folks. I'm NHI re an experienced software professional with over two decades experience in building large scale distributed systems and low latency system. In today's talk I'll talk about managing regulatory incidents in hipaa, GDPR, and. DMA environments. Today's agenda will be split into five different sections. The first section about it will be about the regulatory incident paradox, which will talk about the competing needs for quickly mitigating issue while balancing the need to. Meet the compliance requirements and then we'll move on to look at the regulatory landscape and the shortcomings of the various key regulations in place like hipaa, GDPR, and DMA. Once we understand the lay of the land, we will move to the compliance aware framework where I will introduce your robust framework to integrate regulatory obligations while meeting the most important need to meet the technical recovery. After introducing the competency wire framework, I'll move to balancing priorities and communications during an incident. The last part of the talk will be about building your own incident playbook, where I'll provide practical tapes for developing a comprehensive compliance ready incident response playbook. Alright let's get started with the regulatory incident paradox. When systems fail the responders or operators face a dual mandate, right? The first priority is about the technical recovery, which is mainly about restoring the system functionality and mitigating the data laws, and prevent any cascading failures. And stabilize the environment to get back to the steady state. The competing side of an incident is like the regulatory obligations where things like the mandatory reporting timelines and the documentation requirements come into play, along with evidence preservation and the legal and forensic mandates. So the first part so basically the technical recovery is more about speed. We need to recover the system as quickly as possible, which competes with the accuracy needs for the regulatory obligations. Another aspect is the resourcing conflict, right? Most of the times the responder team will be small and the teams are pulled between immediate remediation and while, the while they have the conflicting need to meet the administrative burden of compliance. This also brings up the comp communication challenges. Balancing transparent, timely communication with the legal and the regulatory constraints on the shared information comes into picture while mitigating incidents. Before we understand the, the. Framework, it's important to understand the regulatory landscape. So the current regulatory landscape can be split into three broad categories. The first one is hipaa, which mainly deals with the healthcare regulations. The HIPAA mandates that any reporting of the personal health information incidents should happen within 60 days. It mandates, the required notification is sent to the affected individuals along with the regulatory bodies like HHS and potentially media outlets depending on the scale of the incident. And thorough risk as assessments are mandated for accurate incident classification. The second important regulation is GDPR, which is EU mandated data protection. It enforces a 72 hour breach notification to supervising authorities. For any high risk breaches, it requests the data subject notification without any UE delay and detailed documentation and impact essence assessments are essential. The the last or the latest regulation is d. Short form for the digital markets side, which demands transparent communication regarding any algorithmic failures. Imposes continuous service obligation even during incident responses. DMA put constraints during mitigations by establishing strict rules on sensitive data access. And usage during recovery efforts. Now let's dive a little more deeper into each of these regulations. Let's start with hipaa. HIPAA comes into picture when the healthcare systems fails. It brings unique challenges like balancing emergency service availability with the breach containment and determining if any personal health information was compromised during system outages. Also mandating the forensic evidence are collected while restoring critical services. It also mandate conducting risk assessments during active incidents. The breach notification rule from HIPAA mandates that any breaches with the PHI incidents are reported to HHS and potentially media. Typically within 60 days. A direct notification to affected individuals should be sent without any undue or delay. Detailing incident information involved and mitigation steps. He also involves risk assessment and documentation. The risk assessment ensures that we can classify the breach severity correctly along with the detailed documentation of the incident. Response. And decision is crucial for compliance and audits. Let's move to GDPR. The key thing to about GDPR is about racing against the 72 hour clock. It starts from R zero when the incident is first reported through an alerting or any other auto detection mechanisms and asked. Zero to 24 is where the preliminary assessment is done. Determine the most important thing is to determine if any personal data was affected and then start, begin evidence collection for later reporting. And R 24 to 28 is about further risk assessment. Evaluate the risk to impacted subjects and draft the notification documents. During hours 48 to 72 can be classified as the notification period. During this period, submit the notification to the supervisory authority and prepare communication to the impacted individuals. Let's quickly take a look at the DMA mandate as well. The digital markets Act. Places a specific stringent obligations on tech platforms called gatekeepers, introducing unique incident response challenges. It should ensure that it should ensure that maintaining inter interoperability during incidents and transparent reporting of any algorithmic issues and demonstrating fairness in service restoration priorities. Let's look at like where traditional incident response management systems fail fall short, right? Traditional incident and management system often prioritizes system recovery as quickly as possible. And it fails to account for the intricate regulatory requirement that fundamentally alter incident response times. So if you look at this picture, there are like, areas like timeline conflicts where regulatory deadlines rarely align with the technical recovery timelines and competing priorities. Balancing immediate business continuity with str strict regulatory requirements bring conflicts. And regulatory requirements bring in a lot of documentation burdens, which slows down the recovery time. Along with the managing the stakeholder complexity, the responders or operators will have to navigate the coordination between the legal and the complaints and the PR teams. The regulatory requirements also put data access limitations which can hamper the recovery. A lot of times the responders need at least some. Level of access to sensitive production data before taking an action which conflicts with the regulatory requirement to not expose sensitive data to the responders. Yeah, and just a quick recap. So far we looked at the different regulations and the challenges during system recovery. Now we look at how to build a compliance aware incident response framework. So we can divide this compliance aware response framework into three different phase. The first phase is the preparation phase, followed by the recovery response phase and the recovery phase. So during the preparation phase we, the framework should ensure that there are the pre pre-approved notification templates and the complaints protocols in place, and ensure that the team builds privacy, preserving investigation and analysis tools and identify the regulatory requirement mapping. During the response phase there should be like parallel tracks for compliance and mitigation. And then there should be tools in place for regulatory triage assessment. And along with the continuous documentation protocols as well as evidence preservation procedures during the recovery phase ensure that there are compliance recovery compliance verification checkpoints. The checkpoints should ensure that all the data required for complaints are collected in place. Ensure that the progressive service restoration is in place. Now let's look about look at balancing technical and regulatory priorities. The first part is called documentation by design. Ensure that automated in evidence collection is part of the technical response workflows. By ensuring that logs are collected and auditing is in place, and ensure there's a single source reporting for multiple regulatory requirements. The second aspect is called decision frameworks utilize predefined criteria for accurate regulatory classification and implement automated notification triggers based on impact thresholds. The third category is privacy preserving analysis where we deploy different initial privacy techniques for incident investigations and implement data minimization during law collection. The next group is called Parallel Work Streams, where there's like a dedicated technical and compliance teams working in tandem and establish synchronization checkpoints at critical junctures. The synchronization points shows that the data is free flowing between the two parallel tracks. Now let's look at the communication protocols for regulated incidents. The communication protocols can be put into two broad categories. Internal communication and external communications for internal communication ensure that their dedicated communication POC is there on all technical calls. And there is a regular status updates for the compliance offices. And ensure that there's illegal checkpoints for external communication followed by protected communication channels for sensitive discussions. External communication is slightly different from the internal communication. Where there needs to be a tiered communication framework by the regulatory framework. And there should be a regulatory authority. Liaison procedures external communication also mandates a data subject notification, coordination. Now let's look at implementing a compliance aware monitoring. The first aspect is proactive regulatory alerting. Ensure that the monitoring systems, which is used to identify incidents are specifically designed to detect compliance related incidents before they escalate into major breaches. The second aspect is personal data flow tracking map and continuously monitor all systems, which is track which is processing or tracking sensitive data. Ensuring heightened visibility into data moments and access patterns. The last aspect is automated regulatory timeline triggers establish automated notification for critical complex deadlines triggered by the classification and progression of incident. Now let's look at the privacy preserving incident analysis. The challenge is incident investigation often require access to production data containing regulated information, creating a compliance conflict. Investigators need data access to assess the impact regulation risk. The flip side or the, from the regulation aspect is that regulator regulators restrict access to sensitive informations. And they which in another word is like evidence collection may violate data minimization. To meet these challenges, modern systems have different technical solutions in place to give a specific example, AWS has something called SSM system Manager, which is an automated tool to, for operators to mitigate incidents while preserving logs and auditing without direct access to production systems by eliminating the direct access to production systems. Directly meets the regulatory mandate by masking the production data from operators and oncology engineers. Now let's look at building a complex rare ready incident playbook, right? This can be split into multiple group. The first one is map peer regulatory landscape, right document, which all regulations apply to your domain and the systems in place. And create their reference metrics for notification requirements and deadlines. And the second aspect is to integrate with the compliance personnel and designate a compliance lesson person for incident teams and train technical responders on regulatory implications and develop documentation templates. Create pre-approved notification templates for each regulation. And implement standardized evidence collection procedures. The next one is about establishing a decision frameworks defend clear criteria for regulatory incident classification and create decision tree for compliance related response actions. The last aspect is practice combine scenarios. This is about creating a game day or a mock testing for incidents involving. Regulatory data the game day or mock testing should ensure that the technical recovery is as quick as possible along with preserving all the data auditing and logs needed for regulatory reporting. The game day should also test the notification procedures and timelines to meet the regulatory needs. The let's to wrap up, let's look at the key takeaways from this presentation. The first important takeaway is integration is essential. Seamlessly integrate technical and compliance workflows from the tum, from the outset rather than attempting to retrofit from during a crisis. This can be ensure by using automated tools which can create audit logs and eliminating direct production system access. The second important key takeaway is the preparation. Preparation is key to enable compliance thorough preparational laws organization to meet to regulatory requirements effectively without compromising the agility of their technical incident response. The last aspect is balance, competing priorities. Achieving efficient incident management and regulated environment relies on skillfully balancing rapid technical recovery. With ongoing business continuity and strict compliance obligations. I hope everyone found this talk useful. Thank you for listening to this talk.