Is it legal for an employer to ask for SIN number over email? I live in Ontario and recently my SIN Number changed. I notified my employer about the change and they asked me to email them the new sin number. I do not want to do so and I prefer to update my sin number through a secured website (https). But, the employer does not have a secured system. They in-directly insists on sending it with email. Is it legal to do so? and what should I do?
It is generally legal for a business to ask, but it is not legal for a business to insist that you provide it as a condition of providing goods and services unless a law requires that the SIN be provided. As explained by the relevant Canadian government website: While there is no law barring businesses from asking for the SIN where there is no legal requirement to do so, they do need to make people aware that collection of a SIN is optional and not a condition of service. The Personal Information Protection and Electronic Documents Act (PIPEDA) sets out ground rules for how private sector organizations may handle personal information — including the SIN — in the course of commercial activities. Under the law, organizations cannot require you to consent to the collection, use or disclosure of your personal information unless it is required for a specific and legitimate purpose. This means that, unless an organization can show that your SIN is required by law, you cannot be denied a product or service on the grounds of your refusal to provide your SIN. Of course, the rub is, that an employer is legally required to have your updated SIN for tax purposes, so the employer is allowed to demand, rather than merely request that you provide it. In particular: 7.3 In addition to the circumstances set out in section 7, for the purpose of clause 4.3 of Schedule 1, and despite the note that accompanies that clause, a federal work, undertaking or business may collect, use and disclose personal information without the consent of the individual if (a) the collection, use or disclosure is necessary to establish, manage or terminate an employment relationship between the federal work, undertaking or business and the individual; and (b) the federal work, undertaking or business has informed the individual that the personal information will be or may be collected, used or disclosed for those purposes. A business is required to do this consistent with Schedule 1 to the Act which provides in the most pertinent part: 4.7 Principle 7 — Safeguards Personal information shall be protected by security safeguards appropriate to the sensitivity of the information. 4.7.1 The security safeguards shall protect personal information against loss or theft, as well as unauthorized access, disclosure, copying, use, or modification. Organizations shall protect personal information regardless of the format in which it is held. 4.7.2 The nature of the safeguards will vary depending on the sensitivity of the information that has been collected, the amount, distribution, and format of the information, and the method of storage. More sensitive information should be safeguarded by a higher level of protection. The concept of sensitivity is discussed in Clause 4.3.4. 4.7.3 The methods of protection should include (a) physical measures, for example, locked filing cabinets and restricted access to offices; (b) organizational measures, for example, security clearances and limiting access on a “need-to-know” basis; and (c) technological measures, for example, the use of passwords and encryption. 4.7.4 Organizations shall make their employees aware of the importance of maintaining the confidentiality of personal information. 4.7.5 Care shall be used in the disposal or destruction of personal information, to prevent unauthorized parties from gaining access to the information (see Clause 4.5.3). There is really no specific provision allowing you to refuse to provide information via email, but the Safeguards provision does state that appropriate care does need to be taken to avoid disclosure, and you are disputing that their email collection is adequate. Also, while employers are required to collect SIN data from employees, there is nothing that expressly requires them to collect it via email. If you wanted to compromise, one option would be to save the SIN in a password protected word processing document (usually available in the save as window in an obscure little corner), and then you could attach the password protected document to the email and communicate the password itself to the recipient orally via telephone with you calling their number to prevent any phishing scam. It's a bit clunky, but it gets the job done. Also, please recognize that while a SIN number is important to keep confidential to the extent possible, it is hardly the most sensitive personal information in existence. Lots of people have a need to know it for legitimate purposes and it probably wouldn't be hard at all for someone to get it illegitimately by making a request for your credit record or a tax return transcript under false pretenses.
Wikipedia explains this well enough: Particular numbers can be trade secrets, and their reproduction and dissemination may be particularly proscribed, e.g., by the U.S. DCMA. As a coarse analogy: Your social security number is not "illegal." But if somebody entrusted with it shared it in violation of law or contract then their communication of the number in a context that allowed potential identity thieves to associate it with you would be illegal. To answer follow-up questions in the comments: Sure, "mere possession" of a number can land one in jail for all sorts of crimes, just like "mere possession" of stolen property can. For example, if you possess a bank account number, credit card number, or PIN, and you "conspire, confederate, or combine with another" person who actually commits fraud or theft using that number, then you can be convicted of the same crime. This is so common that a search for "conspiracy to commit wire fraud" or "credit card fraud" provides ample reading.
If the data controller has “reasonable doubts concerning the identity of the natural person making the request”, then “the controller may request the provision of additional information necessary to confirm the identity of the data subject” (Art 12(6) GDPR). Until the data subject provides this information, the request is paused. But what are reasonable doubts, and what additional information can the controller request? The GDPR itself provides no clear guidelines, though general principles apply – the additional information must be necessary, adequate, and proportionate for the identity conformation purpose. The controller's obligation to comply with access requests must be balanced with the controller's obligation to ensure the security of data by rejecting invalid requests. Just accepting any request without any verification would also be a breach of the GDPR. For example: If the company identifies data subjects by email address, then demonstrating control over the email address would be an appropriate verification step. But just mentioning the email address would not be enough since it could be someone else's email address. If the company provides a website where data subjects have created user accounts, then being able to log in to the account would be an appropriate verification step. In these examples, asking e.g. for government photo ID would not be appropriate because that doesn't help strengthen the link between the person making the request and the personal data being processed. Such data collection would be disproportionate and unnecessary. In contrast, if you walk into a bank and ask for a copy of your data, it would be entirely appropriate for them to ask for government ID because (a) the higher general risks warrant stronger checks, and (b) such ID will help confirm that the person making the request is indeed the proper account holder. The bank will also have been legally required to request ID when the account was originally opened, so that asking for ID as an identity verification measure during this later request won't involve collection of more data than they already have. (These examples were made up by me and are not official, but read on.) The EDPB has issued draft guidelines on the right of access 01/2022, which also discuss the issue of additional information for identity verification in sections 3.2 and 3.3. In particular, paragraphs 73-78 talk about IDs: 73. It should be emphasised that using a copy of an identity document as a part of the authentication process creates a risk for the security of personal data and may lead to unauthorised or unlawful processing, and as such it should be considered inappropriate, unless it is strictly necessary, suitable, and in line with national law. […] it is also important to note that identification by means of an identity card does not necessarily help in the online context (e.g. with the use of pseudonyms) […]. 75. In any case, information on the ID that is not necessary for confirming the identity of the data subject, […] may be blackened or hidden by the data subject before submitting it to the controller, except where national legislation requires a full unredacted copy of the identity card (see para. 77 below). […] 76. […] Example: The user Ms. Y has created an account in the online store, providing her e-mail and username. Subsequently, the account owner asks the controller for information whether it processes their personal data, and if so, asks for access to them within the scope indicated in Art. 15. The controller requests the ID of the person making request to confirm her identity. The controller's action in this case is disproportionate and leads to unnecessary data collection. […] Example: A bank customer, Mr. Y,, plans to get a consumer credit. For this purpose, Mr. Y goes to a bank branch to obtain information, including his personal data, necessary for the assessment of his creditworthiness. To verify the data subject’s identity, the consultant asks for notarised certification of his identity to be able to provide him with the required information. The controller should not require notarised confirmation of identity, unless it is strictly necessary, suitable and in line with the national law […]. Such practice exposes the requesting persons to additional costs and imposes an excessive burden on the data subjects, hampering the exercise of their right of access. 77. Without prejudice to the above general principles, under certain circumstances, verification on the basis of an ID may be a justified and proportionate measure, for example for entities processing special categories of personal data or undertaking data processing which may pose a risk for data subject (e.g. medical or health information). However, at the same time, it should be borne in mind that certain national provisions provide for restrictions on the processing of data contained in public documents, including documents confirming the identity of a person (also on the basis of Art. 87 GDPR). Restrictions on the processing of data from these documents may relate in particular to the scanning or photocopying of ID cards or processing of official personal identification numbers. To summarize: controllers can request IDs only in comparatively niche scenarios, and must then take additional safeguards to protect the sensitive document (e.g. instructing the data subject to redact parts of the ID, not making copies, and immediately deleting the ID after successful verification). A lot here comes down to national laws, which may explicitly require or forbid use of the ID in this context. The EDPB guidelines are not binding or normative, especially since this guidance is still in the public consultation phase. However, the guidelines present an overall consensus of the national data protection authorities in the EU, and the guidelines are regularly cited by courts. In practice, many controllers do ask for disproportionate amounts of data. Sometimes this seems to be an attempt to discourage data subject requests, which would clearly be non-compliant. In some cases, this is due to a narrow interpretation of “reasonable doubts” in which they try to eliminate any doubt about the identity. If the data subject and data controller cannot agree on a suitable identity verification process, then the data subject can: Art 77: lodge a complaint with a data protection authority, and/or Art 79: sue the data controller in court, both for compliance (fulfilling the request) and for compensation (if damages were suffered). It is worth noting that the data controller is responsible for being able to demonstrate compliance (Art 5(2) accountability principle), such as demonstrating the apparent reasonable doubts to a supervisory authority or to a court. When the controller requests ID, the controller has the burden of proof to show that this is compliant.
the first two highlighted parts seem to contradict each other. No, in this case they do not. The first highlighted portion refers to works or items produced "for or under the direction of the Company", whereas the second highlight refers to your creations that satisfy conditions (a) and (b). Where contradictions actually exist, the doctrine of contra proferentem entitles you (the non-draftsman of the contract) to adopt the portion or reasonable interpretation that favors your legal position. Also wondering how valid those statements actually are They are valid and become enforceable as soon as you sign the contract or your subsequent conduct reflects your acceptance thereof. it's a matter of privacy. So the question is what I can do or what the reality is of the situation The reality is that you are asked to sign a contract that is abusive and ridiculous. One vulnerability from describing your inventions (presumably in Appendix A) is that the employer gets "irrevocable, worldwide, etc" rights on them as soon as you "use or disclose any [items listed in Appendix A] when acting within the scope of [your] employment". This means that if instead of reinventing the wheel you share or apply any portion of your prior creations so as to enhance your productivity, you knowingly and irreversibly grant to the employer perpetual rights to those items. Legal disputes regarding APIs can become extremely intricate. And, since judges usually have no decent background on IT, even those few judges with integrity are unlikely to grasp the key subtleties that would lead to a correct ruling. "not useful with or related to any Company Interest" is very vague. The company could be interested in literally anything these days. Clauses which are too vague or excessively wide-encompassing are supposedly stricken as unconscionable, unenforceable, etc. However, I personally would foreclose upfront the risk of judicial hassle and decline the abusive contract. Legal issues aside, keep in mind that you are offering your expertise (in terms of supply &amp; demand, you are on the supply side). This fact has a less derogatory connotation than "asking for a job". Accordingly, the relation between the parties should be more leveled.
I presume you are addressing the various wiretapping laws. In all of those channels, one would have a reasonable expectation of privacy, in contrast to using CB radio or a megaphone. However the context of using the instrument affects that expectation, for example if your phone is on speaker you do not have a reasonable expectation that those around you cannot hear your conversation, when there are others around you. Also, there is no expectation of privacy surrounding employers monitoring employee emails for valid business purposes – but the federal government can't intercept your emails (without a warrant) just because you are using business email. The expectation of privacy is really about the surrounding circumstance, not the instrument you use.
Surely such a well meaning albeit naive driver wouldn't stand a chance in court if they said that it's because they've a section 230-like protection. Because Section 230 of the Communications Decency Act explicitly protects computer service providers from such charges. A driver is not a computer service provider, and the US legislature has never voted to offer similar protection to drivers picking up hitchhikers. You say that an email can easily be classified as fraudulent, but that's not true. Spam detection has gotten pretty sophisticated, but they still get plenty of false positives. They were a lot less sophisticated back in 1996 when the Communications Decency Act was passed.
Your confusion might be caused by the fact that even with a contract, only the data necessary for that contract is covered under the GDPR. So yes, while there might be an &quot;execution of contract&quot; under the T&amp;C, this would only cover necessary data. That means you can't ask arbitrary signup data under the guise of a contract. If you need to deliver a physical product, you can store a physical address. If it's an online service, you can store an email address or similar handle. But you can't mix the two. A physical address is unnecessary for the execution of a contract that's not physical in nature. Now, you mention &quot;consent&quot;. Under GDPR, this is a distinct justification besides &quot;execution of contract&quot;. You might have consent to store a physical address in addition to an online address, e.g. if you offer a customer to physically mail a password request form. This consent is additional to the contract. Also note that the bit above only covers the lawful reasons for the processing of personal data (article 6). You also have to obey the other GDPR rules, e.g. fully inform the user, make sure that consent is freely given, etc.
HIPAA imposes obligations on some people, but not all people. In the case of security and privacy questions, you would consult 45 CFR Part 164. A patient's actions are not subject to government sanctions, so a patient can provide or decline to provide email addresses following their own judgment. A healthcare or insurance provider would be required to securely keep PII under wraps. The regulations also do not impose obligations on unknowing potentially involved third-parties, i.e. no obligation is imposed on Google to know that an individual is using a Gmail account to transmit PII-related information. The medical provider has an obligation to store and transmit such information securely, which would mean for example that they do not send insecure plain text emails saying &quot;Sally Jones at 12345 67th Ave SW was treated for a loathsome disease, we're coding that as 0102, and we want $500&quot;. That obligation is passed on to employees via employment-contractual obligations, for example that may dictate what computer or software you can use to do the job. If the provider passes the buck to the employee (and I assume that the employee is just an employee), they have violated the security rule. In that case, they may be attempting to mitigate the consequences of their actions or at least check if there were identifiable violations of the privacy rule. In the scenario where SmithMed provides all of the infrastructure needed to bill insurance companies, it is not a HIPAA violation to inspect computer logs, email etc. to verify that the employee has been complying with security and privacy policies. It would likewise not be a HIPAA violation to inspect third-party accounts (Gmail etc) to determine whether there has been a security / privacy rule violation. That is as far as HIPAA takes you. Whether or not the ex-employee has an obligation to turn over their email account information is mostly determined by the employment contract, but it is highly unlikely that any such contract has a &quot;gimme your personal email on termination&quot; clause. It is not inconceivable that the employee negligently used their personal account rather than opening a new billing-job only account. Also depending on the email service provider, it may well be a violation of the terms of service to hand over your account information. (Instead, for a certain email provider, the company is expected to set up and pay for a company account). Those are considerations bearing on possible legal impediments to turning over the email information. Needless to say, don't share passwords etc. because that exposes you legally, but that is not about HIPAA.