Information management

Audit

An audit is a systematic, independent examination of an organisation’s processes, systems and data to determine whether activities involving the processing, use and sharing of the data are being carried out in accordance with the Data Protection Act 1998 (DPA).

The chief officer in each force is its data controller. The data controller is required to ensure that all data held on police systems is used lawfully by enforcing data protection policies, procedures and the DPA processing requirements.

The data controller must comply with the data protection principles, subject to exemptions, in relation to all personal and sensitive personal data. This is ensured by auditing, monitoring and self-inspection.

Roles and responsibilities

Data controller

The data controller determines the purposes for which, and how, any data are, or are to be, processed. The chief officer is the data controller for the force. For further information on the role of the data controller click here.

Senior information risk officer

The senior information risk officer (SIRO) is responsible for approving the strategic audit programme and has responsibility for the compliance audit process within a force. In some forces the SIRO is responsible for approving the draft audit report and recommendations, and authorising their dissemination with the action plan.

As the force risk owner, the SIRO should be made aware of any audit recommendations and the action plan implemented to address them, to ensure that any risk has been mitigated. The SIRO closes the audit report when all actions are completed.

Where the SIRO is not responsible for a compliance audit, this responsibility may be delegated. The SIRO should, however, always be made aware of any issues arising from the audit that pose a risk to the force.

Information asset owner/senior system owner

The information asset owner/senior system owner (IAO/SSO) is responsible for a system and the data which supports the business function of that system (eg, a crime recording system). The owners should ensure that the system is managed in compliance with relevant legislation, specifically the data protection principles.

The owner has responsibility for ensuring that only people who have an identified business need to access the system in order to carry out their current role are permitted to do so. They must ensure that access is withdrawn when it is no longer required. These responsibilities may be delegated to other supervisors. The system owner should ensure that:

  • information is collated, processed and used fairly and lawfully
  • any information sharing and disclosure is in accordance with legislation and where necessary is covered by information sharing agreements (ISAs)
  • appropriate physical and technical security is applied to protect the information from loss or unauthorised disclosure
  • any non-police users of the system are covered by a data access agreement, have signed a confidentiality agreement, and have been trained in accordance with relevant force procedures.

The owner should also ensure that:

  • correct access levels to the system are assigned and maintained
  • unlawful access or use of information held on the system is identified
  • information is accurate, relevant and up to date
  • processes are in place to rectify any mistakes and that they are being adhered to
  • appropriate physical and technical security is in place
  • information is being shared lawfully.

The IAO or the SSO is responsible for drawing up an action plan to address the recommendations of an audit. This may be done in consultation with the compliance auditors. They are also responsible for implementing the agreed actions and updating the SIRO and/or information security officer (ISO) so that the audit can be closed.

System administrator

The system administrator assists the IAO by managing the physical access to the system. They should, where possible, introduce validation of fields through use of technical system rules and may undertake regular data quality and/or system monitoring. The system administrator cannot undertake a valid independent audit.

Compliance auditors

Forces must have a sufficient number of auditors to ensure that the baseline requirements for audits are met in order to demonstrate compliance with the DPA and Home Office (2005) Code of Practice for the Management of Police Information.

Compliance auditors may be consulted at the initiation, and during the development, of new systems/applications that process personal data, to ensure audit requirements are addressed. This may be carried out during the consultation required when undertaking a privacy impact assessment (PIA).

The compliance auditor must:

  • receive training in the use of relevant systems to assist in the audit process ‒ where this is not possible because of cost or time constraints, a resource must be allocated to assist the compliance auditor with the audit
  • develop a good understanding of police systems, operational requirements and procedures, and local and national requirements
  • be able to interpret police records
  • be independent to avoid any conflict of interest
  • not be managed by senior staff on the sites they are auditing, as it may be difficult or impossible to ensure total independence.

Where the audit includes information that is being disclosed to, or received from, another agency, the auditor may need to gain a basic understanding of the procedures of the other organisations. The auditor may also be required to carry out site visits to audit other organisations’ use, storage and retention of force data.

Regional and national audit groups

These groups provide support and the opportunity to share and discuss good practice and enable skills to be developed. Although primarily for compliance auditors, they can be attended by national crime recording auditors, information management auditors and other force post holders with an interest in auditing.

Each regional audit group may nominate two of their representatives to sit on the national group known as the ACPO national data quality audit group (ANDQAG).

These groups enable audit practitioners to:

  • share good practice and lessons learned
  • work together to develop new audits
  • establish regional standards for recording risk
  • share information about training courses
  • carry out joint audits within and between forces
  • provide feedback to the audit groups
  • have a forum for discussing issues arising from the ANDQAG
  • discuss national audits and changes to legislation.

The minutes of each meeting should be recorded and disseminated as required.

Data quality

Data quality is a measure of data against a defined standard to indicate its suitability for the policing purpose(s) for which it was recorded. It incorporates attributes such as provenance, completeness, accuracy, relevancy, logical consistency and whether the data is current.

Police information is a valuable asset that may be used within the organisation as well as externally by forces, partners and agencies with whom information is lawfully shared. The implementation of national databases and increased information sharing with partner agencies makes a force’s information more accessible. The quality of data must, therefore, be good from the outset.

For information to be an organisational asset, all users of that information must regard it as fit for purpose. Incomplete and/or inaccurate information has implications for the effectiveness and efficiency of the organisation and may result in risk to an individual or the public.

High quality and known quality

High-quality data is data that can be relied on and used for the purpose(s) for which it is held. Forces should have processes in place to ensure that data is of sufficiently high quality. They should aim to achieve high-quality data in critical business areas, particularly in relation to information held about an individual.

Where it is not possible to achieve high-data quality, it is still important to assess the quality of the data in each business area so that the level of its quality is known. Users of the information are then able to treat the data with the appropriate level of caution. A risk assessment should be completed to identify the data sets that are most critical to policing so that they can be prioritised for audit purposes.

The effort required to achieve high-quality data should be based on the likely use of the data and should be proportionate to the risk. Quality data is assured by a process of regular monitoring, the effectiveness of which is then tested during audit. If expectations are too high, the operational process that captures the data is likely to become overly bureaucratic.

Compliance audit

The Chartered Institute of Internal Auditors defines compliance auditing as: ‘the requirement to examine and evaluate defined activities of an organisation to measure adherence to legal, regulatory, contractual and procedural obligations’.

Compliance audits assist forces to measure compliance with:

A data protection compliance audit is defined by the Information Commissioner’s Office as: A systematic and independent examination to determine whether activities involving the processing of personal data are carried out in accordance with the organisation’s data protection policies and procedures, and whether this processing meets the requirements of the DPA.

The benefits of an audit are that it will:

  • provide an independent view of whether the supervision and monitoring practices in place are adequate to ensure a high standard of data quality is achieved and maintained
  • provide an independent view of the adequacy of internal controls such as policies and procedures and whether or not they are being applied
  • identify specific information that is not held or processed in accordance with the DPA
  • ensure the senior information risk owner (SIRO) and information asset owner (IAO) are aware of any risks that may result in potential breaches of legislation or loss of public confidence
  • identify any operational risks in information assets so that these can be brought to the attention of the IAO for appropriate action to be taken
  • ensure that forces maintain high quality, accurate, reliable and timely police information that assists operational practices and results in better use of public money and services
  • reduce the occurrence of inaccurate information being supplied under the subject access provision of the DPA
  • reduce the possibility of litigation arising from inaccurate information
  • provide evidence of audits for external audit and inspection purpose, for example, an inspection by Her Majesty’s Inspectorate of Constabulary (HMIC)
  • assess whether the IAO’s monitoring is effective in ensuring compliance with the data protection principles and that supervisors are effectively monitoring and dip-sampling staff’s work to ensure information is accurate, relevant and up to date
  • identify examples of good practice
  • highlight issues that can be addressed by further training or improved supervision.

During an HMIC inspection, forces may be required to provide:

  • audit reports, including their findings and recommendations
  • action plans detailing how findings and recommendations will be addressed
  • evidence that the SIRO has acknowledged the action plan and that the action plan has been signed off when completed.

Transaction validation is also necessary to monitor the lawful use of personal information held by the police or provided to the police by other agencies.

Monitoring

Monitoring is the day-to-day examination of procedures for access to information and its use. It is a process that is initiated by the IAO with the objective of identifying misuse or errors to ensure that corrective action can be taken. As monitoring is a self-inspection and quality control process, it is undertaken by the relevant business area and is not recognised as an independent audit. It is the IAO’s responsibility to ensure that information held complies with the requirements of the DPA. This includes ensuring that:

  • correct access levels to the system have been assigned and are maintained at all times
  • unlawful access to or use of information held on the system is identified
  • information is accurate, adequate, relevant and up to date
  • the process in place to rectify any mistakes is being adhered to
  • appropriate physical and technical security is in place
  • information is being shared lawfully within and between forces
  • information sharing agreements have been put in place in relation to ongoing sharing with partners and are being complied with
  • data processing agreements are in place, up to date and being adhered to.

This responsibility can be discharged by the IAO to maintain a process of regular monitoring. Monitoring may identify weaknesses in processes and policies as well as highlight issues of training.

A monitoring policy should be publicised within the force. The monitoring policy should be enforced and appropriate action taken where necessary.

Monitoring of record update/creation

Procedures within forces regarding the update and creation of records vary widely. Typical methods include:

  • centralised input by a dedicated data bureau
  • input by control room personnel
  • officer entry – individual input by the case officer.

The level of risk increases as the process is decentralised and carried out by non-specific data input staff. This may result in errors such as in data transcription, misspellings, fields incorrectly completed, or mandatory fields not completed. The degree of monitoring required will, therefore, vary from dip-sampling to 100% checking before the record is added to the database. The IAO is responsible for ensuring that force processes are being adhered to and for providing assurances of this to the SIRO.

Recording of monitoring

A record of the monitoring and any issues identified should be recorded and retained. This enables ongoing errors to be identified so that action can be taken. Monitoring records are also used when undertaking a risk assessment of the system or process and will be referred to by the compliance auditor during the scoping exercise prior to conducting an audit.

Transaction validation

The integrity of a database system depends upon the ability to account for each transaction. The validation process and audit procedures test this capability.

Transaction validation should be carried out on a regular basis. It performs three important functions. It:

  • deters and detects unauthorised access to systems
  • raises staff awareness of operating procedures and adherence to policy requirements
  • ensures all relevant transaction fields are completed to provide an adequate audit trail for retrospective investigations into past transactions.

Method

The validation process must be planned and controlled. Elements of transaction validation can be delegated to local supervisors. Where this takes place, control is maintained by requiring supervisors to record and report results of validation checks. Any missing or unsatisfactory responses should be followed up and escalated as appropriate.

The following areas should be examined when validating transactions:

  • transaction fields – inputs should be examined for quality
  • sufficiency of detail – there should be sufficient detail to be able to trace the enquiry back to the originator
  • legitimacy – the legitimacy of the check should be confirmed by questioning the originator or by checking any references to source documentation.

Forces should be able to carry out the transaction monitoring requirements stipulated in any code of connection or system operating procedures as required by the provider of the system.

The validation of a transaction should be carried out by the:

  • supervisor verifying the reason for the transaction
  • compliance auditor verifying against source information.

Any issues found as a result of the transaction checks should be categorised and recorded. The collation of results enables recurrent issues, issue trends and individuals involved in the errors to be identified, and permits corrective action to be taken.

Sample size – access to data/transaction checks

Forces should ensure that the number of transactions undertaken complies with the relevant systems’ standard operating procedures. These checks must be proportionate to the total number of transactions carried out. It is recommended that the minimum number of transactions checked daily should be commensurate with the total number of transactions carried out.

Self-inspection

A self-inspection is an activity carried out by staff working in the particular area to be examined. For example, an officer working in an intelligence unit where the PNC wanted/arrest files are stored could undertake a self-inspection of those files.

A self-inspection may be required where insufficient, independent audit resources are available to undertake audits identified as high risk. Following the risk assessment process, forces may wish to consider self-inspection as a means of providing some assurance to the data controller of the force’s compliance with the requirements of the data protection principles and other legislation.

The objective of self-inspection is to identify any processes/procedures that are not being followed and to recommend a course of action to rectify the situation. A self-inspection is always carried out under either the indirect supervision of a compliance auditor or an independent observer within the organisation who has an understanding of data protection and the legal responsibilities of the data controller.

The information and/or process which is to undergo a self-inspection is selected in the same way as for a compliance audit. The IAO responsible for the area to be inspected is provided with a self-inspection package and is responsible for nominating an individual to carry out the self-inspection process.

Self-inspection package

The basic contents of the self-inspection package include:

  • guidance on undertaking the self-inspection
  • instructions on documentation relating to the system/process being inspected
  • self-inspection questionnaires
  • an interim report template
  • the previous audit report and action plans.

The compliance auditor should provide guidance and support, and answer any queries raised during the self-inspection.

A PNC-based self-inspection requires the compliance auditor to obtain the relevant information from the PNC Data Centre. Advice on the number of records to be inspected should be sought from a compliance auditor.

The person carrying out the self-inspection should submit the findings to the compliance auditor and the IAO before the final audit report is completed. The content of the final audit report will be agreed between the person undertaking the self-inspection and the compliance auditor.

The IAO may implement the recommendations of the self-inspection and then repeat the inspection to identify whether or not the actions taken have improved the processes and reduced the number of errors identified. These new findings should be recorded and a report sent to the compliance audit team.

All self-inspections should be followed up by a dip-sample audit undertaken by a compliance auditor. This validates the self-inspection and provides assurance to the IAO and the data controller that the action plan implemented as a result of the self-inspection has been applied. The dissemination of the dip-sample results/report will be agreed with the IAO.

Risk assessment

In order to mitigate the organisation’s risks from the personal information it processes, the data controller should establish the level of threat each set of information poses, the subsequent action to be taken, and the processes that need to be implemented to prevent further issues arising from the use of the information. Risks can be mitigated by introducing actions to reduce the risk, supported by a robust audit regime.

Risk assessment process

Each system holding personal information should be risk assessed and prioritised to identify the level of risk that the systems pose to the force. For example, the more serious risks are the potential failure to protect children and vulnerable adults.

The recommended risk assessment process is based on the likelihood of an event occurring, scored against the impact that such an event would have on a number of factors. See risk assessment score form.

There are 13 impact factors:

  • Importance of operational information – how important is the information in relation to operations both locally and nationally, and how does the information affect core business activities?
  • Inaccurate information – the level of impact inaccurate information would have on both a local and national level.
  • Record amendment – how often is the record updated? The more frequent the update, the more potential for error.
  • System enhancement/new system – has the system changed since the last audit and how have the changes affected the system’s integrity?
  • Legislation/guidance/procedures – has any new legislation/guidance/procedure been introduced since the last audit or is any due to be implemented? What impact will the change(s) have on the system?
  • Past audit/monitoring/self-inspection results – what was the error rate? Has it improved or not over time? Obtain the IAO’s view on the likely impact given the level and type of errors identified.
  • Information classification – the level of information classification on the system is determined in conjunction with the information’s impact on both a local and national level.
  • Disclosure/information sharing – how frequently is information disclosed to third parties and has the force recently been criticised for any such disclosure?
  • Impact upon the data subject – the level of impact and distress the information would have on the data subject.
  • Information retention and weeding rules – are there any weeding rules in place and are they adhered to?
  • Number of users – the percentage of personnel who have access to the system. The smaller the number of users, the lower the chance for errors.
  • Location of users – between how many locations are the users split? The more locations with access to the system, the less secure the data becomes.
  • Data relating to children or vulnerable adults – are children or vulnerable adults the focus of the data and have there previously been any failings in data quality?
Completion of the risk assessment

A risk assessment does not have to be completed by the compliance auditor, however, there are advantages in the auditor’s involvement. It provides them with the opportunity to:

  • discuss the role of audit and the responsibilities surrounding the ownership of a system when the risk assessment is carried out in consultation with the business owner and/or the IAO
  • emphasise the need for action to be taken to ensure any recommendations identified during audit are acted on
  • emphasise the need for the IAO to appreciate the importance of their role to ensure the data controller is complying with the legal requirements of the DPA, Home Office (2005) Code of Practice for the Management of Information and any other relevant legislation
  • discuss how the audit process can improve investigations and performance
  • take into account the implications of the initial PIA.
Risk assessment outcome

The results of the risk assessments identify the high-risk systems and assist in the preparation of an appropriate audit plan.

A benchmark should be set so that any system assessed over a certain score is audited and placed in the audit plan for attention during the ensuing 12 months. The order in which the audits take place depends on a number of issues:

  • the risk assessment score or risk level identified
  • the ability of the auditor to access the particular data (system access being granted/training required)
  • the availability of the administrator if third-party assistance to access data is required
  • the resources available to carry out the audit task.

The SIRO may determine that information or systems with a very high score should be audited as a matter of urgency.

Audit programme (plan)

On completion of the risk assessments, details of the audits to be carried out are included in an audit programme (plan). Forces vary on the time period covered by the audit plan. This plan is a timetable of audits to be undertaken.

The audit progamme (plan) should be submitted to the ACPO officer with responsibility for compliance audit for their written approval, and should also be brought to the attention of the SIRO (if not the same officer). Amendments to the audit programme (plan) must be similarly approved and documented.

If a force has insufficient resources available to carry out all of the high-risk audits that appear in the audit programme (plan), this should be brought to the attention of the SIRO, who should add this information to the force risk register.

Practical audit phase

The audit plan shows which audits have to be undertaken and when they are due. There are four phases to each audit. These are:

Planning the audit

This includes:

  • communicating with the business owner
  • setting terms of reference
  • acquiring an understanding of the relevant policies, procedures and guidance documents
  • obtaining access to relevant systems and any necessary training through the system administrator on the authorisation of the IAO
  • determining error classifications (major/intermediate/minor)
  • determining a sample size for the audit
  • creating an audit documentation sheet to record the findings, including data to identify the record, error code and any comments to justify errors recorded
  • liaising with the head of professional standards to identify any issues (where appropriate).
Communication with the business owner

Details of the specific records to be audited should not be disclosed before the audit begins. The business owner should, however, be made aware of the audit and request that a member of their staff is nominated as liaison officer. The business owner should be informed of the length of the audit and any specific assistance required from their staff.

Discussion with the business owner provides the auditor with the opportunity to acquire an understanding of the system and/or process, the information held, its use and any relevant legislation governing that use.

Auditors should obtain:

  • policies – usually written in force by the business owner, but may be national policies
  • procedures – usually written in force to give specific guidance on the practical use of the information
  • rules – usually written in force providing information on specific rules appertaining to the system or the data
  • guidance – usually written in force, but could have been issued nationally
  • system operating procedures – detailed information about how the whole system should be operated on a day-to-day basis
  • codes of connection – usually detail how a system is to be used, access controls, dissemination of information. These are usually produced by external business/system owners.

Auditors should consider compiling a questionnaire for business owners or key stakeholders to complete, to assist with this phase.

Terms of reference

These should outline the:

  • scope – the extent of the audit
  • aims and the objectives of the audit
  • approach – how it will be undertaken, whether on location or electronically
  • milestones – start, finish, submission of interim report
  • methodology test – having decided on the method of approach, a number of tests should be undertaken to assess whether any modifications are needed.

Resource implications and security issues should be taken into account when choosing the audit method to be used. Site visits should, however, be seen as the ideal.

Process maps

A process map shows the flow of information from start to finish and enables the auditor to fully understand the information management process associated with the system being audited. Process maps should be created if none already exist. The maps and any previous audit reports, monitoring reports and issues identified, provide the auditor with a good understanding of the systems and/or process to be audited and so assist in drawing up the terms of reference.

Testing phase

The following steps should be taken when conducting the audit test:

  1. Select a random sample (see sampling methodology, table one – confidence level (C) 90%, table two – confidence level (C) 95%, chart one – confidence level (C) 90%, chart two – confidence level (C) 95%, random number table – 1000 random numbers).
  2. Apply the toolkit where available (see toolkit).
  3. Collect the evidence (see example data protection audit plan template).
  4. Analyse the findings and identify any errors (see error classification).
  5. Submit any urgent issues/errors to the business owner for immediate correction (see error-recording form).
Supporting/substantiating force records

Forces should have original or supporting/substantiating information to verify the records being audited. The supporting/substantiating information may be in any form that is appropriate to the force. The underlying information is the definitive record of the facts, as it is usually the first record to be updated when any changes occur.

Where paperless systems are used and no originating documentation exists, the associated risks may be mitigated to some extent by ensuring that suitable monitoring controls are incorporated into the record update/creation procedures. The critical factor is the accuracy of the computer record.

All records with information that has the potential to result in the arrest of a person must show a reference on a policing system (eg, the PNC, local intelligence systems) to a supporting/substantiating force record. The supporting/substantiating record must be accessible at all times. The accessibility of these records is tested in the audit procedure by allowing 30 minutes to locate them.

The supporting/substantiating force record for reports without the potential to result in an arrest must be available during normal office hours.

Reporting the audit findings

This includes:

  • collating audit findings
  • compiling a draft audit report
  • arranging a meeting with the appropriate business owner to discuss the findings and audit recommendations
  • a response from the business owner that includes an action plan to address the audit recommendations within the agreed timescales
  • the final report, which should be published and circulated according to force policy.
Post-audit review

The action plan drawn up in response to the audit recommendations should be followed up at a post-audit review or in a subsequent audit. This should include reviewing evidence from any previous action plan and/or conducting a follow-up review.

Retention of audit documentation

HMIC regards the following as the minimum amount of documentation that should be retained for potential examination by external audit:

  • annual/strategic audit plans, including the supporting risk analysis
  • audit plans and audit control sheets (for individual audits)
  • schedules showing summary detail of audit/monitoring work carried out
  • detailed working papers supporting the audit conclusions
  • copies of audit reports
  • executive board/management responses to audit reports.

It is not necessary to retain detailed documentation relating to all audit/monitoring tests carried out on all tested items. Evidence of items that are checked and found to be correct may be documented in summary form, for example, a schedule/matrix of items tested with test results, or similar.

Audit documentation must be retained in accordance with local and/or the national retention schedule.

Page last accessed 28 June 2017