Donor names, contact information, and giving history make a great example of the usefulness of an organization's database.  Not only does it allow you to create a mailing list for your next direct mail appeal, but it also provides enough information to determine a particular donor's likelihood of contributing to a certain campaign.  For example, you can look through the donor's history-or, more practically, have a database that does it for you-in order to discover that John Doe gives small, ongoing donations year-round, while Jane Smith tends to make a large contribution at the end of the tax year.  If you see that another contributor tends to make gifts only during events, you know that it's a good idea to approach him or her when the next one is set to launch.

The volunteer manager, development department, programs officers, accounting department, and so many more folks within the organization can benefit from the types of information stored within your database.

Of course, when this many people have access to the data, there are security concerns.  What's to keep someone from printing out a list of your donors and taking it with them to a new job?  Who really needs access to specific information?  How on earth do you keep constituents' credit card numbers safe?

Many of these concerns will already have been addressed by the vendor who sells the product.  There will likely be different levels of access, for example, allowing for staff members to see only what it relevant to them.  As for credit card information, there are very strict guidelines called Payment Card Industry Data Security Standards.  Again, your vendor, as well as the vendor of your merchant account, will play a large role in ensuring you are complying with these standards.

Still, there are reasonable concerns that must be kept in mind, ranging from simple problems that can be caused accidentally to those that are malicious attempts to access or destroy data.

Inappropriate Use of Data

As mentioned above, it could be possible for an employee to steal information from the database and share it with others.  In this category, as well, is the potential for data to be changed and manipulated for various reasons.

Damage

Physical damage can be done to the server and result in the loss of data.  For example, a fire or natural disaster that destroys a server will take with it any data that hasn't been backed up offsite.  Information can also be lost as a result of data corruption in a system that isn't maintained or has design flaws, or through bad database administration.

Viruses and Malware

There are a number of ways that a system can get a virus or have malware introduced.  In some cases, it's as simple as a staff member opening a harmless-looking email.  In others, however, hackers can target your organization in order to harvest information from your database.  (The SQL injection description below is one method used.)

SQL Injection

There's a good chance that your data base has some type of web interface that allows your staff to use the system through their browsers.  Unfortunately, hackers can use information they gather from the simplest of interfaces in order to get into your database.  They are actually able to use the address bar in their browsers to enter code that makes your database give them far more information than you would have ever wanted.

Inference

Inference happens when someone is able to piece together different bits of information to which they have access in order to determine something to which they don't have access.  Nonprofits tend to work with a fair amount of transparency, but that doesn't mean that there isn't information that requires confidentiality.

Overloads

Nonprofits are generally run with a very tight budget, and it's easy to overlook the importance of expanding your database's capabilities.  As a result, systems can get overloaded.  The result, while it may not seem on the surface like a "security" issue, can be the loss of data and/or the inability to access it.

Protecting Your Database

These are just some of the more common concerns when it comes to database security, and they're obviously not in-depth examinations of each problem.  Instead, this is a starting point for the discussion that should be happening both within the organization and with the vendor who sells and/or maintains the database.

Clearly, backing your database up is an important aspect of protecting the information stored within.  Almost as important is to have it backed up offsite.  Large organizations will often have backups done in a different part of the country so that if one server suffers from a natural disaster, the other will be ready to take on the primary role, if needed.

Setting up user policies is also important.  Having these clearly outlined and reinforced decreases the potential for staff members to do things that expose the database to risk, such as accidentally downloading malware.  Along these lines, non-disclosure agreements can help to protect your data from being stolen and can give you recourse if there is a problem.

When it comes to more malicious outside attacks, you need to work with your vendor to determine what kinds of security and protection they can offer.  In fact, security features should be something that is taken into consideration before purchasing a database.  There are lots of reviews and comparisons available to help make the decision easier.

Finally, there are a number of ways to evaluate your database's security.  They range from looking over a simple questionnaire to staging your own mock attack to see how your system holds up.  While certainly more complicated, this second approach can definitely give you an idea of where your database is most vulnerable so you can then implement best practices to neutralize any threat.