Securing Sensitive Data in your Software

It’s easy to get caught up rubbernecking at serious data breaches at high profile companies – and it’s equally easy to think, “well, who’d want to come after my company? We’re not that big.” This, friends, is a great way to stumble in the running of your business. 

We know there’s a risk of coming across as paranoid when it comes to talking about data security, but it really does require vigilance and taking extra care, no matter your size or prominence. 

And in many of our clients’ cases, choosing to build a custom software solution ends up having a lot to do with wanting to maintain full control of their own clients’ data as well as their business data. For example: when was the last time you thoroughly reviewed the Privacy Policy of a software tool you purchased off the shelf? Can you articulate how those tools protect your customers’ data, and you from liability? 

Whether you choose custom or out of the box, there are three starter questions you will want to think through regarding data security before you make a purchase. 

1. What type of data is in use? 

You may have heard of the phrase, “personal identifiable information” (or PII). Equally important is to keep an eye on all the contexts in which the PII your business works with might show up. For example, do you require credit reports, criminal records, or background checks in your software? Not only are these compilations of PII, they are in and of themselves sensitive data. 

(Note: A subset of PII is PHI, or protected health information. This type of information has to do specifically with medical services, and is subject to additional privacy considerations outlined by, for example, HIPAA and HITECH. If your business involves PHI in some way, you’ll have extra considerations to keep in mind.) 

Anytime you’re asking for any type of information from someone, even if it’s not complete enough to figure out within your particular application, it’s important to ensure your users’ data are secure. It’s possible for someone to illicitly purchase datasets from multiple brokers and piece them together until they have enough information to exploit your users’ identities.

2. How is that data protected in transit and at rest? 

Speaking of data circulating, of course you’ll want to work out how the data you work with will be anonymized and encrypted. If you’re considering building custom software, you can ask the agency or developer, “How do you protect customer information during development and deployment to production?”  

Whether looking into custom software or an off the shelf tool, you can and should ask in both cases whether data are encrypted in transit (i.e. being sent via a network) and at rest (e.g. held in a database). Your app’s target market and use cases will largely influence your security concerns. For one app, securing user data may be extremely important, while another may require only the most minimal of safeguards. You might also listen for if a vendor or builder talks about third party security audits or pen tests as part of their standards. 

(If you’re feeling up for extra credit, you can browse the mobile security standards TSL adheres to for mobile applications, direct from the source.) 

3. How is that data protected when being accessed and viewed? 

You’re probably familiar with being kicked out of your online banking app after a few minutes of inactivity. 

Annoying? Sure. But definitely, definitely a good idea from your bank’s development team to protect your data. Ask any vendor or custom builder you work with to walk you through the measures they take to protect the viewing of sensitive data, like timing out after inactivity. 

As a standard practice we recommend re-authentication using what’s called “multi-factor authentication” (MFA) to be able to view sensitive information on a screen. 

(Note: MFA is the code you have to enter from either a text, an email, or a special code-generating app in order to access, for example, a company intranet. More modern MFA methods include passkeys/passphrases or physical security keys.) 

We also strongly recommend you ask anyone you work with to clarify what standards they adhere to, as well as any additional privacy strategies your vendor or builder uses such as password configuration requirements or auto-logout upon closing a tab. 

As an example of an additional privacy strategy beyond timing out or requiring MFA, at The SilverLogic, we tend to create interfaces that do not show multiple pieces of sensitive data at once. 

We bring up these three starter questions because we’ve seen many cases where clients came to us for a custom build in order to have that clarity around their own customers’ data security. The need to protect data while still creating a good user experience crosses business size and industry, and we want you to feel comfortable and confident navigating this terrain. 

If you want to talk through how to better protect your business’ data, we’re always happy to see how we can serve you. Click over to tsl.io and fill out the contact form at the bottom of the page.