Data security and your business

The GDPR laws that were introduced in 2018, had an impact on data security.

But, the big question for agencies is; what are you doing to keep data secure?

The core of GDPR is related to people’s personal information, and our approach is to ensure that the data exists in as few places as possible.

We also ensure that we have sufficient backups, so that we don’t lose any data in the event of a hardware failure, or something even more significant, such as a natural disaster.

To deliver this, we needed a tool that could backup and obfuscate (scramble) data in numerous frameworks.

The one we’ve designed and developed, has been running the tool and dashboard, to take and monitor backups of databases and uploaded files.

How it works

To reduce the impact on client sites, the backups are automatically created in the early hours of the morning. Weekly.

Our database backups are taken in several parts; the table structure, PII and non-PII data are all stored separately, with the PII data stored in a write-only location, meaning even the tool writing the data can’t read it back afterwards.

The backups are used by our developers and across our UAT servers, to ensure that only the live sites run with PII in their databases.

For UAT environments, our dashboard provides database updates at the click of a button. And for local work, the team pulls these down (using another tool that we built) from secure storage, with access granted to each project’s assets on an individual “as-needed” basis.

Data security and credentials

As well as our GDPR compliance work, we keep credentials secure by storing them all in a password manager.

As with anything that has security considerations, we limit access to each set of credentials to only those who need it, and revoke when they roll off a project.

We also enforce two factor authentication for any tool that allows, and where possible, we ensure that each user has their own unique account.

Software updates and server maintenance

Data isn’t the only security consideration. Software vulnerabilities are a regular occurrence, particularly in the world of open source software.

Our operating systems, software and frameworks that we build our sites in, are all open to exploitation.

We do ensure though that we are always running versions of software that are maintained by the providers, and we migrate/upgrade before software versions reach EOS.

Last year, we had a drive to migrate legacy sites onto updated, secure servers. We did this by creating various server images, following security best practice(s).

We have policies for security patching servers, and run these updates out of hours.

Similarly, we have policies for framework and module patching and for critical updates, we insist on patching first and testing later. It’s better to be safe than sorry.

Access to our servers is also locked down, and again, we grant access on an individual “as-needed” basis, where each user has their own account to ensure we have full audit trails.

Part of the process involves regularly clearing up and removing legacy sites/tools from our servers, because unmaintained software can be a security risk, and our UAT servers run a tool to turn off old sites if they’re not accessed for a period of time.

We take data and security seriously, so if you have a question about this post, or our previous one, get in touch with us today.