Historical data in  log files  has little intrinsic value in the here-and-now process of event response and mediation and compliance check lists have little direct value in protecting customers.
Software Associates specializes in helping medical device and healthcare vendors achieve HIPAA compliance and improve the data and software security of their products in hospital and mobile environments.
The first question any customer asks us regarding HIPAA compliance is how little he can spend. Not how much he should spend. This means we need simple and practical strategies to reduce the risk of data breaches.
There are 2 simple strategies to reduce the risk of data breach, one is technical, one is management:

1. Use real time detection of security events to  directly protect your customers. 
2. Build your security portfolio around specific threat scenarios (e.g a malicious employee stealing IP, a business partner obtaining access to confidential commercial information, a software update exposing PHI etc…) and use the threat scenarios to drive your service and product acquisition process.

Use real-time detection to directly protect your customers

Systems like ERM, SIM and Enterprise information protection are enterprise software applications that serve the back-office business of security delivery; things like log analysis and saving on regulatory documentation. Most of these systems excel at gathering and searching large volumes of data while providing little evidence as to the value of the data or feedback into improving the effectiveness of the current security portfolio.
Enterprise IT security capabilities do not have  a direct relationship with improving customer security and privacy even if they do make the security management process more effective.
This not a technology challenge but a conceptual challenge: It is impossible to achieve a meaningful machine analysis of  security event data in order to improve customer security and privacy using data that was uncertain to begin with, and not collected and validated using standardized evidence-based methods
Instead of log analysis we recommend real-time detection of events. Historical data in  log files  has little intrinsic value in the here-and-now process of event response and mediation.

1. Use DLP (data loss prevention) and monitor key digital assets such as credit cards and PHI for unauthorized outbound transfer.  In plain language – if you detect credit cards or PHI in plain text traversing your network perimeter or removable devices, then you have just detected a data breach in real time, far cheaper and faster than mulling through your log files after discovering 3 months later that a Saudi hacker stole 14,000 credit cards from an unpatched server.
2. Use your customers as early warning sensors for exploits. Provide a human 24×7 hotline that answers on the 3d ring for any customer who thinks they have been phished or had their credit card or medical data breached.  Don’t put this service in the general message queue and never close the service.   Most security breaches become known to a customer when they are not at work.

Build your security portfolio around specific threat scenarios

Building your security portfolio around most likely threat scenarios makes sense.
Nonetheless, current best practices are built around compliance checklists (PCI DSS 2.0, HIPAA security rule, NIST 800 etc…) instead of most likely threat scenarios.
PCI DSS 2.0 has an obsessive preoccupation with anti-virus.  It does not matter if you have a 16 quad-core Linux database server that is not attached the Internet with no removable device nor Windows connectivity. PCI DSS 2.0 wants you to install ClamAV and open the server up to the Internet for the daily anti-virus signature updates. This is an example of a compliance control item that is not rooted in a probable threat scenario.
When we audit a customer for HIPAA compliance or perform a software security assessment of an innovative medical device, we think in terms of “threat scenarios”, and the result of that thinking manifests itself in planning, penetration testing, security countermeasures, and follow-up for compliance.
In current regulatory compliance based systems like PCI DSS or HIPAA, when an auditor records an encounter with the customer, he records the planning, penetration testing, controls, and follow-up, not under a threat scenario, but under a control item (like access control). The next auditor that reviews the  compliance posture of the business  needs to read about the planning, testing, controls, and follow-up and then reverse-engineer the process to arrive at which threats are exploiting which vulnerabilities.
Other actors such as government agencies (DHS for example) and security researchers go through the same process. They all have their own methods of churning through the planning, test results, controls, and follow-up, to reverse-engineer the data in order to arrive at which threats are exploiting which vulnerabilities
This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

• Lack of overview of the the security threats and vulnerabilities that really count
• No sufficient connection to best practice security controls, no indication on which controls to follow or which have been followed
• No connection between controls and security events, except circumstantial
• No ability to detect and warn for negative interactions between countermeasures (for example – configuring a firewall that blocks Internet access but also blocks operating system updates and enables malicious insiders or outsiders to back-door into the systems from inside the network and compromise  firewalled services).
• No archiving or demoting of less important and solved threat scenarios (since the data models are control based)
• Lack of overview of security status of a particular business, only a series of historical observations disclosed or not disclosed.  Is Bank of America getting better at data security or worse?
• An excess of event data that cannot possibly be read by the security and risk analyst at every encounter
• Confidentiality and privacy borders are hard to define since the border definitions are networks, systems and applications not confidentiality and privacy.