been42 has the right approach. Instead of looking for a particular technical fix, let the solution emerge from the details of the customer's requirements. "How sensitive is the data" is a crucial question. Only, you can't answer it. The customer can. Who or what will be consuming the data at the customer's site? A program? An order entry clerk? This will help dictate what sort of transfer mechanisms will be appropriate or possible.

Let's assume that there's an order entry clerk on the other end. Further, let's say the customer judges the data to be confidential in that revealing it will result in commercial disadvantage, but not sudden death, or extreme legal liability. So, that rules out encrypted email on the one hand, because the order entry clerk position turns over frequently, and a given incumbant may or may not be able to grok S/MIME or PGP/Gpg. That means the data must stay on the server (or its back-end database) after being entered by the customer. If we have good SSL and authentication in place on the web server (it's apparently good enough for the sensitive data to be entered in the first place.) why encrypt the data for storage in the database? Does the database server reside on a insecure network? You had better hope not! So store it unencrypted, and put your effort into ensuring that access mechanisms are solid. (Good passwords, stored securely, changed frequently etc.)

That's one possible set of answers to your question. But it all depends on the details of the customer requirements.

OB module link: GnuPG is a good module for encrypting stuff, as long as the other end of the conversation can deal.