Security Clauses for Privacy Policies

A security clause in a Privacy Policy is often more about reassuring the reader than complying with a legal requirement. Including a security clause in your Privacy Policy can help you achieve the wider goal of making your users feel more comfortable sharing data with you, knowing that you have data security safeguards in place and are on top of the topic.

However, it's vital not to overstate or mislead your level of security as doing so could cause legal problems.

A security clause is usually a brief statement, though it can be longer. Its content serves two main purposes:

• To convey the fact that you take security seriously when handling a user's personal data
• To inform the user about the scope or detail of your security procedures and measures

One way to think of this is that the start of the security clause is making a claim (such as "we protect your data") and the rest of the statement backs up that claim. In some cases a security clause might remind the user of their own responsibilities when it comes to security.

Is a Security Clause Mandatory?

The legal requirements of a Privacy Policy vary depending on the specific legislation that affects your business. In most cases, the legislation that requires a published Privacy Policy doesn't specifically say you must include a security clause.

However, the various measures in the legislation may have the combined effect that you need to include one. A security clause may also be something that helps comply with the spirit rather than the letter of the law.

Here's how some key privacy laws cover security clauses.

CalOPPA

The California Online Privacy Protection Act (CalOPPA) affects websites with users in California. The legislation has very specific requirements about what you must include in your Privacy Policy. However, there's no specific requirement to address security in the policy.

PIPEDA

The Personal Information Protection and Electronic Documents Act (PIPEDA) affects many organizations operating in Canada. It's based around 10 information principles, which are detailed in the text of the legislation.

Principle 7 (Safeguards) says you must protect any personal information you collect against "loss or theft" as well as "unauthorized access, disclosure, copying, use or modification." This can include physical, technological and organizational safeguards.

Principle 8 (Openness) says you must make your privacy "policies and practices understandable and easily available," which includes publishing a Privacy Policy.

These two principles have the combined effect that you need to explain your security practices for handling personal data. The Office of the Privacy Commissioner for Canada notes that you could detail your policies in a separate brochure. However, including a security clause in a Privacy Policy may be the easiest way to comply with both principles.

The GDPR

The General Data Protection Regulation (GDPR) covers most organizations which either operate in a European Union country or serve customers who are in a European Union country. It applies even if you process data outside the EU.

The GDPR is based on a set of 6 privacy principles. Principle 1 (Lawfulness, Fairness and Transparency) requires a Privacy Policy. Principle 6 (Integrity and Confidentiality) requires security measures.

The GDPR doesn't specifically require your public Privacy Policy to include a security clause. However, it does require that you address your security practices in a document known as a Data Protection Policy. This can be a purely internal document, but many organizations publish it in the interest of transparency.

Other Reasons For a Security Clause

It can be worth your while including a security clause in your Privacy Policy even if the applicable laws don't require you to do so. But why?

A security clause is useful for your customers and users as it helps them weigh up whether its worth providing the data that's necessary to access all or part of your services. This clause will help build trust among users by reassuring them that you will indeed treat their data responsibly.

Thinking about what to include in your security clause, or reviewing it later on, may spark discussion or consideration in your organization about the security measures themselves.

Creating a Security Clause

Make sure the reader understands what risks you are trying to mitigate with your security procedures. For example, usually you aren't just trying to protect against unauthorized access to data. You could also be trying to protect against the data being destroyed, altered or misused.

This example from the Japan Travel Centre is detailed, if a little wordy. Note how it lists out a number of specific things that could happen to data in the event of a security issue, including unlawful destruction, alteration, loss and unauthorized disclosure. It also makes mention that while it protects its own data, it isn't responsible for any third party security issues:

Give an overview of the types of security measures and protections you use. This could include physical methods such as keeping files in a locked location, technical methods such as secure passwords or restricted file access or organizational methods such as only vetted staff from a relevant department accessing information.

This clause from Secure Engineering is brief but clear. It even goes as far as noting how the office itself is protected when the staff isn't there:

Give the reader a good sense of how you review your security procedures to keep them up to date and relevant.

Tell the reader if your security has been audited or vetted to meet any specific regulations or codes of practice. Give details of the external party that can verify your security procedures.

In this example, OpenText explains how it complies with an international framework and who oversees that compliance.

Note that the Privacy Shield Framework referenced in the below screenshot was invalidated and has been replaced by the EU-U.S. Data Privacy Framework:

Consider including an outline of how you deal with any security breaches including when and how you'll notify affected customers.

Faber Music does this in concise but clear detail:

A Balanced Level of Detail in Your Security Clause

Your Privacy Policy doesn't always need to go into detailed specifics of how your security operates. In fact, dooing so could have several drawbacks:

• You may overwhelm the reader with detail so that they either skip past that section of the policy or otherwise miss the big picture
• You increase the risk that something changes in your security procedures but you don't update the Privacy Policy right away to reflect this change
• You could give so much detail that it helps hackers or other criminals figure out more effective ways to breach your security

Instead it's best to give the reader an overview of your security procedures that helps them understand how extensive your security is, what type of protections you have in place and what procedures your staff follows. In other words, let them know that you have security practices. You don't need to tell them specifically what they are.

Basware strikes a balance by having a security clause in its Privacy Policy that includes a summary of the security measures:

It then links to a dedicated page that covers the specific security measures in more detail, complete with a contact form link and a link to information about filing a security report:

To decide which specifics to include, try to imagine which risks a user might be most concerned about. Save the specifics for the most important and relevant situations. For example, if you store credit card details you can mention measures such as always storing and transmitting the details in encrypted form, or only permanently storing the final four digits of a card number.

Consider the reader's knowledge and interests when deciding what detail to include. For example, if your customers are in the tech industry, giving specifics of the measures you use can be informative and helpful. If you serve the general public, it may be better to give less detail about the measures themselves and more about the effects they have.

Include a Security Disclaimer

It's a good idea to include some form of disclaimer to remind customers that security can't be 100 percent guaranteed.

Think carefully about how you word this. You don't want to create the impression that you might fall short of your responsibilities. Instead you are conveying the point that even an organization doing everything practically possible to maintain security can't rule out all possible breaches.

It can be useful to give some broad examples of areas where security could be beyond your control, for example when data is transmitted online. Don't be too specific however as this could be read as you giving an exhaustive list of possible breaches and thus ruling out any other risks.

The American Psychological Association uses a disclaimer that puts the warning to the user in context:

Remember that a disclaimer such as this doesn't remove your legal (or indeed moral) obligation to do your best to protect customer data. It's not meant to be a "get-out clause." Instead it's more of a way to be more confident that customers have made an informed decision about sharing their personal data, with you and with anyone.

Be Accurate

You must make absolutely certain that any specific details you provide in a security clause are accurate. In particular you must avoid inadvertently or deliberately overstating or exaggerating the level of security you maintain.

The primary purpose of a Privacy Policy is to give the user enough information that they can make an informed decision about your services. This could be whether or not to use the service at all. It could also be whether to provide the additional personal data needed to get the maximum benefit of your service.

If your security clause overstates the protection you offer, it could unfairly sway the user's decision. This could mean losing goodwill and getting bad publicity if your security is not up to the advertised level.

Overstating your security can cause major legal problems if you suffer a breach. It could prompt legal claims by customers who argue they were misled into sharing personal data and suffered as a result. It could also lead to regulatory problems with organizations such as the U.S. Federal Trade Commission (FTC), which could class the overstated security claim as "unfair or deceptive acts or practices."

The potential legal problems don't just involve consumers. If you are a publicly traded company, an inaccurate security clause could be a breach of financial regulations. For example, investors could argue they were misled about your security levels and in turn the overall prospects and risks for your business. This could have played a role in whether or not they chose to invest in your company.

Conclusion

Let's recap what you need to know when considering adding a security clause to your Privacy Policy:

• A security clause is usually a statement that you take security seriously followed by some detail to back up this statement.
• Some legislation explicitly requires a security clause in a Privacy Policy. With some other legislation it's not explicitly required but is the best or only way to meet the overall requirements of the law.
• Even if you don't legally need a security clause, it helps build trust and inform users that you do care about security and have an active practice in place.
• A security clause should cover the types of risk you are trying to mitigate and the procedures you use to achieve this.
• In most cases an overview of the types of security controls you use is more effective than excessive detail. Consider the reader's perspective when deciding what to include.
• Include a disclaimer to remind customers that security can't be guaranteed, but don't rely on this as a "get-out clause."
• Never overstate or exaggerate the security you offer or the measures you use. This can have serious public relations, financial and legal consequences.