Cybersecurity Governance, Risk and Compliance

In a recent LinkedIn poll, I asked for the main use cases that lead to the implementation of a specialized GRC tool, the two most voted use cases were the creation of a “Risk Register” and a “Controls Library” (see image below). The latter, came in with a comment around the progression from a spreadsheet-based controls library to a GRC tool when evidence collection, automation and other processes get implemented.

Today, I would like to share my thoughts on what I believe are the main reasons to build and track a centralized control library from a GRC perspective, whether that is in spreadsheets or in a top notch GRC tool.

My first experience with control libraries came when I performed IT audits to comply with regulations such as SOX, SOC II, etc., the main objective from an external auditor perspective was simple, identify and document those controls that met regulatory requirements, define clear testing procedures and build processes around those controls to understand changes in the environment. More often than not, the responsibility of building and tracking controls would fall into the hands of a Compliance team or Finance, in very rare situations the Business teams, the actual owners of the processes and controls were leading the charge.

With the complexity of the current Cybersecurity environment, the breadth and depth of the technology available to us, not to mention the number of regulatory requirements and risk mitigation activities, a more holistic and multidisciplinary approach is required to realize the potential of a centralized controls repository, one with continuous vigilance of the applicability, accuracy, validity and “freshness” of these controls at all times.

Without getting into the debate of who should own the control library, I propose that whether it is in spreadsheets or a GRC tool, these libraries should be published internally to the organization, for all stakeholders to have a clear line of sight into which controls are key for protecting the company’s data, to keep all levels of the organization informed, ensuring control owners are accountable for the accuracy, applicability and effectiveness of these controls.

The actual repository of controls should not be a limiting factor to ensure the whole company rallies around Cybersecurity and data protection, from my perspective we should move away from calling them “SOX controls” or “PCI controls”, we should refer to them as “Cybersecurity controls” that protect the company’s data and secure its infrastructure, which are leveraged by various teams to meet SOX, PCI and any other compliance requirements.

Please share challenges and benefits you have encountered when creating and maintaining a Cybersecurity controls library, who do you think should be the key participants and their roles in this process? This is an open forum for all of us to learn and share ideas that can move our GRC community forward.

Want more…