📄 Building a Data Privacy & Security Program

🎉 Happy Friday, funds family!

A privacy policy on a website is not simply a privacy and security program. It's an important topic for companies and the investors who back them, because customers, regulators, and acquisition buyers care about how information is actually handled, not just whether the company has published a policy or purchased a security tool. Gaps between those statements and operating practices can become expensive and crucial problems.

The short answer is: a “program” is an ongoing set of responsibilities, processes, and safeguards for collecting, using, protecting, sharing, and deleting information. Privacy addresses what the company does with personal information and the choices people have; security addresses protection against unauthorized access and misuse. The right approach is generally proportionate to the company's data, products, customers, and legal obligations, with clear ownership and eprocess that the controls actually work.

➡️ Where should a company start?

Start by mapping the information the business handles: such as customer records, employee information, payment details, product usage, and anything sensitive. Then identify where it comes from, why it is needed, where it lives, who can access it, and which vendors receive it. Determine the applicable laws and contractual promises. US obligations vary by state, industry, information type, and business size. Keep in mind that same rules do not apply to every startup. For example, a customer-data spreadsheet may exist in a support platform, an employee's download folder, and a vendor's analytics system.

➡️ What are the core components of a workable program?

A practical program should connect policies to repeatable operating processes:

• Ownership and inventory: assign an accountable lead and maintain a current map of personal information, systems, purposes, and recipients.

• Privacy operations: align notices with actual practices, limit collection and retention, and establish a process for applicable access, correction, deletion, and opt-out requests.

• Security controls: use appropriate access restrictions, multifactor authentication, encryption, patching, logging, recoverable backups, and prompt removal of access when people leave.

• Vendor and incident management: review providers, put appropriate contractual protections in place, and document how the company will investigate and respond to an incident.

➡️ Which legal regimes and customer requirements matter?

The applicability analysis should be specific, not a collection of compliance labels. As examples:

• State privacy laws: California's CCPA, for example, applies to qualifying businesses and creates notice, consumer-rights, contracting, and other duties. By the way, not every startup meets its coverage requirements.

• Industry-specific rules: HIPAA applies to covered entities and business associates, not every health-related app; GLBA and COPPA have their own coverage rules.

• FTC expectations: misleading privacy or security promises can create deception risk, and inadequate security can support an unfairness claim in appropriate circumstances.

• Customer commitments: enterprise contracts may require particular controls, incident reporting, audit evidence, and limits on data use beyond the company's baseline statutory obligations.

A SOC 2 report can help demonstrate controls, but it is not a “universal” legal certification. Review its scope, exceptions, and covered period, and distinguish assurance evidence from compliance with the laws applicable to the business.

➡️ How should the program evolve as the company grows?

First build the basics before adding complexity. A small company can start with an accountable owner, an accurate inventory, sensible access controls, vendor review, and an incident plan. More sensitive products, enterprise customers, new jurisdictions, and acquisitions should trigger reassessment. Test backups and response procedures, track remediation, and review whether marketing statements still describe reality. Breach-notification obligations differ, so the response plan should identify applicable deadlines rather than assume one universal reporting period. Likewise, a security questionnaire should be answered by someone who knows the controls, not by a salesperson checking boxes to close the deal. Keep a record of important decisions and exceptions. The objective is not to promise perfect security. Rather, it is to make appropriate commitments, implement them consistently, and show how gaps are identified and corrected over time.

➡️ The practical takeaway

For the company:

1. Map the information you actually collect and use before buying tools or copying a privacy policy.

2. Assign an accountable owner, a realistic budget, and a recurring review cadence. A policy without execution is not a program.

3. Build privacy and security review into product launches, vendor onboarding, and major customer negotiations.

4. Practice incident response and verify that backups, access controls, and deletion processes work in operation.

For the investor:

1. Ask for evidence of implementation, not just a privacy policy or a list of security products.

2. Understand which data creates the company's greatest exposure and whether management has assessed the relevant legal requirements.

3. Review significant incidents, vendor dependencies, customer commitments, and unresolved control gaps as part of diligence, particularly as the company scales.

Thanks for reading, everyone!

Have a great weekend! 🙌

⚠️ Note: This newsletter is for informational purposes only and nothing should be considered legal advice. For that, hire a lawyer! I am a lawyer, but not your lawyer (unless I actually am your lawyer because you’ve signed an engagement letter and we’re working together). This may be considered attorney advertising.