In today’s digital world, it’s imperative to protect your databases from data breaches and vulnerabilities using sufficient security protocols. Login credentials written down on sticky notes, generic passwords, lack of back-ups, and no hand-over procedures can all work against you towards a hack or ransomware situation.
If your organization is interviewing FileMaker developers to either maintain an existing database or create a new one, we recommend asking them the following security questions.
(1) Where will my database be stored?
This question is important to ask as you should not only have the answer to it, but you may need to ask a follow-up question: What are the security protocols for where it’s stored?
The most common answer to this question is the cloud. However, the cloud is merely someone else’s computer. Who will your host be and how can you know your database is securely hosted in that environment?
If your developer is hosting the database on your behalf, do they directly provide the servers for that, or will they go through a hosting service such as AWS? If it’s on-site, what are the physical protections for the servers? They should be behind locked doors with restricted access so not just anyone can disrupt them. The server room should also be climate controlled with fire protections.
If you are providing hosting for your database, you should consider all of these thoughts for your environment. It’s within your control, but are you aware of the server's security stability?
(2) Will my database be encrypted?
We cannot think of a single valid reason to not have your FileMaker database encrypted. Encryption protects your data from a wide variety of vulnerabilities. It’s free and easy to implement on FileMaker databases, as well as required if you’ll use the Data API—and it’s also easy and relatively inexpensive to acquire tools designed to break an unencrypted database in under a minute.
If you open an encrypted FileMaker server that’s hosted locally, you’ll have to input your login credentials twice rather than once. It’s annoying, but security is supposed to be annoying.
(3) Who will have access to my database and how do you handle employee turnover?
Database access is a security vulnerability that can cut both ways. For a larger development agency, developers should have access only to the client databases they work in. On the flip side, you also want a hit-by-bus plan. If there is only one developer with full access to your database and something happens to them, there should still be a way to access your database. A minimum of two employees should have full admin access.
But when employees that have access to your database leave the company, how is that transition handled? This is generally only a concern if an employee has been terminated or laid-off, though it still needs to be considered if they’ve retired or left for a new role elsewhere. Their access should be eliminated and any shared credentials (such as server logins) will need to at a minimum have their passwords changed.
(4) What is your data retention policy?
Will your developer keep database backups on your behalf? If so, what are the security protocols for those? A common mantra says that “A backup isn’t a backup unless it’s off-site and tested.” It goes hand-in-hand with the 3-2-1 backup plan, which says you should have: Three backups in a minimum of two different physical locations with at least one being a cloud solution.
At some point in time, details about or from a client’s database will be written on paper for various reasons. Print layouts from the database will need to be tested, or copious meeting notes will be taken. Will they be discarded in a regular trash can? Recycled? Shredded? How long will they be in the office environment before removal? You’ll want to know the answer to these questions.
(5) Do you have previous experience working with sensitive data?
Your organization may work with information covered by HIPAA laws, personally-identifying information for customers, credit card information, or a variety of other sensitive data types. While every developer will have a first exposure to working with this kind of information, an agency or firm should have considerable experience. You should always feel comfortable asking a developer for references, but especially so if your database has sensitive information. Even if they don’t have experience in your exact sector, they should be able to provide references for clients with similar levels of data protection needed.
(6) How have you previously handled a data breach?
In an ideal world, there would never be a single data breach. But in our world, they’re common at a scary rate. Presume the developer in question has already had to manage the fallout from a previous breach and ask them about that. While they shouldn’t be disclosing intimate details that would identify the organizations involved, you should hopefully learn a considerable amount based on their answer to this.
Rather than search for a developer that will never encounter a data breach, presume it will happen and look for one that has experience successfully recovering from one.
(7) Would you implement this security solution in your own database?
Every organization, database, and developer is different. That said, it’s reasonable to ask your developer if the proposed security solution is one they’d feel comfortable implementing on their own company database. If you felt uneasy with their answers to the previous questions and found they quickly answered this one with “Yes,” then you may have cause to be concerned. On the flip side, if they say they wouldn’t be comfortable with it, you should ask further questions.
The developer you hire should be the expert in their field—in part so you can be the expert in your field. If you’ve insisted on specific security protocols that they say they don’t feel are safe enough, we recommend listening to their reasons why.
PK Information isn’t convinced computerized voting will result in everyone dying, but we do think this is a perfect example of listening to industry experts.
Ideally, you’ve asked your developer these questions before hiring them. But if you’ve already on-boarded them and are reading this after-the-fact, it’s absolutely not too late to ask these questions. Late is better than never.
PK Information is a FileMaker-certified development agency serving the Tampa Bay, Miami Lakes, and Knoxville regions. We believe software should work the way you do, with business priorities first and technology second.
LEARN MORE
Would you like to learn more about rebuilding index fields in FileMaker and the benefits from doing so? We’d love to discuss the possibilities with you! Please complete this form and we’ll connect shortly.