PCI DSS / PHI / PII Compliance Testing

Security of electronic information is more important to corporations now than ever before. Data security has visibility at the C-level of every company that keeps any information about people. The ever increasing number, breadth, and depth of information security rules has companies scrambling to create and meet compliance requirements like:

  • Protected Health Information (PHI) to meet HIPAA, HITECH, and Omnibus regulations.
  • Payment Card Information data Security Standard (PCI DSS) to process credit cards.
  • Personally Identifiable Information (PII) to stay out of the news.

EMail Security Compliance

Individual information (PHI, PCI, PII) is required by law, by corporate policy, by industry best practices, and by common sense, to be encrypted when it is sent over the Internet.

For example, HIPAA’s section 164.312(e)(1), relating to Transmission Security, calls for Covered Entities to “Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network” and to “Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.”

There are three main ways to encrypt email:

  • End-to-end: Encrypt each message at the sender's PC, and decrypt it at the receiver's PC.
  • Forced-transit: Force the sending and receiving email systems to encrypt the email in transit.
  • Test-and-verify: Test new email connections before using them, and continuously test existing connections.


End-to-end encryption is the safest and hardest way to encrypt Internet email. Individual messages are encrypted at the sender's PC and only decrypted on the receiver's PC. A variation on this theme is store-and-notify, where the sender uploads the message or the message payload, and the receiver goes to a web site and retrieves it.

End-to-end encryption requires a client on every sending and receiving PC. Store-and-notify can get around requiring software on the PCs, but it requires users to navigate to a web page and enter a login/password to send and receive email.


Forced-transit encryption is mandatory TLS. Most email systems are opportunistic TLS, meaning they use TLS if both sides agree to use it, otherwise they fall back to insecure (normal) email. This is insufficient to meet HIPAA/HITECH and PCI DSS regulations. TLS encryption is sufficient, but the automatic fall back to insecure email is problematic, especially since there is no notification of TLS failure.

Companies can use TLS to meet HIPAA/HITECH and PCI DSS by turning on mandatory TLS, meaning any email has to be encrypted or it is bounced back to the sender. This requires no changes on either the sending or receiving ends, and requires no additional steps from either sender or receiver. TLS is widely used for Internet email, but it is not used everywhere, so turning mandatory TLS on for every domain results in so many bounces as to make email unusable. This will change as TLS continues to become more and more ubiquitious, but until then mandatory TLS is typically turned on just for specific domains. For example ABC company configures their email system to mandate TLS for any email being sent to XYZ company.

As long as the company using mandatory TLS regularly audits their list of required TLS domains and checks that their software is actually requiring TLS, this method typically meets all the requirements for protecting PHI, PCI, and PII. The CheckTLS "Assure TLS" tests can be used to verify that TLS is properly configured to mandate TLS; it cannot, however, verify that the right domains are listed for mandatory TLS.


Test-and-verify is the easiest way to achieve compliance with email security requirements. Every modern email system has TLS encryption capability, and most companies with any security requirements have it turned on. TLS encryption is HIPAA and PCI compliant. The problem with using these email systems for HIPAA or PCI is in the Internet RFC email standard: it requires these email systems to fall back to plain text, unencrypted, and non-HIPAA non-PCI compliant email if for any reason TLS isn't available or doesn't work. This is called "Opportunistic TLS", and Opportunistic TLS is not HIPAA or PCI compliant.

Opportunistic TLS will use TLS as long as both sides have it working. TLS encryption is compliant. So all a company has to do is make sure that TLS is being used, i.e. that their email is not falling back to sending in unencrypted clear text, and their email, labeled "opportunistic" or not, is HIPAA and PCI compliant. The simplest way to make sure that TLS is being used is to test it.

Most modern email systems can be HIPAA and PCI compliant without any changes from either the sender or the receiver. All that is needed is regular testing to be sure these systems are working properly and are using TLS.

Using CheckTLS for Compliance

CheckTLS is used by some of the largest hospitals and financial institutions in the world as part of their compliance policies and procedures for HIPAA, PCI DSS, and others. They use CheckTLS to implement a "Test and Verify" (see above) email security policy. Because NIST, HIPAA/HITEST, and most corporate policies consider TLS encryption of email to be sufficient, an institution needs only be sure that TLS is working.

Here's what they do. They test every trading partner for working TLS initially with a CheckTLS Basic Receiver Test, and then they periodically test that TLS is still working with automatic Batch Test. While this "Test and Verify" system is not foolproof, it is very simple, straightforward, easily explained and audited, and sufficies for most companies today. CheckTLS does offer a foolproof TLS service with ForceTLS.

We can help you with the testing required to meet HIPAA and PCI DSS compliance, and provide sample language for an email security policy document.
See how easy it is to setup
Contact us at Info(at)CheckTLS.com for more information.