The FTC held its “Start with Security” conference in San Francisco, California, last week, launching an initiative to provide companies with practical resources for implementing effective data security strategies.

The event was targeted at tech start-ups and small- and medium-sized businesses, but the panelists included representatives from companies with mature and well-resourced data security programs.

The panelists agreed that achieving greater data security is cheaper and easier to accomplish when it is considered early in the secure app development lifecycle. At the same time, panelists also acknowledged that companies face a myriad of potential security risks that must be balanced and prioritized, and that it may be more difficult for larger companies with complicated systems to adapt their practices to address evolving security risks.

Below are some practical tips the panelists provided for building a culture of “security by design”:

• Use Encryption. Chairwoman Edith Ramirez encouraged tech start-ups and app developers to use encryption to protect data while in transit.

• Identify and fix security vulnerabilities both pre- and post-launch. The panelists noted that companies using agile software development methods to make continuous, incremental improvements can similarly approach data security deployment in an iterative, continuous way.

• Make sure someone is accountable for security. Although panelists debated the ideal organizational structure, there was consensus that all engineers should receive basic security training and that there should be accountability for security issues within a company. Window Snyder, Chief Security Officer at Fastly, suggested that companies incorporate a security check for vulnerabilities as part of the standard peer review coding process that is conducted at most companies. Jonathan Carter, Project Lead at the Open Web Application Security Project (“OWASP”), emphasized the importance of accountability and suggested that a single person on each developer team be designated as the security “champion.”

• Involve engineers early on to help develop policies and practices. Rather than simply imposing policies on engineers, panelists encouraged businesses to work with developers at every step along the way to increase understanding and buy-in, and avoid losing credibility with “false positives” of potential security threats.

• Leverage the existing security community. The panelists suggested implementing existing third-party security application program interfaces (“APIs”), for example, to encrypt data or otherwise secure communications.  At the same time, Chairwoman Ramirez cautioned companies to research third-party software development kits (“SDKs”) and code libraries for known security vulnerabilities before integrating them into software. The panelists also pointed users to third-party resources, such as the OWASP Top Ten checklist for data security, OWASP WebGoat, Security BSides, and the SANS Institute.

• Incorporate threat modeling early on and throughout the secure app development lifecycle. The panelists encouraged companies to consider what security threats they are likely to face and how they can avoid those threats on an ongoing basis throughout the development process. Devdatta Akhawe, Security Engineer at Dropbox, emphasized that threat modeling can be a simple but effective process when done early in the pre-design phase.

• Engage third-party consultants to conduct penetration testing. Panelists agreed that penetration testing is an important tool in the data security toolbox. However, they suggested that trained engineers within the company should consider data security early on in the secure app development lifecycle before turning to pen testing.

• Automate testing and bug reporting as much as possible. The panelists acknowledged that there is a fulsome debate over whether to build automated data security solutions in-house or whether to outsource these tasks to third-party security vendors, and that the best solution may differ from company to company.

• Implement “bug bounty” programs. Bug bounty programs reward individuals (e.g., through cash incentives, recognition, or free products) for reporting credible software vulnerabilities. The panelists recognized that it might not be appropriate for small start-ups or other companies with immature data security programs to implement a bug bounty program immediately. However, they encouraged larger companies to consider whether a bug bounty program might create the right incentives to identify and remedy security vulnerabilities earlier in the software lifecycle, when it is easier and more cost effective to correct the issue. Specifically, companies should ask whether bug bounty programs can be targeted to a specific stage of product development (such as beta periods) or a specific type of bug report. Companies should avoid creating incentives for individuals to target customer data, trade secrets, or other company “crown jewels.” Importantly, companies should design their bug bounty programs to ensure good communication with individuals who may find software vulnerabilities. Katie Moussouris, Chief Policy Officer at HackerOne, noted that the International Organization for Standardization (“ISO”) has published two standards governing the intake of and response to vulnerabilities—ISO 29147 (Vulnerability Disclosure) and ISO 30111 (Vulnerability Handling Processes).

• Consider using Content Security Policies (“CSPs”). CSPs prevent cross-site scripting and similar attacks by preventing third-party scripts, plugins, and other objects from rendering on a user’s browser. FTC staff member Jessica Lyon stated that CSPs might be a “powerful” and “easy” measure for thwarting data security attacks. However, Jon Oberheide, Co-founder and Chief Technology Officer of Duo Security, cautioned that while start-ups may be able to implement CSPs effectively in some cases, using CSPs may be more difficult for larger organizations with legacy systems or sites and services that make potentially hundreds of third-party server calls. The panelists also acknowledged that CSP reports can produce many false positives–such as a user’s third-party plugins–that do not actually represent data security threats.

• Evaluate whether multi-factor authentication is right for your service. Multi-factor authentication requires more than one method of authentication from independent categories of credentials to verify a user’s identity. For example, a user might be asked to provide not only a username and password, but also a PIN that is texted to the mobile phone number associated with the account. Jon Oberheide described how multi-factor authentication can enhance security, but he also acknowledged that it has real impacts on the consumer experience and may not be appropriate for companies with a small user base or low average revenue per user.

The FTC will host its second “Start With Security” event on November 5, 2015, in Austin, Texas.

Megan Rodgers also contributed to this article.