This is the third installment of our Test-Driven Compliance series. If you're new to the topic, I recommend starting with the previous posts ( 1 and 2).
Today, we'll take one of the controls defined in our last post and test it in a simulated AWS environment. This will help reinforce the concepts and demonstrate that compliance control testing is simply a form of testing, much like integration tests.
This post is the second one in our Test-Driven Compliance series. If you missed the first post, be sure to check it out! This time, we’ll dive into a hands-on example to demonstrate a developer-first approach to compliance.
The Digital Operational Resilience Act (DORA) is the European Union's response to ever-increasing, more sophisticated, and elaborate cyber threats. Effective since January 17, 2025, DORA is reshaping the financial world by setting higher standards for cyber resilience.
I’ve spent over a decade in the payments industry, and if there’s one universal challenge for engineering teams, it’s compliance. Regulations and standards sit at the crossroads of two fundamentally different worlds. Engineers thrive on innovation, always pushing the boundaries of what technology can automate. Compliance, on the other hand, is rooted in control and safety. So far, its digital evolution has largely been a direct translation of analog processes where rules copied and pasted into a digital format rather than reimagined for the digital age.
When I started with PCI DSS auditing in finance, I thought that was the full extent of what audits entailed. But I quickly learned that audits vary widely, especially when moving from a technology supplier to a regulated entity. Each environment brings its own complexities, especially when tied to compliance and the ability to move money. The shift from clear, strict standards like PCI DSS to risk-based regulatory approaches can be a challenging adjustment for engineers and other professionals alike.