Should Devs Get Hands On With Our Data?

By necessity, developers will sometimes have access to our most intimate data – but does this leave us overexposed? Adam Alton looks at what happens behind the buttons.

- Alton

Many companies have systems for handling their customer data that are built so employees can only access the data they’re supposed to. For example, an insurance company call-centre system might only allow the staff to see some parts of a customer’s account information and not others, depending on whether they work in claims or sales. Such systems often store a log of which staff have accessed a customer’s data and when, so if a member of staff does something they shouldn’t, the snooping is at least recorded. But no matter how restrictive or robust these systems are, they always have a flaw: someone has to build them.

This is not unique to software. If companies kept their customer data on paper locked in a vault, someone would still have to build the vault. But the process of building software presents two problems. The first is how do we know what’s been built? Creating software is a highly specialised skill; it’s often the case that someone managing the creation of a piece of software doesn’t have the skills to do the ‘construction’ work themselves. That in itself has many interesting consequences but the most pertinent issue here is if someone doesn’t understand the work being done, how are they going to check that the software being produced actually does what it’s meant to?

The obvious answer is to test it.

Let’s suppose we’ve commissioned some software for an insurance company call centre. We might have a requirement that if the system administrator has set one of the staff accounts as a claims handler, when that staff member logs in they cannot see how much any of the customers paid as their annual premium. We can set up some dummy accounts and customers and we can test that. And we can repeat the process for every requirement we have.