Protecting citizen information and privacy

Protecting citizen information and privacy is a primary concern when collecting and using their data.

On this page:

• About information incidents
• Preventing inbound email incidents
• Preventing inbound API incidents
• Preventing outbound incidents
• Limiting perceived incidents
• Why you should never use "do not reply"

About information incidents

Information incidents occur when unwanted or unexpected events threaten privacy or information security. They can be accidental or deliberate and include the theft, loss, alteration or destruction of information. Any such incident involving personal information needs to be reported.

• Guide to Good Privacy Practices
• Learn about privacy breaches

Information incidents are exceptionally rare among CMS Forms users, but they can occur.

• The most common type of incident is information loss
• These losses are usually outbound to the citizen
• They are incidental and fully recoverable

Keep in mind that not all forms involve personal information. The greater the amount and sensitivity of personal information collected in the form, the more care and attention needed in your design choices. Your design decisions influence whether information incidents may occur, and how serious they can be if they do.

Your ministry privacy officer can advise you on things like who should report the situations described below and how. They may even consider modifying existing Privacy Impact Assessments.

As a form author, you are best placed to discuss this subject with them, apply preventative measures across all forms, and communicate procedures to individual program areas.

If you’re using email as your primary delivery method, you’ll want to ensure that those emails always get through to the program area that is the intended recipient. If this information is lost, the citizen will not receive the service they requested. Depending on what that request is and how time-sensitive it is, the consequences for them can be serious.

To prevent inbound email incidents:

• Only send data to group or shared mailboxes
• Only use mailboxes that the recipient program owns, controls, and has access to
• Do not use a “do not reply” mailbox
• Test your forms thoroughly before releasing them to the public

Remember that email is not an acceptable location for storing information, and that mailboxes can eventually fill up if things like form submissions aren’t regularly processed and stored elsewhere.

CMS Forms can also send data to another application, such as a case management system, using an application programming interface (API). API and application design and development is beyond the scope of CMS Forms and this manual, but there is some general guidance.

Inbound data incidents may occur if:

• The API or application experiences an outage and there's no "safety" mechanism
• The form sends data to the "wrong" API, such as to a test address instead of a production one
• You change the form data in a way that the API or application can't use

The key to preventing potential inbound API incidents is establishing and maintaining a relationship with your ministry's application developers.

• Ask developers to let you know of any planned changes to APIs or applications, particularly if there is a location change
• Consult with developers when you are adding, removing, or renaming form fields
• Include the developers in your form testing so they can confirm that data arrived and there are no issues

An outbound email incident can occur when your form sends information back to a citizen, such as a confirmation email. These don’t always result in a privacy breach. They are most often just a failure to deliver that information.

To be informed of outbound incidents:

• Ensure Sender or Reply-to email addresses are program area group or shared mailboxes
• Do not use a “do not reply” mailbox

The program area will need to see the possible system messages to respond appropriately.

The citizen’s email provider may reject an email from CMS Forms or another system for reasons like:

• The mailbox doesn’t exist, indicating that the citizen mistyped their email
• The mailbox is full, so no emails will get to the citizen until they make space
• The email sent was larger than the provider accepts, indicating that you sent too much information

Thanks to things like browser autofill, mistyped emails are very rare, and you can’t design around the potential for the mailbox to be full.

To prevent message size incidents:

• Do not include copies of documents and files provided by the citizen with their submission:
  • It increases total message size
  • The citizen already possesses them
  • Impact of a privacy breach is significantly reduced

Program areas can recover from rejected emails by:

• Matching notifications to submissions received
• Contacting the citizen another way, such as by phone, to advise them of the issue
• Offering to send them their information by email once the issue is corrected, or through another means, such as fax or mail

A privacy breach can occur if citizen personal information is accidentally or intentionally provided to a third party outside of the provisions of the Freedom of Information and Protection of Privacy Act.

The most likely cause of such a breach is a citizen providing an incorrect but legitimate email address which is owned by someone else. Their information goes to that person instead.

You may become aware of this situation when:

• The citizen contacts you and advises that they did not receive a notification

• The unintended recipient replies that they got the email in error

Your ministry privacy officer can advise you on how to proceed, or even help you develop a consistent practice for this kind of situation.

• Not all forms and notifications involve personal information
• You can reduce potential impacts through design

To limit the potential impact of a privacy breach:

• Limit the information included in the message subject and body
• Do not attach a copy of the form without the citizen’s express permission
• Recommend that they download a copy of the form directly instead

Many companies track and monitor individual behaviours across all their devices. Because of this, there are occasions where a citizen may suddenly notice a change in their Internet experience after submitting a form and think their privacy has been breached.

Examples of this could be:

• A medical clinic sends a citizen a lab requisition to their Gmail account. Gmail scans the requisition and recognizes the tests requested. The citizen then begins seeing ads for the medical condition(s) being tested for
• A citizen visits some income assistance pages and applies for one or more benefits. Their browser recognizes this behaviour and assumes that they are in financial need. The citizen then begins seeing ads for financial advisors and lenders of last resort

Whether or not this occurs depends on factors like:

• If the citizen is using a free email provider like Gmail
• The privacy and security settings of their browser
• If they are using a virtual private network (VPN)
• The privacy terms and conditions of sites they visit or services they use

The government website doesn’t participate in marketing technologies, but that doesn’t mean that the citizen’s tools or services can’t acquire that information another way.

• B.C. Government Website Privacy Statement

To limit the appearance of a privacy breach:

• Limit the information included in the message subject and body
• Do not attach a copy of the form without the citizen’s express permission
• Recommend that they download a copy of the form directly instead

These are the same recommendations to reduce the risk and impact of an actual privacy breach.

It is strongly recommended that you do not use a “do not reply” email address for communications for the following reasons:

• A functioning mailbox is required to send out emails
• If you choose a “do not reply” address that doesn’t exist, your email won’t be sent
• There’s a daily limit on the number of emails that can be sent from any mailbox
  • You don’t know who else is using the mailbox
  • You don’t know how many emails may be sent in a day
  • Excess messages may not be delivered
  • Excess messages may get marked as spam
• You can’t prevent citizens from replying to those addresses
• You will not receive any important system messages or citizen replies
• All replies will go to someone else, potentially constituting a privacy breach

The general expectation is that if you receive an email from someone, you can reply to that email. This is just how email is supposed to work.