Information technology

Podcast: HITECH Act adds new compliance requirements, penalties

The Health Information Technology for Economic and Clinical Health (HITECH) Act, sometimes referred to as “HIPAA2,” introduces new compliance requirements, penalties and incentives for the adoption of electronic health records. In this podcast from SearchCompliance.com, privacy expert Rebecca Herold talks with associate editor Alexander B. Howard about the HITECH Act and its implications for compliance and information security professionals.

 

 Podcast: HITECH Act adds new compliance requirements, penalties [26:01m]: Play Now | Play in Popup | Download

When you listen to the podcast, you’ll learn the following:

• What is HITECH?
• What is generally required by HITECH?
• Who is affected by HITECH and its compliance requirements?
• What is the role of information technology in HITECH?
• What are the penalties for noncompliance in HITECH?
• How does HITECH differ from HIPAA?
• How will HITECH change electronic health care and the jobs of health care CIOs?

Herold is an information privacy, security and compliance consultant, and a frequent contributor to SearchCompliance.com. You can read her blog at Realtime-ITCompliance.com and follow her on Twitter at @PrivacyProf.

Herold’s recent work at SearchCompliance.com includes:

• HIPAA enforcement getting stronger
• HIPAA criminal convictions outpace sanctions
• HIPAA enforcement, more government audits leading to more convictions

How do you align an IT risk assessment with COBIT controls?

[One of our readers, compliance officer Ramon de Bruijn, wrote to the editors of SearchCompliance.com at editor@searchcompliance.com last month looking for some advice. Specifically, he asked "What is the best way to implement a risk assessment in an IT department that aligns COBIT controls with risks?" In her first post for IT Compliance Advisor, Sarah Cortes, PMP, CISA, provides an answer to his question. -Ed.]

Implementing a risk assessment that will align the COBIT control framework with risks is a valuable undertaking and a smart way to approach the challenge. If approached with a working knowledge of COBIT, it should take no longer than any other risk assessment approach.

In the long run, it will likely shorten the overall cycle:

Risk assessment -> Recommendation -> Solution implementation -> Audit

This is because COBIT can provide a thorough checklist of potential risk areas that might otherwise be missed, requiring multiple passes or potential wasted effort implementing solutions to lower-priority risks, while ignoring those with a higher priority.

One thing to keep in mind is that COBIT controls are not just “in an IT department.” They include controls for business interruption and other business problems that have traditionally fallen to IT to deal with, rightly or wrongly.

The first step is to obtain a copy of COBIT controls, which you can do from ISACA.org or other sources on the Web.

The second step is to provide education, if necessary. Make sure key individuals in your organization have heard of COBIT and understand it is an internationally accepted standard. No need to worry anyone will know it better than you. Even auditors and CISA professionals can achieve only a moderate level of memorization of all aspects of COBIT. COBIT changes all the time. Technology in some areas moves beyond it in areas. In general, COBIT is too far-reaching for even the most seasoned IT professional to avoid re-reading and referring to it frequently when working with it.

After obtaining a copy and getting buy-in, the third step is to put it away. You need to ask yourself and others where the known risks to IT and business lie. This bottom-up approach is critical to avoiding “over-COBITING,” a common affliction.

Once you have carefully listened to IT professionals and others with respect to control weaknesses and the risks that actually “keep them up at night,’ you are ready to pull out your COBIT framework again. Review a fuller set of risks with those same individuals. See if that uncovers risks they may have missed the first time. This checkpoint is one benefit of COBIT.

Finally, you should document your risk assessment and note areas listed in COBIT that individuals in your organization did not consider worthy of note. Each COBIT area should be covered. If the risk included in COBIT is not prioritized in the risk assessment, a specific reason should be noted, along with the individual who decided to assume or dismiss that risk. This will come in handy later, trust me.

If you follow these steps, you will be further ahead than 99% of professionals and IT departments in your shoes. Good luck, and happy documentation!

Sarah Cortes is a senior technology manager with extensive experience in all aspects of delivering information technology systems and services to Fortune 500 firms in the financial services industry, as well as biotechnology, media and higher education. Sarah Cortes has managed numerous major Code Red business and system interruptions, including the 9/11 failover of trading, accounting and other critical business systems during Marsh McLennan’s WTC data center collapse. You can learn more her work at InmanTechnologyIT.