There’s a natural struggle between those who write rules around compliance to a standard and those who must implement IT systems to ensure compliance with that standard. The former want to create guidelines rather than hard and fast requirements so there’s flexibility in how to achieve compliance. Plus, they want guidelines that allow for advances in technology. The latter want technical specificity – do X and become compliant.
With a compliance standard like PCI DSS, which specifies credit card information security requirements, there’s a great deal of technical specificity about what is required in order to become PCI DSS compliant. In fact, all but a handful of PCI DSS’s 211 sub-requirements call for specific technical actions. But even then, some PCI DSS sub-requirements are subject to interpretation by the various auditing authorities.
Most compliance mandates, especially those imposed by governments, aren’t as cut and dried as PCI DSS and they always include many specific requirements around acceptable compliant behavior in addition to non-specific requirements around technology-oriented compliant safeguards.
The privacy and security of health information in the U.S. is governed by a Federal law called the Health Insurance Portability and Accountability Act (HIPAA). As written, HIPAA is vague in many behavioral and technological areas. The law turned over “rule-writing,” whose aim is to provide more specificity, to the U.S. Department of Health and Human Services (HHS). HHS wrote a key rule – the HIPAA Security Rule – that is relevant to information security professionals.
But alas, even the HIPAA Security Rule is ambiguous! Read More »