This is a guest post by Cass Brewer, the founder of Truth to Power Association.
John Rostern recently blogged here about the dangers of checkbox compliance, noting that regulatory compliance doesn’t always bring information security.
I’ll take that argument a step further: Especially in terms of PCI DSS, most companies might get better ROI and comparable outcomes if they simply lied on their PCI DSS self assessments and returned to sprinkling salt around their servers, or whatever (apparently) prevented system breaches before PCI DSS came along. As John so aptly notes, siloed, point-in-time compliance is generally inadequate — in terms of both control and cost.
Unfortunately, external mandates tend to pervert otherwise healthy plan-do-check-act operational strategies. In the rush to comply with regulatory panaceas for perceived pervasive risks, managers too often deprecate their own informed risk judgments.
This is a backward response. Enterprise risk management should be both an input and output of any compliance program. As an input, it lets managers “just say no” to immaterial audit recommendations, defines implementation priorities and ensures that relevant controls aren’t displaced by compliance checkboxes.
Management can operationally parse broad compliance requirements by aligning control responses with actual material and significant risks. Or it can limit the in-scope environment of specific controls to particularly critical or sensitive information: cardholder data, customer PII, systems logs, etc. Either way, the bulk of risk management should occur on the front (planning) end of compliance. The risk management output of compliance programs is generally limited to risk mitigation.
Defining and measuring risks up front is also a cost-containment strategy. Under the Sarbanes-Oxley Act and other rules, organizations can exclude irrelevant “compliance” activities aimed at immaterial and insignificant threats. Of course, concrete documentation (and lots of it) is the key to defending such exclusions against auditor challenges.
Risks characteristics including existence, criticality, likelihood and period can further hone appropriate control responses. If a particular risk arises only once a year and potentially impacts just one disconnected system, a siloed, periodic response might be adequate. Of course, most risks are more constant and/or pervasive. Control efforts should respond to those characteristics, hitting compliance goals incidentally.
A risk management approach to compliance has opportunity benefits, too. It’s difficult to measure risk value (or risk abatement value) without understanding business-process value. In many cases, key risk indicators (KRIs) are complements to key performance indicators (KPIs). Defining one provides a base line for defining the other; and that base line is, in turn, a costing base line that supports more broadly strategic business decisions.
How does this work? Learn how to factor risk management into compliance assessments at SearchCompliance.com.
Cass Brewer is the founder of Truth to Power, a free and open research community for better information governance. At T2P and in her previous role as director of the IT Compliance Institute (ITCi), Cass has worked with thousands of compliance, audit, business, and IT leaders to develop practical guidance for corporate compliance and risk management. She can be reached at email@example.com.
What is the state of IT healthcare compliance in 2009? Dr. William Yasnoff has some thoughts.
His reply to ” Healthcare compliance gets boost from national HHS privacy framework,” a recent tip from one of SearchCompliance.com’s sister sites, demonstrated his deep understanding of the complex relationships among regulations, medicine and IT. A quick visit to his blog at WilliamYasnoff.com will confirm that he’s thought long and hard about the role of IT infrastructure in assuring patient privacy and health. SearchCompliance.com’s Alexander B. Howard found Dr. Yasnoff at his office last week and recorded a podcast.
When you listen, you’ll learn the answers to the following questions about e-health, including what changes might be expected under the new Obama administration:
- The United States Department of Health and Human Services (HHS) has a released a new privacy framework that provides guidance to organizations that handle personal health information. Does the Health Insurance Portability and Accountability Act (HIPAA) apply? What are the privacy and data protection issues created by the movement to e-health records?
- How does this directive affect IT compliance officers or system administrators at companies that handle e-health records? How could — and how should — a compliance officer change IT infrastructure and best practices to address the so-called HIPAA “audit hole?”
- The incoming Obama administration made the digitization of health records a focus of its presidential campaign. How may the atmosphere around healthcare compliance change? What additional regulatory requirements may be introduced that compliance officers should consider?
- What is Dossia? What role might this new entity, funded by corporations, play in e-health? How could Dossia affect e-health compliance? What is a health records bank? How many physicians currently use e-health records?
- What is the Electronic Communications Privacy Act (ECPA)? What must a CIO, CTO, CCO or IT administrator do to remain in compliance with the ECPA?
- What are some best practices for setting up IT infrastructure for healthcare institutions so that the systems are compliant? How will consent management factor into compliance in 2009?
- How might emerging enterprise 2.0 technologies be adapted and applied by the incoming U.S. CTO, particularly with regards to e-health records?
|William A. Yasnoff is founder and managing partner of National Health Information Infrastructure (NHII) Advisors, a consulting firm that helps communities and organizations successfully develop health information infrastructure systems and solutions. Previously, as senior advisor, NHII, Department of Health and Human Services, he initiated and organized the activities leading to the president’s creation of the Office of the National Coordinator for Health Information Technology, establishing the NHII as a widely recognized goal for the nation.
As vice president of research for Cell Analysis Systems Inc., he developed the first PC-based commercial system for quantifying DNA content of cells on slides in 1986. He later served as medical director of AMA/Net, the American Medical Association’s first online electronic information system for physicians. He subsequently restarted the network as U.S. HealthLink in Oregon.
Dr. Yasnoff is an associate editor of the Journal of Biomedical Informatics, adjunct professor of Health Sciences Informatics at The Johns Hopkins University, a board member of the nonprofit Public Health Foundation Enterprises Inc., and the author of more than 250 publications and presentations, including co-editor of the textbook ‘Public Health Informatics and Information Systems.’ He earned his Ph.D. in computer science and M.D. from Northwestern University, and was elected a fellow of the American College of Medical Informatics in 1989.
This is a guest post by John Rostern, Jefferson Wells’ Eastern Region Practice Leader for Technology Risk Management.
IT organizations spend billions annually on compliance-related projects. That includes hardware, software, external consultants and (sometimes) uncounted internal human resources. The underlying question, though, is whether compliance improves the overall level of controls and security within a company.
Several factors lead me to believe that may not be the case. At the top of the list is the very point-in-time nature of compliance. Take for example the Payment Card Industry Data Security Standard (PCI DSS). The various self-assessment questionnaires associated with PCI DSS provide testament to the described state of compliance at that point in time. Similarly, the required quarterly scans also provide a point-in-time view relative to specific vulnerabilities that may or may not exist.
While PCI DSS does provide for safe harbor in the event of the breach (if the reports can be subsequently validated), this does nothing to actually improve security. The same may be said for compliance with other regulations such as the Gramm-Leach-Bliley Act (GLBA) (15 USC, Subchapter I, Sec. 6801-6809).
The underlying issue is that compliance with regulatory standards such as PCI DSS and GLBA can lead to a “check the box” approach. In an era of concurrent constraints on budgets and increases in oversight, the temptation to find the quickest and least expensive way to check that box can be compelling. The checkbox approach can also hide the true state of IT controls and security in the organization. Having a report in your hand that “proves” your compliance provides little comfort in the face of an actual data breach or other security incident.
Another potential dead end is to become focused on point solutions and tools. The notion of the “silver bullet” tool that will solve multiple problems has existed throughout generations of information systems and technology professionals. The promise of many tools is unrealized due to incomplete or flawed implementations, or in many cases, lack of processes to support the use of these tools. At the same time, the effectiveness of the best of tools can be minimized by ineffective, poorly designed or missing processes and procedures. For example, the best user provisioning systems still require a regular review of entitlements based on job function. Without this basic “blocking and tackling,” users may accumulate excessive privileges or remain active on a system long after they have left an organization.
An effective IT controls environment encompassing the core tenets of information security — confidentiality, integrity and availability of information — must be viewed as a process. This paradigm also must include the elements of people and technology that combine with process to complete the picture. This provides the basis for a holistic approach to the design, implementation and operation of strong IT controls, rather than the desired outcome: compliance. This approach will provide the foundation for a strong controls environment, which in turn will help the organization to achieve and maintain compliance.
|John Rostern is Jefferson Wells’ Eastern Region Practice Leader for Technology Risk Management. He has more than 27 years of diverse experience in information systems management, architecture, application development, technology, audit and information security.|
This is the official blog for SearchCompliance.com. The blog will provide unbiased news analysis, strategies and information for IT professionals that manage IT compliance infrastructure and operations. IT Compliance Advisor will explore the tools and tactics readers need to understand to survive rigorous audits and assessments.
If you have questions, comments or suggestions about the content of this blog, please let us know at firstname.lastname@example.org.
Associate Editor, SearchCompliance.com