Cybersecurity Integration: Stories from the Trenches

For us at kopexa, every new cybersecurity regulation carries the risk of causing “control fatigue.” So with NIS2, we refused to just hand users another massive, isolated checklist.

We tackled it from a data perspective. Using OSCAL, we mapped out the exact intersections between NIS2 and what most companies already do for ISO 27001. Once you map the overlaps, the actual new work is minimal—we cut the whole NIS2 requirement down to just 29 unique controls.

It worked so well because frameworks simply need to talk to each other. We don’t view a new regulation as an island. Because we built our NIS2 update to drop right into an existing ISO environment, teams aren’t reinventing the wheel. They’re just doing the missing 10 percent.

One example that stands out for us was when we integrated new data protection and breach reporting requirements aligned with global privacy regulations into ZeroThreat’s platform.

As a co-founder, I believe that compliance should not be a checkbox but rather operationalized. When we encountered this requirement, rather than considering them as an independent compliance layer, we integrated them directly into our automated pentesting and validation processes.

Our initial step was to map regulatory controls to real, exploitable risk situations. For instance, rather than merely stating that sensitive data is secure, we converted it into an operational form, such as detecting exposed PII when using API calls, improperly configured storage or a poorly implemented authentication process. We then optimized our scanning engine to automatically identify such patterns and attribute them to compliance-oriented reporting.

The actual change was in the validation layer. We made sure that all the issues identified were not mere theoretical observations but proven, reproducible risks that have definite business consequences. This brought the compliance reporting much closer to the security leaders—they could clearly see their position, what they could exploit, and what they needed to take action on.

Three things made this integration successful:

First, we made compliance meet with engineering reality. Teams were not compelled to make sense of regulations, but rather we converted them into practical security tests.

Second, we made it continuous. Organizations were now able to check compliance posture in real time as part of the development lifecycle as opposed to periodic audits.

And third, we concentrated on usability. The output was not only technical, but contextual, ranking risks by impact, and this allowed security and business stakeholders to make quicker decisions.

Ultimately, this strategy transformed compliance into a responsive practice into a proactive security benefit, i.e., that is how we believe contemporary cybersecurity should work.

In my previous role, I helped our company comply with the UAE Data Protection Law (PDPL) and NESA cybersecurity regulations using our existing security framework (ISO 27001 and NIST CSF). I did not start from zero or build a separate “privacy program.” Instead, I added the new requirements to our existing processes.

First, I used NIST CSF as a common language. We already used it to manage cyber risks, so I mapped the UAE rules to the same areas: governance, identification, protection, detection, response, and recovery. Then I reviewed which controls we already had and where we had gaps, such as breach notification steps or stricter access controls for personal data.

Next, I updated our risk assessments and policies. We added privacy impact to our risk register (the data we collect, its sensitivity, and potential risks). We also updated key procedures, including incident response, vendor management, and data retention, to clearly reflect PDPL and NESA requirements and to provide appropriate evidence.

Finally, I built the changes into our existing routines: the same committee that reviewed ISO 27001 risks also reviewed PDPL and NESA issues, and the same security awareness training now includes simple examples about UAE privacy rules. This made it easier for staff to understand and follow the changes.

This integration was successful because:

We reused the framework people already knew, so change felt smaller and more practical.

We clearly showed what was already compliant and what needed fixing, so management could focus the budget on real gaps.

We built the new rules into our regular governance, risk, and training cycles, ensuring compliance was continuous rather than a one-time project.

One example that stands out is working with a Saudi financial institution that needed to align with the SAMA Cyber Security Framework, specifically the requirements around continuous monitoring, incident response, and data classification within national boundaries.

The challenge was not the regulation itself. The challenge was that their existing SOC setup was built around tools that assumed centralized data aggregation, some of it crossing infrastructure they could not fully control. SAMA CSF does not leave room for ambiguity on data handling. So the first question was not “how do we comply” but “how do we rebuild detection and response to work entirely within this perimeter without losing capability.”

We deployed OmniSense™ by Sirp within their own environment. Alert ingestion, enrichment, correlation, all of it stayed local. No telemetry leaving the boundary. That addressed the data residency requirement directly.

The harder problem was continuous learning. You cannot improve a detection model in isolation if you’re afraid to share anything outside the walls. We handled this through federated learning, training models locally and sharing only encrypted weight updates, not raw data. The system got smarter over time without the data ever moving.

SAMA CSF also has a strong audit and accountability dimension. Every automated action OmniSense™ took came with reasoning attached, what triggered it, what evidence supported it, what the confidence level was. When their compliance team needed to demonstrate accountability to auditors, that trail was already there. It was not reconstructed after the fact.

What made it work was a simple decision made early: we treated the regulation as a constraint that the architecture had to satisfy, not a report to file afterward. Once you do that, you stop fighting it and start designing around it. The result was a system that was genuinely more defensible, not just on paper.

I am a Chief Information Security Officer, and I recently updated our security systems to match Peru’s new national cybersecurity rules. I had only 90 days to make our property technology platform follow these strict government standards, or we would have faced heavy fines.

I followed a clear roadmap to make sure we were protected and legal. I compared our current setup to the new laws and found 12 specific areas we needed to fix. That included the way we check our suppliers and monitor threats. Our old security wall was replaced with a system based on zero trust. It was done for all 120 staff members. That ensured that every single login was verified and safe. It also involved setting up an automated alert system that can notify the authorities about a security issue in just 10 minutes.

“Framework inheritance” was the biggest reason for our success. As we already had strong international security in place, about 85% of the work was already done. When most other companies took 150 days, we finished the project in 76 days.

One example that stands out was integrating updated data protection and reporting requirements into our existing security framework without disrupting day-to-day operations. Instead of treating it as a separate compliance project, we mapped the new requirements directly to the controls and processes we already had in place.

We started by identifying where there was overlap between the regulation and our current policies, things like access controls, logging, and incident response. In many cases, it was not about building something new, but tightening documentation, improving visibility, and making sure controls were consistently enforced. Where gaps existed, we addressed them in a way that fit into existing workflows rather than creating parallel processes.

What made the integration successful was keeping it practical. We involved both technical teams and leadership early, so everyone understood not just what needed to change, but why. We also tested updates in phases instead of rolling everything out at once, which helped us catch issues before they impacted operations.

The biggest takeaway is that compliance works best when it aligns with how your organization already operates. When you build on existing systems and keep the process straightforward, adoption is much smoother and the end result is both compliant and sustainable.

Integrating tighter HIPAA-aligned protocols into a remote setup was one of the more practical challenges we had to solve.

As we grew, we couldn’t just add more rules on paper. The real issue was making sure those requirements held up in everyday work like scheduling, charting, and billing, where teams are moving quickly and under constant pressure.

We ended up rebuilding parts of the workflow instead of forcing compliance on top of it. Access is tied closely to roles, work is done inside secure environments, and tasks follow clearer, more consistent steps. We also shifted training to be more scenario-based so people could see exactly how it applies in real situations.

What made it work is that it didn’t feel like extra effort. It became part of how the job gets done.

If security feels like friction, people will find ways around it. If it fits naturally into the workflow, it sticks.

The integration that taught me the most was adapting our healthcare cloud infrastructure framework to meet increasingly stringent HIPAA security rule requirements after a series of high-profile healthcare breaches in the industry prompted internal security reviews. The challenge was not understanding what the regulation required, that part is well documented. The challenge was that our existing framework had been built incrementally over several years and the security controls were scattered across different layers of the infrastructure with inconsistent implementation and no unified audit trail. Compliance on paper looked fine. Compliance in practice had gaps that a determined auditor would have found quickly.

What made the integration successful was treating it as an architecture problem rather than a checklist problem. Instead of mapping each regulatory requirement to an existing control and documenting the gap, I rebuilt the audit and access logging layer as a first class infrastructure component that every service wrote to consistently. That single change meant that when an auditor asked for evidence of access controls on a specific category of patient data, we could produce a complete tamper-evident log in minutes rather than assembling evidence from five different systems that used different formats and retention policies.

The thing that made it stick rather than regress over time was automating the compliance validation into the deployment pipeline. Any service that did not meet the logging and encryption standards could not be deployed. The regulation became a gate rather than a review. Most compliance integrations fail not because the initial implementation is wrong but because the organization has no mechanism to prevent drift. When the standard is enforced at deployment time rather than audit time, drift becomes structurally difficult rather than just discouraged, and that is the difference between a framework that holds and one that slowly falls apart between audit cycles.

Regulatory changes tend to look straightforward on paper, then create friction once they meet existing systems. The gap usually shows up between what the regulation asks for and how teams actually operate day to day.

This came up when we had to align our controls with GDPR across a product environment that had grown quickly over time. Data handling practices were not centralized. Different teams owned different parts of the lifecycle, and documentation did not always reflect what was happening in production.

The initial approach proved cumbersome. We attempted to translate every single requirement directly into new policies and controls. This backfired, slowing teams considerably and generating resistance, particularly from engineering. Progress ground to a halt, as it seemed like an external burden was being imposed on established workflows.

The shift happened when we stepped back and looked at actual data movement instead of policy language. We traced how user data entered the system, where it was stored, and how it was accessed. That exercise exposed a few high risk areas that were not obvious from documentation alone, including redundant data copies and unclear ownership of deletion requests.

Instead of rolling out broad controls, we focused on those specific points. Access rules were tightened around sensitive datasets. Retention logic was made explicit in the systems handling user data, and deletion workflows were simplified so teams could execute them without escalation.

Within a few weeks, compliance reviews became easier to pass, but more importantly, teams stopped treating the regulation as a separate obligation. It became part of how the system operated.

What made it work was grounding the regulation in real system behavior. Once teams could see where the risks actually lived, changes felt practical instead of imposed.

Successfully integrating new cybersecurity regulations, like GDPR or CCPA, into our framework involved a strategic, modular approach. One example was implementing robust ‘Data Subject Request (DSR) automation’ to handle privacy requests (e.g., data access or deletion). What made it successful was treating DSRs as a standard workflow, not an ad-hoc legal task. We developed internal software that identified and mapped all client data across our disparate systems. When a DSR came in, this tool automatically initiated data collection, redaction, or deletion processes, ensuring compliance and transparency. The key was avoiding a complete re-architecture of existing systems. Instead, we built an API layer that communicated with each system, abstracting the complexity. This allowed us to quickly adapt to regulatory changes, ensuring compliance without excessive manual effort, thereby maintaining client trust and avoiding penalties.

One example from my work in which cybersecurity regulations were successfully integrated into a broader system was the implementation of secure access to enterprise data across both corporate-issued and personal devices.

In our environment, access to sensitive resources such as work emails, Microsoft Teams, and shared documents was initially restricted to corporate-issued devices to protect highly confidential data and maintain system integrity. A key concern was the risk of data leakage if this information were accessed on personal devices, where corporate and personal data could mix, increasing the likelihood of unauthorized access or compromise. While this approach ensured strong security, it limited accessibility and scalability as more users required secure access across platforms.

To address this, I implemented a cloud-based mobile device management (MDM) solution using Microsoft Intune, integrating device compliance with identity-based access control. The objective was to extend secure access to both corporate and personal devices, including iPhones and Android phones, while maintaining strict security controls and governance.

The integration enabled all devices to be governed through a unified platform. Compliance policies, such as encryption, OS version, and security baselines, were enforced and linked to device configuration and compliance policies, as well as Conditional Access policies, ensuring that only compliant devices could access enterprise resources. A secure work profile model was also implemented to isolate corporate data from personal data, allowing users to access work applications without compromising privacy or system security.

This solution was rolled out in phases and has remained in continuous use for over three years, demonstrating long-term stability and effectiveness. Over time, it reduced risks of unauthorized access, including potential breaches and compromise of sensitive data on personal devices, while improving visibility into device compliance and overall security posture.

Additionally, it optimized operational efficiency by reducing reliance on corporate-issued devices, lowering hardware and management costs while expanding secure access to a broader user base.

Overall, this integration successfully aligned cybersecurity requirements with real-world operational needs, creating a scalable and secure framework across on-premise and hybrid environments.