There are two generic approaches to "compliance."
One is merely to "comply" - by creating a facade that addresses the specifics of compliance without systematically addressing the forces that gave rise to the compliance requirements. In the USA alone, a large company could simultaneously be building facades to support, for example, Sarbanes-Oxley, the Patriot Act, export controls, employee privacy, patient privacy, credit reporting privacy, Environmental Health, Safety and Environmental controls and reporting, tax collection and reporting and many others. Achieving passable situational compliance is certainly a must-do, but probably not sufficient.
Although perhaps not always feasible, an important objective is - or should be - to make compliance "free" by having the enforcement functionality enhance business processes. (Borrowing this definition of "free" from TQM is not much of a leap, because TQM itself is in a sense "compliance" - but focused on customer requirements). One should approach compliance needs with a proactive, opportunity-seeking perspective that deals holistically and "architecturally" with the fundamental forces at work. In that context, compliance measures are more likely to address not only "minimum" requirements, but to do so with substantial reuse across different compliance protocols and with forward-looking preparation to address emerging requirements.
Compliance is a matter of achieving suitable intersection between "facts" and events - "who, what when where and why" - and rules and objectives. If the speed limit is 100 kilometers an hour (or 60 miles per hour), the "fact" should be that you are going no more than that speed. Note that those creating compliance requirements more often express them in terms of outcomes rather than means. If you are driving at or below the prescribed speed limit because you are continually stepping on the brakes to offset your excessive pressure on the accelerator, your means are inefficient but the result is what is required. You of course really want to be both compliant and efficient.
Compliance therefore usually requires value-added process design and supportive rule-making. Typically process design (or redesign) would be done by a compliance team - not to be confused with the regulators that created the "speed limit" or other regulatory requirement. Many compliance requirements can be satisfied by the creative implementation and verification of improved business practices, so having a strong team to design the "how-to's" of compliance is important. Conversely, "normal" innovation to streamline business processes provides an opportunity to improve compliance, presuming the innovators proactively making the innovation "compliance friendly."
Importance of Workflow
Whether automated or not, some form of workflow usually is needed to provide systematic authorization and filtering. Workflow is also a potential source of "win-wins" in which both compliance and efficiency improve.
For example, if someone is violating "need to know" - e.g., with respect to privacy rules, he or she (or it, if it is a process) is almost certainly is also wasting time and money as well. Therefore, if "need to know" filters are simultaneously facilitated - to focus the individual on information that he or she genuinely needs - and constrained, we create a win-win situation with respect to both efficiency and privacy/security. See need to know for further information on this subject.
There are other compliance requirements that can be addressed through proper workflow, including inter-entity workflow. You perhaps should not do something -e.g., send a certain package, provide or obtain information, create an order, perform a system change - without proper communications and relevant approval. For example, in the case of sending a package, you should have approval from both the sending and receiving side. Although implementing workflow is challenging, it is good business as well as "compliance-friendly." Two-party workflow is even more challenging, but also opens up some very important compliance-friendly opportunities. Implementing two-sided workflow is not the impossible dream: see the OBI model - open buying the internet.
One source of both regulatory and business nightmares is the use of "naked" horizontal applications - notably email and word processing applications - as both the source and retention environments for various "transactions" and commitments - proposals, contracts, orders, acceptances, etc. Instead, these transactions and documents should be generated by and retained in the applicable workflow and transaction systems. The same personal productivity tools can be used, but "clothed" in a workflow environment. One major, rarely identified payoff from implementing a "service oriented architecture" (SOA) is to create dynamic joins between the horizontal and vertical application worlds.
Working from stale, incorrect or incomplete information is often the root problem hindering either compliance implementation or compliance validation. It is of course also bad business. The infrastructure needed to have the information needed and, at least as important, the ability to access that information is described in several contexts. The environment page and several subsidiary pages are described some of the IT capabilities to be exploited. Rationalizing and simplifying data is described in data bucket reduction. Dynamically linking to additional data sources - internal or external - is described in modes of using XML.
If one weaves these and other capabilities together into effective business processes, compliance emerges as a natural byproduct. If you have need-to-know filtering, workflow internally and with partners, trustworthy, "portable" data that traces back to source information, and dynamic links to sources of "truth" using web services and SOAP (simple object access protocol), you have the makings of verifiable "compliance."
There are some high-visibility compliance topics which are beyond the capabilities described, primarily those involving unstructured communications such as email and instant messaging. One very important compliance measure is to transform some of those processes so that email and IM communications (and plain old paper) are being generated by applications rather than freehand on keyboards - without impeding the effectiveness of the communications process.
Note that almost everyone is not only subject to compliance requirements, but a creator of compliance requirements. With respect to non-governmental creators of compliance requirements, see the Market Subset of the Command Economy.