It may seem unkind to suggest that your data is at risk from authorized users, either accidentally or maliciously, but insider threats are one of the major causes of data breaches.

Let me give an example. In 2011, Britain's News of the World newspaper folded after 168 years of publication when various immoral or illegal practices of its journalists were revealed. The Wikipedia entry 'News International phone hacking scandal' gives an excellent summary.

Journalists, it was alleged, were equipped with phone numbers of people, working in large companies and government departments. For a fee, employees of these organizations would then access their database systems to divulge useful information about individuals. The journalists were, in this case, most interested in celebrities, politicians and the aristocracy but everyone was at risk. Some journalists boasted that a day's work on the phone could produce details of the personal life about almost anyone, often before the police.

One journalist investigated by the police in 2002 reportedly bought information from former and serving police officers, customs officers, a VAT inspector and bank employees who had access to the data. They also employed 'blaggers' who would telephone the Inland Revenue, the Vehicle Licensing Agency, banks and phone companies, and deceive them into releasing confidential information from their records.

However impervious to external attack your application and database may be, the data that your organization holds may still not be safe. It is not an option to trust solely in the probity of your internal users, or to rely on their good sense with data.

How on earth do you guard against the theft of data within an organization? Firstly, determine what sensitive data you hold and why, and where it is stored or cached. If you hold sensitive data, then you must be able to identify individual authorized users of it. Next, you need a system that monitors usage that is entirely separate from the database system. It must log all accesses to the sensitive data. With all this in place, you can introduce a configurable alerting system that looks for any sort of unusual usage.

The database must use full access control, so as to prevent any SQL queries from accessing tables that have sensitive data in them. I always recommend an interface of stored procedures and functions to allow applications to access this type of data, and to make monitoring easier. Through this interface, you can restrict access to sensitive data to just the minimum the user needs to complete their task. There should be a fine-grained range of database roles that match the roles of members of the organization, so that no user is able to access either more data than is necessary for the business operation, or data that is irrelevant or inappropriate. Data exports must be restricted to aggregations done to the finest level of detail needed for reporting.

A seasoned curator of data will never be a popular figure in the organization, because insider data breaches are seldom publicized and the extent of the threat is greatly underestimated, but it is certainly there.