Skip to main content

Tags:

Start with Security: A Guide for Business offers tips for any business wanting to implement sound data security. For health app developers, here’s tailored advice and additional questions to ask.

1. Minimize Data.

  • Do you need to collect and retain people’s information? Remember, if you don’t collect data in the first place, you don’t have to go to the effort of securing it. If the data you collect is integral to your product or service, that’s fine, but take reasonable steps to secure the data you transmit and store, and delete it once you no longer have a legitimate business need to retain it. If you collect and retain it, you must protect it.
  • Can you keep the data in a de-identified form? When data is de-identified, it can’t be reasonably associated with a particular individual. A key to effective de-identification is to ensure that the data cannot be reasonably re-identified. For example, U.S. Department of Health and Human Services regulations require entities covered by the Health Insurance Portability and Accountability Act (HIPAA) either to remove specific identifiers, including date of birth and five-digit zip code, from protected health information or to have a privacy and data security expert determine that the risk of re-identification is “very small.” Appropriately de-identified data can protect people’s privacy while still allowing for beneficial use. For example, if your app collects geolocation information as part of an effort to map asthma outbreaks in a metropolitan area, consider whether you can provide the same functionality while maintaining and using that information in de-identified form. You can reduce the risk of re-identification of location data by not collecting highly specific location data about individual users in the first place, by limiting the number of locations stored for each user, or aggregating location data across users.

    Since re-identification is always a risk, it’s important to keep up with technological developments. Publicly commit not to re-identify the data. And make sure your contracts with third parties require them to commit not to re-identify the data. Then monitor the third parties to make sure they live up to their promises.

2. Limit access and permissions.

  • What permissions does your app really need? Make sure your app doesn’t access consumer information it doesn’t need. For example, if you’re developing a running app, think about whether it really needs access to other resources – like consumers’ contacts. If not, your app shouldn’t access the operating system’s application programming interface (“API”) for that information.
  • Does the operating system you’re using provide tools to tailor access to user information? Find out whether the operating system you are using provides trusted user interface (UI) components instead of direct API access to provide access to user resources. If it does, use those trusted components where it makes sense to do so. Trusted UI components can provide you with more finely tuned access to resources (e.g., a single contact or the ability to dial a specific phone number), thereby minimizing unnecessary data collection while still enabling functionality. For example, if your fitness app has a social feature and you want users to be able to send SMS updates about their latest workouts to certain contacts, you could use those tools to let consumers select particular contacts, rather than having your app request access to all user contacts through the standard API. This is a good example of what security experts call the principle of least privilege: crafting permissions to limit access to the level that will allow for normal functioning.
  • Are your defaults privacy-protective? Choosing privacy-protective default settings will offer out-of-the-box protection for users new to the technology, while still giving experienced users alternatives that best suit their needs. For example, if your fitness app offers users the option of sharing the results of their workouts with others, set the default choice to “private,” rather than “public.”

3. Keep Authentication in Mind.

  • How does your app generate credentials? Invest resources in the design, implementation, and testing of authentication. For example, how will you ensure that the person accessing a particular account is the legitimate owner of the account? If risks are substantial, consider multi-factor authentication – for example, requiring the use of a password and a separate code sent via another channel, such as an email or text.
  • How do you implement strong password requirements? Require complex passwords. Moreover, don’t use default passwords unless you require consumers to change the default during set-up. Think about questions like: How you will handle requests to reset passwords? What about requests to revoke access to data (like when a consumer has lost his or her device) or close an account? 
  • Are you storing passwords securely? Don’t store passwords in clear text. Add salt – random data – to hashed passwords and consider using slow hash functions. These techniques will make passwords harder for attackers to compromise.
  • How do you secure access to your data? When granting access to your data or functionality – for example, through an API – limit access to trusted clients or parties with a legitimate need to use the data.

4. Consider the Mobile Ecosystem.

  • Are you relying on a mobile platform to protect sensitive data? There are differences between mobile platforms. They may use different APIs, have different security-related features, and handle permissions their own way. Research the mobile platforms and adapt your code so you can protect people’s data, regardless of the platform. Conduct security testing to confirm that protections provided by the platform are effective.  
  • How are your third-party service providers protecting data? Ensure they’ll safeguard people’s data. Spell out your expectations and requirements in the contract. For example, if you rely on a commercial cloud data-storage provider, understand the divisions of responsibility for securing and updating software on the server. While some commercial services will monitor and update your servers’ security, others leave you in control.
  • Are you using someone else’s code to build or enhance your app? Do your research first. This includes looking into the permissions that third-party libraries may request. If you use a software tool developed by another company, it’s still your responsibility to ensure it conforms to your privacy promises and consumer expectations. Make sure the code doesn’t have any known security vulnerabilities and that it has been tested in real-world settings. Keep your ear to the ground for vulnerabilities that may emerge in third-party components that are integrated into your products. And be aware of differences between free and paid versions of third-party code. Paid versions may offer security features that free versions don’t.

5. Implement Security By Design.

  • How can you develop a culture of security at your company? Designate a trusted staff member to be responsible for data security at your company. Depending on the size and complexity of your organization, you may need a team of people, including a senior executive. Hire engineers who are experienced in secure coding practices or train them in secure coding. Encourage employees to recognize and speak up about vulnerabilities. Maintain and monitor a channel through which security researchers or consumers can reach you if they discover a vulnerability in your app. Serious inquiries related to the security of your products should generate serious responses. Consider implementing bug bounty programs that offer rewards – perhaps free products or cash – to people who identify significant security vulnerabilities in your products.  
  • Do you incorporate data security at every stage of your app’s lifecycle: design, development, launch, and post-market? This includes testing your security measures and controls before launching, and continuing to evaluate and update your security precautions as appropriate. When testing your products, use scenarios that replicate how people will use them in the real world. For example, do your security precautions work in all foreseeable situations? Have you closed back doors hackers could use to get in or gain control? Have you ensured that data is stored and accessible only as you intend it to be? If you’ve turned security measures off during testing, be sure to switch them back on before going live.
  • Do you use strong encryption at rest and in transit? Encryption is a key security protection for the health information your app collects. Select stronger encryption methods over weaker ones. Since strong encryption can be challenging to develop, think about using well-known, off-the-shelf products for this. Remember that standards change, so keep an eye on current technologies.
  • How will you protect your app from common vulnerabilities? Take steps to protect your app from well-known threats like injection attacks; hard-coded credentials or cryptographic keys, which hackers could exploit; insecure APIs that leak or allow unauthorized access to data; broken or disabled cryptography; and other threats. Consider using rate limiting, a system for controlling the traffic sent to or received by a network to reduce the risk of automated attacks. Some scammers try to break into networks by using software that enters possible passwords over and over again until they succeed. Rate-limiting can help thwart that kind of attack.
  • Are you keeping current? New vulnerabilities arise regularly, so it’s important that you have a plan for how you’ll provide updates for products and how you’ll communicate with consumers – even after you release your app. Think about how you will respond if a significant security flaw is identified. Will updates be automatic? How long will you offer security updates and patches?
  • How do you keep track of the data you collect and retain? Having an up-to-date inventory of the information in your possession can help you allocate data security resources where they’re needed most and help mitigate damage in case of a data breach. Know where data from your app goes and protect it accordingly. Don’t store sensitive data where it might be accessible to others, unless you have appropriate security and privacy controls in place.

6. Don’t reinvent the wheel.

  • Are you taking advantage of what experts have already learned about security? There are free and low-cost tools you can use to safeguard consumers’ personal information and help protect their privacy. For example, there are software development kits (SDKs), software libraries, and cross-platform toolkits. There also are free tools that can help you provide encryption, conduct pre- and post-launch testing, test interfaces, scan networks for open ports, reverse-engineer programming code, check password strength, and even scan for known vulnerabilities. In addition, expert groups provide information that may help you implement appropriate safeguards and stay abreast of the latest security vulnerabilities. Here are some to consider:

7. Innovate How You Communicate With Users.

  • How will you inform users about your app’s security options and privacy features? Strive to be simple, clear, and direct. Don’t use complicated jargon or hard-to-find hyperlinks. Also, since your health app is likely collecting users’ health data – for example, dietary information or blood pressure readings – get users’ affirmative express consent before you collect or share that data. That means you need to ask and they need to indicate “yes” before you collect their data. Do this outside of your privacy policy or terms of service so that users focus on what you are asking.
  • How do you provide effective notice? Tell users about sensitive or unexpected data your app will collect both when they install your app and again when the app begins to collect that data. That’s called “just in time” notice. For example, if your fitness app will collect a consumer’s geolocation information to track the distance and path of a run, consider telling consumers about this before they install the app and then again when the app is about to access their geolocation, in case they didn’t focus on this feature at the outset.

    Have a privacy policy that is easily accessible through the app stores, clearly tells users what information your app collects, and explains how you use, share, and secure that information.

    In your notices, consider explaining why you are collecting users’ data. For instance, if you offer a cycling app, instead of simply stating that it “wants to access your location,” you might state that “it would like to collect your location information to track the distance cycled.” People might be less wary of your data collection practices if they understand the purpose behind it.

    In addition to written notice, you can use icons, lights, or other methods to indicate, for example, that an update is available, or that a device is currently collecting or sharing information. Dashboards also can help consumers to find apps’ privacy and security settings and tailor them to their own comfort level.
  • How informative and accessible is your privacy policy? Don’t cut and paste your policy from another app. Consider additional methods to help users access and understand your policy. These include making your privacy policy accessible on a website that users can access from a computer (where they will have a larger screen to read it), offering to email it to users, and providing a short policy with links to a longer policy with more information. Finally, don’t forget to update your privacy policy if your practices change.  
  • How do you tell people about enhanced security features in your product? One option, for instance, would be to use a set-up wizard to walk users through the process of implementing security features. Another option would be to showcase security tools in an initial registration screen and explain how people can use those tools most effectively. After that, let users choose to receive important information from you via email or text.

8. Don’t Forget About Other Applicable Laws.

  • If you’re a health app developer, your first step should be to determine which federal laws and regulations apply. You may be covered by the FTC Act, the FTC’s Health Breach Notification Rule, HHS’s Health Insurance Portability and Accountability Act (HIPAA), the 21st Century Cures Act and ONC’s Information Blocking Regulations, or the FDA’s Federal Food, Drug & Cosmetic Act. To help answer these questions, start with this interactive tool.
  • If, in addition to health data, you’re dealing with financial data or information collected from children under 13, make sure you understand and comply with applicable standards, rules, and regulations. For example, check out FTC guidance on the Children’s Online Privacy Protection Rule and the Gramm-Leach-Bliley Act’s Safeguards Rule and Privacy Rule.
  • There also may be state laws you need to comply with. The National Conference of State Legislatures has resources that can help you find some of the state laws that might be applicable, but you’ll need to do more research about your particular circumstances.
  • Basic truth-in-advertising and privacy principles apply to your product. Give customers the straight story about what your app can do and be transparent about your privacy practices. For more information, see our guidance on Marketing Your Mobile App: Get It Right from the Start.

For more tips on how to implement sound data security in your business, check out Start with Security: A Guide for Business

Return to top