Now that 2012 is here, and with the threatening prospects of the Mayan calendar looming, it is only natural to think about the state of the industry.
If you are sitting in the small and midsize (SMB) space as one of the more than 99 percent of U.S. employer firms, you are likely wondering how it is that so many regulations can be met without crushing your business. Certainly, there must be a better way to get a handle on the seemingly endless parade of audit-based fire drills. Even more importantly, what is the point of all these compliance activities? Whose risk are you really managing?
In looking at the drivers for many standards and regulations, start with a fairly objective view of just who is managing what risk. The Payment Card Industry's Data Security Standard (PCI DSS) provides a very ready and interesting point for analysis.
What is the objective being sought by the PCI Council? Is it to reduce your risk or theirs? PCI DSS is an active risk management tool for the payment card industry, in which you, the merchant, are part of the threat. They do not exist without the merchants, and yet they experience significant pain if their merchants do not protect PCI-owned data.
If you look at other regulations, you will see a similar effect. Sarbanes-Oxley, Gramm–Leach–Bliley, HIPAA/HITECH, and so on -- these regulations are all designed to manage what is perceived as risk to consumers and government, not to protect the businesses that are the targets of such requirements.
If you understand this point, you are then ready for the next question: Just whose risk are you trying to manage? The answer, sadly, is that a compliance-driven organization is not managing its own risk so much as risk that is "owned" by business partners, consumers, or regulators.
Manage your own risk profile
When analyzing your business, it is then important to look at what is core and key to business functions. Rather than starting with compliance requirements, practitioners must start with the business. How does the business operate? What is most important in keeping the doors open and the paychecks printing? In the vast majority of cases, the answer here will be topics like business processes, access to key data resources, the enablement of collaboration and communication, and other non-security, non-compliance areas.
Why, then, do so many businesses spend significant resources chasing externally applied requirements?
Now is the time to get a handle on your organization's own risk profile. Start by understanding what is vital to ensuring the continuation of business operations. Once you understand the fundamental resource picture (i.e., people, processes, and technology), then -- and only then -- should you start considering how compliance directives apply to your organization.
Get organized
As soon as you start digging into the resource picture, you may start feeling overwhelmed by all the work that needs to be done to help ensure the survival of the business. Start with getting organized, and only leverage tools where appropriate and useful.
It is important to understand what problems need to be solved before looking for technical solutions, and just where you can gain efficiencies from automation. This means starting with a reasonably coherent and complete governance, risk management, and compliance management (GRC) program before considering a major technology purchase.
Building a GRC program starts with three key steps. First, you need to collaborate with business leaders across multiple areas (including legal, HR, and executive leadership) to articulate a prime strategy for ensuring business survivability. This first step will include gaining a solid understanding of how the business operates and what sorts of capabilities underpin its continued survival.
Second, formalize methods and policies. This step includes relegating security responsibilities to operational teams, gathering up only those security-related duties that truly make sense in a centralized organization (e.g., incident response, access management, risk management). Formalization relates to defining processes, updating job descriptions to assert security responsibilities for all personnel, conducting better security awareness campaigns and helping ensure proper accountability in light of incidents.
Finally, once the program is established and supported by formal methods and policies, consider how to mature practices. Today, many organizations rely on simple tools like spreadsheets and file servers, which are often adequate during formative stages of development, but which do not scale well.
For example, policy management can be a bit unwieldy using simple tools like a SharePoint server, which provides an opportunity to look for better document and policy management capabilities. Similarly, centralizing access management will inevitably necessitate a need for better identity and access management tools. Along with these functional tools, you may also find it worthwhile to look at tools that relate more to business intelligence functions, such as those that help track risk factors, exceptions, and asset information.
