Skip to content

Test-Driven Compliance by example

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.

Using DORA as our test-bed

The RTS on ICT risk management framework introduces numerous compliance requirements, making it an ideal foundation for defining our operational controls. We’ll take one of these requirements, identify the testable controls and also provide guidelines on how to test them.

🤔 wait a second, what is a control? In compliance jargon, a control refers to a rule, constraint, or capability that is tested and evaluated during an audit.

Our DORA requirement

Financial entities shall design the policy on encryption and cryptographic controls referred to in paragraph 1 on the basis of the results of an approved data classification and ICT risk assessment. That policy shall contain rules for all of the following:

(a) the encryption of data at rest and in transit;

(b) the encryption of data in use, where necessary;

(c) the encryption of internal network connections and traffic with external parties;

(d) the cryptographic key management referred to in Article 7, laying down rules on the correct use, protection, and lifecycle of cryptographic keys.

For the purposes of point (b), where encryption of data in use is not possible, financial entities shall process data in use in a separated and protected environment, or take equivalent measures to ensure the confidentiality, integrity, authenticity, and availability of data.

Still here? The regulatory language may seem overwhelming but don’t worry, this exercise will show how to transform complex legal text into clear, testable controls.

Identifying operational controls

There are a lot of details in the regulatory text that aren't of interest right now, specially those related to the policies. Focusing on the operational aspects gives us a view that is closer to the things we know in engineering:

[C1] Encryption at rest: this is quite straight forward to implement. All storage should be encrypted, including databases, buckets and file storage in general. Most cloud providers offer this out of the box.

[C2] Encryption of data in transit (EXTERNAL): communication to and from third parties has to be encrypted. This is very standard both in regulated environment and anywhere else thanks to services like Let's Encrypt.

[C3] Encryption of data in transit (INTERNAL): we will differentiate it from C2 (encryption of external communication) as there are more nuances in this case. When we implement it, we should clarify at a minimum the following:

  • where does TLS termination happen?
  • how do we communicate between internal products?
  • and how do we communicate between microservices within the same product?

[C4.Opt1] Encryption of data in use OR [C4.Opt2] Encryption of data in separated, protected environment: these are two alternative ways to protect the data in use. Encrypting it requires the use of advanced techniques like homomorphic encryption, where computations can be performed on the encrypted data without having to decrypt it first. These techniques aren't yet widely adopted and chances are that your products don't use them. In that case, we would use the alternative solution and process the data in an isolated, protected cloud environment, which is something you probably do anyways. Remember to include a justification for this decision in your policies as that will help auditors to understand that you took a conscious decision on this front.

Key Management controls are specified in Article 7 and we won't cover them here. The previous points should give you enough information to tackle other articles on your own.

Doesn't it seem more manageable? If you work in a regulated environment, you’re likely following similar practices already. Ready for the next step? Let’s explore how to test them and provide evidence to auditors.

Testing controls is... a data problem

Auditors need evidence of control effectiveness, essentially, data proving the control is in place. For example, for C1 (encryption at rest), they want to see that all our storage is encrypted. This report is normally referred to as an asset inventory.

The easiest way to have an asset inventory that is ready for an audit is to use it. A practical approach is to extract first your inventory and only then use the data in it to automatically test that the controls are in place. The tests will alert you in case the inventory shows an issue, giving you the opportunity to fix problems early in the development process.

Just like integration tests, you can introduce a compliance test pipeline to automate inventory extraction and validate compliance rules.

Conclusion

This example demonstrates how standard engineering practices can drive compliance. The biggest challenges are the complexity of regulatory language and auditing terminology, ultimately just formal descriptions of familiar activities.

By bridging language gaps and focusing on control testing, we can build audit-friendly products with minimal stress, letting engineers focus on what they do best: building great software.