#3 - Data Privacy: Things to Consider

Hey everyone! Welcome back to Campfire Logs: The Art of Trial & Error. In my last log, #2 - Retrofitting the Privacy Policy, I discussed forgetting to add a privacy policy to my website before it went live, why it was important to me as a solo developer to retrofit it into my contact form, and the issues I ran into during the process. Today, however, I want to shift gears away from the technical issues and dig a little deeper into how I drafted my website’s privacy policy and what shaped my approach.

Data Privacy and Why It’s Important

Now, somebody is probably thinking, “But Derek, you’re just starting out as a freelance developer. You aren’t likely to have many clients for a privacy policy to really matter,” and they’d be right (for now). Regardless, I’ve found that forming good habits early on (when things are slow) can save you from a whole lot of headaches later on. This is no different when it comes to data privacy.

The term Data Privacy Law refers to any legislation that mandates how a business or organization is allowed to collect, use, or store information on the consumers that use their services, as well as the rights consumers have to hold some control over that data. These types of laws are very common, especially in developed countries, but something very important to be aware of is how greatly data privacy laws can vary between jurisdictions. This is true not only from country to country, but even state to state.

In the U.S., for example, while there are some federal and sector-specific laws (like HIPAA or COPPA), the majority of data privacy laws are decided at the state level. This is why California’s data privacy laws, the California Consumer Privacy Act (CCPA) and the California Privacy Rights Act (CPRA), are the strictest consumer protection laws in the country, whereas states like Arkansas and Mississippi barely have data privacy laws at all (comparatively).

By contrast, things abroad look very different. The European Union’s General Data Protection Regulation (GDPR) is (at the time this article was published) the most restrictive set of data privacy laws in the world, with harshest penalties for violations. Additionally, GDPR isn’t solely bound within the EU, but essentially extends to any organization in any country that conducts business with any resident of the EU.

Even though data privacy laws often target larger organizations, that doesn’t mean smaller businesses or solo developers like me get a free pass. Data privacy applies to everyone handling personal information, and overlooking it (even unintentionally) can create significant legal risks, impact client perception, and erode trust. Bigger organizations and enterprises often have compliance officers and legal teams to make sure these don’t happen, but that’s not the case for the little guys. So how did I choose to tackle this endeavor on my own?

I thought you’d never ask!

Your Options as a Solo Dev

Because I sometimes focus so intensely on getting things right that I end up getting in my own way—especially when it involves something that means a lot to me—this process wasn’t as straightforward as I would have preferred. That’s not to say it was difficult, but there was a lot to be seriously considered. Protecting yourself and those you offer services to legally isn’t something to be taken lightly.

This was my process.

Hire a Pro or DIY?

Let me say first and foremost that I am not a lawyer, and I cannot give you legal advice. Because data privacy laws can vary considerably depending on location, the safest bet is to have a lawyer or attorney (those terms aren’t mutually inclusive necessarily) draft or help you draft legal documents that can hold up in court. What I can do, however, is suggest how you might find guidance to make an informed decision for your own use case.

For some, hiring a professional to draft their privacy policy simply isn’t an option. The good news is there are alternatives to consider. Online privacy policy generators, like Termly and FreePrivacyPolicy.com, can be used to create generic policies, but it’s still a good idea to use them cautiously. The policies they generate are very “cookie-cutter,” meaning they are designed to be used by many users and many use cases. In the real world, however, one size does not fit all when it comes to legal documents, so I recommend learning as much about them as you can before committing (still not an option for everyone).

My DIY Approach

My approach to creating a policy tailored to my specific business needs and values wasn’t terribly complicated. I started by generating a policy with both Termly and FreePrivacyPolicy.com, but when I compared them, I was surprised by the differences. FreePrivacyPolicy.com’s document covered a wide range of cases, but in a very broad manner (again, “cookie-cutter”). Termly, on the other hand, was much more detailed, but it included a lot of clauses that didn’t apply to my needs. For me, neither of these would do, but now I had a great jumping-off point.

To write my own, I used clear and approachable language, first focusing on explaining five key points:

• What - What exact PII my contact form collects (name, organization, email, phone, etc.)

• Why - Why that information is collected (as a means to respond to inquiries of potential clients)

• How - How the user’s PII is collected (through voluntary submission via the contact form) and how that information would be used (specific ways I would use their PII for providing my services)

• How Long - How long that information will be retained in my database (no longer than 1 year or otherwise required by law)

• Where - Where I can be contacted for change or deletion requests by the person to whom the PII pertains

For added transparency, I also added what information I do not collect and addressed common points of concern (cookies, tracking, selling data, etc.). I also provided a high-level description of how I protect collected PII and touched on consumer rights to requesting the correction or deletion of their data and their right to an appeal and an explanation if those requests are rejected.

You can check out my website’s policy here.

To put it frankly, my goal wasn’t just to protect myself legally. I also set out to put potential clients’ minds to rest about whether their information would be handled responsibly and with respect.

TL;DR

In short, data privacy is something to be taken seriously. While most data privacy laws are geared toward larger businesses and organizations, responsibly handling collected consumer information—and being transparent about how that data is used—applies to even a solo dev.

If you’re considering a privacy policy for your own use case, you have options. Whether you decide to hire a professional, use an online policy generator, or draft it yourself, it’s important to understand which option best fits your particular situation, knowing that what may work best for one scenario may not be appropriate for all others. Your safest bet will almost always be to seek the advice of a lawyer or attorney. If you choose otherwise, do your research, make well-informed decisions, and don’t make assumptions.

My approach was to draft my own policy tailored to the needs of my specific use case. While doing so, I focused on transparency and honesty to ensure any users of my website and contact form feel safe and respected.

Before You Go

As always, thank you so much for checking out this Campfire Log! I look forward to hearing your thoughts on what is discussed here, as well as answering any questions you may have. Feel free to leave a comment and help expand the conversation. Perhaps you have a similar experience to share.

Looking ahead to #4, I’ll be getting back into the more technical side of things by discussing refactoring to promote modularity and scaling. Be sure to come back and check it out.