Data Security: 4 Ways Your Team Can Do Better

Data Security: 4 Ways Your Team Can Do Better

With all the breathless news coverage of high profile data breaches in recent years, one could be forgiven for thinking data heists are always the result of sophisticated efforts by devious hackers in far-off lands. But the reality is much more plain. According to a recent study by Securis, 25% of data breaches are caused by simple employee error. So if your team is spending all its time trying to anticipate black swan events, it can overlook the everyday safeguards necessary to keep its data secure in a fast moving business environment. In some jurisdictions such as Europe, the day-to-day management of an organization’s data security processes must be overseen by a designated Data Protection Officer. But whether you’re a large organization operating in GDPR territory, or an SME preparing for greater data regulation such as in the US with California Privacy Law (CCPA) in January 2020, below are 4 actionable steps your team can take to do the basics right:

  1. Think Physical – You’ve spent months testing your infrastructure, ensuring your site has the necessary certificates, and building the protocols to store data securely and anonymously. Then someone from marketing leaves a USB stick on the table of a coffee shop and all the hard work is undone in an instant. Technical teams need to think beyond the way data is stored and through to the way that team members, particularly non-technical team members, access and transport company data.  You have the responsibility to educate those who are ignorant to the caution that must be used when handling this precious resource. In real terms, this often means workshops and seminars where the rest of the organization is educated around best practices, and warned of the consequences that can occur when casual attitudes prevail.
  2. Keep Access Control Granular – Despite your best efforts, technical teams must understand that every employee constitutes a security risk and a potential access point for data thieves. Consequently, teams should work to make data access as granular as possible – with no one team member having access to anything more than the data that is necessary to do their job. An “all-or-nothing” access policy is to be avoided at all costs. Finally, you can also apply this philosophy to development work and third-party services and applications – not only are password management tools and key vaults for your developers are essential but you should, and must, limit access for individual services and systems to only the data necessary to complete the function being performed.
  3. Password Policies Matter – Even if your organization has thought proactively about the previous two priority points, the fact remains that passwords are the first line of defence against security breaches, and by consequence, one of the most vulnerable access points. Though it is impossible to ever fully guarantee password security for every employee and customer, development teams can build security into their company’s IT architecture. Risk can be drastically reduced by providing customers and staff with a two-factor authentication login procedure. Furthermore,  passwords to company networks and systems should also be safe guarded with 2FA and encryption at all times.
  4. Use Regulations As A Guidepost – Because the landscape is ever-evolving and because companies are loathe to share the inner-workings of their data systems with the world, SME’s in particular can find it challenging to gauge whether they have taken the appropriate steps to safeguard customer and business data. Here, it can be useful to compare your policies against the regulations laid out in frameworks like the GDPR, the CCPA, and HIPAA. These regulations are the laws of their respective lands, but they are also a good summary of the minimum level of performance and security that organizations need to be building into their data infrastructure. What’s more, they’re not actually all that complex, particularly if you have experience with the subject matter. We encourage developers to go straight to the source and familiarize themselves with the articles of the GDPR as a handy starting point for thinking about data security.