Inevitability of Failure: Flawed Use of Spreadsheets in GRC
Spreadsheets, and their associates documents and emails, are the most prevalent GRC tool used by organizations. Their use comes at a significant cost if not controlled, monitored, and used properly.
In my research, organizations utilize spreadsheets for a variety of purposes. They are used to:
- Conduct risk, compliance, and control surveys, questionnaires, and assessments
- Inventory policies and manage related tasks
- Conduct investigations and remediate issues
- Document and assess controls
- Model and assess risk and finance
- Report on finance or GRC
- Manage the financial close process
I am simply scratching the surface, the use of spreadsheets is pervasive in GRC and business processes. In GRC strategies I am continuously told that the primary reason the organization is looking to improve GRC related areas is to get away from the negative impact the use of spreadsheets has on GRC.
One organization in which I wrote their GRC RFP told me that 80% of their risk, compliance, control, audit, and security FTE resource time was nothing more than spreadsheet reconcilers. They were swamped trying to reconcile and report on thousands of spreadsheets and at the end of the day found the reports filled with errors from manual reconciliation. They wanted this to flip so that 80% of their staff time was managing and improving GRC and only 20% on reconciliation and reporting.
Organizations are facing increased regulatory and audit pressures to ensure that they have adequate controls over end user computing controls, particularly spreadsheets. This is very apparent when spreadsheets are used as part of accounting processes. The Public Company Accounting Oversight Board (PCAOB) has requested auditors to increase their focus on ‘System Generated Data and Reports’ driving the application of so-called ‘enhanced audits’ of Sarbanes Oxley (SOX) control processes. This scrutiny is leading to new SOX failings for companies that had previously had no such failings. In particular these enhanced audits are exposing the role of spreadsheets in context of Internal Control over Financial Reporting (ICFR) and the fact that such spreadsheet controls are often open to manual manipulation.
One mid-sized bank that GRC 20/20 has interviewed stated that one of their regulators told them that the use of spreadsheets for compliance, risk, and control assessments was inadequate as they did not provide the right audit trails and integrity of what was assessed, who assessed it, and control any modifications to the assessment. Anyone could come back and paint a different picture, cover up a trail, and get themselves or the organization out of trouble. They demanded that the organization have a full audit trail of assessment activity.
Or consider the JP Morgan’s London Whale incident with its associated $6 billion loss. The significant contributing factor was a spreadsheet error in the models used. Consider this excerpt from page 124 of the report:
During the review process, additional operational issues became apparent. For example, the model operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another… in a January 23, 2012 e-mail to the modeler, the trader to whom the modeler reported wrote that he should “keep the pressure on our friends in Model Validation and [Quantitative Research].” There is some evidence the Model Review Group accelerated its review as a result of this pressure, and in so doing it may have been more willing to overlook the operational flaws apparent during the approval process.
As a result, regulators have been cracking down on how organizations govern models and manage model risk.
Spreadsheets, left uncontrolled, make for ineffective, inefficient, and unagile GRC processes and have some serious integrity issues that violate principles of GRC. They are very useful tools. I use them everyday in my business, but for managing GRC information they – left to themselves – do not meet par.
The reasons spreadsheets fail for GRC are as follows:
- No audit trail. By themselves, without some additional tools/solutions and significant configuration, spreadsheets do not have inherent audit trails. You cannot go back and state that you know with a specific level of certainty that those answers were gathered from that specific individual on this date and time and represent their actual, unaltered, authenticated answer to that survey, assessment, analysis, policy attestation or audit.
- Easy to manipulate. It is a simple task for anybody to go back and manipulate responses to paint a rosier picture to get himself or herself, someone else, or the organization out of hot water. Someone can easily go back and cover their trail when there is no audit trail and authentication happening that tracks changes, what those changes were, who made them, and keeps a record of all changes.
- Slipping through the cracks. There is no structure of required workflow and task management. Things quickly become impossible to manage in spreadsheets and emails asking for assessments to be done, audit findings to be responded to, policy attestations to be made . . . and no one gets it done. It ends up in the trash, junk folder, filed away, and never responded to until someone is screaming.
- No consistency. It is hard to make assessments, surveys, attestations, policies and other GRC related information consistent. If a new assessment is needed – we just open up a spreadsheet and create a new assessment from scratch and fail to realize that there is another assessment asking the same people half of the same questions as our new assessment. Further, different spreadsheets are formatted in different ways and each requires its own learning curve.
- Compilation nightmares. Have you ever been asked to compile reports involving hundreds or even thousands of spreadsheets? If you are a GRC professional the odds are you have. My research and interviews with organizations find that it often takes 80+ man-hours to compile GRC (risk/compliance/audit) reports from mountains of spreadsheets. There is a significant amount of time needed to integrate and compile information. Myself, I would not be interested in a job very long where 80% of my time is cut, paste, manipulate data for reports. My interest is in analysis and managing risk and compliance not in cut and paste – that is what I did in kindergarten.
- Compilation errors. At the end of the day, all this work compiling and integrating hundreds to thousands of spreadsheets is inevitable failure. Odds are there is something wrong. That much manual reporting is bound to have serious errors. Not malicious, but inadvertent. It happens all the time.
This is why spreadsheets by themselves fail in GRC. There are ways to fix this. Solutions that provide and enforce consistency and audit trails within spreadsheets. Organizations need a stronger GRC architecture that brings efficiency (both human and financial capital efficiency), effectiveness (accurate and auditable reporting), and agility (timely and relevant information when it is needed) to GRC. Spreadsheets left uncontrolled work against this not for it.
What are your thoughts and experiences with spreadsheets in GRC processes and reporting?
If you are dealing with spreadsheets in context of internal controls over financial reporting (ICFR), SOX and PCAOB pressures on end-user computing controls, please take the GRC 20/20 research survey and find out how your concerns and approach compare with your peers . . .
[button link=”http://www.surveygizmo.com/s3/2448771/Spreadsheet-Controls”]Take Survey[/button]