Compliance is all about risk mitigation. Most of the compliance frameworks started as risk mitigation efforts. It’s important that the company knows where its risks are and spend the time and effort to minimize those risks.

It’s also important for a company to know what its risks aren’t. Within many of the compliance frameworks are hundreds of controls, all designed to mitigate specific risks. Depending on the company and the risks associated, some of these controls may not have to be implemented, or there may be compensating controls already in place.  Why reinvent the wheel?

Understanding your risks early in the compliance process helps companies focus the compliance effort on the right areas.
(more…)

Developing and adhering to compliance processes is a maturing process for most companies.  It requires that departments move from ad-hoc to structured and documented processes.

While many auditors would like to see every system within the compliance framework, the key to success is to manage the scope and scale.  For the first year (or phase) of implementation, only include what absolutely has to be included.  Use it as an opportunity to mature your processes and ensure all the compliance requirements are being met.  (more…)

When implementing a compliance framework, it’s rare that the project lead takes the time to think deeply about the business goals of the project.  Why would you?  They’re simple – meeting regulatory (or client) compliance requirements.  DUH?!?

While this may be one of the business goals, it should not be the driver and does not provide value to the business.  Having business goals tied to the compliance project can dramatically change its implementation and have it become a value creator for the business.  Like any other major project, ensuring alignment with the company’s strategy and goals is vital for long-term success.  Well thought out goals can be the difference between a compliance project being overhead and becoming a way to implement best practices.

Some standards require documented goals.  ISO 27001 is specific about this. There’s mention of it in COBiT, although may not be considered a key control for SOX.

Example Compliance-Driven Goals

Goal 1:  To meet client and regulatory information security requirements.

Goal 2:  To ensure the correct, timely and secure processing client information.

Both are good goals.  Goal 1 is important, but not necessarily value-creating, as it simply defines why the framework and processes exist.  It’s good to keep this in focus.

Goal 2, while not required, is where the compliance framework can create value.  Instead of being reactive, merely meeting client requirements, the compliance framework can be implemented in such a way that it improves quality and security, actually reducing costs (less failure) and improving business processes.  From this goal, there’s a clear path to focus on reducing errors, improving performance and security.

Coming up with good compliance goals can be a lot of work, but is a very powerful process.  Its one that spans more than just your security team; it reaches and out includes the business’ leadership team, developing stronger buy-in and support to the compliance efforts.

Compliance is a scary word.  Too many of us think compliance is something bureaucratic and overwhelming.  It’s true – most of the time compliance frameworks are implemented poorly – making them burdensome beasts with forms that have to be be filled out, in triplicate using only #2 pencil, and processes that simply don’t make sense.

What is Compliance?

From Wikipedia:

In general, compliance means conforming to a rule, such as a specification, policy, standard or law. Regulatory compliance describes the goal that corporations or public agencies aspire to in their efforts to ensure that personnel are aware of and take steps to comply with relevant laws and regulations.

Due to the increasing number of regulations and need for operational transparency, organizations are increasingly adopting the use of consolidated and harmonized sets of compliance controls. This approach is used to ensure that all necessary governance requirements can be met without the unnecessary duplication of effort and activity from resources. (more…)

I’ve been reviewing help desk products for a client the past couple weeks and it (continues to) surprise me that vendors don’t recognize a difference between asset management and license management.  A couple years ago, when evaluating MSP software, I went through the same frustration (and pulled lots of hair out). 

Most help desk products focus solely on asset management.  They claim they manage software as well, but what they’re really doing is listing what software is installed on a computer, not what’s licensed for the computer. That’s only half of the job.  When it comes time to self-assessment of computers (you should be spot-checking/auditing on a regular basis) or when Microsoft comes a’knocking, you need record of what’s in use (installed) and what you legally own.  (more…)