- Health Vault = Compliance
-
I don’t know about you, but for me it's a challenge to keep up with the health information of myself and family. If you haven't seen it yet you should check out HealthVault. The current version allows you to collect, store and share health information with your family.
Ask yourself these questions: When was the last time you got a complete physical? What was the name of that medication (which did not sit well with your stomach) that you were taking last year? Have your kids received all their immunization shots? To which foods does your son have an allergy? When did your kids get their last dental and eye exams? During that trip you have planned next summer, how will medical providers be able access your medical information back home? How are you making sure that your aging mother and father get the treatment that they need? Has your teenage daughter received the HPV vaccine? When was the last time you got a tetanus shot?
HealthVault is a place where you can keep track of health information such as this and share it with your spouse and family. What's more, with something called HealthVault Connection Center you can upload and store data directly from a range of devices such as weight scales, blood pressure monitors, blood glucose monitors and pedometers. Also, the data is very portable. For more information, see http://www.healthvault.com/Devices-Directory.htm?rmproc=true. HealthVault supports such standards as XML, HL7, the ASTM Continuity of Care Record (CCR), Clinical Document Architecture (CDA) and the Common Connectivity Device. The search portion of HealthVault permits you to search and find health information and then store it in a private HealthVault Scrapbook for future use. HealthVault even lets you store health records for your pets!
The best part of HealthVault is that you control who has access to your records. You can choose to share them with hospitals, doctors or other medical care providers. For example, see http://www.healthvault.com/hospitals/. I can view my medical records housed by participating providers and learn about my medical tests and test results.
To me, HealthVault is an example of a Microsoft GRC technology that goes beyond mere regulation compliance. It enables people to engage in better healthcare. It is effectively an extension of preventive medicine.
Knowledge is a powerful thing. A safe and updated storage of knowledge regarding the health of you and your family can help reduce health risks and health care costs.
Joe Scalone
jscalone@microsoft.com
- Regulatory Compliance Blogs again.
-
Welcome Back!
As a reader of this blog, I felt it was important to try and bring some life back to the site. So today we start to publish NEW content, about complex issues such as GRC!
Over the next several months, this blog will explore where and how Microsoft is addressing IT compliance issues and provide you with an opportunity to share your comments on what we're doing. In addition to this blog, I invite you to join us in discussion about OneCompliance in a newly minted Microsoft Connect site.
Microsoft Connect Directory (http://connect.microsoft.com/directory).
OneCompliance invitation code: oclm-X8PK-YVKH
The goal of this blog will be to provide you with high quality content, from great authors.
Those of you who have kept an eye on this site, thank you. Everyone else, I welcome you to the blog.
Frank
- Payment Card Industry Standards Updated
-
Excerpted from SANS NewsBites (see www.sans.org to subscribe):
--Credit Card Companies Update PCI
(8 September 2006)
The five major credit card companies, American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International, have formed the Payment Card Industry Security Standards Council, marking the first time all have agreed on a common framework for payment card security. Their first order of business was to update the current PCI Data Security Standard by providing instructions for implementing the requirements and clarifying the language, for instance, replacing vague terms, such as "regularly," with specifics, such as "annually" or "quarterly." The council's goal is "to enhance payment account security by fostering broad adoption of the PCI Data Security Standard."
http://www.zdnet.co.uk/print/?TYPE=story&AT=39282935-39020645t-10000019c
- Reaching Out to Individual Contributors
-
The most important but sometimes overlooked aspect of regulatory compliance is in getting the buy-in of the people who will be doing the work. Getting management buy-in is a pretty simple matter of discussing economics and the negative impact that non-compliance has on the business. ROI, cost benefit analysis, the impact of losses for fines, loss of consumer confidence, and other easily tangible negative financial impact is something that any manager can wrap their head around. The hard part is getting the message to the individual contributor who will be affected by any change process of implementing control objectives. Change is the hobgoblin of the individual contributors as change usually means disruption and chaos as the kinks in the process are worked out.
Once the control objective is defined and the process that will determine success for that control objective is developed, the individual contributor is responsible for its implementation. Some are easier for ICs to see the benefits and some are not. So the key to compliance adherence is two fold; communication and leadership. Most important, there must be a work to reward benefit to the individual contributor or the control objective becomes just another random management dictated task. One that is required for continued employment but not something that will allow for any sense of contribution or perceived benefit
The first key to compliance is to lead by example. No one in the organization is exempt from adherence to the control objective. This is the single greatest point of failure to any compliance policy because if the individual contributor senses that the policy only applies to them and not the rest of the company i.e. management, the policy becomes a bone of contention. Management has to forge a relationship based on trust to achieve compliance. Any perception that there is a double standard to compliance will have more negative impact than just lack of compliance to control objectives.
The next key is that selling compliance requires a benefit. The individual contributor needs to understand the benefit to their job or to the company as a whole for the change in their work habits to be justified. So the processes in the control objective should be created with some benefit to the individual contributor as well as to the company in mind. Some compliance processes and methodologies come with built-in benefits. The automating of some long standing manual process provides the individual contributor a tool to perform a task with a predictable outcome. This makes the job of the individual contributor easier. Making the individual contributor’s job easier and more predictable is a benefit that is an easy sell.
Not all automation is perceived as being good or beneficial however to the individual contributor. Everyone has seen how automation has led to downsizing or to the diminishing value perception that some individual contributors can get. Rather than reverting to a bully pulpit approach to regulatory compliance as part of your company’s framework, each control objective should be a well thought out process that provides tangible and attainable benefits to both management and to the individual contributor. Where there is no tangible benefit, the communication must be clear as to why this is important and how this benefits the company and then in turn benefits the individual contributor.
Auditors rely on repeatability to ensure tasks are performed in a way that each iteration is a part of a complete compliance picture. What tasks that can not be automated must be performed in a prescriptive manner where the results are predictable. Such adherence requires more than direction, it requires an understanding of the task and an understanding of the expected results. This understanding has value to the organization and needs to be cherished in a way that the individual contributor continues to feel valued. Pressure to adhere for compliance sake will be met with indifference because the understanding of the task and its results will be used to the individual contributor’s advantage and not the advantage of the compliance effort. So there has to be a compelling value proposition that will get ICs to want to help contribute.
The lynch pin between the individual contributor and the compliance effort is the front line manager. Communication with this level is crucial to any compliance policy implementation or change success. This is where the value proposition wrapper must have buy-in and where creativity for implementation must be fostered. Getting rank and file to adopt new processes effectively to achieve compliance must come from a level of cognitive awareness of the importance that compliance provides the company. So what front line managers will need to provide is the reinforcement of how the compliance benefits the individual contributor’s position, how the control objective provides them benefit, and how the change streamlines their work effort. The key to success at this level is not just dictating compliance but providing value to their job. The obvious dissention is that not all compliance control objectives will be a positive change on their work effort. In these cases compliance will need to be well communicated as to why this is necessary, the actual benefit value of the control objective to the company, and to enlist their feedback to develop a better way to achieve success in each control objective. Action on this feedback is critical as this is the measure the individual contributor will use to gauge how management views their contribution.
This may sound a bit contrite and on the surface I would say that it is. However, any control objective that is worth implementing is worth the effort to gain compliance at the individual contributor level. Implementers should be willing to take the time and effort to plan for compliance adherence by including this value proposition to the individual contributor. These are the constituents that will be ultimately responsible for compliance even if the control objective is as simple as logging out of their computers, locking their desk and file cabinet, and lock their office door before leaving as part of a change to the company’s asset security policy. The benefit to the individual contributor is that this provides that their work space will be as left it and that company assets which is their work, are protected.
Mark Eden
- A Sustainable Spreadsheet Compliance Framework with Excel 2007, Office 2007 and Office SharePoint Server 2007
-
Spreadsheets are ubiquitous. For many organizations they are a critical resource and essential to business processes. With Office 2007 and Office SharePoint Server 2007 it will be much easier to maintain a sustainable spreadsheet compliance framework.
Office 2007 and Office SharePoint Server 2007 will provide some key capabilities that will assist greatly in the compliance effort:
- Preventing unauthorized access to spreadsheets, with such things as Office SharePoint Server 2007 permissions, Excel Services (Excel on the server), Information Rights Management and Workbook Encryption.
- Managing and monitoring spreadsheet changes with Enterprise Content Management.
- Retaining and archiving spreadsheets with Office SharePoint Server 2007 Record Repository.
- Developing robust spreadsheet models with cell styles, cell locks, Excel tables to reduce errors, defined names made easier with Name Manager and formula auditing tools (e.g., great graphical representations of relationships between cells and formulas).
Especially helpful are the workflow and auditing capabilities of Office SharePoint Server 2007. Spreadsheets can be set up for review and approval before being available for broader use.
Just another example of Microsoft technologies helping users to become compliant. Check out the Spreadsheet Compliance in 2007 Microsoft Office System White Paper: http://www.financialdevelopers.com/assets/ExcelRegulatoryWhitePaper.doc
Joe Scalone
- Auditing Rant!
-
I am seeing a disturbing trend in the industry and I am going to complain. Over the past few months, I have seen requests for clarity for SOX compliance auditing from IT managers through their contacts at Microsoft. Questions are being posed by these contacts asking for clarification of a particular finding from a SOX security audit. Each of these is creating a disturbing trend and are all following the same pattern. Each request is where an “independent security auditor” that was contracted for a SOX compliance audit and has used a tool as a part of their audit effort that had returned what it perceived to be a problem with the customer’s security environment in the form of a registry setting incorrectly being set or some other esoteric security configuration setting problem. This was exposed as part of their SOX compliance audit being done by this independent security auditor.
This is just wrong on so many levels. While security is a part of your SOX compliance picture, it has nothing to do with your ability to comply with this regulation. Your ability to prove your compliance has nothing to do with a pen test. If your CIO has decided that this is a part of a SOX audit, it is your duty to help them understand that it is not. Just because their business card says Independent Security Auditor followed by SOX, GLBA, HIPAA, and any other regulation does not mean that they are certified for this work. As a matter of fact, my guess is that they do not know what certification is for these. A CPA is required for SOX, certification from FDIC is required for GLBA, accreditation by HFCA is needed to ensure HIPAA, and VISA/MasterCard is needed for CISP/PCI. While a CISA or a CISSP is a good thing to have for a security audit, it is not certification to determine compliance with any of these regulations.
My concern is that there are consultants that are doing compliance work for these regulations without a clue of what they mean or what real regulatory compliance means. If you are an IT Manager that finds themselves in a situation where the compliance auditor is doing a pen test of your environment, this is a Red Flag that you will not find yourself able to prove regulatory compliance when you are audited by that regulatory body. The right things are to inspect your common control framework and to see proof that you are doing the things that make you compliant.
This is not to say that a security audit is not helpful in determining whether your current security practices are meeting the demands of your own control objectives. Just be sure you know what you are paying for. That security audit is not going to get you far with your CPA when it comes time to prove that you are SOX compliant.
- Break Down Regulatory Complaince Into Manageable Steps
-
Are your regulatory compliance (RC) policies being followed the way you expect them to be? Helping employees comply may be easier if your RC implementation is broken into manageable steps. JC Cannon provides some excellent advice for breaking down the complexity of RC implementation into steps:
- Determine where to focus your compliance efforts.
- Use procedures that validate compliance.
- Consolidate the management of compliance.
- Create compliance policies using a hierarchical approach.
- Decide to automate compliance processes.
- Choose compliance-enabling technologies.
Security Management - June 2006 Achieving Compliance
Joe Scalone
- Microsoft release the Regulatory Compliance Planning Guide
-
Yesterday, Microsoft released the Regulatory Compliance Planning Guide. This guide is available at http://go.microsoft.com/fwlink/?linkid=56114.
The Planning Guide:
- shows IT professionals how they can use an IT controls framework to help address IT compliance requirements,
- includes a mapping of several significant regulations and standards, including Sarbanes-Oxley Act (SOX), Gramm-Leach-Bliley Act (GLBA), and Health Insurance Portability and Accountability Act (HIPAA) to a sample control framework, and
- directs customers to Microsoft software and solutions that can help them address their compliance requirements.
The guide is available for online viewing and as a download.
If you have any questions or comments about the guide, please email them to secwish@microsoft.com.
- The "F" Word
-
The word is framework, of course. What did you think?
It is important that we establish some way of defining the processes we are going to use and where they fit into the overall schema for our enterprise. I am not going to say that you should adopt my framework! I am going to say that you should build your own. Make the framework you choose fit your enterprise and the goals of your Regulatory Compliance effort. This is your solution that is built on the corporate strategy that you as the IT Manager work out with your Executive Management committee and the Regulatory Compliance Office or Officer.
I am going to start with a process circle. I am sure that you have seen one of these, well if you poke around Microsoft sites you have seen several. Microsoft has them for MOF, MSF, and other iterative operational functions. Remember, Regulatory Compliance is not an exercise in time where at the conclusion we are done forever. Regulatory Compliance is a never ending process to introduce new regulations and be able to document the remediation activities. Below is the Shewhart Circle for Learning and Improvement. This is a nice generic circle that has been with us for a while. All it does is to set forth four stages of activities to validate the idea to implementation process. We plan the plan. We devise a way to remediate the regulatory requirements. At this point we are also seeking approval for the change. We then act on the plan. This is to check the validity and to test how well we think that the plan will effect the needed change to accommodate new regulation. We test on a small scale before deploying on a broad scale. We study the results from the act phase. This is where we look at how this is really going to impact the environment and whether it is really going to accomplish the remediation. Then finally we implement the plan. We then reiterate the cycle.
From this basic process circle we can begin to devise our own Regulatory Compliance Roadmap and Framework. The first step in regulatory compliance seems to be to identify the control that we need to establish in response to a change or to new regulatory requirements. This is done with the help of other people in the organization like the compliance officer and the Executive Committee. Once the problem has been identified, we can move forward with the remediation process. Below are process steps in an outline. All of these steps take place in the planning stage.
Compliance Planning Roadmap
1) Scope and plan for the remediation.
a. Define the requirements.
b. Identify the systems to be added, changed, or deleted.
c. Identify all supporting systems.
d. Define documentation and reporting.
2) Assess Risk
a. How are we vulnerable?
b. What are the probability and impact factors?
c. Determine size, difficulty, and complexity of risks.
3) Identify control objectives added, changed, or deleted
a. IT Function Controls
b. Application Controls
4) Documentation of Controls
a. Policy documents
b. Configurations
c. Processes and Procedures
d. Flowcharts
e. Discussions
f. User Feedback
5) Evaluate Operational Effectiveness
a. Remediation achieves risk control objectives
b. User Acceptance
c. Meets Auditory Requirements
d. Identify and remediate control deficiencies
6) Evaluate Sustainability
a. Model sustainability to different department requirements
b. Test for acceptance
7) Plan to document process and results
a. Auditor acceptance
b. Internal Signoff
At this point we should be ready to act. We can test our plan in a controlled environment. This is the common pilot program for a small control set of users. It is very important to gather lots of data from this pilot program. This allows us to able to test our plan and determine whether we have reached the expected level of compliance. We can gauge user acceptance and also make sure that we are gathering the right documentation to prove that we are reaching the right level of reporting to prove compliance. After we have tweaked our plan from the data gathered in the prlot program, we are ready to deploy or as our circle calls, do.
From this example roadmap, we are ready to map our requirements through the risk management and remediation frameworks that are available for us. Through these environmental frameworks we can map the remediation to the service management function responsible in the organization for the different parts of its implementation and maintenance. Change Management would need to determine how the change would be implemented and recorded. Security Management would be responsible for making sure that the remediation fits the overall security posture of the organization. Program management would be responsible for defining how the change would be implemented and what resources would be required. Audit management would determine how to report the remediation and how to collect the reporting data. There are other service management functions what would also need to accept responsibility for their part of the enterprise environment.
These service management functions map into the different operations frameworks which are listed below as Risk Management and Remediation Frameworks. Risk management and remediation functionality are ancillary outputs of operational precision but are integral to the success of each. ITIL is the Information Technology Infrastructure Library which defines a vast majority of IT functions each of which contribute to overall risk management. COBIT which we discussed previously deals with IT Governance and in turn risk management. MOF/MSF are Microsoft operational and program management frameworks that are more product specific. ISO 17799 is a framework for security management. COSO is an auditing frame work for Certified Public Accountants that defines essential Enterprise Risk Management components. While not directly Information Technology focused, it does link directly into established ERM targets that auditors and executives readily understand and already adhere to. Common Criteria is the U.S. Government’s standards for computing. All of these provide predefined methodologies to approach aspects of IT functionality that enable IT Managers to achieve operational precision and in turn regulatory compliance through risk management and remediation.
The final piece here is the mapping of the different regulatory requirements into the proper operation framework that will align a risk management activity to satisfy that goal. For example, HIPAA has a requirement for document retention. Document handling functions are described in ITIL and MOF. In ITIL and MOF the operational process of handling documents. COBIT defines control objectives for document handling to comply with legal requirements. ISO 17799 defines security goals for document handling. COSO provides auditing standards on how to define and report our document handling process as part of enterprise compliance. Common Criteria provides examples and guidance from the government for document handling. Each of our Service Management Functions has its role in how we classify documents; how we access documents, how we store documents, how we transmit documents, and finally how we destroy documents. The Document Management service function of course is responsible a large chunk of the execution of this functionality but Security Management will define the security requirements for document handling. Change Management will define how document handling is implemented and how changes will be applied to the process. Program management will define how the document handling program is run. Audit Management will define how we report our document handling processes and compliance. All of these functions will then become the document handing process.
This compliance roadmap and framework are intended to act as an example of how you would go about implementing your own regulatory remediation framework. As you can see that this is not rocket science but it is a start to a thorough analysis of the requirements and remediation steps needed to reach your regulatory goals. The longest journey starts with the first step.
- Don't Panic
-
Addressing the caveats of regulatory compliance is like approaching any other risk. We will look at the risk and then we will develop a plan to mitigate the risk. Sounds simple, right? Good, because it really is as long as we know what we need to do. Yes, there are serious consequences for non-compliance but in the words of Douglas Adams, “Don’t Panic!” So, grab your towel and we will find our way.
What these regulatory statutes require is having business processes in place that address operations policy, security policy, and regular audit data that supports that your actions. The key is that we have controls in place that eliminate the chance for mistakes or allowing malicious actions. We need to align the specific actions that are associated with the different regulatory statutes and then we can map these into our IT security and privacy framework. There is that framework thing again.
There are several auditing frameworks out there but the most well known is COBIT or Control Objectives for Information and related Technology. COBIT provides a clear and easy to follow framework that fits nicely into the ITIL framework. And Microsoft’s Operational Framework is based on ITIL. It is pretty easy then to create a set of processes to address the compliance caveats. Another neat thing that COBIT does is it gives us a rating system that we can use to measure our effectiveness. These metrics can then be used to create our IT security and privacy scorecard.
There are benefits to identifying Control Objectives for your IT organization. The first benefit is that auditors like automated processes, so you can identify all the inefficient manual processes that are in place in your enterprise and get your management’s buy in to replace these with automated processes. Whether it is provisioning users, creating standard system builds, or just establishing a central repository for log files this is your opportunity to automate. Sure this is going to cost money but the value proposition is that you will be more compliant. You should now feel empowered to go after these as long as they fit the IT control and privacy policy.
This should also help you standardize your systems hardware because to lower the number of standard builds you are responsible for to control costs the fewer number of builds you will need. While this creates its own set of concerns your life just got better and you lowered your stress level. Something else a standard build allows you to do is to lower your help desk costs by allowing you to establish a policy of imaging a system after an unsuccessful attempt to correct a problem. Have the user save their data off of the target machine, re-image the box, restore the users data and you are done. The users can get back to work quickly. But you are already doing that, right?
Back to Control Objectives, this term describes the effort to fulfill a regulatory requirement. Several regulations may require you to control and report for the same thing, such as defining how to control your desktops. Inside this objective might be strategies to satisfy several independent requirements. If you actually enjoy the pain you are welcome to read each regulation but you can take it from, me there is a lot of overlap. Inside these objectives we will satisfy questions like who will have access, what information is needed to perform the task, and is the user’s machine compliant. Now we can start to think about the control solutions we can establish to address these questions.
A couple of weeks ago, Joe Scalone did a really good job of pointing out which Microsoft technologies can be used to address the requirements that would come from creating a Control Objective. The technology solution defines how we will use the technology to satisfy the requirement. This becomes the process that we need to fulfill the caveats of our IT control and privacy policies. These automated processes are what we use to demonstrate to the auditors that we are meeting the caveats of the requirements that are in each regulation.
So Regulatory Compliance is security management, operational precision, and a good measure of common sense in developing these processes. If you were worried about trying to make sense of all of this, I don’t think that you should spend your time reading the text and interpretations of Sarbanes Oxley. Instead you should spend your time reading about COBIT and some of the other auditory and operational frameworks. Building a framework for your IT operations is more valuable than trying to determine what requirements you will have to meet for a single regulation. I have included a few links below to help. You can also use the MSN Search to find more. .
COBIT
http://www.isaca.org/cobit
Mark Eden
- Regulatory Compliance Planning Guide Beta Coming
-
Just a heads up that Microsoft soon will be making available a beta version of a Regulatory Compliance Planning Guide that my team (Solutions for Security and Compliance) is developing. This guide will help readers understand the types of controls that they need to address for five common regulations and standards. In addition, it will point readers to various Microsoft technologies, products, and solutions that can help address those control requirements.
The beta document will be available on Download Center toward the end of this month. I will post the link when the document is ready for download.
Bill Canning
- Regulatory Compliance and the IT Manager
-
There are a lot of legislative bodies that are requiring IT to protect information for different reasons. It would appear that IT Professionals now need to add paralegal to their repertoire as we address some of the new challenges to defending the enterprise from those that would do us harm. This should not actually be the case nor should IT bear the entire burden for regulatory compliance within an organization. Whether action needs to be take to address some new piece of legislation does not belong on the head of IT, this needs to be a business decision made by the business. This does not mean however, that IT should stick its head in the sand either.
Regulatory responsibility sits in several places within the business. In a perfect world each company would have its own regulatory committee, whose responsibility it is to determine what regulatory legislation the organization is responsible for and what regulatory measures are required to satisfy those needs. It is then that IT can identify how these regulatory requirements impact the protection of electronic assets associated with these regulations. My concern is that within many of the customers I work with, much of the regulatory compliance work is dumped on IT as IT becomes the place where these activities reside and because most organizations do not have a committee to evaluate the regulatory impact on the business. To any IT Professional who allows this to happen, I say “Shame on you!” The real problem is that IT Professionals are trained to be technically savvy and not business savvy.
Now, before you drag out your club to smack me out of frustration, lets looks some things that IT can do to alleviate the pain associated with being left to hold the regulatory compliance bag. For whatever part of regulatory compliance that IT is held accountable for should come from a conscious decision of the business that the risk of non-compliance is not acceptable and that there is an executive decision to allocate the resources to satisfy the mitigation of that risk. This cannot be where some IT Professional read Sarbanes-Oxley and decided that measures X, Y, and Z are appropriate. This is just wrong on so many levels.
While IT is where the preverbal rubber meets the road for many of these compliance activities, the responsibility should not reside solely within IT. This is where an operational framework can provide a lot of help. Instead of creating a whole new stratum of compliance management, it does make sense to leverage the management functions that are already defined in the organization that are tasked with risk management and auditing compliance management. After all, this is at the heart of regulatory compliance. Compliance is all about being able to prove that your organization has assessed the risks of and is meeting the caveats set forth in applicable legislation.
The first and foremost part of any regulatory compliance plan is executive commitment. The executive committee must consciously embrace the notion that regulatory compliance is a necessary part of daily business activities. They must also be aware that there is a cost associated with these activities. This will in turn spawn some sort of reporting process back to the executive committee which will require a focal point in the business for regulatory compliance. Most companies have already taken the first step which is creating a Chief Compliance Officer or at the very least a Chief Risk Officer or Chief Security Officer. Most of these positions are tied to the financial part of the business because financial officers have traditionally borne the burden of proving the authenticity of the financial statements that get submitted to the different regulatory bodies that scrutinizes proper business ethics. These are the people that IT should engage with to identify the risks for the business that are in any regulatory legislation. This should be easy as most companies are structured where the CIO reports to the CFO. The financial organization has traditionally been where risks to the business are assessed.
The establishment of this responsibility chain does several things for IT. It establishes a path to identify what risks should be mitigated. It establishes an approval process where mitigations to risk can be chosen in a way that fits the existing environment and satisfies the regulatory commitment. It defers responsibility for compliance out of IT and spreads the responsibility across the organization. It establishes a regulatory compliance process that fits into existing operational frameworks like ITIL and MOF. And lastly, it takes the IT Manager out of the hot seat for compliance.
Mark Eden
- Contributory Compliance Technologies
-
A problem for regulatory compliance document and data management systems can be employee subversion, whereby employees try to find ways around the hurdles in the management system. They might create their own local copies of documents or spread sheets, create unauthorized shares, or print or redistribute private documents. If you put yourself in the shoes of the workers for a moment, you can hardly blame them. Complying with strict document management rules can be inefficient (for such things as editing and approval), cumbersome (because of difficulty locating files across applications and databases), disruptive (with regard to enforcement of check-in and check-out and versioning) and disjointed (due to lack of integration with other systems). Knowledge workers tend to follow easier, less bureaucratic, workflow paths, even if compliance rules are otherwise violated. These issues can be exacerbated when you mix in things such as cross-group collaboration, outsourcing, and international virtual teams. As companies grow larger and more complicated and work teams go beyond company boundaries the challenges to compliance regulation can be daunting.
Of course technologies such as Active Directory, Information Rights Management, Rights Management Services and The Microsoft Office System can be used to lock down documents and prevent many of the employee compliance skirts. With SharePoint (part of the Microsoft Office System), for example, permissions can be easily set by office workers for access to documents by other office workers. Documents can be checked out, edited and checked back in. Security groups can be created in Active Directory and then used to set broad strokes of permissions to those using SharePoint.
Still, the proverbial stick is only part of the answer. Office workers need carrots also. They need to be motivated to work together, and to comply with regulations because they want to do so. Motivation is increased if the regulatory compliant workflow path for workers is a naturally easy one for them to follow. Part of that motivation can be supplied by technologies that, while not strictly speaking are regulatory compliance technologies, can be thought of as “contributory compliance technologies”. SQL Reporting Services and Microsoft Live Meeting are such technologies.
Live Meeting helps employees come together to discuss the use of documents and data and to visually see how another employee or group is using similar documents or overlapping data. It permits divergent teams to collaborate and agree on document usage, enhancing personal trust between employees and groups. Shared goals (and matching metrics) can be agreed upon and memorialized in a document, and then revisited during regular meetings between group representatives. Checkpoint meetings along the path of the usage of documents and data can not only help confirm that the agreed usage is on track, but also provide an outlet for expression of desired changes in usage. The immediate interaction during a short meeting via Live Meeting can expedite negotiated agreement as to the proper usage of documents and data circumvent what might otherwise be a time-consuming process.
SQL Reporting Services helps employees share goals. One of the best ways for a group to collaborate with other portions of a business, or with other businesses, is via shared goals. When a group identifies goals of another group and helps that other group attain their goals, very often the other group reciprocates. What then happens is that the goals of each group partially become the goals of the other. To some extent there is a perceived overlap of goals, or “shared goals”. Reporting Services provides reports that give transparency to the usage of secure data across groups in a scalable but targeted and appropriate manner. This helps eliminate the perceived need of some employees or groups to do things like keep multiple local copies of spread sheets. Reports can be easily created, tailored and provided to an intended audience. Sometimes it is a matter of modifying the nomenclature or taxonomy of one group slightly to more easily align the goals of two groups and compare apples to apples. Common threads in data can be identified by data base administrators, and the appropriate reports derived there from, in a secure and scalable manner, and with the appropriate intended audiences.
In terms of governance, a continuous discussion among employees and groups of shared goals that are given transparency by way of reports is a very beneficial way to manage changes in a dynamic environment. Those who lead or monitor compliance efforts should encourage the use of contributory collaborative technologies, such as Live Meeting and Reporting Services, in order to make the sometimes difficult practical constraints of regulations easier for employees to naturally follow and to keep ever far reaching teams on track.
Joe Scalone
- Regulatory Compliance is a Treasure Trove of Value
-
Regulatory Compliance (RC) is a treasure trove of value. From better business intelligence to improved security, the benefits of RC abound. The key is to understand the payback and how to get it. It is a mistake to view costs of RC as greatly outweighing the benefits. Aside from the overarching societal benefits from corporate accountability there are abundant economic and business benefits for those companies who choose to harvest such fruit.
Let’s take a look at one aspect of business value and how RC might promote it. Of enormous value to a company is the identification of that company’s optimal economic denominator. Author Jim Collins, in his book “Good To Great”, has posited the question this way: “What is the economic denominator that best drives your economic engine (profit or cash flow per ‘x’)?” Companies who have answered this question correctly have had great success. Ask yourself: “Is what best drives my company profit per customer interaction? Is it profit per customer, per customer visit, per employee, per product, per store, or per any one of hundreds of other possible denominators?” This is a hugely important question that is not easy to answer. Collins points out that in some of the best companies there is healthy vigorous debate about the correct economic denominator.
Now image that you had in front of you a set of charts that plotted profit per a hundred different denominators over the life of your company. Wouldn’t the decision about which economic denominator be easier to answer? Wouldn’t it be interesting to see which denominators produced optimal results during those times at which the company was doing the best? Think of a time when your company was doing very well. Do you know for certain which denominator was out-performing all others at that time?
At this point you might ask, “What does this have to do with regulatory compliance?” It has everything to do with RC. RC efforts do not have to be, and should not be, a knee jerk reaction to another regulation. Truly authentic solutions to RC challenges will be built on a solid groundwork that includes the selection of a robust and extensible platform, and a framework that can easily integrate with current mechanisms, but also easily meet change requirements, in a manner that is repeatable and sustainable over the long term. Such a platform and framework not only make regulatory compliance much easier in the long run, but provide the basis for discovering and mining other business value. Providing short-term reactionary answers to the demands of one regulation will not solve the RC problem, nor will it provide anywhere near the long term benefit available for the taking. RC is an opportunity for a company to build a software infrastructure and control framework that not only “does RC”, but also lays the underpinning to provide much better answers for questions like “What is our best economic denominator?” RC is the aegis for accountability, but accountability is not a one-way window through which only auditors can see. If a company is true to itself, to its own mission, it can turn that accountability inward and reuse the same infrastructure to answer serious economic questions that might never have been answered before. Perhaps a company has not documented its processes, or it doesn’t keep good track of its employees, or doesn’t know very much about its customers. The actions that such a company takes to become compliant can help it better document processes, track employees and understand customers, and at that same time take a substantial step toward answering questions like “What is our optimal economic denominator?” This is what makes Regulatory Compliance (RC) a treasure trove of value.
Joe Scalone
- Paper Harmonizes COBIT, ITIL, and ISO 17799
-
ITGI and the UK government's Office of Government Commerce (OGC) have released a paper that shows how ITIL and ISO 17799 can be mapped up under the COBIT framework. This seems like a valuable thing to me, since one of the main complaints about COBIT (from an IT manager's perspective), is that it is not detailed enough. By mapping ITIL and ISO to COBIT, more detailed guidance is provided for the two very important parts of the framework: security and operations.
You can learn more about this paper at ISACA's website. The URL is: http://www.isaca.org/Template.cfm?Section=Home&CONTENTID=22493&TEMPLATE=/ContentManagement/ContentDisplay.cfm
