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.
  • 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
    Commented Apr 10, 2016 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
    Commented Apr 10, 2016 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
    Commented Apr 10, 2016 at 18:17

3 Answers 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.

  • 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
    Commented Apr 10, 2016 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
    Commented Apr 11, 2016 at 4: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
    Commented Apr 12, 2016 at 5: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
    Commented Apr 12, 2016 at 6:51

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

  • 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
    Commented Apr 12, 2016 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
    Commented Apr 12, 2016 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
    Commented Apr 13, 2016 at 5:43

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.

  • 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
    Commented Apr 12, 2016 at 5: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
    Commented Apr 12, 2016 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
    Commented Apr 13, 2016 at 4:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .