Compliance Roles in the Enterprise

BY JUSTIN ARBUCKLE

This is the second in a series that describes the compliance landscape. The first article can be found here.

This article describes the functional roles involved in compliance and how the organizational structure surrounding these roles affects how we implement compliance.

Compliance officers ensure the legitimacy of a company’s operations within the broader ecosystem of rules in the industry and economy. In many cases the compliance officer is personally at risk should s/he be found to have been negligent in ensuring compliance with certain regulations. A recent example is here.

Compliance officers are also responsible for the controls and processes that guarantee that others are doing their part to ensure that policy implementation is effective.

Internal auditors ensure that these controls and processes are implemented and followed. Internal audits are primarily concerned with ensuring repeatable compliance with procedure rather than finding and remediating specific failures.

There are also roles for IT audit and IT security. These two roles focus on information systems rather than procedures and processes. Information technology audits evaluate an organization’s ability to protect its information assets and to properly dispense information to authorized parties. For example, an IT audit evaluates if an organization’s computer systems will be available when required, and if the information in the systems is only disclosed to authorized users.

IT security involves many different activities. For example, a penetration tester actively looks for vulnerabilities in target systems, networks and applications.

Here’s how the primary compliance roles in an organization relate to one another:

In the diagram there is a single output for each role; the roles are not cross-connected. While there will always be informal relationships, in reality it is rare for a regulatory compliance finding to be communicated by a compliance officer (often reporting to either the CEO or CFO) directly to a CISO. The path from implementation of a security policy back to the compliance officer is a long one.

This lengthy path illustrates why it is so difficult to separate the outcome required by regulators from the implementation. As we move further away from the sometimes abstract expression of regulatory intent and towards concrete system implementation, the domain knowledge of practitioners becomes an implicit part of the regulatory interpretation that is passed along the path. Domain knowledge can come from accepted practices in an industry such as financial services, or it can come from areas such as IT and marketing within an organization. No matter what the source, domain-specific interpretation is necessary to map high-level outcomes to concrete requirements that are meaningful for each role to implement. We can call this the interpretation problem.

What starts out as a discussion of how to support a specific policy turns very quickly into a discussion of how to select an implementation that satisfies the constraints of every role along the path from regulatory intent to compliance implementation. The greater the number of steps in the process of translation of a regulation into an organizational policy, the less reliable the implementation of the rule becomes. This is why, in most organizations, compliance requirements are like photocopies of photocopies. The images may be discernible, but their boundaries are fuzzy.

Processes and systems

What is the relationship between the ‘process’ side and the ‘system’ side of the compliance pathway? Recall that the process side includes compliance officers and internal audit while the system side consists of IT audit and IT security.

There is a very real separation between the core business view of regulation and the IT department’s view of how to implement it. These differing views arise from an inadequate understanding of how the regulation or policy impacts infrastructure and a lack of a formal language that can translate outcomes into implementable tasks.

The long feedback path also means that errors or improvements in the implementation take a long time to get back to the compliance and audit staff (who may lobby a regulator). Organizations try to compensate by adopting programs that attempt ‘full’ or ‘deep’ compliance with a regulation rather than smaller, incremental improvements over time.

So what does this all mean for a hapless technologist? Discussions of possible implementation approaches are stifled by the reluctance of auditors to separate the desired outcome from the implementations that have been used in the past. In many companies, once an implementation approach has been adopted, it is almost impossible to rework it. Unfortunately, with increasingly complex and ambiguous legislation the chances of getting an implementation right the first time is almost zero, especially considering the many organizational issues associated with driving change in a large enterprise.

Still, there is a great deal that technology professionals, who are on the ‘system’ side, can learn from the ‘process’ side of the house. Often, as technologists faced with a compliance requirement, we tend to think of the instance we are working on, rather than thinking about how to produce a replicable process for implementing the requirement in other situations.

Once we begin writing code or building images, the compliance problem is only solved within a narrowly defined scope. One example is a standard image build for an OS. In many cases, the base image is the lowest common denominator. All of the ‘interesting’ customization occurs once the application is deployed. Crystalizing the build process into repeatable and reusable libraries is difficult without automation. Automation for compliance is the subject of a subsequent article in this series.

In the next article in this series we’ll describe the increasing importance of best practices and industry norms in compliance, as regulators increasingly defer details to domain-specific bodies or councils.