GRC Spreadsheets, Documents & Email, OH MY!
Why Spreadsheets, Documents & Emails Fail for GRC
At times I can sound like a broken record – repeating myself over, and over, and over, and over again, and again, and again. One of my prominent soapboxes over the past decade has been the failure of spreadsheets, documents, and emails to assess, audit, manage, and monitor governance, risk management, and compliance (GRC) processes.
Yes, I acknowledge that Microsoft is the largest GRC software vendor on the planet with Word, Excel, Outlook/Exchange, and Sharepoint. However, these tools, and their counterparts from Google and others, 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 – by themselves – do not meet par.
In fact, after a decade of screaming and preaching from my GRC soapbox, I hear that the regulators are cracking down. I am in the process of substantiating this, but I have heard from a few sources that the U.S. financial services regulators are now stating that using documents and spreadsheets for audits and risk/compliance assessments (by themselves without additional tools to enhance them) are not acceptable.
The reasons documents, spreadsheets, and emails fail for GRC are as follows:
- No audit trail. By themselves, without some additional tools/solutions and significant configuration, these solutions 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. Building on the first point, there is no audit trail or history of changes made. 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 can be configured in email systems, but most often people fire off 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 Excel 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 documents and 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 documents, spreadsheets, and emails? If you are a GRC professional the odds are you have. I have had one financial services organization tell me in an RFP project (I was writing the RFP for them) that 80% of their GRC resources (FTEs) were nothing more than document reconcilers. In surveys and webinar pulls you find that it often takes 80+ man-hours to compile GRC (risk/compliance/audit) reports. There is a significant amount of time needed to integrate and compile information from a mountain of documents, spreadsheets, and emails. 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 documents, spreadsheets and emails 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. In fact, one of the primary contributing factors to the multi-billion dollar JP Morgan Whale loss was an error in a spreadsheet.
Those are my primary reasons why documents, spreadsheets and emails by themselves fail in GRC. There are ways to fix this. Solutions that provide and enforce consistency and audit trails within spreadsheets, but these do not account for workflow and task management needs. The best approach to address these limitations is to implement GRC management solutions that provide for audit trails, consistency, and integrated reporting. Solutions that bring efficiency (both human and financial capital efficiency), effectiveness (accurate and auditable reporting), and agility (timely and relevant information when it is needed).
What are your thoughts and experiences with spreadsheets, documents and emails in GRC processes and reporting?