Lyle introduces the topic of auditing cryptocurrency using his experience in evaluating risk and controls for a number of cryptocurrrency trader platforms.
These are challenging times for all organisations with business environments centered around building services on top of a relatively complex technology. The data involved is intimidating with 10s of millions of transactions, each of which might have multiple custodial ledger entries in the case of trader platforms or might be driven from trading algorithms that move money around markets in split seconds and are themselves as secret as Coca Cola’s recipe.
These challenges have led me to two conclusions with regards to auditing these types of business environments. The first is that for high velocity businesses, culture and project methodology are one and the same and cannot be ignored. The second is that evidence of control operation can sometimes exist as part of the outcome or output of the process and this requires flexibility, creativity and a more data focused and risk indicator focused approach than in a typical process orientated audit.
I’ll focus here on high velocity organisations. So, what does high velocity mean?
Velocity refers to the rate of change. In a high velocity organisation a Project Initiation Document (PID) could be obsolete in as little as a month. Requests for Change (RFCs) to a feature set add time to the process so these are often the first to go. So how do you audit this?
There is no one size fits all model.
However, in my experience well-functioning teams have a clearly shared vision and have clear roles. These should be articulated even if it is at a strategic level. MS Teams Wikis (chat groups), architecture models, and user stories are good sources of evidence.
It’s important to accept that documents are an incidental byproduct of the process. They assist in communication and are not an artefact to demonstrate that someone has done their job. Looking at collaboration tools such as Slack, Jira, Confluence or even Yammer and seeing discussion, challenge and questions is a more valuable indication that the culture is working appropriately than a project document. This is especially the case when the approval workflow and communication tools are integrated (Jira + Confluence is a good example of this.) Seeing approvals with no discussion is often an indication of a team/organisation adopting a new tool but not the way of working.
As the organisation strips away preventative controls to remove barriers to velocity you should see a complementary migration of controls from preventive to detective and corrective.
Detective controls must be automated to handle the volume and there must be a clear maintenance process to ensure that they remain up to date. User stories, test strategy and test cases should detail what a fail looks like and this should be part of the key deliverable.
With a higher risk appetite there must be enhanced corrective controls. Mature organisations launch multiple releases a day, detect anomalies and roll back within seconds. The control environment shifts from preventing outage to accepting it and correcting it as fast as possible.
Looking at the risk indicators or how fast, how often and what types of rollbacks and bugs an organisation is experiencing allows the auditor to see into the black box and still give that assurance.
For those grappling with this area of audit I’d highly recommend visiting http://dearauditor.org/ which reframes the question from the auditee’s perspective.