There are several compliance frameworks these days that organizations have to implement for different reasons. I still see many organizations that struggle with all these frameworks. Each framework usually has an impressive set of objectives and controls.
Does an organization have to process credit card information? There are PCI DSS requirements to implement for the cardholder data environment. Does an organization offer cloud services? Their clients are probably asking for a SOC 2 report. Financial audit? More IT controls related to financial systems. Or even, if it’s a publicly traded company, Sarbanes-Oxley (SOX). And, so on.
However, organizations often manage each framework independently. This situation results in a duplication of multiple similar objectives and controls. And, some auditors, external or internal, will request almost the same evidence to the same employees a few times a year. When the same employee has to retrieve the same users' list, from the same application, for the 5th times, it could definitely be a situation a little bit frustrating.
Unfortunately, most employees are not seeing audits as necessarily a good thing for the organization. For them, it’s often a mandatory regulation and, as a burden, there is an annual audit. Employees will often have to do overtime in order to provide evidence to auditors while also doing their usual daily work. It’s possible to point out the lack of structure and planning, even more, when the same auditors request the same evidence many times. This redundant situation doesn’t help to keep a good relationship between employees and auditors. I would be the first one to be frustrating, and I have been in both positions. It’s important to engage employees by explaining the thinking behind some controls and evidence.
The main problem here is the different frameworks, with each one, specific objectives, and controls. For example, 3 controls and/or objectives from 3 different frameworks related to new logical access :
- ISO/IEC 27001 Control 9.2.2: A formal user access provisioning process shall be implemented to assign or revoke access rights for all user types to all systems and services.
- PCI DSS Control 7.1.4: Require documented approval by authorized parties specifying required privileges.
- SOC 2 (TSC) Objective CC6.2: Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.
The wording is obviously different but the meaning is similar: an organization must implement a process for provisioning new logical access. What if an organization could have a common framework with controls mapped to various other frameworks? In the end, these frameworks simply force an organization to put in place good internal controls related to IT systems. Large organizations are trying to do that with different existing frameworks e.g. COSO. Or even, by creating a custom framework from scratch. It could also be a custom framework provided by the company’s GRC solution which could offer some kind of mapping with existing frameworks.
But, one organization did it, really well, and even open-sourced the framework: Adobe. It would have been the last organization I though would provide something like that. But, thanks to them, it’s possible to save so much time. It is the Common Controls Framework (CCF), first mentioned in October 2015 but open-sourced in October 2018. This framework is currently mapped with 8 frameworks: ISO/IEC 27001, AICPA Trust Service Criteria - Common Criteria, AICPA Trust Service Criteria - Availability, FedRAMP Tailored baseline, PCI DSS, as well as the security requirements of GLBA, FERPA, and HIPAA Security. There are more than 200 controls mapped to these frameworks. To continue with the previous example, there is the following control: “Logical access provisioning to information systems requires approval from appropriate personnel.” It’s enough to mention the requirement for a provisioning user process.
The number of required controls would, of course, depend on the required frameworks for which an organization needs to be compliant. However, an organization should not implement these controls blindly. Some controls could not apply to an organization. Maybe a different structure, a different company size, or a different environment. Some controls are just not practical for a small business. But it’s definitely a good start for anyone responsible for implementing internal control. It’s possible to customize these controls to be more tailored to an organization. Or, even add more controls that would be specific to the business field.
Also, the scope of each framework could be different. For example, the scope related to PCI DSS, and SOC 2, could have different implicated IT systems. Sometimes it’s not possible to streamline all processes. Some employees would still need to provide evidence a few times a year according to the audit scope. But, if the sysadmin doesn’t have to provide the same screenshot for the backup schedule multiple times, it’s already a good move.