![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Data Protection Homepage |
|
|
![]() |
![]() |
|
![]() |
![]() |
Purpose of Compliance Audits (print ref: Part 2, Section 1.2)The purpose of the Compliance Audit is to check that the organisation is in fact operating in accordance with its documented Policies, Codes of Practice, Guidelines and Procedures. It is the most important part of an audit and has to be conducted on-site. An obvious question raised by Figure 2.1 is why an Internal Audit only involves a Compliance Audit? The reasons for this are that the following assumptions are made:
Therefore, it is normal practice for Internal Audits not to include an Adequacy Audit. There is of course no reason why organisations cannot conduct Adequacy Audits as part of their Internal Audit programmes should they so wish, and in fact this might prove quite beneficial for new systems where outside help has not been involved. Compliance Audit (print ref: Part 2, Section 3) There are two basic methodologies that are commonly used for conducting Compliance Audits and these can either be used separately or in combination on each audit. Functional or Vertical Audit (print ref: Part 2, Section 3.1) This type of audit involves checking all aspects of the data protection system within a particular area, function or department. A Functional Audit concentrates on processes, procedures and records restricted to the department itself and does not cross inter-departmental boundaries. It is recommended that Auditors question data protection staff during Functional Audits because they should be most familiar with how departmental systems implement the organisation's overall data protection policies. A typical example of when it would be appropriate to conduct a Functional Audit would be where it was required to assess the compliance of a Human Resources department. In this case most of the procedures, personnel files etc. associated with the Human Resources function are likely to reside wholly within the department itself. The Functional Audit could then restrict itself to checking all the activities involving the gathering and processing of personal data within the department. The way that such a Functional Audit would be undertaken is illustrated graphically in Figure 2.2 which represents the structure of a typical organisation as being divided into separate, vertical, functional departments. It shows how the Functional Audit would only affect the Human Resources department but would also have to examine the Data Protection Policy, Organisational Resources and Records that directly relate to the Human Resources function. ![]() Fig. 2.2: Functional or Vertical Audit Process or Horizontal Audit (print ref: Part 2, Section 3.2) This type of audit involves tracking a particular process from one end to the other. A Process Audit will cross a number of interfaces between areas, functions or departments. It is the key to understanding how an organisation functions and is best conducted with front-line, operational staff. A typical example of when it would be appropriate to conduct a Process Audit would be where it was required to assess the processing of Data Subject Access Requests. In this case the processing of these requests is likely to involve the co-operation of a number of different departments within the organisation. The Process Audit would follow the progress of the Subject Access Request as it was processed by the various departments and staff involved. Another example could be the process for approving a new application form that involved the collection of personal data. The form could typically originate with the Marketing Department, but might need to be checked by Sales, Operations, Finance, Legal and IT and should certainly require some form of data protection sign off. The way that such a Process Audit would be undertaken is illustrated graphically in Figure 2.3, which shows how processes like Subject Access Requests may cut horizontally across many different inter-departmental boundaries. Section 3.3.2 of Part 3 describes how the Auditor has the choice of either starting at the beginning of a process and tracing forward, or starting at the end and tracing backwards. ![]() Fig. 2.3: Process or Horizontal Audit |
|
![]() |
![]() |