30 December 2019
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:
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.
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.
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.
This article is not a substitute for professional legal advice. This article does not create an attorney-client relationship, nor is it a solicitation to offer legal advice.