IT compliance in practice – correctly containing and deleting data and projects in B2B software development

For many, compliance is an abstract concept that only managers have to deal with. But it’s not. Compliance is everyone’s business.

What is compliance and why is it so important?

Briefly, compliance is the observance of laws, rules, standards, contracts and moral values, which can come from both outside and inside a company. The tricky thing about compliance is that non-compliance is not always immediately apparent. However, once it is discovered, things can quickly become unpleasant. Compliance affects not only management, but every employee, since anyone can knowingly or unknowingly violate it in the decisions they make. Examples of this include not using software under the terms of its license or failing to comply with data protection guidelines by not deleting data as required.

A special case: deletion or handing over of data

Since compliance is about adhering to regulations of any kind, this is very complex and individual issue. That's why this post will be dealing with a very specific topic: the deletion of data when the contract ends.

In B2B software development, it is customary for contracts to contain a clause on how to hand over or destroy all records and documents related to the project.

At first glance, this does not seem to pose a problem. Yet, as is so often the case, the devil is in the details. Depending on how meticulous tidying up at the end of the project is, it can be very time-consuming to actually find and delete all of the information and data.

Inadequate isolation of projects can be a compliance issue

The clause referred to above means that at the end of a project all systems would have to be searched to find all of the data relating to the project. This ranges from obvious data such as repositories, artifacts, Wiki entries, documents such as conceptual designs or documentation to less obvious data such as tickets in the issue tracker or source code stored on secondary systems. How extensive this search is essentially depends on two factors:

• The scope and duration of the project
• Isolation of data from different projects

The scope and duration of projects

The longer and larger a project is, the more data is accumulated, increasing the likelihood that some of the stored data will be forgotten and that more and more systems will be used. This means that the “search radius” must be considerably expanded. It also means that there’s a lot more to do.

A wide dispersion of data can be reduced, for instance, by organizational rules on the storage of data. But rules like these often provide a lot of leeway and are hence only helpful to a limited extent.

Isolation of projects

In addition to the size and duration of a project, its isolation from other projects is also a factor influencing what has to be done to identify all of the relevant data. Here is a simple example of different levels of project isolation:

• Low isolation: The data from different projects are all stored on one network drive. There is no prescribed folder structure.
• Medium isolation: All of the data is on the same drive, but each project has its own folder.
• High isolation: Data from different projects are stored on their own network drives with separate hard disks.

It is immediately apparent how much easier it is to identify the data in a highly contained project. If all of the data for one project is stored on a separate hard disk, it can easily be handed over to the customer or erased. In medium isolation, only a few folders need to be copied or deleted. The work involved in a low isolation situation is something everyone is free to imagine on their own.

It is also important to keep in mind that data may be present in any system used for the project. This quickly makes it relatively apparent why even small differences can have a big effect.

Backups – a story on its own

But that’s not all. Backups of systems are created to prevent data loss during a project. Depending on the level of project isolation, what needs to be done at the end of the project can be multiplied again. Because here too, the lower the level of isolation, the more complex the search will be. If the backups are still compressed or encrypted, the task becomes even more time-consuming, and because that is not enough, it must also be remembered that every change made to the backup puts its integrity at risk.

Separate infrastructure for each project

The good news is that it can also be very easy to abide by the contract: Using the Cloudogu EcoSystem, a completely independent instance can be used for each project. It contains all of the data such as repositories, issues, documentation, artifacts, etc., making it easy to delete all of the data at the end of the project or hand it over to the client. Backups are also easy to delete, since they are also created separately by project.