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.