Compliance Does Not Have to Be a Four-Letter Word

For many CSOs, compliance is a four-letter word. Maintaining and managing distinct regulatory and industry compliance standards creates a drain on already tapped and scarce security resources. Making matters worse, many midsize and small enterprises lack dedicated governance, risk and compliance (GRC) teams to address compliance related concerns, leaving organizations to use ad hoc approaches that are inefficient and do not benefit the organization’s overall security posture.

There is a brighter side to compliance, and it all comes down to strategy. At the highest level, compliance is often perceived as a “checkbox” function that is addressed as its own integrated and distinct functional requirement. However, leveraging compliance as a foundational element to drive the development and maturity of a strong security program integrates both activities into a single initiative which provides ongoing benefits to operations and the overall security profile of the organization.

Through the strategic lens, compliance becomes part of a larger risk framework. A best practice is to map compliance requirements to a common security framework, such as NIST. Another option is to leverage a third party risk assessment service such as FireEye Security Program Assessment to see where compliance requirements can be identified as part of a larger security framework. This ensures that the efforts applied to addressing compliance requirements are also leveraged to the benefit of the organization’s broader security initiatives.  

When compliance is a component of a larger framework, many of the compliance “checkbox” requirements roll up into a larger risk discussion.

For example, one of the PCI DSS requirements is to segment networks so that cardholder data environments are sectioned off from other segments. Knowing this, the question to ask is not “how to segment the network for PCI compliance”, but instead, “how are risks reduced in our organization by using network segmentation?” In this case, by not limiting a control to just a specific implementation that only addresses PCI compliance, the organization can benefit from applying a control in the broader context of security. This reduces the overall complexity and amount of effort required to maintain compliance.

Even when a security framework maps to a compliance requirement, obstacles can remain. For example, many organizations name vulnerability management as one of the biggest challenges to maintaining compliance – specifically how to prioritize what patches are needed and when. However, when viewed as part of a larger framework, vulnerability management becomes part of the overall security program, instead of being limited to a separate effort that is focused on just the components within the realm of compliance. In this example, vulnerability management becomes part of the framework for security.

Compliance is an ongoing process, where risk management and compliance teams are the leaders. A typical compliance program will need a year to go from launch to operation. During that time, updates will be made to the program. Team members should discover areas that need remediation and new risks will be identified. Over time, these modifications will enhance and improve the organization’s security maturity profile.

Schedule audits and reports to the executive staff. They need to know how risks and compliance controls map up to a larger security framework. As for the board, focus the discussion around risks, making compliance a part of that discussion.

With compliance, there is no magic bullet. Instead, map compliance to a larger framework and do risk assessments on a regular basis. By doing so, you will find that compliance really isn’t a four-letter word.