5

A company sent me a document to sign via CudaSign, I did.

As soon as I completed the transaction, I got a PDF over email with the document attached. The document includes my SSN. I assume, the originator also got the document via PDF attachment.

Isn't sending a PDF with SSN via email clearly insecure, and shouldn't this practice be stopped? Aren't the end users (me in this case) exposed? Is there any recommended action?

To clarify:

  • The PDF is sent automatically by the service provider in this case as a "confirmation" step. Not by the originator or the party signing the document.
S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
csmba
  • 151
  • 4
  • I think you need to refine the question. This situation is not about the signing process or the services doing it, but simply about the sending of a clear-text PDF with your PII in it. – schroeder Apr 10 '16 at 17:55
  • It is about the signing process since it is a end-to-end workflow which results in a clear PDF with PII info in peoples inbox. 1/ You get a email with link to go to the service providers website to sign the document (https) 2/ you follow instructions in a safe and protected website 3/ you get a clear PDF with SNN info in your inbox – csmba Apr 10 '16 at 18:10
  • 1
    Ok - I think I can se your point better, but does the signing service require the PII in the document? I think the answer lies in choosing the signing service that has a process for protecting PII better. The signing service did nothing 'wrong', per se, but considering the content, a different process was required. – schroeder Apr 10 '16 at 18:17

3 Answers3

3

A document signing service does not process the data contained within the document it is signing. Theoretically, the signing service is completely unaware of the content. All it does is process the metadata as a whole in order to provide service.

From this perspective, the fact that a certain document contains PII is not within their control, and therefore they have not broken any rules or regulations. It is up to the customer who chose the service, and hence the process, to make sure that the process is appropriate for the data being processed.

As you can guess, there is then a lot of "buck passing" for responsibility, but you should inform the one who chose the service about the impact of their choice.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • I agree with the principle, but I would say that a large portion of documents that require signature contain PII (real estate, employment, contracts) and other sensitive information (bank accounts etc'). I don't see why would the responsibility be on the originator instead of the service to assure that they don't expose the information. Unless the originator had to Opt-in to sending the document via email, I see this as a vulnerability in the service. – csmba Apr 10 '16 at 21:33
  • I hear you, but the reality of who processes the information is a factor. I am the Security Architect for an HR analytics SaaS company. We deal with PII and we navigate the murky waters of having to take responsibility for PII, or not. The fact is that if the service is not the one who processes the PII data, then they are not responsible for PII-specific protections of the data. That is changing with the upcoming EU Directive, but those new regulations will not apply globally. – schroeder Apr 11 '16 at 04:07
  • In the real world, due to issues such as PII information in documents, a signing service, as part of the overall service, should have the ability to understand that part of the data is PII and handle it accordingly. See my answer to the question. – Larry K Apr 12 '16 at 05:36
  • @LarryK I deal with the "real world" of this problem daily. How would the service know that there is PII? Why should it treat all data as if it were PII and take on the costs and logistics that go along with that assumption? There are limits to liabilities for a reason. – schroeder Apr 12 '16 at 06:51
2

Note, I work for DocuSign.

The answers by Lie Ryan and schroeder are focused on the "pure" aspects of a signing service, which is responsible for just signing, in the narrow sense.

However, signing services can offer a broader product that includes additional services. For example, my company, DocuSign, offers the "Concealed View" feature. See the Quick Start Guide. Data fields that should be hidden are shown as asterisks. The data can be retrieved, but it is not shown.

It is the responsibility of the sender to mark data fields as "concealed." This can be done via the web browser admin tool, or via the api.

Setting a field to "concealed"

Setting a field to be concealed

Viewing a concealed field

Viewing a document that has a concealed field

Community
  • 1
Larry K
  • 591
  • 2
  • 11
  • This doesn't really answer the question. The question is if a rule or regulation has been violated, not if it is possible for a signing service to protect PII. – schroeder Apr 12 '16 at 14:35
  • Like I said in my answer, it is up to the user to choose the service that is appropriate for the information being processed. Yes, there are signing services that can protect PII in appropriate ways, this is *one* way of doing that. The other is to not send the data in clear text, but to encrypt it, or to not send it at all, but to store securely on the services servers. – schroeder Apr 12 '16 at 14:39
  • I think we're all in "violent agreement" I certainly agree that a signing process, at its core, just signs. It is also the case that signing documents that include PII is a common use case. That use case can and should be supported by signing services. – Larry K Apr 13 '16 at 05:43
0

Like most other users here, I don't think the signing service is at any fault here.

The signing service provides a certain workflow, which is the same for any documents, whether it contains PII or not. To the signing service, the document being signed is just a blob. They have no idea whether a document contains business contracts, PII, top secret documents, or some saucy fanfics you wrote over the weekend.

It is the responsibility of whoever asked you to sign this document to choose the signing mechanism that satisfies their responsibility to protect their customer's private data or to choose what data to be embedded in the document that is to be signed. In this case, they choose a service that aren't designed to protect sensitive data adequately, to the level that is necessary for their document.

In addition, just because the document is sent over email does not necessarily mean it is sent in clear text. Mail server to mail server communication are often encrypted, and you are then responsible for the last hop of setting up to access your email via IMAP/POP with TLS or via HTTPS webmail client.

Depending on the sensitivity of the document, setting up GPG or S/MIME so they can send you end to end encrypted email may not be appropriate for the purpose. Part of the reason why online signing service is popular is because they are much easier to use than having to set up GPG/x509 key pair properly. And if you have to set these up to use the document signing service anyway, you might as well just skip the middlemen and sign the document yourself with these certificates.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • In the real world, due to issues such as PII information in documents, a signing service, as part of the overall service, should have the ability to understand that part of the data is PII and handle it accordingly. See my answer to the question. – Larry K Apr 12 '16 at 05:36
  • @LarryK: my point is that no matter what security features the signing service does, it does not matter if the document sender doesn't generate the document and pick a signing service/features that satisfies their security responsibilities. Ultimately, the document sender have chosen a signing workflow that compromises their client's private data. – Lie Ryan Apr 12 '16 at 12:47
  • The regulations say that "a reasonable effort" should be made to protect (and remove if needed) PII information. I understand and accept that the sender should have a part and control over the workflow. If the services clearly has a path to mark the SSN field as such, and that _would_ change the workflow in this case (either mast the value in the pdf or not send the pdf to begin with), I guess it is ok. In any case, I do not know why it would send the attachment unless you opt-in for that, since it seems to be a likely problem that most users will hit. – csmba Apr 13 '16 at 04:01