Since the term governance risk and compliance (GRC), was coined in 2007, much has changed in the world, and even more so in the information technology world including cybersecurity. Back in 2007, GRC was a simple picture that mainly focused on Financial compliance (FTC, FFIEC, SEC, SOX), and HIPAA. At this time, Governance, Risk Management, and Compliance was a good first step to capturing the “devil in the details” if companies were doing what they said they were doing. Here’s their story.
Each organization had different drivers and definitions of what its GRC program must entail. It was likely one or more of these objectives:
- Define access controls and access management in applications
- Define policies that are followed in the management of those applications
- Define the information technology risk in Risk Management
- Meet internal audit management requirements
- Meet external compliance management requirements
Then, this GRC program was applied to critical applications, critical infrastructure, or critical data protection, including customer data. The process to protect these assets was typically based on the following three-phase strategy.
G – Say What We Do
Application Governance is a good practice to capture – by writing it down – what the expectations are for managing who can access critical applications inside of an organization. Back then, defining this strategy was attainable and used the following three-phased, “SMART Goal” project approach that worked like this:
- Define a framework that includes management of, infrastructure, applications, and data protection
- Perform a GAP assessment
- Build a road map of defined systems and deliver necessary governance
The solutions and systems were well defined. And, the framework contained things like a firewall to protect data centers that was managed centrally so the staff in charge could easily identify and protect intruders. And, this protection method aligned perfectly to a auditable process that demonstrated the company was doing what they said they would do, which was protecting the three lines of defence.
R – Define a Risk-Based Approach
Risk Management meant organizations needed to begin to include information technology risks as part of the organization’s overall business risk calculations. Financial systems need to have rigorous testing and defined controls that could be measured, both inside and outside of the applications. The goal was to be able to evaluate the threats and define what the risk was based on any situation, whether an IT systems failure to deliver stock market transactions, or an unintended data entry error that could affect global economic trading.
C – Do What We Say
Compliance meant we could actually show what we said we would complete. At a given point in time we can show evidence that we followed what we said we were going to do, and followed through. We could follow contractual obligations and produce Information Security Policies, Information Technology General Controls (ITGCs), DIsaster Recovery Plans, Business Continuity Plans, and be “compliant” on regulatory requirements – Sarbanes-Oxley (SOx), PCI-DSS, etc. And develop programs to map to SAS70, SSAE16, ISO 27001 certifications.
And all was well. If you had a compliance driver, you could find a solution that met your initial needs. And this is how large organizations – mainly the financial kind – at the time, used GRC to ensure global economies thrived because the banks with the IT systems that processes transactions were protected against fraud, inadvertent mistakes and other potential risks.
Next up in the Modern GRC blogs is what changed – the arrival of the cloud.