Convincing people of the importance of data protection

Some people take some convincing as to the importance of data protection. Here are some impact on individuals that could result from data protection breaches:

• Fraud/financial loss
• Identity theft (resulting in financial loss, but potentially other issues)
• Loss of personal privacy
• Persecution (by employer/government/companies/other organisations)
• Damage to relationships with friends/family

For example, your employer might discriminate you if they found out you were a member of an extreme political party (e.g. far right) or a activist group that is often at odds with the employer (e.g. an Oil & Gas company finding out one of its employees is a signed-up member of GreenPeace).

Explanation

Most good controls are about written explanations:

• Comparative Review of Outturn - explanations of variance
• Journals - explanation of the journal
• Reconciliations - explanations of the reconciling items
• Process documents - explanations of the process

Meeting minutes

Often the biggest challenge of audit is gathering the necessary information and gaining the necessary understanding. Meetings are a good source of this, but it's often hard to note down all the relevant information (speed of handwriting). One thing I have found that makes it easier is to prepare a set of slides for the meeting, to print these out, and then to annotate during the meeting. Then I dont' have to write some of the heading type information to support the notes.

Auditing an organisation's policies and policy framework

In my experience, I have seen an organisation's policies in two forms: standalone documents (in Word, PDF  or [rarely] Excel format); or on the intranet as inter-linked documents. There are advantages to both: the former is more portable and archivable; the latter allows an understanding of the interrelationships between policy. On balance, I would prefer the latter, particularly where there is a robust mechanism to create a portable offline copy using website downloading tools (if these are permitted by your organisation's IT team!).

Some criteria for assessing policies and the policy framework:

• Is it complete? Does it cover every eventuality?
• Is is up-to-date? All policy documents should note a last review date.
• Is there ownership in place? All policy documents should note an owner (which should be up-to-date)
• Are archived copies kept when (major) changes are made?
• Does the policy comply with the relevant legislation?
• Is the policy strong enough to address the risk?
• Is the policy understandable? Is there only one possible interpretation?
• Are all hyperlinks current?

Interrelationships between preventive, corrective, directive and detective controls

Both detective and corrective controls are preventive in the sense that they can enable the prevention further events or the continuation of the detected event. For example, a control that detects fraud by an employee will prevent further frauds by that employee and will reduce the likelihood of fraud by other employees through deterrence.

Directive controls (i.e. policy and procedures) support controls at all stages.

It may be helpful to visualise the action of different controls on a timeline:

[Definition of corrective controls: act to reduce the impact of a detected event]

Not one, but two definitions of risk

I think two definitions of risk are necessary to successfully explain risk management:

a risk - countable abstract noun - an event, occurence, circumstance, situation or outcome that may occur and would impact on the achievement of objectives (either positively or negatively)

risk - uncountable abstract noun - the likelihood and impact of an event, occurrence, circumstance, situation or outcome. In some cases the word may be used to refer to just the likelihood e.g. "what is the risk of dying in plane crash?" (the impact is defined, therefore the risk reflects the likelihood) or just the impact "what is the risk associated with touching this wire?" (the probability is ignored and therefore risk reflects just the impact.

Adding risk management to job descriptions

In addition to cooperating with audit, risk management should be included in the job descriptions of all people of manager grade and above (and possibly for all employees for some organisations). The responsibilities should include risk identification and reporting upwards, and developing/maintaining control response (where this has been assigned to the person).

Strategy audit

I've not seen much in the way of strategy audit, but it seems an interesting area (particularly for the auditor). Perhaps the reason that it is not subject to frequent audit is that it tends to be the domain of senior management, that don't want audit sniffing around.

Some questions I'd want to ask:

• Is the strategy formation (and update) process documented?
• Is there an up-to-date organisational strategy?
• Has the strategy been communicated to the right people?
• Are all the necessary inputs to strategy formation in place (market information, competitor information, technology information, internal information)? (this would use PESTLE, Porters 5 Forces, 9Ms, etc)
• Are the right people involved in strategy formation? (sales, marketing, finance, risk management, technology, research & development)
• Do the strategy formers have the right qualifications, experience and skill?
• Are there any training requirements? Are these being met?
• Does the strategy flow through from the single-line mission statement to more detailed objectives, and right down to individual performance objectives?
• Is there a feedback loop on performance that allows validation of the strategy?
• Is there a process to accommodate significant events into the strategy?

Single line journal report

Journal auditing can be hard work. Say you have a general ledger dump and you want to identify all journals to cash accounts. That's easy enough, just apply a filter to the account code. But then you've only got one side of the journal. To get both, you need to extract that filtered set of journals, then reapply to the original dataset as a join, matching on the journal identifier.

What would be really useful is a report from the accounting system that gives both sides of the journal entry in one line of the report. One column would should the account code debited, and another the account code credited. Applying filters to each of these columns makes it very easy to see where journals are going.

To get this work, the system would need to force all journals to be two-entry only equal and opposite (rather than those that say debit two accounts and credit one). But having such a rule would be not bad thing, as it would give a granularity of data in the ledger.

Net transaction view

Often, trying to understand what comprises the balance on a GL account can be challenging, particularly where there a lots of journal entries (e.g. reclassifications and reversing journals).

Reclassification and reversing journals should be linked on the system. The user should be able to pick up a line entry (in the case of a reclassification) or a double entry (for reversing journals) and then execute an action (e.g. change the account code or cost centre, or reverse, etc). Such an action should still go through the journal segregation of duty/authorisation process and supporting documentation be retained.

The advantage of a system that links entries on the GL is that it allows a "net transaction view", i.e. only showing where transactions ended up (not how they got there). The full audit trail is there on the system if needed, but the "net transaction view" allows the contents of the ledger to be more easily understood.

Almost certain

Should risk management cover events or outcomes that will almost certainly happen?

The appropriate definition of risk

Unhelpfully, there are lots of different definitions of risk. For example, "a risk" can mean "a potential event". What helps me is thinking about what people mean when they ask the question "what is the risk?": they mean "what is the probability and significance of the outcome". Therefore risk is the probability and level of impact associated with an event.

But should it just be "event"? In some circumstances it may be helpful to think in terms of outcomes, situations and occurrences. For example, having insufficient premises isn't something that fits the definition of an event, but rather a situation.

Working backwards from controls?

Where there are already controls in place, should the risk be added to the risk register?

For example, if an organisation is new to implementing risk management, is it appropriate to track back from the controls in place to ensure all controls and their corresponding risks are on the risk register?

Risk: how low do you go?

How complete does risk management need to be? How low (impact/probability) should you go? At what stage are you just making risk management bureaucratic? How do you evidence the consideration of this long tail without including it in the risk management process?

We think to ourselves "this risk is too low (impact/probability) to include in our risk management". But this undocumented thought is itself risk management.

Is there an opportunity to outsource risk management for low value risks? Such an outsourcing function would, based on business criteria and information provided to it, estimate the relevant low value risks to the business. This document can then be shared with the organisation for sense checking (and possible escalation of some risks into the core risk register).

Organisational responsibility database

Often it is very difficult, particularly in a large organisation, to find out who has responsibility for what. One possible solution would be an organisational responsibility database. All of the responsibilities are defined in the database, and then assigned to a particular person. Another possibility would be to encourage staff to detail their responsibilities on the internal directory (and upload their job descriptions to it).

SOX software

Anyone who enjoys SOX auditing needs their head examined. But SOX auditing can be made much better. One of the areas of weakness in SOX auditing is relying on spreadsheets and other documents that could well have been prepared when asked for rather than at the time. A solution to this problem would be to create a SOX database system that allows a person (preparer) to upload a file, which is then date stamped and locked. Another person edits/reviews that file, another version of which is then date stamped and locked. Such a system would ensure segregation of duty (as long as password sharing doesn't occur) and prove that audit trail existed at the time.